Christmas and new year with the Javi were the only ones on The farm work. He played the pleasant task of preparing scripts of deployment, test them at local, then see how they fail in the test environment and not to mention in PRE and PRO. But hey, as the Javi is nicotinero, I was with him that you quench your Vice and between one thing and another we started to talk about the interesting and recurring themes
How often is recommended to make CheckIn while I modify codeshare? (or protect code in the repository)
But the issue was rather more specific, talking about what happens if we take a large portion of code and begin to work and improve it. In this case, can I protect my code at the end of the process of refactoring? do or do it more often when I apply will apply small changes? Here are some examples:
In the first case, it is common to see how a person takes a piece of code for a couple of days, is devoted to playing with them, and 48 hours after decides protect changes he has made. If you are working in a team together and you have modified common elements as for example the definition of a project, because it is very likely need to do one or moreMERGEactions. If in addition you have modified classes that were being used by other colleagues, then the MERGE would be more delicate.
After presenting this example, someone might think that the solution is to protect more frequently. Suppose that for each modification "mild" that we apply in our process of refactoring, and perform a CheckIn. In this case, we must very tuned the operation of the development team, as it is at that moment when other members should evaluate whether they need to get the latest version of SC and the same question should be the person who is doing the refactoring.
As we see none of the two cases it is a complete solution for this scenario. I from my humble opinion I can suggest the following for this example:
- Evaluates the changes that you make and tries to them to be significant for the code. I.e. it’s not a line of commentary, nor the destruction and total replacement of 20 lessons per 7 different projects.
- You must always comply with the basic premises prior to protect code > verify to compile and pass the latest version of unit testing.
- If you find yourself frequently with "classes" which are working 2 people (or more), assesses whether you are serving the SOLIDprinciples. 2 People to work on the same classes usually indicator that this class is taking too much responsibility
- If you fulfill the SOLIDprinciples, but you still find 2 people working on the same class; then give the person divides the tasks on the computer that we are sure that there is something that does not fit a touch.
- He says this work with your classmates. The daily meeting of "updating" is an ideal time to discuss this work.
- Finally, remember that a team must respect the principle of the shared ownership of the code. Each change that you apply affects the work of your peers and nobody is responsible and "master" of a single piece of code.
And to close, the classic of every day when we pass these things… (sourcehttp://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0162fe399bd1970d-pi ))
Greetings @ Here
Geek And Poke: http://geekandpoke.typepad.com