I'm looking for techniques to produce the same or better result in less time (without sacrificing quality). I'd be happy to read a good fluent book on the topic.
I work for a small web app development consultancy company. Our code doesn't need to be perfect and our clients are happy to have a few non-critical bugs / imperfection and save some money. I understand.
I hate when I'm in the middle of my development and I discover some detail that forces me to rewrite part of my envisioned solution. Once I TDD a controller API that turned out to be completely useless. It didn't take too long, but it's the sort of waste I'm referring to. Another time I learned how to use a small library, but never used it. Since then I've been doing some research to avoid useless development and become more effective in general.
Searching around "faster development" or similar keywords produces mostly results that focus on tools, like snippet and shortcuts for IDE, ZSH tricks etc, I think I'm setup fine for these, but I don't think that's really where the most of my time goes.
I've found good readings, on programmers I'd like to mention:
- how-do-you-dive-into-large-code-bases
- http://programmers.stackexchange.com/questions/252669/things-developers-do-before-the-coding-phase
I browse around the app, making sure I understand the requirements. I roughly envision what I want and start reading the relevant code. If needed I write the relational model or even a sequence diagram (if really needed). Not always the latter seems to pay off the time it takes to be written, focusing on the code alone for the same time might produce better clarity.
The planning is a mix of reading the code and thinking of what changes to make. class/sequence diagrams could appear, again sequence diagrams not always pay off.
We don't do this too much in my company, not sure I should push for it, but if I fell the need I ask my questions.
- Why this way
- What's the context of a method call
- Known gotchas
Check the sha is also good to see what changes a method went through.
I start from the UI and I work down my way. I focus on getting the minimum functionality done as quickly as possible, I don't care about single object responsibility, duplication or anything at this stage.
Once I have the bare minimum working I can be finally sure I understand all the complexity involved. I can now look at the parts I'm sure won't change. Typically, controller actions at least.
I lock down the functionality by writing a few tests around the controller. As I'm confident I won't change it drastically, these tests will be part of my final delivery.
Often my controller tests fail their fist execution as I haven't recreated a completed context. So I proceed to get them green. I guess that's my own version of red green refactor.
I am aware it's not "by the book", but plain TDD doesn't seem to always work for me. If I'm confident enough I'm happy to use it, but I hate testing methods I simply might not need in the end.
I look at the whole code and think of the best implementation. I double check the requirements. I update my diagrams. I implement the final code and this time I test drive it. I'm mainly talking about service and model specs.
Now I might write some feature specs. They're quite expensive to write and maintain, so I don't want to write them first, or any change will need double work to get them back to green.
I review my own code, amend the messages to the user, make sure names are meaningful and I add a few lines of doc.
I send my PR, which often gets reviewed quite quickly. In the meanwhile I implement those minor functionalities and other small things. If there's any useful comment I'm right on the code, if it gets accepted I can always send a second small one.
What can I improve in my flow?