共计 1374 个字符，预计需要花费 4 分钟才能阅读完成。
-- 这世界有那么多张三 复制代码最近整顿文档时，偶尔看到几年前的某个我的项目，一时衰亡便载入 IDE，瞬间勾起很多回顾，唏嘘感叹之余，也对本人的代码品质感到羞愧。
因为有些代码，我居然看不懂了，霎时又对当年的本人莫名崇拜，原来本人也已经写过这么“高深莫测”的代码。某个刹那，竟盲目技不如从前，当初越发感觉编码就跟写作文一样，满满的套路和不置可否的话。要说看不懂，那纯正是口是心非，努致力还是能晓得什么意思的，但真的不容易看懂：两百行的函数，数十个参数，各种全局变量，重要的是，还没有正文。
或者过后感觉，这么简略，齐全没必要写正文。现在看来，全然不是那么回事儿。
翻完本人的旧我的项目，还是来总结下之前犯下的谬误。
- 多正文代码首先是给人看的，更多的时候是给本人看的，所以还是对本人好一些。把重要要害的信息正文起来，毕竟好忘性不如烂笔头。正文写好，代码的可读性个别不会太差，看不懂代码还能看正文搞懂逻辑。但正文并非越多越好，如果代码能容易看懂，就没必要写正文了。所以咱们要 减少代码表达力，从变量命名到逻辑拆解，都要让代码更易懂。
- 小函数两百行的函数大体上是一段“坏”代码，相同，超过二十行的逻辑，就应该思考是否须要拆分。逻辑拆分，实质是逻辑解耦，看似很简略，但其底层逻辑却发人深思。小函数其实更容易进步代码复用性，毕竟反复永远是俊俏的。函数应该有尽量少的参数，这也意味着函数的逻辑趋势繁多，这也是设计哲学中，繁多职责准则的体现。
- 多应用类事实世界中充斥对象，而代码世界恰好是真实世界的镜子，这就是要面向对象编程的底层逻辑。把逻辑封装进函数，更多是面向过程编程；把逻辑封装进类，则更多是面向对象编程。对象是过程更高一层的封装。
- 胖模型瘦视图在 MVC 设计模式中，模型和视图都能够承载逻辑，但更优的计划是：胖模型瘦视图。即把逻辑封装在模型办法中，给模型赋予更多的性能，从而能够大幅度缩小视图层的复杂性。胖模型瘦视图同时也更符合高内聚低耦合的指标。
- 重视设计模式设计模式是经典的，场景化解决方案，其实笔者开篇说的代码中充斥套路，就是设计模式。程序员能够分为两类，一类不晓得设计模式，一类纯熟应用设计模式。当你真心了解设计模式，你便会切实地感触到，这两种程序员之间的差距。所以，如果有工夫，请尽早学习设计模式。
- 分层设计多应用类，实质上把逻辑纵向拆分；分层设计，则是把逻辑横向拆分。就像汉堡一样，每一层都是不同的滋味，他们组合起来才是美味。分层设计和设计模式，是代码易保护的关键所在。
- 进步可读性后面所有的技巧，都为进步代码的可读性。想让代码看起来像自然语言，就必须要高度重视命名。尽管取名字往往难以抉择，其实也有法则可循，比方：类名多应用名词，函数名多以动词结尾等等。不要胆怯名字长，计算机并不关怀名字有几个字母，只有有助于了解，长点又何妨。命名是切记不要应用微软晚期的匈牙利命名法，比方变量后面对立加上 m_。如果每个变量都要加，那为什么不都省略呢，为何要多此一举。进步可读性另一个要留神的是，把逻辑相关性的代码放到一起。代码和作文一样，都有先后顺序，段落之间也都有关联关系。相干逻辑放一起，省得还要承前启后。
- 总结本文仅仅是从笔者的旧我的项目延展，并未升华到哲学高度。但已表白分明，应该如何思考能力让代码更加易读易保护。倡议各位有工夫也翻翻本人的旧代码，你会发现总有改良的空间。
正文完