不要过早优化

从入cs这个坑(或者更早一点)的时候,我一直秉承 “代码要精简,高效”这个观点。
所以我写出过:

void inplace_swap(int& a, int& b){  //会溢出
a = a + b;
b = a - b;
a = a - b;
}

void inplace_swap_bit(int& a, int& b){ //没考虑过a ==b 的情况
a = a ^ b;
b = a ^ b;
a = a ^ b;
}

这种想要穿越回几年前狠狠抽自己一巴掌的代码。(而且当时还像掌握了什么武林秘籍似的沾沾自喜)


还有幼年期的时候因为听说“查找虚函数表会在运行期降低性能所以要尽量避免继承”这种鬼话而避免写类与继承,结果一个小项目里面有90多个类,一、个、继、承、关、系、都、没、有。为此又引入了40多个helper 方法,看着都心累。

后来虽然开始讲求起了代码可读性,可复用性。但是依旧忍不住会去为了提升性能(?)而写一些如 const reference 之类的代码(当然更多的时候是在方法里又做了一次拷贝以便修改);或者在PoC阶段就搞一些引用传来传去,结果爆了栈;还有为了避免拷贝结果修改了引用导致数据不一致的bug(当然智商不够,过分naive也是原因)。统计起来看,平均每节约一个拷贝的收益,远小于找bug,掉头发等生理心理和时间上的损失。

在一次一次重新回顾自己的代码(AKA 修以前的bug)之后,我开始反问自己:代码优化(在初期开发阶段)真的重要么?一次拷贝真的会浪费大把大把的资源么?

答案是:真的不重要。

在原型阶段,完成业务流程的优先级远大于代码本身的运行效率。而且此时很多工具尚未定型,过早优化会给自己引来技术债,导致重复修改内部接口,甚至早早出现包装方法,转接器等设计模式,使逻辑跳转更加复杂,可读性大大下降(都是泪)。相反,从个人经验来看:让工具趋向泛型比让工具更具体,更优化来的有意义的多。清理发布阶段再做优化,为时不晚。过早优化,过早背上技术债,得不偿失。