Chapters1 Mentor的技术品味
1.1 TDD
Test-driven development: Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.
测试驱动开发. 这个是Mentor一直强调的, 人是靠不住的, 觉得可能会出问题的地方, 一般一定会出问题. 无法测试的code, 不是好的code.
一些特殊原因我需要了解其他业务团队的代码, 我发现其他的团队很少有TDD思想. 他们很难理解Test如何写, 要写到什么样的力度. 一些Test Case本身是一种自省, 也是一种宣布: 我写的代码是没问题的, 因为:
Every case was TESTED
在TDD的指导下, 我们顺利地完成了项目的迁移而未出现大的问题.
1.2 一个方法不超过10行, 一个方法只做一件事
Curly: Do you know what the secret of life is?
Curly: This. [holds up one finger]
Mitch: Your finger?
Curly: One thing. Just one thing. You stick to that and the rest don't mean shit.
Mitch: But what is the "one thing?"
Curly: [smiles] That's what you have to find out.
以前写代码的时候, 恨不得所有的功能都在一个方法里面实现了, 即所谓的Fat Method. 这个原则一直影响着我. 到后面做业务的时候也是在思考: 这个功能是不是被复杂化了, 它做了很多超出其业务属性的事情?
Mentor非常强调这一点: 方法不超过10行, 能让你去思考起一个好的变量名和方法名, 每一行没有多余的代码. 一个方法只做一件事, 让你的每个方法都很轻量, 每个业务功能都原子化, 更利于测试.
1.3 所见即所得(KISS)
Keep it simple, stupid
所有混乱的来源都是因为 我们将很多事情复杂化了, 她不是所见即所得的. 我们做了很多feature, 很多新业务属性, 写了很多magic的代码. 也为此付出了很多的代价, 复杂的业务没人会使用, 下线了. 在业务代码中使用的Ruby Mentorprogramming也发现是众多bug的来源.
Mentor在带领我们做需求评审的时候, 所见所得是一个非常基本的原则, 将很多的业务变简化了, 适用性也更好.
1.4 2/8法则
For many events, roughly 80% of the effects come from 20% of the causes.
和Mentor合作最开心的一点是, 能站在一个系统地角度去思考问题.
Mentor提出: 我们仅仅用到了20%的知识, 那如果我们如果能够整理出这核心的20%的知识, 对于以后 新员工的培养, 技术的传承 是非常有效的. 所以才有了我们后来的 Ruby知识树, MySQL知识树 系列. 对于知识的整理和总结对整理这本身和使用者的作用是巨大的. 他在无形之中构建了整个团队的技术框架和技术领域结构.
1.5 最佳开发实践
一次做好, 一次做对
Mentor之前推行过一个项目, 初衷为减少团队的bug数, 为此我们做了非常多的努力和讨论, 这是我最钦佩Mentor的一点: 让开发流程去让"人"少犯错.
一般的公司是不太管code的质量的, 一个系统他们有一万个理由不让自己的代码被review, 不去写 Unit test, 拿到业务需求, 不加分析就开始做. 做完了之后也不考虑功能对历史数据的影响, 后人的维护成本等等.
我们现在还非常自豪地可以说: 我们的团队的流程是最好, 而且bug是最少的. 这个除了团队本身素质高之外, 非常重要的一点是: 最佳开发实践. 我们总结的最佳开发实践, 让我们不仅仅是一个开发者的角度去思考问题, 而是从一个系统可用性和易用性角度去思考业务合理性, 架构的设计, 历史数据处理等. 一次做好, 一次做对.
1.6 讲座分享
知识需要传承
对于我个人而言, Mentor给了我极大的空间. 其中一个就是组织讲座分享. Mentor组织了 每日果汁, Rebuilding Rails, 编程之美等重要的技术讲座, 提供了大家很多的空间去思考技术问题, 在做完日常功能之外, 还能去思考技术本身是怎么样的, 什么是最优解.
另外, Mentor也传授了我们很多关于演讲方面的知识. 包括我们的演讲的时候, 需要注意观众的反应, 尽量的举简单轻松的例子, 少文字多图画和视频信息. 在关键的地方进行重音提醒等等.
对于一个好的演讲者和不好的演讲者, 听众的反应是不同的, 互动也不一样. 我们肯定开过很多无聊的会议, 在会议室里面刷着微博聊着天, 根本不care别人在讲什么. 但是对于一个有趣的演讲, 一个有深度地知识传达, 听众的参与度是不同的. Mentor在这一点上做得很棒, 他自己本身也是一个非常优秀的演讲者.
1.7 信息检索
并非无所不知, 只是会用Google
刚和Mentor接触的时候, 发现他基本上什么都知道, 很多技术上的问题他都会有解决方案, 而且思路很清晰, 甚至能在很多现有的解决方案中选择出最优的一种. 慢慢地, 他发现我开始问他一些很愚蠢的问题, 于是传授了一个我受益终生的技巧: 如何描述你的问题以及进行信息检索.
- 你的问题不是新问题, 肯定有人已经提出而且解决过了
- 如果在半小时内没有任何思路, 一定要将该问题拿出来一起讨论
- 学会使用Google去检索技术问题, 不要用baidu.
- 学会用英语而不是中文去Google
后期在一位架构师的指导下, 我知道了这篇文章: 提问的智慧 其中很多理念和Mentor说的如出一辙.
学会自己解决问题, 但是不深陷于其中, 愿意讨论, 向别人提问的时候, 要注意提问的智慧. 这是我学到的最受用的知识.
2 Mentor对于我的影响
2.1 曲线
我跟随了Mentor大约6年的时间, 从一个什么都不会的菜鸟, 到现在可以独挡一面的高级研发, 也慢慢地开始变成了别人的Mentor, 教授别人我踩过的坑, 缩短别人成长的曲线等.
Mentor对我最大的影响是什么呢? 他给我最深刻的感觉是, 你永远觉得他对你是包容但是有要求的. 在这几年里, 我出过很严重的线上事故, 也跟别人产生过激烈的冲突导致非常严重地投诉, Mentor的批评是有的, 但是这些事情的后果不会让你来承担, 而是单独和你一起分析这个问题, 并讨论之后如何杜绝的方案.
慢慢地, 随着Mentor的职级越来越高, 他也开始将权力全权放下, 提出要求, 给出激励方式, 并要求汇报结果, 但是不干涉问题的解决方案.
在Mentor的带领下, 我觉得自己的进步很快, 也非常有安全感和冲劲儿, 很多好的习惯和方式也在朝着Mentor的步伐看齐着. 无论他在哪儿, 他的影响力是巨大的, 会持续地影响着我们团队里的每一个人.
2.2 成熟
刚来到Mentor团队的时候, 我还是不谙世事的小孩儿, 很多事情负面情绪很重, 容易被激怒, 不好沟通. 而Mentor看起来永远似乎不会发怒, 思路很清晰, 慢慢地我也开始很多事情不动声色, 不会和别人产生正面的冲突, 不会再任何能保留下记录的地方留下任何自己的负面情绪等.
说自己变成熟总觉得会很矫情, 但其实这样是对的, 只有规避掉很多负面, 将重点放在自己关注的地方, 才更有意义.
3 后记
很多话当面说总是显得太做作, 不希望这些重要的话仅仅成为一个简单地酒桌饭局的敬酒词, 所以啰啰嗦嗦写了这么多.
我觉得人和人之间的关系是很微妙的, 尤其是同事之间的关系, 我们永远无法走得很近, 一旦各奔东西, 随着时间流逝也就各自淡忘了. 我不希望这种淡忘发送在Mentor身上, 感受也是瞬息即逝的, 所以在我还能感受和回忆的时候, 赶紧写下来.
非常感谢Mentor, 祝您之后越来越好, 也祝您和您的家人, 身体健康, 每天都开开心心.
