程序员修炼之道:从小工到专家
今天终于把pragmatic programmer, the: from journeyman to master给读完了，历时好几个月，中间断断续续，没想到自己能坚持到最后。
, 有些章节我是一眼飘过了。
读完之后对我还是挺有帮助的，表现在下面几点。
一 what makes a prgmatic programmer (如何成为务实的程序员)
1 early adopter / fast adapter: 快速适应新的开发环境，新项目，新团队
2 inquisitive: 对新技术充满好奇，好问
3 critical thinker
4 realistic : 分析问题的本质，而不是表面现象
5 Jack of all trades: 万事通，多熟悉几个开发环境，几门语言，几种开发方法。（以前觉得精通一项就可以了，作者并不认为这样。现在来看多掌握一些技术有利于触类旁通，实际点的就是跳槽也容易些）
二 Invest Regularly in your knowledge portfolio (如何让自己变得强大，相信你如果做到了以下几点，你的工资奖金肯定不会低，如果低的话免费推荐来我们公司——MicroStrategy)
1 Learn at least one new language every year
2 read a technical book each quarter
3 read nontechnical books, too. (我去，hunt等人的要求也太高了吧)
4 take classes
5 participate in local user groups
6 exeperiment with different enviroments. (嗨，以前也确实坚持过一阵用linux，现在工作上用不着又淡忘了)
7 stay current
8 get wired (常常上网，看看最近的技术趋势，最近好像数据中心，云计算搞得很火)
三 pragmatic approach
1 DRY,don't duplicate yourself. 如果你参与过大型项目，那么你一般都会深刻体会到这一点的重要性。当你在使用ctrl +copy键的时候，一定要记得把重复的代码提取出来，这也许是你重构代码的最好时机。如果放任不管，因为代码冗余，程序的可维护性能将立马下降一个等级。
当然，有时候我们可能允许一些代码冗余，或者需要代码冗余，例如某些相同的逻辑在客户端和服务器上都需要存在，这时最好是用宏或者脚本来生成这些代码。
2 Orthogonality, 功能模块，项目组之间相互独立，不要有重叠的部分。
3 Reversibility, 软件开发的速度有时候远比不上硬件或者用户需求变得快，所以软件可能需要在开发的过程中更改已有的逻辑。这需要软件有灵活的架构
四 debugging strategies
1 don't panic, the best start fixing a bug is to make it reproducible. 在fix issue的时候，确实不应该慌。不要先盲目的去调试，先看看issue是否能被重现。如果不能被重现，有可能是已经被fix了，或者QE的reproduce step有问题，所以需要先和QE确认。
2 think over. 自己加的，个人觉得如果issue是能够重现的，先得自己想想逻辑，猜猜哪些地方可能出问题了。
3 tracing
4 regression test, 我觉得fix issue之后，至少得运行几个基本的case，确保不会引入大的问题
五 DBC, design by contract
1 assertive programming, 使用assert真是一个艺术，它能基本确保程序在按照我们的想法跑。
2 crash, and crash early, don't trash. 开发阶段，另可让程序crash,也不能在出现错误后，让程序继续运行；这样容易暴露出程序的问题。
3 delight user not superise them. 不要做自以为很酷的东西，要符合用户的需求
六 Decoupling
1 put abstractions in code and details in metadata. 有时候我们可以利用配置文件，元文件极大的降低模块之间的耦合程度，提高程序的可维护性。
2 Design using services
3 design for concurrency ,从设计初就考虑是否需要并发性
4 sperate view and model
5 blackboard , 黑板模式，作者用了侦查员分析给警员分析罪犯的例子，非常形象的解释了blackboard模式。各个警员不需要知道其他警员是否存在；各个警员的知识背景都可以不同；在侦查员分析的过程中，有可能有新的警员加入，也有可能又警员离开；在黑板上可以放置不同的内容，如图片，文字。如果你的用户场景也符合上诉条件，那么blackboard可能非常适合你的系统
七 Test
1 find bugs once, 测试人员手动测试发现bug后，下次同样的bug测试人员不应该手动测第二遍，而应该交给机器来做。例如测试人员用case1发现了bug1, 那么下次在跑自动化测试的时候，就应该把case1加入到baseline里，这样测试人员就不用手动再测试bug1是否存在了。
