程序员修炼之道(一)

程序员修炼之道(一)

最近两周突然就忙了起来，需求一个接着一个，短时间内还不能完全适应的我有些手足无措心力交瘁，不过通过加班总归是缓了过来。所幸产出的代码经过师父的review之后没啥大问题，遂打算抽点时间总结一下近期的工作经验。
由于本人挺喜欢《程序员修炼之道》这本书(现在第二版已经由云风翻译完成)，个人认为里面提到的不少观点和建议对程序员(尤其是我这种彩笔)大有裨益，而且这些宝贵的经验也能在工作实践中得到反向验证，故此类涉及程序员解决问题的方法论的相关问题探讨都会以这本书的名字命名，这篇博客算是开个头吧(也不知自己能不能坚持下来)。

一、始终以解决问题为目标

“只要目标是对的，偏离方向的可能性就会小很多，然后如何实现目标往往只是一个时间问题。”
对程序员来说，解决问题就是实现需求，实现需求就是首要目标(听起来像是一句废话)。但是在面对一个大型项目时，一个需求从最初的提出到最后的测试通过，整个过程中涉及到的人员和要素很多，开发人员可能会因为各种原因产生偏离目标的奇怪想法，仅以本人为参考，举几个例子：

1. 理顺了需求，正在思考如何设计。同事A:对于需求里的某件事，我打算这么处理blabla，你看怎么样？(和我没什么关系，随他咋处理吧)
2. 正在写代码，同事B总是经常提醒：这里你可以参考。。。那里你可以这样，然后你还可以看看那个。。。思路各种被打断。
3. 每个人各司其职把自己的工作做好就行。
4. 同事C的做事节奏好慢(我自己手上有活还要一边帮他调试，还挺烦的，懒得管了)。

对于以上几点，我总结出的经验就是：

1. 很多时候你无法定义哪些事情是"你自己的工作"，这会导致一种情况的出现：每个人写自己的代码，然后问题在最后才暴露出来，拖慢进度。但如果第一反应是把许多工作视为"需要共同解决的问题"就会好很多(事实上也确实是这样)，团队成员可以通过沟通提早发现并解决一些问题，这样带来的正反馈既节省了沟通成本，又能提高工作效率。
2. 情绪问题是难以避免的，但是不适合带到工作中来，多告诉自己解决问题为重。要么想想是否可以改进某些令人厌烦的流程，要么就忍忍吧(草)。
3. 实际上如何与他人沟通、了解他们的做事风格和情绪等也是你在解决问题的过程中会碰到的困难之一，能否把它们也视为问题的一部分来处理？(就好像是闲暇之余学习人类行为和心理学- -)

如果你在实现需求的过程中经常提醒自己"首要目的是解决问题"，以上三点都是比较容易察觉并总结出来的。

二、如果你不能将正在做的事描述为一个流程，那么你就不知道自己在做什么

“代码是意图的体现，而如果连意图都无法表述清楚，就完全没有写代码的必要了。”
对于大型项目而言，如果能在一开始将需求尽可能详细地描述为一个或多个流程，不仅能更加精准地把握需求的进度和开发方向，又能以"分而治之"的方法将大问题分解成小问题逐一破解，也便于团队成员在出现问题时快速定位问题发生在哪个具体环节。
以游戏为例，大部分需求可以概括为玩家的观察、思考、输入、得到反馈的一个流程。而站在客户端程序的角度，就可以进一步翻译为：玩家从登陆游戏再到退出的过程中，客户端需要根据玩家的输入做出什么反馈，如何处理产生的数据，回应服务器下发的消息的整个流程。
同时也不难发现，基于这个方法结合需求设计和实现代码，各个子流程又能不断向下被细分为若干个单一职责的类、接口或函数，代码的内聚性能够得到一定保证，也有利于后期代码的扩展和维护。

三、补上破窗户

“你是来解决问题的，在解决一个问题之后又引入了一个新的问题等于啥也没干。”
项目发展到一定规模之后，最初的代码都会难以避免地出现逐渐腐烂的迹象，所谓的屎山就是这么来的。扒完层层屎山后毫不犹豫地往上再堆一坨，虽然能解决燃眉之急，但对项目代码的维护来说毫无裨益。如果时间允许的话，趁着还能吹嘘一下自己有一点职业操守，能改一点是一点。一次简单的封装，一个简洁的接口，说不定能让下一个倒霉的程序员找到一丝慰藉。

四、负责任

老生常谈了，be a man, bro.

以上观点都可在《程序的修炼之道》一书中寻到蛛丝马迹。个人认为，不仅是程序员，对于每一个人来说，做事的方法和态度始终贯穿整个职业生涯，影响着自己看问题的角度，以及思考并解决问题时产生的认知。然后这些认知又反过来不断修正自己得出的方法论和经验，在不长不短的职业生涯里形成一个良性循环，个人才得以不断发展和进步。虽然有时候这些所谓的态度在他人看来可能是愚蠢、中二或是没啥意义，但是有些自己的坚持，对社会或是国家，甚至是世界，能做出一丢丢贡献也是极好的。