Timeline for How to set up something like an integration server that measures the quality of code and reject the code if the score is below a certain number?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 9, 2014 at 6:09 | comment | added | Signature | Missed the reply window, but here are my thoughts: yes, that was a problem where I worked, too. The non-programmers do not see the business value of refactoring and cleaning things up. I try to get some discussion about mission statement / goals going and I offer t present some of the concepts from "The 7 Habits of Highly Effective People". There is one part which is especially relevant: readytoevolve.com/blog/2009/09/… - if that does not help I am gone. In my current employment that process is ongoing (mission statement discussions, not leaving). | |
| May 4, 2014 at 17:42 | comment | added | Arseni Mourzenko | "In those cases there need to be sprints for cleaning up the code that you had to produce": recalls me my previous job. They always promised to clean stuff up when we have time for that. The fact is, they will never have time, since they always work under pressure. | |
| May 4, 2014 at 17:40 | comment | added | Arseni Mourzenko | For small companies the Clean Code rules can not be followed all the time: what do you mean? Wait, I'll rather create a separate question for that. Here: programmers.stackexchange.com/q/237894/6605 | |
| May 4, 2014 at 17:06 | comment | added | Signature | The book "Thinking Fast And Slow" explains a lot. It is just very tiring when your brain needs to figure things out that it should not have to. Maybe the size of the company matters. For small companies the Clean Code rules can not be followed all the time. In those cases there need to be sprints for cleaning up the code that you had to produce. I do not like those situations, but they can not be avoided in small teams. | |
| May 4, 2014 at 17:01 | comment | added | Signature | Nah that is just bull. It is invaluable if the code looks coherent and when you can count on conventions. I work at the 2nd company that leaves a lot to the programmers and you will always fall into traps because you think you know what you are looking at when you really don't. | |
| May 4, 2014 at 16:01 | comment | added | Arseni Mourzenko | But there will be tense moments when you do not want the strict style checking to get in the way.: That's exactly why (1) you don't discuss style at the beginning of the project with the team (see my first comment) and (2) you do the checks on commit, and forbid any non-compliant code to get in. This mitigates the risk of tense moments, since it distills the checking itself by doing it by small steps (commit) instead of a big step ("Ok, now that we've released our app and have more time, let's fix the style... let's see... just 30 000 warnings to fix for Friday, should be fine.") | |
| May 4, 2014 at 15:56 | comment | added | Arseni Mourzenko | I would still call the build successful (just with warnings): It depends. Warnings are often a bad idea itself. If it's something wrong which must be corrected, fail the build. Otherwise, many teams, especially under time pressure, will keep the number of warnings increasing. Also, the check shouldn't be done at build level, but at commit level: keeping the code base clean is just simpler than letting dirty code in, and then clean it up. | |
| May 4, 2014 at 15:54 | comment | added | Arseni Mourzenko | You need the programmers to commit to / agree on the coding style: I totally disagree. Keep your team away from parasitic subjects which cause important loss of time. Discussing if we need to capitalize or not private non-static properties can take weeks, because there is no one right answer, but what this discussion brings to the team, to the product or the end users? Right, nothing. Wouldn't be much more useful to spend time discussing the actual features, technical aspects and workflows? | |
| May 4, 2014 at 10:15 | history | edited | Signature | CC BY-SA 3.0 |
Added a sentence "... there will be tense moments ..."
|
| May 4, 2014 at 10:10 | history | answered | Signature | CC BY-SA 3.0 |