Care About Your Craft
除非你在乎能否漂亮地开发出软gQ否则其它事情都是没有意义的?
2、思考！你的工作
Think!About Your Work
在你做某件事情的时候思考你在做什么。不间断地思考，实时地批判你的工作。这占据你的一些宝贉|_酬劳则是更ؓz跃地参与你喜爱的工作、感觉到自己在掌握范围日增的各种主题以及因感受到持箋的进步而欢愉。从长远来说Q你在时间上的投入将会随着你和你的团队变得更ؓ高效、编写出更易于维护的代码以及开会时间的减少而得到回报?
3、提供各U选择Q不要找y脚的借口
Provide Options,Don't Make Lame Excuses
不要说事情做不到Q要说明能够做什么来挽回局面。不要害怕提求，也不要害怕承认你需要帮助?
4、不要容忍破H户
Don't Live With Broken Windows
不要留着“破窗?#8221;Q低劣的设计、错误的决策、或者糟p的代码Q不修。发C个就修一个。如果没有够的旉q行适当的修理，采取某种行动防止q一步的破坏Qƈ说明情势处在你的控制之下?
如果你发C所在团队和目的代码十分漂亮——编写整z、设计良好，q且很优雅，?/em>不会x为第一个弄脏东西的人?
5、做变化的催化剂
Be a Catalyst for Change
你不能强qh们改变。相反，要向他们展示未来可能会怎样Qƈ帮助他们参与Ҏ来的创造?
设计Z可以合理要求的东西，好好开发它。一旦完成，拿l大家看Q让他们大吃一惊。然后说Q?#8220;要是我们增加...可能׃更好?#8221;假装那ƈ不重要。坐回椅子上Q等着他们开始要你增加你本来想要的功能。h们发玎ͼ参与正在发生的成功要更容易。让他们瞥见未来Q你p让他们聚集在你周围?
6、记住大图景
Remember the Big Picture
如果你抓一只青蛙放q沸水里Q它会一下子跛_来。但是，如果你把青蛙放进h里，然后慢慢加热Q青蛙不会注意到温度的缓慢变化，会呆在锅里，直到被煮熟?
不要像青蛙一栗留心大图景。要持箋不断地观察周围发生的事情Q而不只是你自己在做的事情?
7、质量成ؓ需求问?/strong>
Make Quality a Requirements Issue
你所制作的系l的范围和质量应该作为系l需求的一部分规定下来。让你的用户参与权衡Q知道何时止步，提供_好的软g?
8、定期ؓ你的知识资投资
Invest Regularly in Your Knowledge Portfolio
9、批判地分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自q看法和你的项目的情况d信息q行分析?
10、你说什么和你怎么说同样重?/strong>
It's Both What You Say and the Way You Say It
11、DRY原则——不要重复你自己
DRY - Don't Repeat Yourself
pȝ中的每一知识都必须h单一、无歧义、权威的表示。与此不同的做法是在两个或更多地方表辑一事物。如果你改变其中一处，你必记得改变其它各处。这不是你能否记住的问题Q而是你何时忘记的问题?
12、让复用变得Ҏ
Make it Easy to Reuse
你要做的是营造一U环境，在其中要扑ֈq复用已有的东西Q比自己~写更容易。如果复用很ҎQh们就会去复用。而如果不复用Q你们就会有重复知识的风险?
13、消除无关事物之间的影响
Eliminate Effects Between Unrelated Things
我们惌设计自Qself-containedQ的lgQ独立，h单一、良好定义的目的。如果组件是怺隔离的，你就知道你能够改变其中一个，而不用担心其余组件。只要你不改变组件的外部接口Q你可以放心：你不会造成波及整个pȝ的问题?
你得C个主要好处：提高生率与降低风险?
14、不存在最l决{?/strong>
There Are No Final Decisions
没有什么永q不变——而如果你严重依赖某一事实Q你几乎可以定它将会变化。与我们开发Y件的速度相比Q需求、用以及g变得更快。通过DRY原则?a >解?/a>以及元数据的使用Q我们不必做多关键的、不可逆{的决{。有许多Z设法保持代码的灵zL，而你q需要考虑l持架、部|及供应商集成等领域的灵zL?
15、用曛_Ҏ到目?/strong>
Use Tracer Bullets to Find the Target
曛_弹能通过试验各种事物q检查它们离目标有多q来让你q踪目标?
曛_弹代码含有Q何一D品代码都拥有的完整的错误查、结构、文、以及自查。它只不q功能不全而已。但是，一旦你在系l的各组件之间实C端到端（end-to-endQ的q接Q你可以检查你ȝ标还有多q，q在必要的情况下q行调整。一旦你完全瞄准Q增加功能将是一件容易的事情?
16、ؓ了学习而制作原?/strong>
Prototype to Learn
M带有风险的事物。以前没有试q的事物Q或是对于最l系l极其关键的事物。Q何未被证明的、试验性的、或有疑问的事物。Q何让你觉得不舒服的东ѝ都可以通过制作原型来研I。比如：架构Q已有系l中的新功能Q外部数据的l构或内容；W三方工hlgQ性能问题Q用L面设计等{?
原型制作是一U学习经验，其h值ƈ不在于所产生的代码，而在于所学到的经验教训?
17、靠q问题领域编E?/strong>
Program Close to The Problem domain
计算a会媄响你思考问题的方式Q以及你看待交流的方式。用你的用户的语aq行设计和编码?
]]>
egQ?br> 1. 没有null reference?
2. reference必须有初倹{?
3. 使用reference要比使用指针效率高。因为reference不需要测试其有效性?
4. 指针可以重新赋|而referenceL指向它最初获得的对象
(参：http://dev.csdn.net/article/17/17286.shtm )
]]>