程序员修炼之道

讲的内容有点玄乎，对于初出茅庐的我们来说，没人指导的话很难想明白深层次的东西。这书啊，还是越有经验看着越有味道

霍炬的序：《程序员升级必备》

当一个程序员水平不够的时候，永远不能认识到那些朴素道理的重要。而当水平达到的时候，这些道理自然会明白。所以一本帮助程序员进阶的书，很容易落到低手觉得是废话，高手也觉得是废话的悲惨境地。

在我心目中，最好的入门书永远是《代码大全》，那也是对我影响最深的一本书。而这本不逊于代码大全的伟大著作。 好书不会因为平台的变化和技术的变迁而消亡，好书只会成为经典。无论是《人月神话》还是《代码大全》，都在时间的长河中沉淀下来，传诵至今。这本书也有10年历史了，不过现在翻来看也毫不落伍，甚至感觉穿透了时间，看到了这些年中不少自己犯过的错误，我相信这也是一本经得起时间沉淀的书，只不过需要多点耐心。

正如本书开头所说：注重时效的程序员应该不断学习。我们都应该不断地学习下去。

徐宥的序：《程序员心底的小声音》

在任何行业，适合新手的入门书很多，适合中手的书就很少。原因有两个，一来高手极少愿意耐心指点成长秘诀，即使写了，也是蜻蜓点水，因为这些经验啊，结论啊，都被他们本身提炼成了珠玑，他们觉得最重要的就是那么寥寥几句，说多了都是废话。而读者往往没有类似的经历，看到这些珠玑，也只是觉得把玩颇为有趣而已，极少能有同感。而没有同感，接受起来效果也不好。二来中手水平参差不齐，偏好不一，挑三拣四，自作聪明，所以也不太喜欢读这些书。 但是还是有一些书的，比如《Pragmatic Programmer程序员修炼之道》《The Art of UNIX ProgrammingUNIX编程艺术》《Elements of Progarmming Style 程序风格珠玑》和《The Productive Programmer卓有成效的程序员》。

能否让正确的原则指导正确的行动本身，其实就是区分是否是高手的一个显著标志。比如KISS，很多人知道，但是能否内化，并用在自己写的程序里，这个可能就是区分中手和高手的标志了。

如何将原则尽快内化成自己的行动？--- 就是说怎样尽快成为高手？ 第一条路需要有一个高强度的环境，没有高强度复杂的文本处理任务，很难内化正则表达式；没有大型多模块项目，很难内化自动化构建和测试。 第二条路就是有意识的反复强化实践和反复提醒。想要内化这些小声音，还是要靠实践，如果不实践，即使你把这些小声音写在100块钱的高档笔记本上也没有用。不妨一段时间反复练习里面的几个tips，内化后再练习其他的。几个月可能就把所有的tips都实践过了。

高手可以看这个书，很可能你对其中一些道理的认识比作者还要深刻。那有什么关系呢，能够帮助你提炼更加圆润的珠玑岂不是更好？

书籍正文的摘录和思考：第一章 注重实效的哲学

注重实效的编程源于注重实效的思考的哲学。

在所有的弱点中，最大的弱点就是害怕暴露弱点。

注重实效的程序员对他自己的职业生涯负责，并不害怕承认无知或错误。遇到各种问题，尽量职业地处理他们。这意味着诚实和坦率。负责，并设法给出各种选择，而不是抱怨他人。

提供各种选择，不要找蹩脚的借口。

这个就最好懂了。工作过的人都知道，谁也不喜欢满嘴借口的人。犯错不怕，就怕犯了错还不承认，不吸取教训，不想弥补。

不要容忍破窗户

一个软件的腐烂可能就是从一个模块腐烂开始的，所以及时修补，省得代码越来越烂。这点驴哥有句话特别好：只要嗅到自己的代码有一点点坏的味道，就要及时修正。 反过来，如果一个项目代码整洁，设计良好，而且很优雅，你就很有可能会格外注意不要去把他弄脏。

请求原谅，比获取许可更容易。

有时候你想做一个事情，畏首畏脚到处去争取许可和同意往往得不到许可和帮助。而你先开始做，让别人看到你的成果，或者起码看到你的勇气。再找资源和获得帮助就会容易得多。你需要做变化的催化剂，而不是等着变化。也让我想起了google做google books的一个原则：书籍先扫描收录（当然只是有限的页码），如果有作者提出不妥，再删除相应的部分。这样可能要比事先设法联系作者，请求许可要容易得多。如果google采取第二种办法，我甚至怀疑他还能不能做成这件事。

记住Big Picture

这个和我在公司的经历差不多，leader总是教育我们要站在更高的层面思考。比如站在组长的层面，站在总监的层面。这样你做的事情才不会在方向上出问题，和上级的沟通也会更加的顺畅。记得翟鸿亮在他的《心路文集》（腾讯内部分享）里画过一张，个人能力和团队贡献度的图。即使你的个人能力箭头再长，和团队的方向不一致，给到团队的分力可能也不够。

使质量成为需求问题

人们往往喜欢现在能用的还ok的软件，不喜欢后天才能用的完美的软件。

知道何时止步

在某些方面，编程就像绘画。如果你不懂何时止步，所有的辛劳就会遭到破坏。如果你一层又一层，细节复细节的叠加，绘画就迷失在来绘画本身了。

知识上的投资总能得到最好的回报。

你的知识经验是你最重要的职业财富。但遗憾的是，知识资产是有实效的。所以你要不停的学习。管理知识资产和管理我们通常意义上的资产有很多相似的地方，比如：1、严肃的投资者定期投资---作为习惯。（定期学习）2、多元化是长期成功的关键。（拓宽你的知识面，比如多种编程语言，你知道的事情越多，你就越有价值）3、聪明的投资者在保守的投资和高风险、高回报的投资之间做出平衡。（不要抱着铁饭碗的死脑筋。不要把你所有的技术鸡蛋放到）4、投资者设法低买高卖，以获取最大回报。（在一个知识大多数人接触前熟练掌握，往往可以使自己更吃香）5、应周期性的重新评估和平衡资产。（周期性的回顾自己的知识结构，看看哪方面需要重点提高）

批判地分析你读到的和听到的

不要人云亦云，要有独立思考的精神和能力。现在这个社会，视图混淆你的视听，扰乱你的步伐的事情太多了。在社区提问时，切记提问的技巧。关于学习，作者也给出了一些实际行动的建议。每一年学习一门新语言。（新工作要求把C++的编程能力提高，或者可以去学一下smalltalk？）每一季度读一本技术书籍。（我的技术书籍不是太少了，而是消化得太少了）

关于交流：你说什么和你怎么说同样重要。

这个在我的工作中体现得尤为明显，有的时候怎么说比说什么本身还重要... 交流越有效，你就越有影响力，真的这样。第二章 注重实效的途径上面一章讲得是哲学（就是讲道理），这一张开始讲途径（方法）。这本书的组织方式和我时间管理课程的思路有点像啊。这一章主要讲的是开发过程中要遵循的一些原则。

系统中的每一项知识，都必须有单一，权威，无歧义的唯一一个解释。这就是DRY原则。

DRY---- Don't Repeat Yourself.

两个方面理解：1、系统中不要存在自相矛盾的两个地方（比如文档和代码的不一致）2、自己不要做重复性的工作避免信息的人工多重表示。比如过多的注释可能造成你改代码时候不得不也改注释，注释很容易被遗忘而变得自相矛盾。改成由文本或代码生成器来生成会更好。而很多的重复也是可以在代码设计阶段解决的。比如一个表示线段的类:class Line { public: Point start; Point end; double length;}; 其中，length显然是可以通过起点和终点坐标计算出来的。那么这里最好可以让他以函数的形式返回。class Line { public: Point start; Point end; double length() { return start.distanceTo(end); }; 而每次这样求length显然很慢。有时候你不得不使用缓存而可能影响DRY原则。那么这么做的诀窍是尽量使得影响局部化。比如提供setStart setEnd接口，使得改变start 或者end都有标识，那么只有length()方法检测到起点或者终点有更新后，才更新length。这个例子还带出来了像Java C++这样面向对象语言的另一个重要的问题：在可能的情况下，总是使用accessor访问器来读写对象的属性。这样是的未来增加功能（比如缓存）变得容易很多。还有很多的重复是程序员偷懒造成的，比如直接拷贝粘贴代码段，而不是将公用的抽取出来做成公共库。比如原来的千年虫问题（程序员偷懒用两个数字代表年份，而不是参数指定）。这个就需要你知道一个道理：现在节省几分钟，可能会导致以后花费数周的时间偿还。开发者之间的重复也太常见了。比如公司内可能很多部门在写着差不多的函数库，比如很多部门在搞分布式数据平台... 比如大家都在写着自己的身份证验证合法性代码... 避免这个问题可能需要两个方面都给力一点，一个是要有强有力和方向明确的领导，各个部门或技术团队之间权责清晰。二个是鼓励技术人员之间的相互交流，比如腾讯的KM平台就是一个很好的例子。

让复用变得容易。

你要做的就是营造一种环境，在其中找到并复用已有的东西比自己编写要容易。如果不容易，大家就不会去复用。就这么简单。正交性。比如MVC可能就比较符合正交性，你动用户界面，不会影响底层数据或者算法。我们就说界面和底层是正交的。比如直升机的控制器就不是正交的。

所以我们说，尽量降低无关事物之间的影响。

你的系统都是正交的组件的话，好处非常的多。1、可以提高生产率，因为正交的系统往往更好测试，往往相乘后的到的组合功能会最大化。2、无疑可以降低变更的风险，正交系统可以得到更好的测试。工作中的正交性不只体现在编码上。团队的任务分配如果正交性太差，则很容易出现相互不符合DRY原则和扯皮的情况发生。成员也就会对责任感困惑。（想想自己原来的团队）在系统设计上，典型的正交性原则是分层设计、模块化和基于组件。在编码上，保持你编写模块的高内聚，低耦合很重要。说白了就是编写羞怯的代码。如果你要改变某个对象的属性，让这个对象自己去完成。测试，建议每个模块都拥有自己的、内建在代码中的单元测试，并让这测试作为常规构建过程的一部分自动运行。（想到了make test）

我在读书的时候就听过着本书的大名，现在网上也有这本书的pdf分享版本。一直就觉得计算机方面的书籍太贵了，致使很都先进的知识得不到有效的普及。程序员修炼之道这本书，以程序员职业规划、所需知识等为线索，提到了一些代码优化，整合知识，但是不够全面。更多www.nsdupiwu.com计算机信息。

软件项目永恒的敌人就是不能按期交付，项目经理的任务在掌握有限资源的情况下，不断地同它做斗争。这需要注意多个方面：首先最重要的是确定方向，同时要细化最终的完成目标，即可交付物是什么。讨论项目的关键驱动因素、约束和浮动因素，列出项目的优先级。这可以在两难的时候帮助取舍，要让你的上级和投资人都进入到这个环节中，这有助于将来抵制出资人过多的功能变更需求等外部压力。其中的难点在于预测未来，识别真正的驱动因素。之后制定项目章程模板，主要包括远景、需求、目标、成功标准、ROI（投资回报率）估算。然后细化其中的每项，配备人员，制定发布条件以及项目风险列表。从项目本身来说，新Bug的发现与修正是早成延期的主要原因，所以要采用先进的生命周期组织方式来管理项目，安排好日程，尽量预测未来风险，同时让项目组内的每个人都意识到这一点。反馈及时，迅速发现错误并修正。将错误留到最后会消耗比当初多几倍的经历成本。安排项目日程也很有学问，原则是注重实效、简单。使用低技术含量的工具安排项目日程，比如贴纸、白板等。识别和避免日程安排游戏，主要就是自欺欺人，盲目乐观可以在某个时间点完成。估算工作的一个技巧就是使用“小石子”，即把项目分成一个一个可以在一两天之内完成的小单元，单元内部应该不可再分，只有“完成”和“未完成”两种状态。要掌控项目，及时回顾。保持项目节奏，持续集成。重点强调，减少技术债务。创建并使用项目仪表板，量化指标。尽量不要在同一时间管理多个项目，项目结束时无论成功与否都要进行总结。会议不可避免，管理会议，需要举行的和不需要举行的。每次会议都能达到目的，不要浪费整个组的时间。人的因素是另外一个主要因素：创建出色的项目团队，招募需要的人，形成团队凝聚力。知道如何应对人。