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 approachDaniel 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' );
How to put lessons learned, good practices, etc into the work flow
programming practices;development process;specifications
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.