Re: Tips for managing Perl projects?

[nothingmuch]

IMHO, the two most important design principals go hand in hand.. These are minimalism (a subset of laziness, but also something entirely different (small, compact, decoupled bits)), and robustness (never cut corners. You should design so that the corners are left in tact, even if between them everything is just a stub). I use # FIXME comments a lot, when I don't want to lose my concentration, but I make sure that the places that have to be fixed are really problematic, and can't be worked around more eleganlty instead.

If you design for these two, possibly with the latter being the tie breaker, you usually end up forcing yourself into writing concise, maintainable, reasonably efficient code.

After that, optimise for readability, which implies robustness (due to less errors especially in maintaince), and interface flexibility (use the law of demeter, as well as tests (especially having to do with mocking) to try and find the weak points of your interfaces).

These basic principals are easily enforced by unit testing as both a test for your design, since it is the first real world usage the code gets, and as a measure for robustness (Devel::Cover helps you find edge cases you may have overlooked, and code that shouldn't be there (which should be considered as more room for bugs)).

I usually write two scripts per piece of functionality - an api test, and a real world test. A real world test makes use of as much of real examples as possible, and helps with the design, as well as overall sanity. It does one thing, usaully. The api tests cover every corner, and make extensive use of mocking/white box techniques. I never ever test more than one piece of functionality in a single test, because that confuses stuff. As time goes by regression test files for errors are made, or appended to the api tests, and the critical sections get stress tests, which is a deliberate attempt to try and break the system (usually these are worth a lot once, when you first write them, but not as much afterwords).

Provided you keep things small, and tidy, and well behaved, and always listen to your gut if it tells you you're doing something you don't really like, you should be OK.

Places where I get a bad gut feeling are, for example when the logic knows about special cases having to do with the environment, or when tests jump through hoops to get the job done, or any kind of repitition.

Lastly I'd like to mention that the best sanity check is to get other peoople to help you think, usually about design. Code reviews are hard to get done because usually deadlines don't let them happen as much as they should, but design reviews are really a necessity. And if you can't get design reviews, then try and design as early as possible, but implement as late as possible, so that you can more easily criticise yourself about your design in retrospect.