工作记录

====== 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