After almost a month of sitting idly, finally I was assigned to a project. I started by writing some unit tests on the legacy code using CppUTest framework. The learning curve is hard. In fact, there are many things to learn such as mocks and stubs which I am having difficulty writing. But when I finally got my unit tests merged into the main codebase, that feeling was very satisfying. Furthermore, lcov is used to track the test coverage. Writing test cases and seeing the progression of the test coverage is almost like unlocking levels in video games, oddly addictive.
Although I can say I know programming, this is the first time I get to work on a large codebase. With a large codebase, the importance of a software development process becomes clearer to me than ever before. In one particular school project, my teacher kept emphasizing on thinking about the test cases the code needed to fulfill before actually writing any code. During that time, I didn't know it was called Test Driven Development (TDD). Actually, I didn't even know there was a thing called software development process.
Before getting into Motorola, I knew almost nothing about TDD. The same goes for Agile. I first heard of Agile when working on the project under Thales during the summer of 2015. That time my friends and I were sort of left into the wild. It was my friend Louis who found out what was Agile. We tried to implement the process into our code development. But since it was just small project involving a small number of people, we dropped the idea and went on the coding blindly. In spontaneous and surprising ways when I come to think about it, we unconsciously implemented a few techniques from Agile. We were able to divide the code into parts. Each of us were responsible to manage different parts and at the same time, each of us knew the code thoroughly. We did stand up meeting every morning before working to make known the progress made and progress to make to each other. In fact, we were kinda in constant meeting and discussion since we were just four in our small office. This kinda rendered the stand up meeting in the morning to just a formality. Also by chance, we also performed quite often pair programming, which was also one of the techniques in Agile.
One major problem we faced during the Thales project was version control. Each time we made some code change, we needed to painstakingly integrate it into the principal code, which meant comparing side by side the code with all the changes and the principal code, copied and pasted the changes, recompiled, and prayed for the best. 90% of the time, there will be some errors. The worst case scenario, the bugs burst out like you just accidentally opened the Pandora's box. Near the end of the project, one of us, Cyprien, was needed to do this one and only task - version control and code integration. If only we used some sort of version control system like Git or Redmine, we could have freed Cyprien from that painful task of manual version control and put that extra hand into better use. Lucky for us, our team and our code size was relatively small, so manual version control was still manageable. With a large codebase and hundreds of people working on it like in Motorola, it becomes almost impossible.
I was never taught about unit test, software development process, and version control in school. After being a Motorolan and exposed to these new knowledge, I realized how bad the final product of the Thales project was - no singular coding style, no elaborate test cases, not well structured in general, and not easily maintainable in long term. I already imagine the person who continue to work on our code will hate us for life.
Before getting into Motorola, I knew almost nothing about TDD. The same goes for Agile. I first heard of Agile when working on the project under Thales during the summer of 2015. That time my friends and I were sort of left into the wild. It was my friend Louis who found out what was Agile. We tried to implement the process into our code development. But since it was just small project involving a small number of people, we dropped the idea and went on the coding blindly. In spontaneous and surprising ways when I come to think about it, we unconsciously implemented a few techniques from Agile. We were able to divide the code into parts. Each of us were responsible to manage different parts and at the same time, each of us knew the code thoroughly. We did stand up meeting every morning before working to make known the progress made and progress to make to each other. In fact, we were kinda in constant meeting and discussion since we were just four in our small office. This kinda rendered the stand up meeting in the morning to just a formality. Also by chance, we also performed quite often pair programming, which was also one of the techniques in Agile.
One major problem we faced during the Thales project was version control. Each time we made some code change, we needed to painstakingly integrate it into the principal code, which meant comparing side by side the code with all the changes and the principal code, copied and pasted the changes, recompiled, and prayed for the best. 90% of the time, there will be some errors. The worst case scenario, the bugs burst out like you just accidentally opened the Pandora's box. Near the end of the project, one of us, Cyprien, was needed to do this one and only task - version control and code integration. If only we used some sort of version control system like Git or Redmine, we could have freed Cyprien from that painful task of manual version control and put that extra hand into better use. Lucky for us, our team and our code size was relatively small, so manual version control was still manageable. With a large codebase and hundreds of people working on it like in Motorola, it becomes almost impossible.
I was never taught about unit test, software development process, and version control in school. After being a Motorolan and exposed to these new knowledge, I realized how bad the final product of the Thales project was - no singular coding style, no elaborate test cases, not well structured in general, and not easily maintainable in long term. I already imagine the person who continue to work on our code will hate us for life.
No comments:
Post a Comment