软件开发原则、模式与实践

一、前言

软件开发这么多年，只有《敏捷软件开发：原则、模式与实践》这本书，是每隔一段时间会拿出来读读的。大家把架构师想的特别高大上，其实架构是一种职责，有些公司也会专门设置岗位，我们在设计系统模块，设计子系统的时候，已经是在履行架构师的职责了，在好几百万行的庞大系统里面，没有哪个架构师可以hold全局，各个子系统子模块，都在不断迭代，发现在一些大厂，反而没有了架构师这个岗位，但是架构却实实在在的在演进着，朝着更加符合业务的方向去发展....架构设计，成为每个资深工程师及以上岗位都必须掌握的一项技能了。

乘着有空，重温这本书，每次读都有新的感觉，今天做一些摘录和整理。

二、敏捷软件开发宣言

1. 个体和交互 胜过 过程和工具
   • 强调人与人之间的沟通和协作，认为团队中的个体及其交互是软件开发中最重要的因素，而不是仅仅依赖流程和工具。
2. 可以工作的软件 胜过 面面俱到的文档
   • 强调实际可运行的软件的重要性，认为软件的价值在于它能做什么，而不是写了多少文档。
3. 客户合作 胜过 合同谈判
   • 提倡与客户紧密合作，频繁交流，以便更好地理解和响应需求变化，而不是通过详尽的合同来锁定需求。
4. 响应变化 胜过 遵循计划
   • 强调在软件开发过程中要灵活应对变化，通过迭代和反馈来不断调整和优化计划，而不是坚持一个固定的计划不变。

三、十二条原则

1. 最高优先级的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 欣然面对需求变化，即使在开发后期也不例外。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 业务人员和开发人员必须每天在一起工作。
5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 可以工作的软件是进度的主要度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使未完成的工作最大化的艺术——是根本的。
11. 最好的架构、需求和设计出自于自组织的团队。
12. 团队定期地反思如何能提高成效，然后相应地调整自身的行为。

敏捷软件开发宣言及其原则为软件开发领域带来了深刻的变革，促进了更加灵活、高效和以客户为中心的软件开发方法的兴起。

我们也要结合实际情况来应用，敏捷开发及结对编程和客户一起工作等， 可能客观原因比较难做到，但是阶段性的沟通机制，还是要去建立的。

 

四、软件设计的臭味

日常工作中，如何识别设计的优劣呢，可以通过以下几个方面去做判断：

僵化性(Rigidity): 设计难以改变。单一的改动，会导致有依赖关系的模块连锁改动，那设计就是僵化的。
脆弱性(Fragility): 设计易于遭到破坏。进行一个改动时，程序的许多地方就可能出现问题（特别是没有概念关联的功能）。
牢固性(Immobility):设计难以重用。功能难以抽离重用，分离出来的努力和风险是巨大的。
粘滞性(Viscosity):难以做正确的事情。难以保持软件已有的设计，容易被诱导破坏设计。
不必要的复杂性(Needless Complexity): 过分设计。软件变得复杂又难以理解。
不必要的重复(Needless Repetition): 滥用鼠标。及时抽象而不是频繁拷贝，减少维护成本。
晦涩性(Opacity): 混乱的表达。代码不够清晰和有表现力，他人难以维护。
这些症状在本质上和代码的“臭味”(smell)相似”，但是它们所处的层次稍高一些。它们是遍及整个软件结构的臭味，而不仅仅是一小段代码。

软件设计的最终目标，应该是高内聚、低耦合，具备良好的可扩展性，容易修改和维护。

 

五、面向对象设计最重要的五个原则（solid）

面向对象设计原则是一系列指导性的准则，旨在帮助开发者在设计软件时，创建出更加灵活、可维护、可扩展和可复用的系统。这些原则基于面向对象编程（OOP）的基本概念，如封装、继承、多态等，并且强调软件设计中的高内聚、低耦合等特性。以下是一些常用的面向对象设计原则：

1、单一职责原则（Single Responsibility Principle, SRP）：

一个类应该仅有一个引起它变化的原因。这意味着一个类应该负责一组相对独立的功能，而不是过多地承担其他不相关的责任。

2、开闭原则（Open-Closed Principle, OCP）：

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。这意味着软件应该通过添加新的代码来扩展功能，而不是修改已有的代码。

3、里氏替换原则（Liskov Substitution Principle, LSP）：

子类型必须能够替换掉它们的基类型。这是多态的基石，即派生类（子类）对象能够替换其基类（超类）对象被使用，而程序逻辑不会改变。

这个很好理解不做过多的解释，原则就是不要让子类搞幺蛾子，闹革命，不要重写父类的方法，如果存在重写父类方法的行为，基本就违法了里氏替换原则了。

4、依赖倒置原则（Dependency Inversion Principle, DIP）：

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。这通常通过接口或抽象类来实现，以减少模块间的耦合。

解释：著名的哈佛原则：don't call us，we'll call you，倒置的是接口所有权，高层模块定义接口，底层模块实现接口。这样高层模块就不依赖底层细节了。

5、接口隔离原则（Interface Segregation Principle, ISP）：

不应该强迫客户依赖于它们不使用的方法。这意味着一个类对另一个类的依赖应该建立在最小的接口上，接口应该尽可能小。

六、结束语

整体过了下，面向对象设计的基本原则，后续会继续更新基于设计原则的设计模式，熟练掌握设计模式，对于阅读源代码，自己设计框架，引导多人合作，都有很好的益处，作为未来的架构师，建立技术影响力，这方面的基本功是马虎不得的。

如果觉得不错，请收藏或者点赞支持，小红点是我持续更新的动力之一，感谢~