citypaul

Test driven design is a better name for what it's really all about: http://www.drdobbs.com/architecture-and-design/test-driven-design/240168102 Most refactoring steps are actually quite small. The idea is that it's hard to do two things at once - getting the actual logic and functionality right is hard enough - doing it in a neat way is even harder. So focus on getting the functionality right first, write tests that don't care about the implementation (in so far as this is possible), and then, once you've got the tests green, refactor. Because refactoring is done regularly, most refactorings are quite small and fast. It can be removing some code duplication here, renaming a few variables, extracting a method there and so on. Sometimes the refactoring step takes a minute or so and nothing more. Other times it can take a bit longer, but it's usually the fastest part of the whole process. I've heard it described with an analogy to how chefs work - if you tidy up as you go along you keep the kitchen clean and it's easy to keep making more meals. Otherwise the kitchen gets dirty - same with code - you end up with technical debt if you don't clean up after yourself. So do it often and early and you only end up tidying up small bits here and there instead of spending ages with it. Well, firstly we never estimate to dates. We try to break work up into quite small amounts and our features are generally quite small and focused. We work in feature squads, so there's usually only one or two developers working on a feature at any one point in time. Instead of estimating to dates, we use story points and we're quite flexible about changing these along the way. The fact is, having dates set up front usually doesn't work any way - it just gives project managers false hope and often ends up with people rushing to meet deadlines and thereby creating more technical debt, which just compounds itself. It often ends up in a finger pointing exercise in my experience. The way we work obviously involves a lot of communication and team work. We also accept that estimation is not a science and shouldn't be treated as such. Keeping the quality of the code high is a priority, so just having something functionally complete doesn't mean it means our definition of "done". All code is hosted privately on Github and has to be code reviewed before getting merged into master. I agree with you completely. All I'm saying is I don't stick to a plan religiously and I'm always happy to move stuff around and adapt the plan if needs be. I also don't need to know every last detail before I start coding. I sketch stuff down, sure. Sometimes I think I may know which design patterns I'm going to use and so on and so forth, but I always work test first in the way I described above, and I listen to the feedback my tests are giving me. If my tests are telling me my design is bad, I change it. If they're telling me the design looks good, I carry on down that path. Sometimes I don't know how I'm going to do something and I simply make the tests pass then work out the design in the refactoring stage. That's why I use TDD. Because I want to write clean code that I've got high confidence in. Read the article I posted above: http://www.drdobbs.com/architecture-and-design/test-driven-design/240168102 From the article:

Well despite our initial squabble, I tried to "like" this comment but the system wouldn't allow me, presumably because of my low number of posts. This is pretty accurate advice. Unit testing is a very good thing to learn. TDD is even better, which is really a way of maximising the use of automated tests to work out your design and reduce the fear of change. One step at a time though. I'd recommend reading those books I mentioned, and watch that video. This stuff won't come to you over night. It's only by reading, watching good videos and of course constantly putting these ideas into practice that things will start to "click" for you.

TDD means nothing of the sort. Test DRIVEN DESIGN. The tests are all based on business behaviour, not implementation details (so nothing, or as little as possible, about the structure of the code should be baked into the tests), and the tests are not all written at once and then made to pass with the "coding" step. You write one test. You see it fail. You make it pass and then you refactor if necessary, then you write another test. Repeat until you're done. The refactoring stage, which is a natural and essential part of the TDD process, is where you make important design decisions. You may split out an object into smaller objects, extract functions, move things up and down a hierarchy, split out new objects and so on and so forth. This is part of the process in tdd: 1) Write a failing test 2) Make the test pass 3) Refactor if necessary 4) Repeat until done So TDD is all about creating a design based on evidence, not following a blue print. You become much more intimately familiar with the code and the solution domain while you are working on it, so any design process that allows you to use that evidence to inform the architectural design of your code is a good thing, no?

No, refactoring should happen constantly, all the time. You should not design a big plan up front, because the plan will inevitably be wrong - if the plan is not perfect it causes all kinds of issues. What happens if you think of a better way during development? Do you just stick to your plan even though you can see the advantage to doing something a better way? The truth is there shouldn't really be too many discrete stages. There certainly shouldn't be a design, code, test phase - these should all happen interchangeably and be combined. I use TDD, which means that I get to refactor my code without the fear of change. This means I can start with only a minimal design (I usually have an idea in mind, but never stick to it religiously and I never design too much in advance) and I can incrementally create a great design by constantly refactoring using feedback from my tests. This is essentially a form of "evidence based design", which relies on short feedback loops that lead to constant incremental improvements. I would never trust an upfront design. There's nothing wrong with jotting some ideas down and aiming for a certain design, but when the feedback you get from your tests (and you DO have automated tests, don't you?) tells you a design isn't working, you should adapt to that feedback and change your design now, not later. Refactoring is something that you do while you code - it's not something you do at the end, and you should be writing code AS you're designing and fleshing out your ideas.

To the OP: So I found a youtube video by Robert Martin, the author of the Clean Code book I recommended above, and incidentally the guy who coined the phrase SOLID principles (literally the guy who came up with the Single Responsibility Principle), so you can't go wrong with this. I've not watched it but I'm sure it'll be a great starting point: Edit: I've seen plenty of his videos in the past and he often starts by going on about space for no apparent reason. If he does that just skip that bit, unless you want to learn about space. I've no idea why he does that...

It's the truth though. I read through a bunch of topics and read a lot of code before writing that comment. Most of the people here are learning, so you shouldn't expect too many experts. That's not to say that that will be the case for all people though of course. Some people here may be excellent And I never said object oriented is the be all and end all, but this person's code uses classes and he's talking about the single responsibility principle, so he is clearly interested in learning about good OOP design. I was merely explaining that the code he has at the moment isn't OOP, but that's ok as everyone has to learn. I started out the same way and had the same questions. To the OP: I'll have a hunt around to see if I can find a good video or something.

I don't agree with the idea of a discreet design "stage". Designs should evolve over time and can be refactored. I never stick to a plan and I consider it a good practice to not plan too far ahead.

Your classes definitely do have WAY too much responsibility. It may surprise you to learn this, but you are in no way writing object oriented code here. This is procedural code, not object oriented. The reason smaller objects are better is because it makes it far easier to change and adapt your system later. It also means you can get plenty of reusability out of objects. It's all about making them focused and giving them a clear reason to exist. Right now your code is a nightmare and I'd hate having to maintain it - adding some new functionality to this code would be horrible. Your code is also far too knowledgeable about the wider system in which it lives. You should not be accessing POST variables AT ALL in your objects like this. Instead, you should be passing things into your objects. Right now you're tied to the exact structure of the HTML form now because of this. So if you changed the form value of "vehicle_sufix" to something else, your code would break, which obviously is not what you want. It's quite hard to teach this stuff without being able to show it in practice, but essentially you would be well advised to break out your code into much smaller units. I've just read through your code a bit more. It's very messy and will be impossible to change. You're gonna get bugs all over the place - you'll change one thing and something else will break and so on and so forth. I don't have time to break your stuff apart in the way you asked. Instead, I'll recommend two books to you. Here's the first: http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 And here's the second: http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-Wesley/dp/0321721330 And yes, the second is a Ruby book. However, it's all about OO design and Ruby just happens to be the language chosen. I use lessons from that book at all the time. You really should read those books, as most of the people on these forums are amateurs and don't know how to write object oriented code.

You should probably start by refactoring this code to be object oriented.