software architecture (OO design) refresher course [closed]

I am lead developer and team lead in a small RAD team. Deadlines are tight and we have to release often, which we do, and this is what keep the business happy.

While we (the development team) are trying to maintain the quality of the code (clean and short methods), I can’t help but notice that the overall quality of the OO design&architecture is getting worse over the time – the library we are working on is gradually reducing itself to a “bag of functions”. Well, we try to use the design patterns, but since we don’t really have much time for a design as such we are mostly using the creational ones.

I have read Code Complete / Design Patterns (GOF & enterprise) / Progmatic Programmer / and many books from Effective XXX series. Should I re-read them again as I have read them a long time ago and forgotten quite a lot, or there are other / better OO design / software architeture books been published since then which I should definitely read?

Any ideas, recommendations on how can I get the situation under control and start improving the architecture. The way I see it – I will start improving the architectural / design quality of software components I am working on and then will start helping other team members once I find what is working for me.

Am I right in my assumption that you don’t do any unit testing? Unit testing is a great way to show you where you design/architecture lacks… if you are not able to test classes in isolation, your design may be broken… if it is reeeaaally hard to write tests for your classes, this may also be a sign that the design could be improved. Unit testing taught me more about proper design than any book out there…

My two suggestions would be on the one hand, go back to the fundamentals, and on the other hand add to those fundamentals in your tool box:

Back to the fundamentals:
Design principles are the fundamental elements that drive design patterns, without principles to strive for all those formal patterns wouldn’t exist. Start with SOLID http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) and go into pieces of the code you feel have become bumpy and start assessing which principles are being broken and why. For future code you write, with each class or method or design you begin to implement, ask yourself if it’s obeying the principles or breaking any of them.

Adding fundamentals:
You mention OO and clearly have a strong drive towards this direction, but OO designs can often be improved through understanding of the functional paradigm and how it achieves compliance with design principles. If you haven’t learned any functional languages, go learn Haskell or f# or Clojure or any of them really (Haskell will literally give you a headache, and simultaneously change your mind for you). Just learning and practicing one of these for a month in your spare time will give you new tools which will allow you to more easily and comprehensively obey good design principles in scenarios where maybe the OO approaches just didn’t quite meet good design.

Another approach for an refreshment is Clean Coders. It’s a collection of videos from Uncle Bob (Robert C. Martin).

Look at the headlines of these videos. You will see that they are mostly about TDD, Clean Code, SOLID and Component Patterns. Our team is watching one video per week (with a discussion afterwards) to have a common understanding what principles we want to follow. Unit testing for example… and the videos explaining very good, how to do it and how to start.

Giving releases often means that the code is changing all the time: small improvements, new features, additional functionality, etc. So the main rule (as my college says) is to keep in mind that whatever you write today will be changed tomorrow. The whole system should be extremely flexible and simple, so that changes will not break it’s architecture or cause any other problems.

If you don’t have enough time to design everything well, I’m pretty sure it’s your management’s fault. They keep pushing you, so you have to produce working code all the time. Try to convince them that creating good design from the beginning is essential: it will save time in future. Otherwise you risk to have a pile of working but unmanageable code. Besides, the better the design is, the less time coding requires. When everything is thought out thoroughly, there’s very little left to do.

You could also consider code reviewing. Development will take longer, but a lot more time will be saved on fixing bugs.

In the company I work, every piece of somewhat big design is discussed with our team-leader. Nothing is coded without his OK. I assume, you should be the very person in your team who would approve design. If you think you don’t have enough skills, you could do this together with other members of your team, who are most skillful. During code reviews you could gather the whole team and tell them about those improvements: how and why they were made. This is important, because (a) everyone will learn and (b) there is a big chance you’ll get some good ideas from you less experienced colleges.

I can detect something from your question:

You seem to think that “improving” software architecture is possible. This is not true. Every modification you’re doing can only break the original design idea – the ideas you had years ago were already forgotten and something else replaced them.
What you can do is “try to follow existing architecture.” This takes effort to understand and follow it. Should only do such improvements which follow the existing architecture. The architecture gets stronger once people stop inventing new stuff and just follow the existing patterns.
Over time software is going to get more complicated. This can hide the original structure of the software if the new stuff is inventing new patterns.

Filed under: softwareengineering - @ 06:46

Thẻ: architecture, design, object-oriented-design

Thiết kế website giá rẻ

Danh mục

software architecture (OO design) refresher course [closed]