如何应对复杂软件开发？

鞠禄亮

此文成形于极客时间《设计之美》，作为自己的学习笔记。对于重点内容，做些记录。当然有需要的朋友也可以学习，也推荐大家去极客时间去学习。

• 从设计原则和思想的角度来看，如何应对庞大而复杂的项目开发？
  
• 从研发管理和开发技巧的角度来看，如何应对庞大而复杂的项目开发？
  
• 聚焦在Code Review 上来看，如何通过Code Review保持项目的代码质量？
  

封装与抽象

抽象和封装还能有效控制代码复杂性的蔓延，将复杂性封装在局部代码中，隔离实现的易变性，提供简单、统一的访问接口，让其他模块来使用，其他模块基于抽象的接口而非具体的实现编程，代码会更加稳定
分层与模块化

模块化是构建复杂系统的常用手段。每个小的团队聚焦于一个独立的高内聚模块来开发，最终像搭积木一样，将各个模块组装起来，构建成一个超级复杂的系统。
分层也是我们常用来架构复杂系统的方法。每一层都对上层封装实现细节，暴露抽象的接口来调用
面对复杂系统的开发，我们要善于应用分层技术，把容易复用、跟具体业务关系不大的代码，尽量下沉到下层，把容易变动、跟具体业务强相关的代码，尽量上移到上层。
基于接口通信

在设计模块（module）或者层（layer）要暴露的接口的时候，我们要学会隐藏实现，接口从命名到定义都要抽象一些，尽量少涉及具体的实现细节。
高内聚、松耦合

能让我们在修改或者阅读代码的时候，聚集到在一个小范围的模块或者类中
封装、抽象、分层、模块化、基于接口通信，都能有效地实现代码的高内聚、松耦合。反过来，代码的高内聚、松耦合，也就意味着，抽象、封装做到比较到位、代码结构清晰、分层和模块化合理、依赖关系简单，那代码整体的质量就不会太差。
为扩展而设计

满足开闭原则，做到代码可扩展 比如封装和抽象，基于接口编程等 识别出代码可变部分和不可变部分，将可变部分封装起来，隔离变化，提供抽象化的不可变接口，供上层系统使用
KISS 首要原则

简单清晰、可读性好，是任何大型软件开发要遵循的首要原则 如果你对现有代码的逻辑似懂非懂，抱着尝试的心态去修改代码，引入 bug 的可能性就会很大。
在参与大型项目开发的时候，要尽量避免过度设计、过早优化，在扩展性和可读性有冲突的时候，或者在两者之间权衡，模棱两可的时候，应该选择遵循 KISS 原则，首选可读性。
最小惊奇原则

《Unix 编程艺术》提到一个 Unix 的经典设计原则，叫“最小惊奇原则”，英文是“The Least Surprise Principle”。实际上，这个原则等同于“遵守开发规范”
遵从统一的编码规范，所有的代码都像一个人写出来的，能有效地减少阅读干扰

博途

我擦！我要沙发！