通往务实的提示

 

1. 关注你的技艺
2. 思考！思考你的工作
3. 你有权选择
4. 提供选择，别找借口
5. 不要放任破窗
6. 做推动变革的催化剂
7. 牢记全景
8. 将质量要求视为需求问题
9. 对知识组合做定期投资
10. 批判性地分析你读到的东西和听到的东西
11. 英语就是另一门编程语言
12. 说什么和怎么说同样重要
13. 把文档嵌进去，而不要栓在表面
14. 优秀的设计比糟糕的设计更容易变更
15. 不要重复自己
16. 让复用变得容易
17. 消除不相关事物之间的影响
18. 不设最终决定
19. 放弃追逐时尚
20. 使用曳光弹找到目标
21. 用原型学习
22. 靠近问题域编程
23. 通过估算来避免意外
24. 根据代码不断迭代进度表
25. 将知识用纯文本保存
26. 发挥Shell命令的威力
27. 游刃有余地使用编辑器
28. 永远适用版本控制
29. 去解决问题，而不是责备
30. 不要恐慌
31. 修代码前先让代码在测试中失败
32. 读一下那些该死的出错信息
33. “select”没出问题
34. 不要假设，要证明
35. 学习一门文本处理语言
36. 你无法写出完美的软件
37. 通过契约进行设计
38. 尽早崩溃
39. 使用断言去预防不可能的事情
40. 有始有终
41. 在局部行动
42. 小步前进——由始至终
43. 避免占卜
44. 解耦代码让改变更容易
45. 只管命令不要询问
46. 不要链式调用方法
47. 避免全局数据
48. 如果全局唯一非常重要，那么将它包装到API中
49. 编程讲的是代码，而程序谈的是数据
50. 不要囤积状态，传递下去
51. 不要付继承税
52. 尽量用接口来表达多态
53. 用委托提供服务：“有一个”胜过“是一个”
54. 利用mixin共享功能
55. 使用外部配置参数化应用程序
56. 通过分析工作流来提高并发性
57. 共享状态是不正确的状态
58. 随机故障通常是并发问题
59. 用角色实现并发行时不必共享状态
60. 使用黑板来协调工作流
61. 倾听你内心的蜥蜴
62. 不要依靠巧合编程
63. 评估算法的级别
64. 对估算做测试
65. 尽早重构，经常重构
66. 测试与找Bug无关
67. 测试是代码的第一个用户
68. 既非自上而下，也不自下而上，基于端对端构建
69. 为测试做设计
70. 要对软件做测试，否则只能留给用户去做
71. 使用基于特性的测试来校验假设
72. 保持代码简洁，让供给面最小
73. 尽早打上安全补丁
74. 好好取名；需要时更名
75. 无人确切知道自己想要什么
76. 程序员帮助人们理解他们想要什么
77. 需求是从反馈循环中学到的
78. 和用户一起工作以便从用户角度思考
79. 策略即元数据
80. 使用项目术语表
81. 不要跳出框框思考——找到框框
82. 不要一个人埋头钻进代码中
83. 敏捷不是一个名次；敏捷有关你如何做事
84. 维持小而稳定的团队
85. 排上日程以待其成
86. 组织全功能的团队
87. 做能起作用的事，别赶时髦
88. 在用户需要时交付
89. 使用版本控制来驱动构建、测试和发布
90. 测试状态覆盖率，而非代码覆盖率
91. 每个Bug只找一次
92. 不要使用手动程序
93. 取悦用户，而不要只是交付代码
94. 在作品上签名
95. 先勿伤害
96. 不要助纣为虐