Writing Great Software [closed]_问答_开发者_运维开发者技术经验分享

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I'm currently reading Head First's Object Oriented Analysis and Design. The book states that to write great software (i.e. software that is well-designed, well-coded, easy to maintain, reuse, and extend) you need to do three things:

Firstly, make sure the software does everything the customer wants it to do
Once step 1 is completed, apply Object Oriented principles and techniques to eliminate any duplicate code that might have slipped in
Once steps 1 and 2 are complete, then apply de开发者_C百科sign patterns to make sure the software is maintainable and reusable for years to come.

My question is, do you follow these steps, and in this order, when developing great software? If not, what steps do you usually follow inorder to ensure it's well designed, well-coded, easy to maintain, reuse and extend?

Object orientation is not something you bolt on as an afterthought - you start with OO analysis and design and proceed to an OO implementation. I suspect you may have misread or misinterpreted the book. Similarly with design patterns - they are not add-ons.

I disagree with #1 because most great software needs several major iterations to become truly great. The only other way to actually achieve #1 (on the first try) is to copy some other already-great software. But to come up with something new and unique (like I did with ClipMate in 1991), you make your best effort, then release it to the world to see what customers have to say about it. Through repeated cycles of re-assessing the product as a result of customer input and interaction, you eventually achieve great software.

I've read this book. I think there is some mis interpretation everywhere.

Firstly, make sure the software does everything the customer wants it to do

The book is saying to make sure you understand the customer requirements before starting a design.
Once step 1 is completed, apply Object Oriented principles and techniques to eliminate any duplicate code that might have slipped in

The book says to design with O-O principles
Once steps 1 and 2 are complete, then apply design patterns to make sure the software is maintainable and reusable for years to come.

Use design pattern.

I'd normally start with an object-orientated design. It would have to be a pretty quick dirty/hack not to need #2 and #3. The trouble is, not to overdose on them.

If I'm interpreting it correctly, it sounds a little ridgid. But perhaps the intent is correct - 1) can be paraphrased as "stay focused", in particular focusing on the business needs. That doesn't mean ignore all coding needs, but getting the balance right. There are many code changes and refactorings that no doubt improve the quality of the code, but these have to be weighted up against the time taken, risks, and delays caused to the project. As a developer, it's all too easy to (over)priorize code changes above business needs.

Applying OO principles later sounds impractical - if you haven't used OO principles, how was the software that does what the customer wants built in the first place? Perhaps it's hinting to continual refactoring, KISS, and reducing up-front design in favor of an iterative development cycle.

There is an element of truth in 3) - recognising patterns after the software is built and refactoring to isolate common repeated elements, but I think of this as a natrual consequence of an iterative development cycle.

First and foremost great software must do everything the customer needs it to do and at least most of what the customer wants it to do. These are not the same thing. Also it is better to start off with something small and simple, and evolve it rather than trying to build everything in one ginormous app.

As for the other two points, they seem a bit confused. Avoiding duplication is a design principle, but only one of many. Why single it out for special consideration? Rather than (say) Programming to interfaces? Or Tell don't ask? Or Avoid broken windows?

Hmmmm...

When I started typing this response I intended to say I don't think you can retrofit OO techniques or design patterns. But having thought about it some more it has occured to me that this is not the case. It is quite common in TDD practice for the initial implementation - the simplest thing which gets the code to pass the test - to be quite procedural. But once the code passes its tests there is a cycle of refactoring which applies design patterns and produces a more objected-oriented implementation.

Great Software is based on good design and clean programmation with approving design pattern ( MVC, process component..).