====== 2014/01 ======
对今天公司大Boss在的birthday chat上的精彩谈话,以及和某位senior engineer的谈话,做些记录:
【其一】
相比做一个全新的项目,一个engineer的价值,更体现在解决现有项目中的critical issue。
- 做全新的项目,没有学习现有代码的成本,没有学习债务,轻装上路,以后维护也驾轻就熟。大多数新项目,可能都是做新feature,未必引入新技术。
- 而解决现有项目中的critical issue,则需要做以下工作:
1)深入理解critical issue是什么
2)通过各种方式,逐步排查,确定问题瓶颈所在
3)列举解决方案,和相关engineer商讨,选择最佳解决方案
做全新项目固然能体现engineer的价值,但是解决非常棘手的现有critical issue,更能体现价值所在,也更能锻炼和提升自己,不管是在技术上、沟通能力上、组织能力上……
【其二】
做好一件事情,至少有两种层次。一是按质按量完成上级布置的任务;二是在一之前,先审查上级的要求是否合理、解决方案是否最佳,不然,则否定之、修改之。
上级给出的要求和解决方案未必就是合理或最佳的,如果照做可能会导致产品的质量不高,甚至失败或返工。因为不合理之处最终总会被暴露出来,与其返工,不如在一开始选择方案时,就提出自己的见解和质疑。如果自己觉得不合理,但又不能最终做出决定,至少要让别人知道潜在的风险。
【其三】“旧瓶装新酒”
新酒和旧酒指的是新的和老的技术;新瓶和旧瓶指的是新的和老的表现样式,比如用户界面样式和风格。
一些老的产品,由于年代久远,使用的核心技术已经多少有些过时,而业界已经出现更有效的、新的、成熟的、通用的解决方案。这时,用新的技术重构现有产品的核心实现,会从根本上提升老产品的品质。这就是“旧瓶装新酒”。
与此相对比,不更新核心技术,而只是改进用户界面风格和样式,看上去效果很美观,但根本功能却不会有改进,不能从根本上带来更好的用户体验。
显然,前者更可取,而后者比较短视。
【其四】
对自己确定的解决方案,最好在实施之前,找相关领域的专家一起review下,因为自己的知识和技能在深度和广度上都是有限的。
越早发现问题越好,不要等做了一半或做完了,被别人质疑,就太被动了,费时费力。
====== 2014/02/11 ======
知其然,知其所以然。
勿以善小而不为,勿以恶小而为之。
====== 2014/02/12 ======
今天被人指出了代码中几处多线程的问题。都是因为没有考虑到,或者忽视了多线程问题,导致的。下次要小心了。
在写公用的库的时候,要认真写 wiki 或 readme,凡事都考虑到并写得清清楚楚,这样的话,即使调用的模块再多,也不会带来太大的工作量,比如沟通成本、联调成本……
在公共库的 wiki 或 readme 中,要把所有潜在的问题都写清楚。比如“是否是线程安全的”,这个要明确写出来,否则如果不是线程安全的,而用户不知情却当初线程安全的来用,结果crash了,就悲剧了。可以参照 GNU 相关 wiki 的做法,比如:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html
http://www.sgi.com/tech/stl/thread_safety.html