Having become immersed in computers from an early age, one of the reasons I wanted to become a software developer was because I enjoy solving problems. It’s not just about building applications, but a large part of a software developer’s career is maintaining and testing the code. There are several important lessons that I learned from Sonmez while reading the sections on testing and source control. Sonmez states that testing is about reducing risk. If you think about the research that goes into user interface and experience, there is always an advantage to fixing issues that you normally wouldn’t focus on when deploying the code to consumers.
As a developer, it’s important to understand which areas of software development have the greatest impact on the consumer. This can be accomplished through a series of tests before the code is released. However, as Sonmez you have to know the why and how of building and running these tests. I agree with this because when you’re working with a team, you are responsible for your part of the code. If you don’t build any meaningful tests, it becomes much more difficult for your team members to deploy the code as any errors or bugs would not have been fixed. I think of different versions and patches of products that are released on a weekly and monthly basis. There is never a perfect deployment, but you can speed up the process by understanding the concepts and terms behind testing. This strategy will also create more time for implementing new features and acting on consumer feedback.
While Sonmez also explores the steps of testing such as planning and executing the tests and making sure that there are “asserts”, something I found interesting was when he said that each feature of the code should be “treated like a mini project.” I think this is crucial because you want to pay close attention to the details of each component in order to prevent errors and bugs. You don’t want to constantly keep making edits to the code once it’s deployed as it becomes detrimental. He further states that “regression and automated testing are critical as new software is released on very short iterations.” This goes back to what I mentioned before about responsibility. If each developer focuses on taking ownership of their code, which includes building, implementing, and testing than there is a higher chance it will be of qualitative production. Consumers will want to utilize your application or product because the number of bugs will be significantly decreased. You also want to make sure the code that you wrote doesn’t conflict with others and this can be solved through a centralized source control system.
Sonmez describes source control as “a way to keep track of the different versions of files and the source code of a software project.” When I think of source control, my mind immediately jumps to GitHub since all of my repositories and the lessons and labs that I’ve completed through The Flatiron Curriculum are stored there. Considering that I’ve mostly built applications and projects individually up to this point, this isn’t a problem that I’ve encountered much, but I will say that this is the most valuable information for entry-level developers. Nearly all of the alumni that I’ve networked with have discussed that they work on a team and are assigned a component of the much larger project. A crucial part of the software development world is collaboration so when you think about writing code, you should also have the perspective that it’s going to be consistently reviewed by your entire team, no matter how confident you are about it.
As Sonmez states, it’s very easy for developers to overwrite each other’s changes because you are working on the same files for projects. There needs to be a reliable solution to make sure that every part of the process occurs successfully. This is why creating unit tests is incredibly beneficial because they eliminate time that would be spent analyzing your specific component compared to other members of your team. They also offer a learning experience to better understand the functionality and logic of the code. Sonmez concludes that you should “always be pragmatic” because the decisions you make not only affect your co-workers, but also the eventual audience of your application or product.