3.2 “过早优化是一切烦恼的根源”：那么，如何界定早晚？

既然软件是“软”的，那它就有很大的可塑性，可以不断改进。
Chapter. 3 Pg. 53

在既往的实际项目构建经验中，我既有过纠结于为小项目提供足够健壮根基——选择适用于大型软件的复杂架构，以致开发进度严重滞后损害软件开发的实践，也有过受益于未雨绸缪的早期架构设计及亡羊补牢的重构大大减轻扩增需求压力的经验。 软件天然便是“软”的吗？ 我认为，这个命题矛盾地指涉其自身。软件的可塑性在于对其构建方式、架构的设计与考量，而这一考量本身就落入了“优化”的范畴。

为了得到高质量的软件产品，我们是应该把精力更多地集中在提升其中每一个人员、过程、产出物的能力和质量上，还是该把更多精力放在整体流程和架构上？笔者先给这个问题一个“和稀泥”式的回答：这两者都重要。前者重术，后者重道；前者更多与编码能力相关，后者更多与软件架构相关；前者主要由开发者个体水平决定，后者主要由技术决策者水平决定。
《凤凰架构：构建可靠的大型分布式系统》：引言 - 什么是凤凰架构。

这样的决定往往落入一种挂一漏万的思考模式，即“术”和“道”相辅相成却又相互龃龉。在软件架构不断演进的当下，即便组成软件的构件不断地向模块化的方向前进，使得系统整体更具与具体组件无关的鲁棒性，但也带来了越来越多似乎永远也看不到头的“性能-设计难度-稳健性”之间的 trading。本书浅涉这一议题，却没有涉及进一步的分享和解说。我相信，它的最优解在接下来的实践中会慢慢浮出水面。
————————————————
版权声明：本文为CSDN博主「takivotoid」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/takivotoid/article/details/123436565