Some Thoughts on Software Development
内容提要
一位有六年经验的开发者总结了约30条改变或坚持的软件开发观点。改变的看法包括：类型语言有利于经验不一的团队；站会和回顾会有实际价值；架构最重要，糟糕的抽象会导致代码腐烂；Java没那么糟；清晰胜于聪明；最佳实践需结合语境；无需过早设计可扩展系统；静态分析有用；关系型数据库通常优于NoSQL；函数式编程并非万能。坚持的看法包括：过度纠结代码风格的人是怪人；代码覆盖率与质量无关；单体架构在多数情况下不错；TDD纯粹主义者最糟。
延伸解读
从“改变”与“坚持”看经验积累
作者列出近30条观点，分为“改变想法”和“坚持不变”两类。改变的部分多与团队协作、工程实践相关，如类型语言、站会、架构重要性；坚持的部分则涉及代码风格、覆盖率、单体架构等。这种对比显示，六年经验带来的不是全盘否定，而是在具体语境下重新评估早期信念。读者可借此反思自己的技术观点是否也随实践调整。
架构优先与避免过度设计
作者认为软件架构可能比其他任何东西都重要，糟糕的抽象或缺失的层会导致代码腐烂。同时，他反对在不需要时设计可伸缩系统，并指出“scalable”一词对工程师有神秘力量。这提示读者：架构决策应关注抽象质量，而非盲目追求扩展性；在未明确需求前，过度设计反而可能成为糟糕工程师的表现。
实践中的取舍：清晰、实用与工具
作者强调清晰胜于聪明，最佳实践需结合语境，盲目追随会变蠢。他主张用纯洁交换实用性通常是好主意，增加更多技术很少是好主意，并认为铅笔和纸是最好的编程工具却很少被使用。这些观点共同指向：工程决策应优先考虑可读性和实际效果，而非教条或工具堆砌。
对常见教条的保留态度
作者坚持认为代码覆盖率与质量无关，单体架构在多数情况下不错，TDD纯粹主义者最糟。这些观点与当前一些流行实践相左，但作者并未展开论证。读者应注意，这些是个人经验总结，并非普适结论；在采纳或反驳前，需结合自身团队和项目语境进行判断。
Q&A
在经验水平不一的团队中，应该选择类型语言还是动态语言？
作者认为，当团队由不同经验水平的人组成时，类型语言更好。
站会和回顾会真的有用吗？
作者改变了看法，认为站会实际上有助于关注新手；回顾会有其价值，但前提是用于实际的路线修正，而不是浪费时间的“敏捷”形式。
软件架构为什么比具体实现更重要？
作者认为软件架构可能比其他任何东西都重要。好的抽象即使实现糟糕也不会对代码库造成净损害，而糟糕的抽象或缺失的层会导致一切腐烂。
代码覆盖率能反映代码质量吗？
作者坚持认为代码覆盖率绝对与代码质量无关。
为什么说盲目遵循最佳实践是愚蠢的？
作者认为所谓“最佳实践”是有上下文依赖的，并非广泛适用，盲目遵循会让人变成白痴。
在大多数情况下，应该选择关系型数据库还是NoSQL？
作者的一般观点是关系型数据库管理系统（RDBMS）优于NoSQL。
