As the title states it, I would like to get some suggestions about putting knowledge into action.
We have many additional requirements that concern: coding practices feature development (all of them or only a subset), process, etc. The problem is that we have problems with introducing those practices into new projects and I want to help developers and reviewers to remember about it, but I don’t want them to have everything just in theirs heads, but rather in some kind of a database that they can use easily.
The list of practices is already defined in Excel. I would like all team members to apply these practices in their work but I don’t know how make those information easy to find. When developer starts working on a feature he should be able to easily find all practices that he should use in these feature.
To be clear with what I mean, I’m showing some examples of information we have to apply:
-
(new design request) every feature must output logs (and it must not contain any sensitive data);
-
(new design request) every feature has to have a flag in the configuration that allows to disable it;
-
(good practice) always update docs when feature is ready;
-
(retrospective feedback) QA must test only on release package (not in debug mode);
-
(retrospective feedback) make stress tests for every new feature implemented;
-
(lead’s task) write release notes after each sprint that includes tasks completed and open bugs;
-
(design usage) every event from “ABCStoreManager” must be disconnected after being invoked;
-
(design usage) try-catch every event.Invoke() call;
I thought for a while about a wiki, but it’s no good, because it doesn’t support tagging/categories or querying and I’m afraid that everybody would ignore it (people must know exactly where to look).
My question can be summed up as how can I improve communication to our developers about the required development methodologies and practices listed above in an easy way?
Remarks:
-
this question is not about security issues or code smells per-se;
-
I’m not looking for any heavy process (like RUP) or any process for that matter, which forces you to go step by step. Preferably I am looking for an agile approach
-
Daniel Figueroa has suggested adding additional requirements to the “definition of done”. And it seems like a good way. But the problem is that some features have, for instance, 20 additional requirements (“all GUI features”), some 10 (“all server requests”), etc. I would like to have this stuff aggregated in a one place and just use links (“see: ‘GUI feature’ “);
5
Okay so here is what I believe.
When it comes to your example with the logs I think you actually have the answer in your list. What it boils down to is in the definition of done. If the devs are printing sensitive data to the logs and the testers are supposed to check that no sensitive data makes it to the logs, then clearly that feature isn’t done, which means that the tester should put that feature back to In progress or whatever you guys are doing to keep track of development.
The same goes for everything that has to do with the actual code, now I’m not promoting a view that the testers should teach the developers. But they should work as a guard that the implementation is up to par with your standards. Any developer worth his/her salt should quickly take it to heart if every time they create a new feature it gets sent back because they didn’t properly adhere to some of your rules.
Another thing I think is really important is what @Robert Harvey put in the comments field, code reviewing. That could be anything from pair-programming to something more formal. If a piece of code has only touched one pair of eyes I strongly believe something must be done. Such a simple thing as a high level description of what the code does while showing the actual code has made me blush several times because I’ve found problems or things I’ve missed several times. And usually it’s just dumb mistakes.
So to recap:
- One responsibility of the testers are to check that the devs are following rules.
- Don’t let devs act as lone-wolfs, should be a social activity (I don’t always like it but it’s true).
- Have a clear definition of done, and don’t let the implementer be the only one that says it’s done.
I think this is a question about culture not about tools.
4
We used a wiki at a previous job, and it worked well. Any changes were publicised to the developers, and the team leads discussed it at regular intervals.
It seems to be that in in your list, you have both programming best practice and process definitions. I’d suggest first writing up the process by which you develop software. Then you can add sub-polices regarding best practice or language-specific guidelines. The main policy should refer to it and make it clear that developers should follow the style practice guidelines unless there is good reason not too.
Note that I’m not advocating writing pages and pages of docs – just enough to make it clear what a dev is supposed to do at any particular point in a project. If you can’t easily summarise it, I’d suggest the current process itself is vague.
5