5 Important Points of Software Engineering

While there are countless aspects of Software Engineering that are extremely important-- to the point where you could call many of them "the most important aspect of software engineering", I would like to share with you all just five of those points in the format of a mini quiz. See if you can answer all of them!

Questions:

1. Why should you use annotations in Java even though they are not necessary?
2. Automated quality assurance tools are also very important to programming effectively. The following code will result in which automated quality assurance tool (Checkstyle, PMD, or FindBugs) to report an error?: if (true) { x = 6; }
3. What is JaCoCo used for, and what is one aspect to beware of when using it?
4. Give an example of a good way to incorporate different types of software reviewing at various stages along the lifespan of a program.
5. How and why would you recommend using an IDE to someone who normally codes using a text editor?

Think you got all the answers? Check out my answers below and see how much you know about these software engineering components!:

Answers:

1. (Why should you use annotations in Java even though they are not necessary?) Although the Java Interpreter ignores them, annotations are useful in that they associate various “metadata” with elements within the program. They allow Java tools such as the compiler and Javadoc, and even automated quality assurance tools such as Checkstyle and PMD to find errors in your code more effectively. Annotations are sort of like extra tools that help make sure that what you are writing is actually what you mean to write. For example, if you are intending to override a superclass method but you spell the name wrong or use different arguments, having put the @Override annotation will give you an error saying that the method does not in fact override a superclass method. After realizing this, you can fix the error in your code right away without having to ponder and search through your code later to figure out what is causing the problem.
2. (Automated quality assurance tools are also very important to programming effectively. The following code will result in which automated quality assurance tool (Checkstyle, PMD, or FindBugs) to report an error?: if (true) { x = 6; }) This code will result in PMD reporting an error. Because PMD searches for possible bugs, dead and suboptimal code, overcomplicated expressions, and duplicate code, the above will be flagged as it is redundant; the condition inside the if statement is always true. It is syntactically correct and will not show up as a bug in the Java bytecode, so neither Checkstyle nor FindBugs will raise a concern for this statement.
3. (What is JaCoCo used for, and what is one aspect to beware of when using it?) JaCoCo is a tool for automatically analyzing how many lines of code in a program are covered by test cases that are written for that program. When using JaCoCo, it is important to keep in mind that coverage does not equal perfect testing. Although it is important to make sure that as many lines as possible are tested, just because you have a 100% line coverage does not mean that your code will be unbreakable if the tests pass. You could very much have a test that runs through only 50% of the lines but is a much better test than a test that runs through 100% of the code, because the test case itself is much more rigorous and exposes more flaws. So when testing code, just use JaCoCo to get a sense of how many lines you have covered, and then work on making sure those lines are covered as best as possible. Then you can add more to the test or make another test in the same way to cover more lines of code, and your program will be extremely robust!
4. (Give an example of a good way to incorporate different types of software reviewing at various stages along the lifespan of a program.) Following the general software development process: Requirements specification, Design, Implementation (Coding), and Testing, you should incorporate a reviewing process between each of these four stages. One example of how you could go about doing this is to first start off with a Walkthrough after analyzing the requirements. Since there is no code or design produced yet, just a basic check to make sure the idea is valid or thinking about other general issues may be sufficient at this point. Then, after coming up with a software design, it would probably be good to perform a little more in-depth Technical Review, since there will be more technical specifications at this point, so it would be a good way to check the design and find any defects and resolve ambiguities, before moving on to code the program. Another walkthrough could perhaps be performed in addition, to informally check the overall integrity of the program. Finally, after the coding is done, some nitty-gritty Inspections ought to be performed, to really detect and remove defects. Technical reviews and walkthroughs may also be good to incorporate, but streamline programs that are to be distributed for public use should definitely go through thorough inspection to get rid of as many bugs as possible, even before moving on to test the code.
5. (How and why would you recommend using an IDE to someone who normally codes using a text editor?) IDEs are made to do more work for you, so that you don't have to. They do not only simple tasks such as closing open parentheses and braces and automatically indenting new lines of code, but IDEs also contain libraries that enable things such as auto-complete, allowing you to view the available methods right then and there in case you forgot the exact spelling or what parameters are needed. IDEs will also tell you if something is spelled wrong or is invalid syntax, and also provide a place for compiling (which is done in the background), running, and debugging code, without having to compile and execute the code manually. All in all, IDEs allow for far more efficient programming that is also much more accurate, so you will probably never have to dig through code to fix an error caused by forgetting to close a brace or by using the wrong method name, because the IDE will take care of that for you.

Did you get them all correct? I know the answers are rather lengthy, but if you got the general idea down in your head, then congratulations, you know quite a bit of tools that can help you in productive software engineering! If not, then please be sure to learn to love these tools and tips; they will certainly come in handy in your experience as a software engineer. Please be aware though, that these are not the only vital tools to know for software engineering; there are tons and tons more that I have not covered here that are absolutely essential to programming, so please, search and play around with them, and read up on my other blog posts to gain more tools to put under your belt, so that you too may be on your way to becoming an excellent software engineer!