半步踏入专业的大门（逃

半步踏入专业的大门（逃

这两周看了《代码整洁之道》（其实这本书并不是具体教你怎么写代码的，而是教你怎么成为一个专业的开发），感觉很多东西确实说的很有道理，我也正在逐渐去落实。下面我就挑选了一些我认为我们团队的开发所欠缺的一些素养，融合我自己的一些观点、经历来提取一些建议。

态度

不要忽略任何一个问题的（bug, 缺陷，设计不合理......）地方

印象很深刻的就是，大家总是说：

• “我知道我的代码写的很烂”

• “这里只能怎么怎么样，不能怎么怎么样”。

• “当这里怎么样的时候，可能会出问题”

• ...

一个人是很基本不可能写出完美的程序的。但是，一个基本的素养就在于，一旦知道这个地方是有问题的，就马上去改。这个时候多花的时间要远远比你出问题来再来修复要来的快（同时也有价值）。举个例子，当时我在开发亮灯的时候，项目推进的比较急，同时对工具不熟悉。我选择了完全过程式的写死了所有的接口。当时我也知道这样做不对，但是就放过了这个问题。然而，问题就像滚雪球一样，越滚越大，以至于后来，我自己的不能很好的理解自己的程序，每加一个功能都举步维艰。那个时候真的是非常黑暗的一段日子。因此，只要你知道你的程序在哪个地方不合理，就应该尽快的去修正他。

了解自己的领域（工作领域，业务领域）

在团队，可能做技术的（我一直认为，产品，设计，运营也算是技术，只是技术点，技术形式不一样）大多有一个误区：衡量一个做技术的人是否专业，就在于他的专业知识学习的量。不是这样的。技术是多个维度的。做东西是，他既需要了解自己的工作领域（就是从事方向的知识，比如开发就包括算法，设计模式等），也需要了解自己的业务领域。如果是编写招新的筛选系统，你就应该对整个招新的流程，面试官需要什么，报名的人需要什么进行了解；如果是编写写作的程序，你就应该去了解每个作家的习惯，行业的标准。最不专业的做法就是对着原型，原型说明文档写程序，却对里面为什么是这样不求甚解。相反，你应该能辨别，质疑规格说明书。了解业务领域还有一个好处就是，你对未来会有一定的预见性，你可能会有意识的往某些方面留个后手，用于扩展。

说 “不” 与 “是”

我们在团队做东西的时候经常会面临说“不”和说“是”的情况。

• “你能不能在这周完成某个功能”

• “这个项目能不能在什么时候上线上线”

• “你能不能在某个时间点之前把图出完”

• “你能不能在什么时候把粉丝数增到多少”

• ....

基本上在做项目的时候我们无时无刻的都会面临这个问题

自己是否真的尽全力了

每当我被人问及，“你为什么不能再某个时间点完成这个任务”的时候，我真的都会去思考，我到底是不是尽全力了，还是我真的花费了很多时间来堕落。我个人人为，如果没有进全力去做一件事，是没有资格去说“不”的。否则，至少你的内心要生出一丝愧疚感，这才是正常的。

能不能 与 试一试

大家都是人，人性都是有弱点的：我们大家总是会趋向于护住面子，避免承担责任或是避免冲突。当你说出试试的时候，意思你之前的想法并没有尽自己的全力，你还有额外的精力去做；抑或有新的方案。如果你没有额外的经历，又没有新的方案，那说试一试的时候你是不是就是为了自己能做完也是对的，不能做完也是对的？这本质上也是不诚实的表现。同时回忆，自己有没有说过“我是该做什么事情了”，“我希望做什么事情了”这样的话。然后最终结果是怎么样的？

当你说是的时候，必须是

• 口头上说会做

• 心里认真对待做出的承诺

• 真正行动

我觉得一个专业的人，他会说”我将在什么时候完成什么事“。当你说出一句确定的许诺的时候，就会认真的对待自己要做的事情。

坚守原则

当你进了全力的时候，如果是不能完成的，这个时候就应该坚定的说”不“。同时，对于ddl的问题，我个人认为，如果真的是为了整个team好，是不应该为了ddl而放弃一些原则的。比如说，你不应该因为赶时间就不做测试；你不应该因为赶时间就选择放弃良好的设计，而去堆代码。

寻找编程的状态

规律的工作时间

有一些不好的现象就在于，炫耀自己熬了多少夜，把自己的晚睡作为一种荣耀，这是一种畸形的行为。要想为什么会让自己熬夜，是不是因为自己在精神状态好的时候时间没充分利用（这个时候去熬夜还算态度端正....）。事实上，你真的相信自己半夜精神状态不佳的情况下写出来的程序吗？也许，你这个时候搞出来的东西，会成为你日后的梦魇。

避免心流和阻塞

不知道大家有没有过这种感觉：有时候你会进入一种非常玄妙的状态，感觉自己写程序效率超高，沉迷于编程不能自拔。你会不会感觉这很爽？其实事实上这并不一定是一件好事。因为大多数情况下，你在这种状态是的目光是非常狭窄的，你并不能站在一个非常全局的角度其思考，去设计。我就有过这样的经历，在写寻她这个项目的时候，写了一大堆之后发现和我原来的设计是冲突的....

和心流相对应的一种状态就是堵塞。有时候会有这么一种感觉，你怎么也不想写程序了，或者说怎么样都写不出程序了。

感觉解决心流和堵塞的方式就是：找个人和你一起结对编程。你们一起写程序的时候，可能时不时的会交流一下，遇到问题相互解决一下。这实际上就是一个中断的过程，中断了进入心流。同时，不知道大家有没有这种体验，和别人一起干活的时候，自己也会想着去做事情。如果结对不能解决你的问题，不妨暂时离开，出去走走。

压力，焦虑

之前程序组有位新人和我说：我最近又要考试，又要做任务，感觉真的什么都做不好，觉得十分焦虑。对于这种情况，我觉得比较好的就是，可以找个人沟通，寻求一些支援；同时要把有限的时间真正规划好，在做事情的时候就不要想别的了，毕竟焦虑也没用是吧。同时就是，即使时间紧，也要坚持自己的原则，危机中也要有纪律。因为纪律之所以为纪律，就是帮助你度过难关的。

思考的习惯，时机

大家在写程序的时候，有时候会遇到一些问题不能解决。这个时候你会怎么办？一直盯着你的显示器硬杠？我觉得，平时要适度的知道什么时候自己应该离开一下。同时，自己平时也要养成思考的习惯。我自己就曾经在自行车上，在洗澡的时候解决过不少问题。平时可以培养出一种节奏。

互助

当你遇到一个问题死杠杠不出来的时候，感觉是时候去询问一下别人的看法。我知道程序员都比较闷骚，都喜欢自己独立去解决问题。这是我们的优点，也是我们的弱点，没有绝对正确的事情，把握好平衡，该和别人交流时候就交流。评判一个东西是否学通，不再与你自己是不是觉得自己懂了，在于能不能用自己的话，逻辑清楚的把他讲明白，同时听的人也能听明白。所以，咨询的时候，无论是对己，还是对人，都是有好处的。

Kata

卡塔就是当你每天开始编程的时候，都花个10分钟左右，用你希望熟悉的语言，写一个你已经知道怎么解决了得问题。这个称之为变成柔道场。这不是为了真正解决问题，而是在于练习你需要解决这个问题所需要的动作和决策。叫编程柔道场的原因就在于，柔道就是为了训练你能在真正需要的时候不需要思考就能出招。我最近的一个星期就以快排作为我的卡塔，目前能在2分钟内写出一个正确的快排。

下面是一些收集了各种卡塔的网站，里面都是大家喜欢用的卡塔

http://codingdojo.org/

http://katas.softwarecraftsma...

http://codekata.pragprog.com/

测试驱动开发

这个我推荐老人去试试，不推荐新人去试（因为可能你再也写不出程序了....）。

相信大家已经好久没经历过以前那种，写几行程序，然后就能编译，连接，运行看到结果那种欣喜的感觉了。目前的状态时你可能会写出好大一坨代码。然后最后去试试他能不能跑通。这样一个不好的点在于你的测试数据并不嫩敢保证测试到所有的模块。

我就有这种感觉：一个项目写完，程序跑通。但是，我还是非常担心我写的不够完整，逻辑不够严密，可能随时会挂。

测试驱动开发就是你在每写一段小程序之前，先写他的测试程序，然后写好之后马上测试。这样的一个周期在十几分钟。测试驱动开发的好处在于：

• 能够让你的程序设计更良好。因为，你要做到一个小东西他是可测试的，你就会想着让他的耦合度降低，能够拿出来单独测试

• 中断心流。实际上一次测试就是一个中断，如果没通过，就要回去修，直到通过了测试

• 整体上缩短时间。自动化测试的好处在于，你加入了一个新模块后，如果不确定会不会破坏掉以前的模块，就跑下测试就好了。因为原来的测试程序都在

• 反馈及时而细致。通过单元测试，你能马上定位到，程序是那个模块出了问题。

• 文档。事实上，你的测试就是你的文档。

学习

时间拆分（番茄工作法）

比较理想的状态是，手头上有一个项目。这样就能很好的平衡项目和学习的时间。一个好的做法是把任务都按时间拆分成多个时间段吧。可以参考番茄工作法

避免钻死

这个已经在上面提到过了

多样性

一个人只有一个技术是比较难活下去的，可以多尝试不同的东西。比如你原来是写Java这样的静态语言，你就可以试试Python这样的动态语言；如果原来是用IDE的，不妨试试用文本编辑器，然后自己编译，运行，调试；如果平时习惯用图形界面，不妨去体验一下命令行的威力.....

多给别人看自己的程序，多看别人的程序

不要因为觉得自己的程序写的搓就不好意思给别别人看。想想都知道这样不是一件好事情。想要进步，还是要不断的突破自我吧。多看别人的程序，能看到别人是怎么考虑问题，怎么去设计的，吸收别人的一些长处。我基本上...每看一个人的代码.....写程序套路都会变一下....

预估

产品一般是没有这个能力来准确预估一个开发、设计需要多长时间的。当被问及完成一个东西需要多久的时候，你是不是会凭感觉马上说一个数呢？是，预估很多时候是凭感觉的。但是，我觉得比较好的做法是，你和他说等一下。然后你就来算一算自己要多久。显然，一个任务越小，我们的预估是越准的。所以一个可行的方案就是，你先尽可能的把自己的任务拆分成很多很多的小分，然后每个都给自己留一个，乐观时间，标准实际，悲观时间。然后累加。然后告诉你的产品经理。当你遇到意外超过了你的标准时间，马上和team里面的人反馈。来做计划修正。

结语

以上都是《代码整洁之道》的一些挑选和思考。因为有个人因素，也不一定是正确的吧。同时很多很比较虚，如果对具体的感兴趣，可以翻翻这本书，挺不错的。