在你要写的软件设计中，你遵循的工作流程是什么?

恐怕人们不愿意听到这样的回答。无论如何，让我陈述我的观点。

OOP should be viewed as one of the paradigms, not as the superior paradigm. OOP is good for solving certain kind of problems, like developing a GUI library. It also fits into the style of software development usually followed by large software companies - an elite team of designers or architects lays down the software design in UML diagrams or some other similar medium and a less enlightened team of developers translate that design into source code. OOP offer little benefit if you are working alone or with a small team of highly talented programmers. Then, it is better to use a language that supports multiple paradigms and will help you to come up with a prototype fast. Python, Ruby, Lisp/Scheme etc are good choices. The prototype is your design. Then you improve on that. Use the paradigm that is best to solve the problem at hand. If needed, optimize hot spots with extensions written in C or some other systems language. By using one of these languages, you also get extensibility for free, not just at the programmer level but also at the user level. Languages like Lisp can dynamically generate and execute code, which means your users can extend the application by writing small code snippets, in the language that the software itself is coded! Or if you choose to write the program in C or C++, consider embedding an interpreter for a small language like Lua. Expose functionalities as plugins written in that language.

我认为，大多数时候OOP和OOD所创造的软件都是过度设计的受害者。

总之，我喜欢的写软件的方式是:

使用动态语言。 用这种语言编写设计(原型)。 如果有必要，使用C/ c++优化某些领域。 通过实现语言本身的解释器提供可扩展性。

最后一个特性使软件能够轻松地适应特定用户(包括我自己!)的需求。

首先，设计应该来自你的灵魂。你必须用每一根纤维去感受它。在我开始做任何事情之前，我通常会走两三个月，只是在街上走(真的)。和思考。你知道，散步是一种很好的冥想。所以它能让你更好地集中注意力。

其次，只在存在自然对象层次结构的地方使用OOP和类。不要人为地把它“拧”进去。如果没有严格的层次结构存在(就像在大多数业务应用程序中一样)-选择过程式/函数式，或者至少只将对象用作具有隔离访问器的数据容器。

最后一本——试着读一下:《创造性思维的算法》

尝试使用行为驱动开发。要打破你的旧习惯很难，但我发现BDD确实是你在现实世界中开发的最佳选择。

http://behaviour-driven.org/

斯科特·戴维斯补充说:

Make absolutely sure you know what your program is all about before you start. What is your program? What will it not do? What problem is it trying to solve? Your first set of use cases shouldn't be a laundry list of everything the program will eventually do. Start with the smallest set of use cases you can come up with that still captures the essence of what your program is for. For this web site, for example, the core use cases might be log in, ask a question, answer a question, and view questions and answers. Nothing about reputation, voting, or the community wiki, just the raw essence of what you're shooting for. As you come up with potential classes, don't think of them only in terms of what noun they represent, but what responsibilities they have. I've found this to be the biggest aid in figuring out how classes relate to each other during program execution. It's easy to come up with relationships like "a dog is an animal" or "a puppy has one mother." It's usually harder to figure out relationships describing run-time interactions between objects. You're program's algorithms are at least as important as your objects, and they're much easier to design if you've spelled out what each class's job is. Once you've got that minimal set of use cases and objects, start coding. Get something that actually runs as soon as possible, even though it doesn't do much and probably looks like crap. It's a starting point, and will force you to answer questions you might gloss over on paper. Now go back and pick more use cases, write up how they'll work, modify your class model, and write more code. Just like your first cut, take on as little at a time as you can while still adding something meaningful. Rinse and repeat.

这只是我的个人意见。希望对大家有用。

如果你对你要从事的项目有专业知识，比如银行业。你可以很容易地构建你的对象，而且你知道每隔一天就会有这些增强。

如果你没有这方面的专业知识，那就和有这方面专业知识的人合作，把这些想法转化为技术细节。

如果你对如何组织你的项目设计感到困惑。盲目地遵循“实用的程序员”这本书。我以前也遇到过同样的情况，试着读那本书的一章。它会改变你作为软件开发人员的思维方式。