像写书一样写代码，好的代码应该如好文章一样表达思想，被人读懂

书是人类用来记录一切成就的主要工具，也是人类交融感情，取得知识，传承经验的重要媒介，读书可以明理。可以获取知识，但这一切的前提是书中言之有物、结构清晰可以被人读懂。

像写书一样写代码，好的代码应该如好文章一样表达思想，被人读懂。

程序是开发者用编程语言写成的一本书，首先应该是记录开发者对业务需求分析、系统分析，最终用软件实现所思所想的知识的记录与传承。其次才是完成程序放在服务器上运行只是他的副产品。

但事实上在工作中，很多时候结果为导向，各种敏捷开发、快速迭代开发逻辑让我们我们疲于应对无休止的需求，尤以小公司更甚，但这不应该是我们所写代码难以读懂的理由。

书有目录，目录是书中知识的高度提炼和浓缩，具有极强的概括性，通过阅读目录能提纲挈领地了解全书的主旨和各部分内容，阅读目录可以从整体上把握全书的结构布局，清楚地了解全书各章节及章节与章节之间的逻辑关系，进而能体察作者写作该书的思想和行文脉络。

程序有架构设计，软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

一个项目的软件代码是项目业务逻辑的具体描述，是公司全体开发者共同智慧的结晶。应该如书一样结构清晰可以被人读懂，项目团队的老人写的代码能够被新人按照清晰的目录（系统架构）读懂是项目可维护的基础。一个项目源码随着业务变化、需求增加原有代码可维护、可扩展他就是好的源码。

这些都是常识性的东西，但实际项目中总会有项目在做这推翻原代码重写新版本的需求，也有新人看着老人写的类代码内心一万只羊驼路过，不知道这个类到底是完成什么工作，也不知道类中的某个方法到底是要返回什么结果，因为你发现那些不好的代码一个方法竟然会根据传入参数返回不同类型的值。这样的代码不是要告诉别人自己的想法，而是要别人猜自己的想法。

至于如何让别人读懂自己的代码其实具体到细节还是有许多需要注意的，毕竟编程语言不是自然语言，变量命名、注释、分层等等，各位新手朋友们具体在应用中体会吧。

作为一个开发者，项目进入编码环节之前，所制定的一切规则都可以叫做软件架构，代码分层、设计模式，每一个类的职责，对其的理解与应用是构成了代码实现的整体脉络。进入编码环节之后，合理的代码分层，即将不同的代码放到合适的层，类的单一职责原则像极了一篇文章的中心思想，方法的单一职责原则也像极了文章的段落，一个是文章中最基本的单位。内容上它具有一个相对完整的意思，在文章中用于体现作者的思路发展或全篇文章的层次。

其实写书是要难于写代码的，因为每本书的章节目录都不同，而软件架构设计是可以一样或者大体一样的，不同的只是具体业务需求实现的代码有差异，我们知道有些函数、类都是可以复用的，甚至我们可以肆无忌惮的参考别人的代码应用到自己的coding中，这本身就给写代码降低了难度，如果抛去如何使用框架、扩展包等等，我们编码所作的主要工作就只剩下具体业务逻辑的书写，而这部分coding如果细算实际上占整个项目的比例并不高，业务逻辑代码的编写在实际开发中占的比例并不高，软件架构设计的不合理，编码中不遵循架构既定的原则，都会导致大量的时间都耗费在了已写代码的维护与重构上了。

软件架构师可以通过出色的系统分析来构建可演进的软件架构，就像给一本书制定大纲，按照其内容设定章节目录，软件工程师则通过良好的设计和编程风格来完成任务。软件架构、设计原则本身都是为了更好的服务于代码的可维护、可扩展性，否则也不会牺牲代码运行效率而被广泛接受与运用。

以下摘抄一位朋友在博客中总结的关于优雅代码风格的描述：

代码简单：不隐藏设计者的意图，抽象干净利落，控制语句直截了当。

接口清晰：类型接口表现力直白，字面表达含义，API 相互呼应以增强可测试性。

依赖项少：依赖关系越少越好，依赖少证明内聚程度高，低耦合利于自动测试，便于重构。

没有重复：重复代码意味着某些概念或想法没有在代码中良好的体现，及时重构消除重复。

战术分层：代码分层清晰，隔离明确，减少间接依赖，划清名空间，理清目录。

性能最优：局部代码性能调至最优，减少后期因性能问题修改代码的机会。

自动测试：测试与产品代码同等重要，自动测试覆盖 80% 的代码，剩余 20% 选择性测试。

更多文章

PHP踩坑之旅，这些事情千万不要在开发中继续做了

宅同学问答：学习php有哪些技巧？

宅同学php学习总结：用一张思维导图总结php知识网络体系

老菜鸟献给小菜鸟的关于编程开发的七点建议