《The Effective Engineer》读书笔记

The Effective Engineer How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

采纳正确的Mindsets[编辑]

聚焦于高影响力的活动[编辑]

1. Leverage = Impact / Time
   1. 降低时间（提供个人的技能/开发效率）
   2. 增加活动的输出（提供更多价值）
   3. 转移到higher-leverage活动（选择高速发展的行业/优先级）
2. 对工程师来说，时间才是最大的成本
   1. 愈早地改变愈好！（vs我之前的观点：Scale Up & Scale Out）

为学习优化[编辑]

1. Adopt a Growth Mindset
   1. 根据指数增长原理，愈早改变愈好。尽快增长自己的base（人的学习能力在年轻的时候更强，年纪大了学习能力会退化）
2. Dedicate Time on the Job to Develop New Skills
   1. 研究代码库中的核心代码
   2. 写更多的代码
   3. 阅读公司内部的技术资料
   4. 掌握你使用的编程语言
   5. 主动要求代码review
   6. 学习网上课程（？）
   7. 参与你感兴趣项目的设计讨论
   8. Work on a diversity of projects.（这似乎在外包行业才能做到？哈哈）
   9. 确保在新团队里你能够向大牛学习（避免那种你就是唯一的大牛那种情况）
   10. 无畏（勇于接手你不了解的代码，与“跳出舒适区”）
3. 评论：跳槽换工作时，找那些能够让自己学到新东西的
   1. 问题是社招一般看最近3年的工作经验，并且我也不认可换领域就必须减薪（事实上，应该发展的是自己的元学习能力，而不是什么特定领域的知识点/工作经验）
4. Always Be Learning
   1. 怎么走出去参加业内技术会议，认识大牛？

优先级[编辑]

1. ToDo List（本周、当天、Working）
2. 聚焦于能立即产生价值的（活动）
3. 优先级是动态调整的
4. 始终关注于“重要，但不紧急”的（那一天总会到来，一点一滴地积累准备，好过事到临头毫无准备）
   1. 但是人很难有长远的眼光、恒心、长年如一日的坚持（自律）
   2. 只有你喜欢和感兴趣的事情，你才能一直坚持
5. “心流”、频繁中断的坏处
6. 限制WIP的数量
7. 用If-Then计划（自觉的条件反射？）打败拖延症
8. 每天做好工作优先级的安排

执行[编辑]

加速迭代[编辑]

1. 连续发布/连续交付
   1. “一天发布几十次... （当然，这只需要发布过程自动化即可以做到）
   2. 快速迭代是否只适用于Web系统的开发？如何针对嵌入式系统、或传统中间件做适配？？？
   3. CD是否意味着编程实践上需要从一个稳固的核心出发，可靠地增量开发？
      1. 反思，如果对于一个遗留系统，不可靠的增量只能意味着错误的设计和Bad Smells被慢慢累积... 所以需要逐步的重构？
2. Move Fast to Learn Fast（会不会给自己太多压力了？）
3. Invest in Time-Saving Tools
   1. Google的分布式build集群
   2. 用Python做快速原型，用C++做后期实际开发
   3. Eclipse这种大型IDE实际上不如Sublime更快速灵活（前提是先构建一个快速的命令行build工具）
      1. 这里的一个问题是：纯文本写HTML设计Web页面不够方便（尤其是页面布局比较复杂的时候）
4. Shorten Your Debugging and Validation Loops（优化工作流）
   1. 备注：有没有一个可以从JS代码中自动删除log语言的自动化工具？（注意，Android开发下的Gradle支持这么做）
5. “One common type of bottleneck is dependency on other people”

度量你想要提高的（正确的metrics！）[编辑]

1. Google的搜索质量团队
   1. 如何衡量用户的快乐？“long click”（后来的社交网络反其道而行）
2. “Average response times vs. 95th or 99th percentile response times.”
3. “Instrument Everything to Understand What’s Going On”
   1. “Open-source tools like Graphite, StatsD, InfluxDB, Ganglia, Nagios, and Munin make it easy to monitor systems in near real-time.”
4. Internalizing useful numbers（预估单个系统的IO／响应性能／容量上限？）
5. Data abuse：Be skeptical

早期&频繁地验证你的想法[编辑]

1. Cuil：buggy、slow、pathetic！
   1. 对产品进行早期验证！
   2. Optimizing for feedback ASAP
2. MVP
3. Dropbox：制作一段4分钟的视频
4. 新网站UI设计：fake页面有点滥用用户的信任了
5. “Obama’s campaign email test”（怎么不担心小样本误差的）

提高你的项目估算技能[编辑]

1. 分解为更小粒度的任务
2. “Think of estimates as probability distributions, not best-case scenarios.”
3. Budget for the Unknown：
   1. 编写单元测试
   2. 推行编码规范
   3. 被客户的高优先级的其他事情打断
   4. 某些未预期的技术难题的Debug
   5. 可扩展性问题
   6. 中途的人员流失
   7. 为降低二进制尺寸，重写UI而不是直接使用第三方库
   8. 代码库迁移（可归到管理类问题）
4. 定义specific project goals，而不是简单的rewrite（后者很容易又会变成需求泛滥的mess）
   1. “Even more effective than defining specific goals is outlining measurable milestones to achieve them.”
5. Reduce Risk Early
   1. 降低集成风险：“build end-to-end scaffolding and do system testing earlier”
6. Incremental/Phased Rewrite
   1. e.g 把C#写的Writely移植到Google内部的Java基础架构上，先移植再重构

这部分主要是跟项目管理有关的。

建造长期价值[编辑]

平衡质量与实用主义[编辑]

1. Establish a Sustainable Code Review Process
   1. 早期检出bugs和设计缺陷
   2. 防止dirty monkey patch
   3. better code（正向激励）
   4. 共享代码库知识
2. 并不需要强制要求代码在提交之前一定经过review，可以推迟到产品发布后再review也是可以的（review作为接下来的refactor指导）
3. “Newly hired engineers may reason incorrectly about code, pattern-match from bad code, or start re-solving similar problems in different ways”
4. Manage Complexity through Abstraction
   1. Map-Reduce框架
5. 自动化测试
   1. “Writing the first test is often the hardest.”（能够节省大量时间浪费的测试！）
6. 技术债务

最小化运营负担[编辑]

1. Instagram
   1. Simplicity（or：Do the simple things first）：PostgreSQL + Redis／Memcache
   2. 这里的复杂性指的是实现复杂性？但感觉做好服务隔离理论上应该没有什么问题（除了一点，复杂的技术栈维护代码更高一点）
2. 反面教材：Pinterest
   1. 奇怪，这里的Memcache与Redis为什么要同时使用？？？难道前者作为KV缓存比后者性能更好？？？
3. Build Systems to Fail Fast（这说的是Erlang设计哲学吧？）
4. “Relentlessly Automate Mechanical Tasks”
   1. e.g Facebook的最大的MySQL shards集群
5. Make Batch Processes Idempotent
   1. 幂等 与 可重入
6. Netflix的Chaos Monkey
   1. Google的灾难恢复测试
   2. 测试负载不均衡的情况

投资团队成长[编辑]

1. On-boarding
2. Higher ladder：不仅仅是看个人贡献，而要看对周围人的影响力
3. “You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you’re making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.”
4. 你的职业生涯的成功依赖于公司和团队的成功
5. Make Hiring Everyone’s Responsibility
   1. interview：“高信噪比”？
6. Share Ownership of Code（这是之前极限编程里的一个概念，代码的共享所有权）
7. Build Collective Wisdom through Post-Mortems（进行事后原因分析，or 集体内省）
   1. e.g. NASA astronauts debrief after every simulation，Flight Rules
8. 工程师文化
   1. 持续学习和改善