The first question one usually asks if one hasn't been exposed it is why use version control software?
My first experience with version control within a team environment was just after I came off a project where two other developers and myself were unable to deliver a first cut of a project because each of us developed in our own way and style, and we just could not get many, many ownership and integration issues worked out in time. I then joined a team that used Sourgear Vault for version control. and where several ground rules placed by our Technical Architect ensured that all code was checked in at the end of every day, and that builds were made automatically on commits. Breaking the build was a big no-no, and the incentive to keep to this was that if someone broke the build, they bought everyone lunch that day, a nice rule which cost me a bit at first in terms of free BK for folks at my expense, but paid itself back nicely in terms of disciplining me to check my code and my tests more thoroughly before committing.
This also gave immediate benefits to me in that not only did I become a better programmer because my code was being constantly checked to ensure I did not break the build, but it also allowed for easier reviewing by my team to ensure adherence to good design patterns, no implementation of anti-patterns or unwarranted hacks, and an adherence to accepted coding standards. For the team it also meant that integration of various components in the project happened much eariler and frequently. Learning from each other's own hacks and best practices also happened much more often, and frequently.
As a single or lone developer, I would also recommend version control as features such as 'code-revert' means quickly 'righting the wrongs' of horrible coding efforts where the neat organised project you started with several hours earlier became strands of spaghetti code you wish you could throw out with yesterdays leftovers.
Recently I came across a video on YouTube about Git by Linus Torvalds, creator of Linux. After watching it and playing around with Git myself, I find it personally appealling to my style of development as I find myself to now be a more mature developer, but still wishing to work closely with younger developers who may be very talented but not have had as many best practice habits in team development ingrained in them.
The key point of this version control system is the term 'distributed' There are no branches, there is no central repository, things common in all systems I met before such as Vault, Team Foundation Server, CVS and Subversion. Instead, every member of the team has his/her own copy of a starting point in the system, and one may choose to include submissions by team members to all to update their own copy of the project system, or not.
In a mentoring-friendly environment of software development I think this can be most effective to training junior developers, as code reviews can be more real time and one-on-one with anyone, from a peer to the lead technical architect. This is not to discount the team dynamics, full team code reviews are great for experienced developers, but for me required a bit of a thick skin as my coding practices are open to a barrage of public, sometimes undiplomatic, feedback from everyone on my team at once. Developers are passionate about their code and coding practices, and so peer code reviews can get a bit heated at times.
With Git, I can see more interaction happening with just as much passion, as well as growth, for a junior developer as a technical architect or senior team member walks through one-on-one with them why certain submissions they make to the technical architect's repository won't make the grade and be included in their build, at least, not yet.
One thing that is great about this is that ownership is so clear here. In this case, the project will be delivered via one person's copy of the project, probably the technical architect or project delivery lead. This ensures ownership is directly attributed, so that in the case of a technical architect code reviews HAVE happened, and no unfixed results of previous code reviews are present.
I missed getting in to today's Open Space Coding so I haven't gotten a 'real world' test with Git yet, but hopefully soon I'll find an opportunity to experiment with it, either at work or on a pet project of my own.
My first experience with version control within a team environment was just after I came off a project where two other developers and myself were unable to deliver a first cut of a project because each of us developed in our own way and style, and we just could not get many, many ownership and integration issues worked out in time. I then joined a team that used Sourgear Vault for version control. and where several ground rules placed by our Technical Architect ensured that all code was checked in at the end of every day, and that builds were made automatically on commits. Breaking the build was a big no-no, and the incentive to keep to this was that if someone broke the build, they bought everyone lunch that day, a nice rule which cost me a bit at first in terms of free BK for folks at my expense, but paid itself back nicely in terms of disciplining me to check my code and my tests more thoroughly before committing.
This also gave immediate benefits to me in that not only did I become a better programmer because my code was being constantly checked to ensure I did not break the build, but it also allowed for easier reviewing by my team to ensure adherence to good design patterns, no implementation of anti-patterns or unwarranted hacks, and an adherence to accepted coding standards. For the team it also meant that integration of various components in the project happened much eariler and frequently. Learning from each other's own hacks and best practices also happened much more often, and frequently.
As a single or lone developer, I would also recommend version control as features such as 'code-revert' means quickly 'righting the wrongs' of horrible coding efforts where the neat organised project you started with several hours earlier became strands of spaghetti code you wish you could throw out with yesterdays leftovers.
Recently I came across a video on YouTube about Git by Linus Torvalds, creator of Linux. After watching it and playing around with Git myself, I find it personally appealling to my style of development as I find myself to now be a more mature developer, but still wishing to work closely with younger developers who may be very talented but not have had as many best practice habits in team development ingrained in them.
The key point of this version control system is the term 'distributed' There are no branches, there is no central repository, things common in all systems I met before such as Vault, Team Foundation Server, CVS and Subversion. Instead, every member of the team has his/her own copy of a starting point in the system, and one may choose to include submissions by team members to all to update their own copy of the project system, or not.
In a mentoring-friendly environment of software development I think this can be most effective to training junior developers, as code reviews can be more real time and one-on-one with anyone, from a peer to the lead technical architect. This is not to discount the team dynamics, full team code reviews are great for experienced developers, but for me required a bit of a thick skin as my coding practices are open to a barrage of public, sometimes undiplomatic, feedback from everyone on my team at once. Developers are passionate about their code and coding practices, and so peer code reviews can get a bit heated at times.
With Git, I can see more interaction happening with just as much passion, as well as growth, for a junior developer as a technical architect or senior team member walks through one-on-one with them why certain submissions they make to the technical architect's repository won't make the grade and be included in their build, at least, not yet.
One thing that is great about this is that ownership is so clear here. In this case, the project will be delivered via one person's copy of the project, probably the technical architect or project delivery lead. This ensures ownership is directly attributed, so that in the case of a technical architect code reviews HAVE happened, and no unfixed results of previous code reviews are present.
I missed getting in to today's Open Space Coding so I haven't gotten a 'real world' test with Git yet, but hopefully soon I'll find an opportunity to experiment with it, either at work or on a pet project of my own.
No comments:
Post a Comment