专家
这个问题很有趣。实际上，程序员先迅速做出一个简易版本，之后再思考优化，这是一种很明智的做法。要知道，很多时候，我们难以确定最初的想法就是最棒的，也不确定它是否真的能符合需求。所以，先搞出一个能运行的版本，看看成效，再依据反馈来优化，这就好比做菜时先尝尝味道，然后再决定是否加盐加醋。不过，要是一直没有进行优化，可能会存在以下几种状况：忙不过来：项目或许一直在赶工期，新的需求源源不断，大家忙得不可开交，哪还有空闲回过头去优化旧代码？在这种情形下，要理解团队所承受的压力，同时也要考量是否能够调整一下节奏，毕竟，代码质量也是项目成功的关键因素。优先级改变：也许原本被视为重要的优化点，在新的业务发展趋向之下变得不再那么关键了。这个时候，就需要重新衡量优化的价值与必要性了。缺乏动力：有时候，项目进入稳定阶段，大家可能就丧失了刚开始的那种干劲，对于优化这种看不到直接收益的工作就没什么兴趣了。此时，就要思考如何激发团队的积极性，例如设立一些小奖励，或者让大家参与讨论，听听大家对优化有什么看法。技术瓶颈：有时候，优化并非易事，可能牵涉到较为复杂的技术难题，团队里没人能够解决。这时候，就要考虑是否要引入一些新技术，或者寻求外部
专家的协助了。总而言之，这个问题要依据具体情况进行分析。但不管怎样，保持代码的持续优化与迭代，对提高项目质量和开发效率极为重要。所以，我们还是要尽量设法让优化工作能够持续开展下去。
