编码之道：是谁制造了混乱

21 January 2015

项目随着时间的推移，开发人员换过了一波又一波，项目的代码被一些代码风格“狂野”的新同学们“强奸”了一遍又一遍。我们游戏服务器代码从09年时的50W行激增到现在的200W行，不得不赞叹：“还真是能写啊！”。代码混乱的程度，简直不忍直视：风格迥异的命名方式、得以米计算长度的函数、各种MagicNumber，让人摸不着头脑、缺少封装导致的大量重复代码、各种奇葩的缩进方式、拥挤在一堆，就不知道敲个空格或空行会浪费多少时间啊...。

更多内容：http://game-lab.org/posts/zoc-cleancode-1/

是谁制造了混乱？

是程序员的作茧自缚，和项目对于规范的不重视。

游戏开发对于策划或产品他们来说，他们是不会看到代码的，更不会关心代码质量和整洁的。他们只会要求你实现了某个功能，这份代码帮他们赚了多少钱，快速、保质保量地实现他们提出的各种需求。需求永远不会停止，并且还都有严格的时间节点。最终导致的开发团队，都疲于奔命，功能都写不完，还有谁会在乎规范这件事情。“能把功能实现就行了！”，这是多数人的想法。

这样的情况，存在一个恶性循环：无止境的需求->赶时间些的缺乏规范代码->制造混乱->仿照混乱的代码制造更多的混乱。 最终就是：更多的需求->更乱的代码。

归根结底，代码是我们自己写的，经验不足，缺乏规范和前辈的指导，往往会养成不好的习惯。由于：

• 规范的缺失，在写代码的时候，没有规则可依，只能按照自己的喜好来，或者仿照前辈们的代码风格，导致了各种风格迥异的代码，第一眼看过去就不想再读下去了。

• 没有经常进行重构，导致了混乱的设计，和持续积累的恶臭代码。

混乱引起了不少麻烦

面对遗留系统，先辈的各种“神作”和自己做的孽，导致：

• 修改已有功能的时候，很容易摸不着头脑，一头雾水。要想在原有系统上修改点东西，迈出任何一步，都如履薄冰，不得不小心翼翼，一不留神就掉“坑”里面了。往往很容易听到，接受这样任务的同学们的叹息和咒骂！

• 查BUG得时候，那叫一个大海捞针啊！没有GDB，估计早都撞墙了，有些时候就算是有GBD也得折腾个半天才能有点眉目。不过大家战斗力都可以，经过几番折腾，都还是找得到。

• 添加新功能的时候，特别是新同学，看着前辈的神都看不懂的代码，一知半解，只能摸着石头过河了，或者就照猫画虎，再加点自己独特的风格。恭喜，您又把代码给“强奸”了一遍。

该是“救赎”的时刻了！

面对如此规模代码，想做点重构，往往望洋兴叹，不知从何下手。曾经不知有多少次有此想法，又多少次放弃。

需求不止，混乱不息！打破这个恶性循环的杠杆就在：制定规范，和养成重构的习惯

• 添加新需求的时候，尽量遵循规范和代码整洁的编码原则；在写完代码准备入库的时候，能简单的整理一遍是最好的了。
• 在修改BUG、优化功能的时候或抽空，找出混乱的代码，来一次重构，养成回头看的习惯。

小结

代码就是程序员的孩子，也是程序员的一张脸，代码是些给人看的，不是写给自己孤芳自赏的，更不是写给编译器，让编译器认识就行的！

代码的“救赎”是整个开发团队的事情。制定规范，并遵守之；养成重构的习惯。只要形成这个良性循环，再混乱的代码，也会向着一个整洁的方向在演化，

整洁代码，指日可待！！(PS. 3周时间，我们团队已干掉10W多行废弃的代码，这个数字对于手游和一些APP，基本上算是全部代码了)

到底是谁在作恶？是我们自己！！