高效能程序员的修炼
俗话说：程序员不能只想着写代码。在编程以外的闲暇时间，读一点这种有助于程序员扩展视野和提高素养的书籍是很好的。
笔者找到了这本《高效能程序员的修炼》：本书作者是大名鼎鼎Stack Overflow的创始人Jeff Atwood，内容是有关代码以外的，需要每个程序员思考和注意的事情。
这本书是笔者在今年1月份看的，因为忙于项目开发，所以没有整理好笔记。正好这周五公司app提交过审，有空宅在家里整理一下。笔记内容没有提到书中所说的每个方面，只是针对了笔者觉得比较重要的几点并结合了笔者自己的想法和感悟整理而成。
笔者的读书笔记的格式：
标题：与书中目录不符，完全由笔者自己列出。
�正文：浅灰色框中的文字为书中摘录，其他部分均为笔者个人观点。
欢迎各路大侠指点！欢迎各路大侠指点！欢迎各路大侠指点！
关于选择工作
我更建议人们先花时间想想，什么样的问题才是他们真正热爱和感兴趣的，然后再好好研究这些问题。生命中最难的，是想清楚你真正想要做的事情，而不是学上一堆假设将来会有用的东西。
所以说在决定这种人生大事上，确实要花上心思，就好比笔者自己在通信工程专业从本科一直念完了硕士，拿到硕士学位证后花了一周的时间苦思冥想，探求内心后，毅然决定做软件，顶住各方压力(因为毕竟是换专业择业，不过还好父母还是一直很支持我的)三个月的时间自学了iOS开发。
如今已经入职4个月，在工作学习中甚感愉快，虽然有时会有压力，但是每天都过得很开心，因为这正是我想做的。
关于程序员的表达能力
杰出的程序员和勉强过得去的程序员之间的差别是他们能不能把他们的想法表达清楚。
大家应该不会怀疑程序员的平均智商，但是程序员中每个人的表达能力却参差不齐，差别极大。其实有些时候头脑中想到的方法可能是在潜意识下想到的，如果这时候需要我们有条理地说出来，确实不是一件容易的事。
像这种用意识层面的语言来表达潜意识的思考的能力确实是值得锻炼的。试想一下，如果我们能把自己潜意识层面的思考准确地再现于意识层面，那么这显然会有助于帮助我们检查思维的缜密性和正确性，而且也会锻炼我们的逻辑思维，从而能更好地去思考，形成良性循环。
关于程序员的学习：
勤加练习固然重要，但是只顾着买头写代码，没有讨论和反思的时间，那么是无法得到真正的进步的。在阅读博客和相关书籍的过程中，从自身利益出发去考虑，如果我们能从中找到哪怕一点对我们有用的东西，其实就已经很赚了。
复习和反思是学习过程中很重要的环节，如果没有及时的复习与反思，那么往往事倍公半：忘记知识，而且就算不忘，也无法高效地将知识提取出来。作为程序员，应该适当脱离键盘反复思考，将学到的知识高效地整合到自己的知识结构中，有助于知识的提取和运用。
关于代码
- 评价及代码的几个维度:从简洁性开始，依据测试的结果按需提升其他的维度。
- 代码简洁度
- 功能完整性
- 执行速度
- 编码所花费时间
- 健壮性
- 灵活性
- 你的代码越多，bug能藏身的地方就越多。
- 最好的代码就是完全没有代码。
关于代码的注释
- 注释需要说：程序为什么这样工作。
- 你应该总是专注于编写代码，而忘了还有注释这种东西的存在。
- 当我脑子里了一个明确的目标，并且有一段复杂的代码要写时，我会把时间花在时间代码上面，而不是写下他的故事，讲给我自己听。
- 如果你的代码在没有注释的情况下显得过于复杂，很难被人理解，那只能说明你的代码写得太早了，重写代码，直到它不再需要任何注释。
读到这里的时候笔者很是惭愧。因为笔者在写代码的时候，是将代码和注释一起写的。所以应该将这个习惯改过来：写代码的时候忘记注释，应该尽全力用代码自己解释逻辑。到最后逻辑达到很清晰的程度后，再加上必要的注释：为什么用的是这个逻辑。
关于请教问题
- 向别人请教问题：
- 提供足够多的细节描述发生的状况
- 说明你为什么需要这个答案
- 表述你所做的研究和发现
- 如果你想让别人花上宝贵的时间来帮助你，你也要花了宝贵的时间酝酿出一个合格的问题才算公平。
笔者在工作中也会请教同事问题，前几次问的时候发现自己将问题说出来之后，自己头脑里已经有了解决的办法，而且觉得很简单。所以后来想问问题的时候，保证自己先解决一般问题，将问题深入，然后尽可能问出高质量的问题来。
关于提出问题
- 提出正确的问题差不多已经把问题解决了一半。
- 完全投入地向一个假想中的人或者是没有生命的物体问一个透彻而相近的问题。
笔者认为如果是对一个无生命体，大脑中负责情感的部分会被抑制，会更加促进理性分析，更加清晰地表述问题(因为你的潜意识知道小黄鸭*是不会“理解”你的话里半点遗漏的点)。
关于创意和执行
- 如果你想要赚钱，你必须把这两者相乘，除非创意被执行，否则它一文不值，执行是创意的倍增器，真正价值巨大的是执行。
- 与其担心你全心投入等下一个创意是否足够出色，不如担心你能执行的多好。
- 在软件开发领域，执行意味着专注于构成你的应用程序的所有微小细节，如果你不是始终沉迷于你的应用程序的每个方面，不去优化和赶紧它的每一处细节，那么你就不是在执行，至少，不是在很好地执行。
关于团队
- 如果你把一个好的创意给一个普通的团队，他们会把它搞砸。如果你把一个普通的创意给一个好的团队，他们会对它加以完善，或者他们会把那个创意丢掉，然后相处一些更棒的 - Catmull"
- 如果你想取得成功，不要担心没有伟大的创意，转而去专注于培养卓越的团队。
关于会议：
会议绝不应该超过一个小时。
每个会议都要有一个清晰的目标声明。
在开户之前做好功课：提前知道将要讨论和分享的内容。
把会议变成可选的：每一个人都因为他们想要在那里，或者需要在那里。
会议结束后，概括一下待办事项。
其实会议确实比较耗费时间，所以就要为了提升会议的效率和价值：
- 在会议开始前：熟悉会议内容并提前思考。
- 在会议结束前：整理会议结果，列个待办事项。
- 在会议结束后：执行！执行！执行！
关于用户和产品
- 用户不会阅读你屏幕上的任何东西。用户只会读取屏幕上足以让他们完成任务的，最少量的文字。
- 与世隔绝在实验室花上三个月的时间修复第一版里的问题，不如把这3个月的时间用于倾听来自真实世界里使用你的软件的用户提出的反馈。
这两条分别告诉我们：
- 我们在做产品的时候，应该把用户当成“弱视不会思考”的人。
- 用户可以“为我们所用”。
看似是矛盾的两点，但确是提升用户体验的“黄金理论”。
对于第一条，笔者深有体验:笔者做了一个类似新手引导的教程，因为队友修改了页面加载的逻辑，导致了用户只能通过，点击，滑动，手动加载后才能出现看到教程的情况，而刚看到页面时，教程是不会自动出来的，其实这个体验是很差的，因为用户需要自己动手。但是当时由于已经处于测试末尾阶段，我个人也没有在意。
在跟产品经理交流后，产品经理人很好，只是说了最好要加上。我想了想还是加了，添加的方法很简单，只是在viewWillAppear方法里加了触发的逻辑，但却发现体验直线上升。这件事对我感触很大，只是一两行代码就能明显改善用户体验，那么为什么不去做呢？为什么一定要去麻烦用户去动脑，去动手呢？
笔者结语：
本书中，作者说的点还是蛮多的，比较杂，但确是引发程序员代码之外思考的好的启蒙，有助于不让程序员局限于代码之中，能够多角度，多层面考虑问题。
本文已经同步到我的个人博客：传送门，欢迎常来^^
本文已在版权印备案，如需转载请访问版权印。48422928
网友评论