11 ms·
One more question - so if we agree to keep the documentation within the code, are there any rules outside of using MVC / choosing good naming conventions that w
by evaldas_a 16y ago
One more question - so if we agree to keep the documentation within the code, are there any rules outside of using MVC / choosing good naming conventions that would help to undestand what's going on for somebody who is knew to the project?
I.e. right now the only way a new developer can find out that we create invoices upon campaign deactivation would be by doing search in project files for instances where invoicing module is called. Is it possible to have some auto documenting system which could list all files w/ line numbers where specific function is called?
- briandoll 16y agoThe best way for a new developer to get to know the domain model and to understand the business rules is to read through the test suite first. From there the new developer may read through the implementation of the domain objects, controllers, etc. This assumes, of course, that the application is well designed, continually refactored and well tested. Every app has skeletons in the closet, though, and this perfect world often leaves something to be desired. If your code is relatively clean though, you'll have one and only one place where you instruct an account to be invoiced, and you can trace through that code anytime you have questions about how that scenario works. Suggestion: Every time you go diving into the code to investigate some scenario and wish to discover the business rules, start by writing a test for it. Write tests that expect that behavior, then execute the scenario and ensure your tests pass. Better yet, write those test first and you're all the way there. :)