最近在阅读《程序员修炼之道–从小工到专家》，书中提出的很多实用性建议和提示，所有的建议和提示都能为我在项目中节省很多时间，帮助我更快更高效的完成我的工作。我认为作为一个程序员这本书是必须拥有的。
1、我的源码让猫给吃了
—-在所有的弱点中，最大的弱点就是害怕暴露弱点
责任是你主动担负的东西。你承若确保某件事情正确完成，但你不一定能直接控制事情的每一个方面。但我们犯错误，或者是判断失误时，我们应该提供各种选择，不要找蹩脚的借口。
不要说事情做不到，要说明能够做什么来挽回局面。
2、软件的熵
—熵是指某个系统中的“无序”的集合
不要留着“破窗户”（低劣的设计，错误决策、或是糟糕的代码）不修。运行良好的系统一旦窗户开始破裂，就相当迅速地恶化。
记得我在做一个项目需求时，把解析配置信息的功能实现放到了一个配置管理类中，当时【chaofan】跟我说，这样做不合理，配置管理类的职责是负责加载和存储配置，如果你带头把其他的功能实现放到该类，那么，后续可能会有更多的人把与该类不相关的实现放进来，于是该类会不断恶化，这就是“破窗户”理论。
如果你发现你所在团队和项目的代码十分漂亮—-编写整洁、设计良好，并且很优雅，你就很可能会格外注意不去把它弄脏。
3、石头汤和煮青蛙
—— 做变化的催化剂
当我刚看到这个标题时，摸不清是什么意思。石头汤是什么？跟煮青蛙又有什么关系？
大多数软件灾难都是从微不足道的小事情开始的，大多数项目的拖延都是一天一天发生的。系统一个特性一个特性地偏离其规范，一个又一个的补丁被打在某段代码上，直到最初的代码一点没有留下。常常是小事情的累积破坏了士气和团队。
【lvfei】多次跟我谈到，我们做项目需求的时候不能像打补丁一样，在项目上修修补补，这样虽然能短时间解决需求，但却会使项目越来越糟。就像青蛙感觉不到慢慢变热的水，最终被煮熟一样。
要持续不断地观察周围发生的事情，而不只是你自己在做的事情。【lvfei】曾今也这么跟我说过，多去了解别人做的需求，不要求你了解透彻，但你要知道该需求要达到的目标是什么。这有利于自己对项目的全局把握。
4、足够好的软件
—–欲求更好，往往会把事情办遭
现实世界不会让我们制作出十分完美的产品，特别是不会有无措的软件，但是我们可以训练自己，编写出足够好的软件。所有系统必须满足用户需求，才能取得成功。
无视用户需求，一味地给程序增加新特性，或是一次又一次润饰代码，这不是有职业素养的做法。
今天了不起的软件常常比明天更完美软件更加可取，让用户及早的使用我们编写的软件，他们的反馈常常会把你引向更好的最终解决方案，不断完善我们的产品。
不要因为过度修饰和过去求精而毁损完好的程序，这有点画蛇添足的味道，适得其反。
给你做一个选择题
某公司有一个不完整的软件，作为用户，你会：
A、等着他们清除所有bug，使用最完美的软件
B、允许有某些bug，但是使用起来比较复杂
C、有缺陷，使用起来比较简单。
5、你的知识产权
—– 知识上的投资总能得到最好的回报
早起的鸟儿有虫吃，那早起的虫子呢？
你的知识和经验是最重要的职业财富。但是它们是有时效的资产，会变得过时的。
管理知识资产
（1）定期投资（作为习惯）
（2）多元化投资 ———你知道的不同事情越多，你就越有价值。今天的热门技术明天可能变得几乎无用。不要把所有的技术鸡蛋放到一个篮子里。
（3）利用自己的资产获取最大的回报
（4）周期性地评估和平衡资产
目标：
（1）每年至少学习一门语言。不同的语言以不同的方式解决相同的问题，通过学习若干不同的方法，可以帮助你拓宽你的思维，并避免墨守成规。
（2）每季度阅读一本技术书籍。
（3）多阅读非技术书籍
（4）试验不同的环境
（5）学习沟通技巧，加强与周围人的交流
如果你自己找不到答案，就去找出能找到答案的人，不要把问题搁在那里。
询问技巧：
确切地知道你想要问什么，并尽量明确具体
小心而具体的组织你的问题，记住你是在求助别人，不要显得好像是在要求对方回答。
组织到好问题后，听下来，再找找答案。
6、交流
没有有效的交流，一个好想法就只是一个无人关心的孤儿。
知道你想要说什么: 简略记下你要交流的想法，并准备好几种把它们将清楚的策略。
了解你的观众：
做倾听者：如果你想要大家听你说话，你必须使用一种方法：听他们说话
回复他人：随时通知别人，会让他们更容易原谅你偶然的疏忽，并让他们觉得你没有忘记他们。
交流越有效，你就越有影响力
7、重复的危害
可靠的开发软件、并让我们开发更易于理解与维护的唯一途径，是遵循DRY（Don’t Repeat Yourself）原则。
不可信任的注释比完全没有注释更糟！
8、正交性
在计算机术语中，正交性表示某种不相互依赖性或是解耦性
提高生产率：改动得以局部化；促进复用；
降低风险：更容易寻找问题，使得系统更加健壮
项目团队的管理也与正交性相关，如果团队的组织有许多重叠，各个成员就会对责任感到困惑。
设计，模块化、基于组件、分层。系统应该由一组相互不依赖的组件构成，每个组件的实现都不依赖于其他组件的功能。
让你的代码保持解耦；避免使用全局数据；避免编写相似的函数。
9、曳光弹
项目永远不会结束，总有改动需要完成，总有功能需要增加，这是一个渐进的过程！
10、纯文本的威力
纯文本的缺点：存储纯文本所需空间更多；解释和处理纯文本的计算代价更高
11、shell游戏
GUI的好处是所见即所得，缺点是所见即全部所得！
当你想要组合一些命令，已完成一次查询或者其他任务时，命令行要更加合适！
12、强力编辑
精通一种编辑器，选择一种编辑器，彻底了解它，并将用于所有的编辑任务！
我使用许多不同的编辑器，但只使用其基本个性。那么我需要选择一种强大的编辑器，好好学习它。精通一种编辑器能大大的提高生产率和工作效率。在这方面【lvfei】教会了我很多，刚进项目组的时候，他就教会我使用编辑器的各种快捷键，分析数据时，教我如何使用正则表达式快速获取需要的数据。
13、源码控制
把整个项目置于源码控制系统的保护之下具有一项很大的好处：你可以进行自动的和可重复的产品构建。
我们项目的源码控制就是采用的svn，项目自动化集成采用的jenkins，Jenkins从svn拉代码进行项目构建，非常方便非常好用。
14、调试
没有人能写出完美的软件，所以调试肯定要占用你大量的时间。要修正问题，而不是发出职责。
如果你目睹bug或者见到bug报告时的第一反应是“那不可能”，你就完全错了。一个脑细胞都不要浪费在以“但那不可能发生”起头的死路上，因为很明显，那不仅可能，而且已经发生了。
要抵制只修正你看到的症状的急迫愿望。要总是设法找出问题的根源，而不只是问题的特定表现。
找出问题的原因的一种非常简单、却又特别有用的技术就是向别人解释它。向他人解释问题时，你必须明确地陈述那些你在自己检查代码时想当然的事情。确实，当你跟别人解释代码时，可能问题就从屏幕上跳出来了。
如果没有显而易见的地方让你着手查看，你总是尅依靠好用的老式二分查找。
在面对“让人吃惊”的故障时，你必须意识到你的一个或更多的假设是错的。不要因为你“知道”它能工作而轻易放过与bug有牵连的例程或代码。
如果bug是一些坏数据的结果，这些数据在造成爆发之前传播通过了若干层面，看看在这些例程中进行更好的参数检查是否能更早地隔离它。