I am currently a software developer on coop that was in an interesting situation today. I cannot say too much, as the things I do are under NDA, but I make Grasshopper 3D (which is a Rhino plugin) components.
Our firm has under three software developers including me. We all specialize in different languages. This project I was working on, I was in charge of creating a piece of software that has a very broad general use. It’s an extension from typical Grasshopper behavior.
With this said, the other developer I worked with has been in this industry for a good… decade or two. He is very knowledgeable towards the use of Grasshopper. His prior education involved great use of it, and his daily work involves the use of Grasshopper (though not explicitly what I am doing, which is creating C# components for it).
With that said, my final component went through a number of iterations. It seemed each iteration was better than the previous. An interesting point is, the other developer I worked with (I was essentially under his wing) manages to break my component every single time. I don’t mean this in a malicious way.
By breaking, I meant, he was able to overflow particular lists. He was able to, after almost every iteration, find ways that my component could be improved on. Honestly, I really feel grateful for his suggestions and critique, because these were honestly things that either I overlooked, or did not know could happen.
My question is are three-fold:
-
Is it normal in software development practices/companies to have someone critique and improve your code? There was no code review. It was simply ways improving the tool through either UX improves or back-end improvements. And honestly, even though there was no code review, I learned so much from his suggestions which I always found success in implementing.
-
Are there any suggestions for a more “formal” testing procedure? I am relatively new to the software development world, and thus am interested in software dev testing procedures.
-
How can I improve on my way to “predict” issues?
At one side, I feel like there are issues that I cannot normally find out myself because everyone uses a piece of software differently. On another side, I feel it may be my oversight or incompetence that’s causing this.
I’m reading up on this thread, and it seems in a way, we have a loose testing procedure, though it’s all dependent on me to ask for critique.
1
To improve your ability to predict problems:
- Look for edge cases. If your function operates on numbers, how does it handle 0? Negative numbers? Very large numbers? If it operates on strings, can it handle an empty string? A string with 10,000 characters? What didn’t you expect to happen when you wrote it?
- Look for problems similar to others that have been found before. You said he was able to overflow particular lists. Be on the lookout for list overflow issues.
- Look for patterns in the bugs. Is there something in particular that you “always” miss? Then be on the lookout for it.
- Learn this Grasshopper software you’re working on better. Part of the senior developer’s ability to see problems may be due to his familiarity with it.
- Ask the senior developer. As someone with a lot of experience, he probably has good advice about finding bugs and writing code in general, and about Grasshopper specifically.
-
yes, it’s called QA
-
When anybody discovers a bug, create a test that reproduces it, then fix the code so the test passes. That way, this specific issue should never appear again.
-
practice, practice, practice.
To reduce your dependency on outside testing, make sure you incorporate as much testing as possible in the coding process itself. Consider every requirement specification as a source of tests. Then write the code to make those tests pass.
4