第七十六章 第4章 设计原则
第七十七章 原则62 将设计追溯至需求
原文：软件部署后，当检测到故障时，维护人员需要快速分离出那些最有可能包含故障原因的软件组件。在维护期间，当一个软件组件被修复时，维护人员需要知道哪些需求可能会受到不利的影响。
目前贴吧，产品文档建设不健全，功能归一性不强，经常看代码好像有什么功能，但是无法确认对应代码还用不用。无法确认影响面
第八十章 原则65 封装
原文：大多数软件模块应该对所有其他软件隐藏一些信息
根据经验来判断，在日常写需求的时候只暴露一定会用到的方法和属性，不要暴露“日后可能会用到的”方法和属性。
第八十一章 原则66 不要重复造轮子
原文：不要重复造轮子
这里面的不要重复造轮子，不仅说是自己重新实现一遍功能，也包括直接成段的复制代码。
第八十三章 原则68 避免大量的特殊案例
原文：在你设计算法时，无疑会发现存在许多例外情况。例外情况会使得特殊案例被加入算法。每一个特殊案例都会使你更难调试，并使其他人更难修改、维护和增加功能。
其实不仅是在代码的设计阶段，在需求功能方面也存在类似的问题，比如交互逻辑经常考虑不全面，造成不得不在源代码上增加一些，看起来没问题，但是存在隐患或未知的问题。例如：回复框
第九十章 原则75 为维护而设计
原文：为维护而设计
保证下一个人能读懂。个人觉得这是最重要的原则，一开始无论设计的多么优雅，高级，下一个维护的人看不懂，都没有意义。改着改着就面目全非