工程师文化

读陈皓老师的https://coolshell.cn/articles/17497.html有感。

https://brendansterne.com/2013/07/11/do-the-right-thing-wait-to-get-fired/

https://news.ycombinator.com/item?id=6029823

有段话印象很深刻:

计划就是瞎猜

除非你是算命先生,长期的商业计划是种幻想。有太多的事实证明那是超出你的掌控的:市场环境、对手、顾客、经济等等。做计划让你觉得一切尽在掌握但实际上你没有。
当你把计划变成猜测时,就等于进入一个危险的境地。做计划就是在用过去推导未来,等于给你戴上了眼罩。

感想:你有职业规划吗?如果你有的话,那么你就一定就错了。职业规划是一件很扯淡的事情。我和一些高手都交流过,其实这些人在当初都并不有什么职业规划的,要说有的话,也就是想把技术搞透搞精。这些人在一开始从来没有想过要当个什么经理或是什么架构师之类的东西,这些人就是对技术有非常大的热情,把身边的那些看得见够得着的事情做到好好地,并且保持不持续强大的好奇心努力地学习自己不懂的东西。一个坚定不移的决定和意志力会比任何的计划和职业规划都重要。你问问自己,想不想当程序员,能不能一辈子都当一个程序员,能不能写程序写一辈子?(关于做一辈子程序员这个事,大家可以看看我的新浪微博 ——没哪个行业能像计算机行业这么活跃、刺激和有趣了。不仅是新兴工业革命的主力,又渗入到所有的行业中,干一辈子值了。//@_你亲爱的偏执狂: 程序员首先是工程师,Professional,就跟律师,医生一样,给大家解决问题;但是另一面呢,又是艺术家,创造新奇好玩的东西。这样的职业做一辈子有什么问题?)

http://www.effectiveengineer.com/blog/what-makes-a-good-engineering-culture
https://www.quora.com/Software-Engineering/What-makes-a-good-engineering-culture/answer/Edmond-Lau?share=1

1.优化迭代速度。

  1. 快速的迭代速度增加了工作动力和兴奋度
  2. 在基础设施方面,优化迭代速度意味着构建持续部署以支持快速验证、高测试覆盖率以减少构建和站点损坏、快速单元测试以鼓励人们运行它们,以及快速增量编译和重新加载以减少开发时间。
  3. 团队方面,快速的迭代速度意味着拥有一组强大的领导者来帮助协调和推动团队工作。

2. 不懈地推动自动化。

  1. 自动化解决方案和编写重复性任务脚本很重要,因为它们可以让工程团队腾出时间来处理实际产品。自动化必须由数据和监控驱动。

3. 构建正确的软件抽象。

  1. 保持核心抽象的简单和通用可以减少对自定义解决方案的需求,并提高团队对通用抽象的熟悉度和专业知识。将团队的注意力集中在少数核心抽象上,这意味着通用库变得更加健壮,监控变得更加智能,性能特征得到更好的理解,测试变得更加全面。所有这些都有助于简化系统并减少操作负担。

4. 通过代码审查来关注高代码质量。

维护高质量的代码库可以提高整个工程团队的生产力。更简洁的代码更容易推理、更快地开发、更易于更改并且更不容易受到错误的影响。一个健康的代码审查过程使这成为可能。

建立一个及时的代码审查流程,无论是提交前还是提交后,都可以在几个方面提高代码质量。首先,知道有人会审查你的代码并且提交写得不好的代码可能会让你的队友失望的同行压力是对骇客、不可维护或未经测试的代码的强大威慑。其次,代码审查为代码审查者和作者提供了相互学习以编写更好的代码的机会。

如果工程团队的其他成员可以轻松访问代码审查,那么审查还带来以下好处:a)增加及时审查代码的责任,b)允许团队成员 - 特别是新成员 - 进行建模其他人的良好代码审查,以及 c) 加速传播最佳编码实践。

敏捷团队没有时间花在代码审查上的反驳忽略了很容易从编写不佳的代码中积累的技术债务。Ooyala 在其早期的启动阶段,用于优化以尽可能多地推出功能,而无需进行代码审查;结果是,虽然最初的产品可能更快地推向市场,但最终的代码修改起来很痛苦,我们花了一年多的时间重写脆弱的代码以消除技术债务。

就其规模而言,Google 会对所有代码进行预先提交的代码审查,但较小的团队不需要如此全面或严格,并且并非所有代码都需要以同样严格的方式审查。Ooyala 后来在我在那里时通过电子邮件对核心或有风险的更改进行了提交后审查。在 Quora,我们在Phabricator中进行了所有代码审查,主要是提交后,并对模型或控制器代码和视图代码应用不同的标准;对于敏感代码或新工程师的代码,我们要么进行预提交审查,要么尝试在提交代码后的几个小时内对其进行审查。

5. 保持互相尊重的工作环境。

同行之间的尊重构成了任何类型的开放式沟通的基础。一个人们乐于挑战彼此想法的地方是一个通过辩论形成合理想法的地方。人们容易被冒犯的地方是关键反馈被隐瞒的地方。

6. 建立代码的共享所有权。

    虽然个人精通代码库或基础设施的各个部分是很自然的,但没有人应该觉得他们拥有或是任何一个部分的唯一维护者。 

    在组织上,共享代码所有权提供了三个好处。首先,保持总线因子大于 1 可以减轻维护者的压力,并降低团队在维护者离开时的风险。这也使那个人很难无忧无虑地休假。

    其次,共享所有权使在特定领域不深入的工程师能够提供新的见解。它使工程师摆脱了他们被困在某些项目上的感觉,并鼓励他们从事各种项目,这有助于保持工作的趣味性并促进员工的学习和积极性。从长远来看,它降低了一些工程师感到停滞不前并决定离开的组织风险。

    第三,共享所有权还为在需要更快地完成战略目标时让多个团队成员蜂拥而至(来自敏捷开发的一种技术)共同解决高优先级问题奠定了基础。对于孤立的所有权,负担通常落在一两个人身上。

7. 投资自动化测试。

单元测试覆盖率和某种程度的集成测试覆盖率是管理一大群人的大型代码库而不不断破坏构建或产品的唯一可扩展方式。自动化测试为提高代码质量所需的大规模重构提供了信心和有意义的保护。在缺乏严格的自动化测试的情况下,工程团队或外包测试团队进行手动测试所需的时间很容易变得令人望而却步,并且很容易陷入一种害怕改进一段代码的文化,因为它可能会破坏。

强大自动化测试将验证责任转移到原作者身上,减少不熟悉的人的投入。

8. 分配 20% 的时间。

9. 建立学习和持续改进的文化。

10. 雇佣最好的。

如果没有足够的工程经验,很难识别出要构建的正确抽象。如果没有其他聪明人来挑战你的想法并推动你走向简单,很容易陷入构建复杂事物的陷阱。

硅谷有句谚语,由史蒂夫·乔布斯(Steve Jobs)创造,“A 球员雇佣 A 球员。B 玩家雇佣 C 玩家。” 专注于招聘和聘用合适的人是困难的,但对于有效发展工程组织至关重要
因为低质量代码和团队中较弱的工程师带来的技术债务最终会伤害团队和产品。