One of the first things that took me by surprise was the large code base I was working with. Besides just the size of the project, there were also a number of programmers working on it, and if one part didnt behave as it should, it could affect other parts of the system. In this post, I ll briefly look at how one manages such projects and some useful tools that could be useful to do the same. Before I go any further, I d like to inform the more experienced readers that this post has very basic information. However, I promise to give more interesting things in the posts coming up later.
Right, so back to tools that can help you manage such large code bases. The most basic problem that most of us face of course is maintaining different versions of our code. For example, if me and my friend Melvin were to write a simple programme. Lets say, I write the part that talks to the user(the UI) and Melvin writes the core(stuff that does work behind the scenes). When we start its very confusing, we dont really know where to start, and even once we start we get confused as to when to put these parts together.
Another problem of course is when we make changes. Last week everything was working fine and dandy.But today Melvin might make a change and everything might stop working. Also, he has edited his file and he cant figure out how the programme looked earlier.
So basically if you do the same with a very large application and with many programmers working on it, there is a lot of code:
- Each programmer writes new code each day
- Not all code fits perfectly with the rest
- It is important to know who wrote which part of the code(so you can blame them)
- It is important to be able to go back to an older version(so you can save your ass)
For the very same purposes, all software companies will use some sort of a version control system. The most common type of version control is svn, many other popular systems exist like GIT.Each system has its own advantages. The purpose however is for many people to code on the same project and share their code. Also there is a complete revision history showing your previous changes. Next time you work on a coding project with your friend, try not to share the code via gmail, try using a version control system.
It is also useful to maintain your notes, we usually use a wiki. Notes including documentation for various parts of the system, meeting minutes, use-cases, etc. The wiki is useful because of its flexibility and again, its ability to show revision history. For example if the wiki page was capturing how the software can be used, it might go through some changes as development progresses. As users update the wiki pages, one can look back at these changes. Besides wikis now also allow chats and discussions. But there are many other collaborative tools for these purposes too. The advantage with a wiki of course is that it is on the web and doesnt involve passing files from one person to another(via gtalk or paper).Its almost like google docs, just a little simpler and little more flexible.
Final point I d stress on in this post, is the use of unit tests. At school, I always found them useless When are they useful? Primarily unit tests are useful to make sure you wrote the code to behave in the way you want it to, but also, when you make changes to your code, these unit tests will show if anything has changed. Quite simply put, instead of compiling, running and typing out a lot of input each time you debug your programme, you can have these awesome unit tests that will tell you exactly when a programme fails and also in which cases it fails.You could actually test any number of test cases by just running one programme..
When you write unit tests, check out junit and jmock (in java, similar things exist for python, C etc.). junit is a unit testing framework that makes the automation of your tests easier. jmock is a utility used along with junit that can mock specific parts of the programme. For example, in the case of the programme Melvin and I write, I could write unit tests to test the part of the programme i write, and mock the performance of Melvin's code. Since,I know how Melvin's code should behave(by design), I can use this to simulate the entire system, but yet test only my part of the programme. This also useful when Melvin is late with his work, like he usually is... ;)
Hope version controls, documentation in wikis and unit tests will make your projects easier to do. Try them out sometime. Search on google a bit for more info, join a few forums, you ll soon find large projects very easy to manage.
What is coming up in the next post? I am thinking of looking into tricks on how one manages large systems. This includes testing, various environments and more importantly about how you avoid downtimes while upgrading the software you just wrote. To put that in perspective. Each time your small hello world programme starts up it takes atleast a fraction of a second. When a million users use a programme, it usually takes a lot more time to start up,however we need to be able to constantly make upgrades to these programmes. What do we do to avoid downtimes? How do you upgrade your service and yet not let the user suffer with no service for even a fraction of a second?
No comments:
Post a Comment