半步踏入专业的大门（逃

半步踏入专业的大门（逃

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

态度

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

印象很深入的就是，你们老是说：

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

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

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

• ...

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

了解本身的领域（工做领域，业务领域）

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

说 “不” 与 “是”

咱们在团队作东西的时候常常会面临说“不”和说“是”的状况。

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

• “这个项目能不能在何时上线上线”

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

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

• ....

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

本身是否真的尽全力了

每当我被人问及，“你为何不能再某个时间点完成这个任务”的时候，我真的都会去思考，我究竟是不是尽全力了，仍是我真的花费了不少时间来堕落。我我的人为，若是没有进全力去作一件事，是没有资格去说“不”的。不然，至少你的心里要生出一丝愧疚感，这才是正常的。

能不能 与 试一试

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

当你说是的时候，必须是

• 口头上说会作

• 内心认真对待作出的承诺

• 真正行动

我以为一个专业的人，他会说”我将在何时完成什么事“。当你说出一句肯定的许诺的时候，就会认真的对待本身要作的事情。

坚守原则

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

寻找编程的状态

规律的工做时间

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

避免心流和阻塞

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

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

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

压力，焦虑

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

思考的习惯，时机

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

互助

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

Kata

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

下面是一些收集了各类卡塔的网站，里面都是你们喜欢用的卡塔

http://codingdojo.org/

http://katas.softwarecraftsma...

http://codekata.pragprog.com/

测试驱动开发

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

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

我就有这种感受：一个项目写完，程序跑通。可是，我仍是很是担忧我写的不够完整，逻辑不够严密，可能随时会挂。

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

• 可以让你的程序设计更良好。由于，你要作到一个小东西他是可测试的，你就会想着让他的耦合度下降，可以拿出来单独测试

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

• 总体上缩短期。自动化测试的好处在于，你加入了一个新模块后，若是不肯定会不会破坏掉之前的模块，就跑下测试就行了。由于原来的测试程序都在

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

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

学习

时间拆分（番茄工做法）

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

避免钻死

这个已经在上面提到过了

多样性

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

多给别人看本身的程序，多看别人的程序

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

预估

产品通常是没有这个能力来准确预估一个开发、设计须要多长时间的。当被问及完成一个东西须要多久的时候，你是否是会凭感受立刻说一个数呢？是，预估不少时候是凭感受的。可是，我以为比较好的作法是，你和他说等一下。而后你就来算一算本身要多久。显然，一个任务越小，咱们的预估是越准的。因此一个可行的方案就是，你先尽量的把本身的任务拆分红不少不少的小分，而后每一个都给本身留一个，乐观时间，标准实际，悲观时间。而后累加。而后告诉你的产品经理。当你遇到意外超过了你的标准时间，立刻和team里面的人反馈。来作计划修正。

结语

以上都是《代码整洁之道》的一些挑选和思考。由于有我的因素，也不必定是正确的吧。同时不少很比较虚，若是对具体的感兴趣，能够翻翻这本书，挺不错的。