励志司机锐锐|高级软件工程师成长秘诀( 七 )


由于代码总是在改动的 , 所以这是一个持续的过程:你对代码的理解会上下浮动 , 这取决于你接触的代码的占比 。
另外一个获取层次2-3理解的理由是获取灵感 。 当你理解了一个新系统的代码 , 你找出他们做了哪些决定以及为什么这么做的决定 。 这增加了你的工作技能 。 这也是我深入钻研Unix并撰写关于Unix的工作原理的文章的一个重要原因 。 这也是你理解你所使用的工具的一个很好的理由 , 我就是因此而学习Git是如何工作的 。
总结:
不要写你不理解的代码尽可能优先学习为将来的你保留上下文对你的团队的代码达到2-3的理解层次代码审核有助于让你的思维模型保持与时俱进测试
假设你构建了一个新系统 , 而测试发现它非常慢 。 你设计它的时候考虑了每个部件将会花费多长时间 , 但是看起来你的一些假设不正确 。 你接下来要做什么?
我将测量每个组件需要多少时间 , 来确定我在哪个部分可以产生最多的影响 。 有些事情确实是超出你的控制范围 , 比如请求延迟 。 你不可能去发射一个卫星来让你的代码运行得更快 。 测量时间并找出你可以改进的地方是非常重要的 。
我试过大刀阔斧的改动 , 优化任何看起来对我不太理想的东西 , 例如将dicts转换成sets——但最终的解决方案通常不会这么明显 。 Dicts很可能不是你的请求会花费一秒多时间的原因 。
测量而不是假设 。
在去年的回顾中 , 我写到:
如果测试机器和部署机器之间有环境不匹配的地方 , 你就麻烦了 。 这就是部署环境的用武之地 。 […]这个想法是尝试捕获单元测试和系统测试中没有发现的异常 。 例如 , 请求系统和相应系统之间的API不匹配 。
我以前不太热衷干净的测试环境 , 直到因此吃了苦头 。 说到干净 , 我的意思是它完全复制了你的生产环境 。 它使你能够准确地测试生产环境会发生什么 。 当然 , 你不需要一台物理机器 , docker就可以很好地完成这项工作 。
我发现docker是测试效率最高的工具之一 。 它使我能够创造新的环境 , 进行本地测试 , 并减少偏差 。 这种快速的反馈回路使我能够更快地开发 。 让我等5到10分钟来检查我部署好了没有、触发一个测试、检查输出等等 , 是非常令人沮丧的 。 Docker完成了所有这些功能 , 就在我的机器上 。
我学到的最后一件事是优化零假阳性 。 编写并不是你真正想测的东西的测试是非常容易的 。 例如 , 遍历数据库游标并检查值?好吧 , 如果iterator什么都没有返回 , 你的测试不检查任何东西都能够通过 。
这些都是假阳性 , 它们给了你一种错误的自信感 。 我如何修补这些呢?好吧 , 我首先要在代码评审时额外认真 。 其次 , 测试这个问题的肯定触发的方法是让你的测试失败 。 我将等于换成了不等于 。 如果它仍然通过了 , 那我就发现了一个问题 。 这就是我最近开始做的事情 , 一旦我发现了我的第一个假阳性测试 。
总结:
对于优化问题 , 测量而不是假设 。 拥有一个干净的预发布环境 。 容器化非常酷 。 优化零假阳性 。设计
几乎每一个系统设计都关乎权衡 。 优秀的工程师会把这些权衡明确化 。
这些权衡取决于我们和我们想要的产品的约束 。
说到这里 , 需求和约束是不一样的 。 约束是现实世界的限制 。 例如 , 我们还不能在1毫秒内将信息从纽约发送到澳大利亚 。 还有一些产品约束 , 例如我们不希望用户在任何时候看到3个以上弹出窗口 。
另一方面 , 需求是弹性的 。 需求是我们想要让发生的事情 , 但是通常我们不知道自己想要什么 。 问问自己“我到底想要做什么呢?”有助于揭示需求约束 。 通常 , 人们太快地投入到需求中——这只是从约束中选择的众多可能途径之一 。 所以 , 每当我感到需求不靠谱时 , 我都会回归约束条件 , 然后再去寻找替代性的需求 。 我从我的项目经理那里学习这一点——他非常棒!另外还从@shreyas的推特推文中学习 。