原文关键总结：
1、Every good work of software starts by scratching a developer's personal itch.
每一个好的软件起因都是挠到了开发者本人的痒处。
2、Good Programmers know what to write.Great ones know what to rewrite(and reuse).
好的程序员知道写什么。伟大的程序员知道改写（和重复使用）什么。
3、"Plan to throw one away;you will,anyhow"(Fred Brooks,The Mythical Man-Month,Chapter 11)
“计划扔掉一个；无论如何你都会扔掉一个的。”（弗里德.布洛克《人月神话》第11章）
4、If you have the right attitude,interesting problems will find you.
如果你有正确的态度，有意思的问题会找到你。
5、When you lose interest in a program,your last duty to it is to hand it off to a competent successor.
当你对一个项目失去兴趣时，你的最后的职责是把它交给一个称职的继承者。
6、Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
把用户像合作者来对待是通往快速改进代码和有效调试的最佳通道
7、Release early.Release often.And listen to your customers.
早发布。常发布。听取用户的意见。
8、Given a large enough beta-tester and co-developer base,almost every problem will be characterized quickly and the fix obvious to someone.
如果beta测试者和合作开发者的群体足够大的话，几乎每个问题都会快速显形，会有人轻而易举地把它解决。
9、Smart data structures and dumb code works a lot better than the other way around.
聪明的数据结构和愚蠢的代码要比反过来好得多。
10、If you treat your beat-testers as if they're your most valuable resource,they will respond by becoming your most valuable resource.
如果你以“最有价值资源”来对待你的beta测试者，他们会以成为“最有价值资源”来回应。
11、The next best thing to having good ideas is recongizing good ideas from your users.Sometimes the latter is better.
仅次于拥有好的主意的是认识到来自于用户的好主意。有时候后者更好一些。
12、Often,the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
最有突破和创新的方案常常来自于意识到你把问题的模型弄错了。
13、"Perfection(in design) is achieved not when there is nothing more to add,but rather when there is nothing more to take away."
“设计达到完美的时候，不是增加得不能再增加了，而是减少得不能再减少了”。
14、Any tool should be useful in the expected way,but a truly great tool lends itself to uses you never expected.
任何一个工具都应该达到预期的作用，但是一个真正棒的工具会带来你从来预期不到的用处。
15、When writing gateway software of any kind,take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!
在写任何关口软件的时候，花点功夫尽可能不要干扰数据流-除非用户强迫你，永远不要扔掉任何信息！
16、When your language is nowhere near Turing-complete,syntactic sugar can be your friend.
当你的语言离图灵穷尽还差得远的时候，给语法加点风味可以有帮助。
17、A security system is only as secure as its secret.Beware of pseudo-secrets.
一个安全系统的安全性取决于它保守的秘密的安全性。小心伪秘密。
18、To solve an interesting problem,start by finding a problem that is interesting to you.
要解决一个有意思的问题，首先找到一个你觉得有意思的问题。
19、Provided the development coordinator has a communications medium at least as good as the Internet,and knows how to lead without coercion,many heads are inevitably better than one.
如果开发的协调者有一个至少和互联网一样好的通讯媒介，而且懂得如何不通过强迫来领导，多个头脑不可避免地优于单个头脑。
几年前还在做程序员的时候读过一次这篇文章，当时并没有太多的感受，只是激发了我想做一个自己在开源世界中做些什么的冲动。因为是做c#的原因，当时找了大量的c#开源软件，想找一个契机参与进去，最后选定了DNN。06年做了DNNFamily网站进行DNN的技术推广工作，并提供DNN主机服务，后来因为工作原因这个事情也就不了了之了。这次重读，少了当年的冲动，多了些实际的思考。我目前的工作是企业IT部门管理，涉及软件开发管理工作，去年开发团队进行了敏捷开发的转型。所以，我想结合企业内部项目软件开发管理和敏捷开发两方面谈谈我对本文的读后感。 一、畅想“企业内部系统开源” 企业内部的软件项目往往涉及企业业务流程，不适于对外公开，而且因为各企业业务的差异，开源后对其他用户的价值也不大。如何能让企业内部软件项目享受到“集市”带来的好处呢？我有几点想法： 1、将中间件、公共组件开源，这类代码不涉及具体业务，而且复用性强，能为更多人带来价值。 2、企业内部共享代码，所有人可以接触到所有代码，记录每个人的贡献作为激励手段。 3、尽量应用开源系统、中间件，为员工创造接触开源项目的机会。 4、借鉴优秀实践，比如“早发布。常发布。听取用户的意见。”等。 二、“开源”和“敏捷”，以工程师为本的软件开发模式 近两年敏捷在国内异常火爆，我们也有幸在11年引入了敏捷开发（袁斌老师是我们的启蒙老师）。工程师是一类特殊的人群，他们兴趣广泛，但是他们可以专注于自己喜欢的事情上；他们喜欢隐藏自己的喜怒，但是他们渴望得到认可；“给我一个支点，我可以撬动地球”，他们笃信通过自己的双手他们可以实现任何奇迹；他们有自己的信仰，他们渴望完美。 为什么会有无数素未谋面的人为了开源项目无私地贡献自己的时间和代码，这是工程师的本性使然。他们无法忍受不完美，他们希望自己创造奇迹，他们希望得到认可。“开源”和“敏捷”之所以成功与流行是因为他们创造了“工程师的天堂”。
