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

[GreyZeng]

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

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

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

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

[GreyZeng]

好问题，事实是，在Alpha阶段这种紧锣密鼓的急速开发过程中，根本没时间想优化的问题，Beta和Gamma阶段才能回来想想优化。所以我认为，与其说提前考虑优化的问题，不如先设计好，让项目有充足的可扩展性，然后给后期的优化留下空间。

原文地址

[GreyZeng]

 就目前，以个人看来，当整体架构不清晰、不完整时，去花大量时间优化局部，属于过早的优化。而合理的优化，个人觉得有两种，一种是，对局部进行架构时，在不影响整体进度的前提下，花费较少的时间，得到更好的改进；另一种是，当整体功能已经完善时，根据对全局的重要性，有选择地对相应的模块进行优化。对于全局过大的问题，个人认为，如果是团队合作的项目，则根据团队的沟通交流，来决定是否优化；如果是个人的项目，因为全局过大，在未完成项目前，暂且不优化。

原文地址

[GreyZeng]

何时优化代码？何时抽象泛化代码？这两个问题笔者至今也没有比较准确的答案，或者说只能视情况而定。
  在笔者进行结对编程的时候基本没有进行泛化，更多的是优化。这主要是因为结对编程的程序不需要面对很多需求上的改变，所有的要求一开始就已经确定了。在此之上，程序对于运行效率上的要求很高，需要一开始就注意代码上的优化，否则十分影响最后的优化效果。
  在进行团队开发时，情况就完全相反了。由于需要进行三次迭代周期，面对变化很快的需求，程序需要有较高的可延展性。于是要求更早地进行泛化，按照功能进行抽象，编写相应地通用功能模块。而过早地优化可能并没有太多的收益。

原文地址

[GreyZeng]

——比起界定早晚，不如分类“优化”。

好的架构是成功的一半。 在团队开发过程中，以我们的前端开发为例：前端基于 MVVM 架构开发，在此基础上，开发团队在 Web 端 VM 层上进一步抽象出网络层，分离 API 交互实现与客户端离线功能，提高 Web-app 的鲁棒性。并且，模块化进行视图层开发，引入中间件等复用代码、为平台逻辑提供统一实现。这样开发完成的招聘者前端因为其架构优势，具有清晰的代码结构和很高的可维护性。架构层面的优化没有所谓“过早”一说，基于成熟的设计模式在*开发前8就对架构进行充分的考虑和优化，是开发中不可缺失的过程。

重构什么时候开始都不晚。 团队开发过程中，团队为适应需求的变更和扩展性的需要，进行了规模有大有小的数次重构，都取得了较好的成果。重构本身应当动态地进行，在项目低耦合、模块化设计、开发规范清晰、协作机制通畅的前提下，重构并不会带来很高的成本——背着重担的代码反而更难生长。
————————————————
版权声明：本文为CSDN博主「takivotoid」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/takivotoid/article/details/125465615

[GreyZeng]

A2：为了确定何时进行优化，可以考虑以下因素：

性能要求：如果软件系统的性能需求已经明确定义，并且当前的实现无法满足这些需求，那么可能需要优化。

用户反馈：如果用户报告了性能问题或不满意的情况，这可能是优化的信号。

关键路径：如果某个部分的性能问题阻碍了整个系统的正常运行或是关键功能的实现，那么需要优化。

可扩展性：如果预计系统将来需要处理更大规模的数据或者更高的负载，那么可以在合适的时机进行优化，以保证系统的可扩展性。

总而言之，选择合适的优化时间需要综合考虑项目的需求、性能要求、用户反馈和系统的可扩展性。重要的是要权衡当下的需求和未来的发展，以找到一个平衡点来进行优化，以避免过早的优化带来的负面影响。

原文地址：https://bbs.csdn.net/topics/616068969