Software Engineering in Python
I recently took another Python course from Enthought on Software Engineering. I highly recommend it.
A few weeks ago I took another Python class from Enthought. This one was called Software Engineering in Python. It was quite good. I went to it wanting to understand how to take all the software engineering lessons I had learned in LabVIEW and translate that into Python. I was hoping to learn about all the available tools and maybe even learn some new techniques.
The class was largely discussion with a few exercises interspersed. As part of the class, for each new section there was a question. The instructor had everyone write down their answers and then we went around and shared them and talked about them. Here are my answers.
Q: What is Software Engineering?
A: Software Engineering is the process, theory, and tools around how we design, write, and maintain software. It is about how the work gets done and how we collaborate to solve the end user's problem.
Q: What makes code readable for humans?
A: Written with the audience in mind, Consistency, meaningful names, domain-specific terms, meaningful abstractions ( definitely not too many), managing cognitive load - ie not a too much to keep in working memory at a given time. Good division of responsibility. Low coupling, high cohesion.
Q: Isn't all code self-documenting?
A: No. It can easily tell you what it is doing, but not why. Engineering is about trade offs. Why did you make the trade offs you did? What are those trade offs?
Q: What does refactoring mean to you?
A: Changing the implementation without changing the behavior. This iterative process requires having tests to verify the behavior doesn't change and then taking small steps and running the tests after each step, making sure to leave the code runnable at the end of each step.
Q: How do you monitor code execution?
A: Mostly logging. Logging user interactions. Logging some timing details. Monitor CPU and RAM usage. Perhaps logging that.
Q: How do you currently test your code?
A: I use Test Driven Development. I come up with a list of tests for the feature I want to add. Then I pick one, write the test and then write the code. I know I'm done when the test passes. For existing inherited code I try to get it under test as quickly as possible, usually using some type of approval test. I generally only unit test logic and avoid unit testing GUI code and messaging code. Sometimes I run some approval tests as integration tests. Then I do a handful of manual integration tests and feel good/smoke tests before I release. I also write unit tests when bugs are discovered.
Q: Does your team currently use Code Reviews?
A: I tend to work alone so in general no. I do periodic check ins with the customer and I get feedback on how the system works in a functional sense from that, but that doesn't give me feedback on the quality. For quality I rely on a CI/CD pipeline and running linters. When I have subcontractors working on projects with me, we do informal code reviews and checkin regularly. When possible I prefer pair/ensemble programming to code reviews.
Q: What is your software planning process?
A: I start with doing an Agile Inception Deck. Then I sit with the customer and collect all the features they want and help them prioritize them. As part of the Inception Deck we come up with a general overall architecture. Then we work iteratively. Every week we (myself and the customer) look at the list, prioritize what we want to do this week. We also reevaluate the overall architecture and make sure it is still suiting our needs. Then I write code and deliver a working prototype. The next week the customer delivers feedback on the prototype, and we use that to inform the planning and prioritization for the next iteration.
Q: What is Software Engineering? (again) How has your opinion changed?
A: It's pretty much the same. Maybe added a little more depth.
Q: What part of course was most useful?
A: Generally reinforcing a lot of what I knew. Not a whole lot of new information. A few tidbits. Gave a slight bit more appreciation for waterfall - but not a lot. It was good to learn some of the Python equivalents for tools I use in LabVIEW and finding some new ones. I enjoyed the discussion. Learned some new tools. Gained some new perspective. I liked the fact that it was more discussion than exercises, but I am going to have to go back and look at the links and do the exercises.
