Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏

12.2. 程序猿说的「优化」是什么意思?

产品经理,程序猿口中的优化是什么意思?你是否想知道员工在干什么?是不是常常在会议上听到,产品经理和程序猿说在优化产品?

确实有20%的优化工作确实是在优化产品,产品经理在打磨产品,程序猿在优化性能。

但80%的优化工作其实是在修修补补,这些工作不创造任何价值,也是可以避免的。

12.2.1. 经验和能力不足

成为一名优秀的攻城狮,至少需要 9-15年,攻城狮的经验是从失败中积累的,这个过程是漫长的,需要时间和参与项目的数量。如果一名攻城狮进入公司后只做一个项目,积累经验是有限的,攻城狮参与的项目越多积累经验就越多。

从招聘网站上的数据看,目前企业招聘追究性价比,会选择3-5年工作经验的员工,这些员工的经验积累不足,能力有限。很多企业为了弥补这些员工的经验和能力不足还会配置一个岗位叫架构师,一般也是5-8年工作经验。

成为一名优秀的架构师首先需要有足够的项目练手,目前市面上的很多所谓架构师都达不到架构师的水平,他们更多只是熟手程序猿。在我看来一个团队中仅仅有一两名架构师是不足以提高团队的整体素质的。

产品经理也是做的产品越多经验越丰富。

一个经验不足的产品经理在做项目的时候,设计出的产品存在各种缺陷,常常是提交给开发人员后,发现不对,需要立即修改。这也是产品跟开发人员的主要冲突和矛盾。老道的产品经理就会先不做修改,事后一段时间后再提交一次优化,把这个遗留问题解决掉。

开发人员也一样,经验不足,考虑不周,就会留下bug,甚至是刚刚提交代码,立马又想到问题所在,必须在再做一次修改。这也是开发人员跟测试人员的主要冲突和矛盾。测试人员刚刚测试完一轮,程序猿就要修改代码,需要重新再测试一遍。老油条,他会评估BUG影响的范围,如果不影响正常使用或者达不到触发条件,就会先不修改代码,如果测试人员没有发现 这个BUG,就先上线,待日后优化掉。

对于有10年以上经验的老码农写程序根本不用什么架构师来优化。他写程序的时候已经考虑了所有可能的性能,数据库结构,缓存策略,性能,扩展性,高可用......

一个合理团队应该是是橄榄形的,它又少量的高级和初级岗位以及绝大多数的中级岗位够成。

12.2.2. 给前人擦屁股

国内企业的人流量非常大,超过3年的老员工非常少,工作岗位细分,每个人都有自己负责的工作,即使是老员工也不愿意去维护其他同事写的代码,最终公司里没有一个人熟悉整个项目,总是那里出问题,临时去翻看代码。

团队需要不断补充新鲜血液,新员工至少三个月的时间才能独立工作,新员工对老代码不熟悉,问了一圈也得不到答案,于是他想还不如重写那些老代码。的确有可能代码被重写后性能提高了,更多的是修改旧代码产生的新BUG。

这个过程叫优化老代码

12.2.3. 先盖楼,后打地基

很多互联网企业追求快,是先把项目做起来再说,随着业务的增长,发现系统已经无法满足,这时就期望高价招聘一个架构师解决系统存在的问题。

这种先盖楼,后打地基的做法,后期产生的优化是无穷无尽的,直到整个系统被新代码被替换掉,或是推倒重来。如果中途架构师离职,新来的架构师又是一套新操作。

12.2.4. 使用新技术和不熟悉的技术

网上常常看到一些踩坑的文章,意思就是在实施某项目过程中遇到的问题。

使用新技术和不熟悉的技术,无法预判产生的影响和结果,才一次又一次的优化之后,对技术越来越熟悉,最终解决了问题。

在我看来之所以出现“踩坑”问题,是让一个没有经验的人负责一个复杂的项目,搞出一堆问题,生产环境成了实验场,不去追究责任,反倒鼓励员工的经验总结。

对于员工来说倒是个非常好的练手机会,对于公司来说是各种损失。这种作风再当下比比皆是,抢险救灾领导被表扬,而不追究为什么发生事故。

12.2.5. 最后总结

之所以现在网上各种优化类的文章,只能说明程序猿能力不足,经验不足,对技术掌握不全面,不深入。才会留那么多问题带日后解决,这些问题应该在设计之初就考虑,开发中就发现,不应该等到上线后再去验证。

软件的犯错成本太低了,你见过做硬件的天天优化吗?