如何用正确的方法来写出质量好的软件的75条体会

这七十五条，是网友在微软工作两年来的体会的总结，关于如何用正确的方法来写出质量好的软件的体会的总结。或许看似平淡无奇，但大音希声，这七十五条的效用，未必及不上那几十页几百页的体系，却远远比那好用

1. 你们的项目组使用源代码管理工具了么？
3. 你们的测试组还在用word写测试用例么？
5. 你们的项目组用了你能买到最好的工具么？
7. 你们的员工每个人都有一部电话么？
9. 你遇到过有人说"我以为…"么？
11. 你们的进度表是否反映最新开发进展情况？
13. 你们的开发人员从项目一开始就加班么？
15. 值得再多花一些时间，从95%做到100%好
17. 写新代码前会把已知缺陷解决么？
19. 你们对意见不一的缺陷有三国会议么？
21. 你们的程序员厌恶修改老的代码么？
23. 你们项目组有自己的logo么？
25. 总经理至少每月参加一次项目组会议
27. 有人长期不check-in代码么？
29. 有没有设定每天check-in的最后期限？
31. 你们的项目组做每日编译么？
33. 设计越简单越好
35. 你们会隔一段时间就停下来夯实代码么？
37. 你们的项目经理会发出weekly report么？
39. 你们项目组的会议、讨论都有记录么？
41. 通过email进行所有正式沟通
43. 每个人都知道哪里可以找到全部的文档么？
45. stay agile and expect change
47. 你们的测试有一份总的计划来规定做什么和怎么做么？
49. 你是否会为各种输入组合创建测试用例？
51. 你们是否随便抓一些人来做易用性测试？
53. 你们的性能测试是等所有功能都开发完才做的么？
55. 你们项目组中有人能说出产品的当前整体质量情况么？
57. 你们的程序员是写完代码就扔过墙的么？
59. 产品有统一的错误处理机制和报错界面么？
61. 你们的每个人都了解项目的商业意义么？
63. 有可以作为宣传亮点的cool feature么？
65. 不要过于注重内在品质而忽视了第一眼的外在印象
67. 开始开发和测试之前每个人都仔细审阅功能设计么？
69. dev工作的划分是单纯纵向或横向的么？
71. 你在招人面试时让他写一段程序么？
73. 你们的程序员都能专注于一件事情么？
75. 尽量不要用virtual heads 这75条的主题是这样的：
6-10：沟通
16-20：缺陷管理
26-30：配置管理
36-40：又是沟通
46-50：测试
56-60：编码，developer
66-70：设计