关于‘技术道路’的一点思考

1. 关注技术之余还要关注业务

• 一定要搞清楚业务目标，不搞清楚不开工
• 习惯基于业务目标去分析可能会面临的技术挑战
• 从‘质量-成本-时间’这个‘不可能三角’去寻找合适的技术框架、解决方案，尽可能地寻求最优的平衡

2. ‘设计’代码而不是‘写’代码

• 多关注业务
• 如果某个功能的开发/修改，以‘天’为工时单位，一定先画图
• 搞明白每个设计模式的特点和使用场景

3. ‘接’需求之前会先‘砍’需求

• 时刻保持着‘做这个需求的目的是什么’这个问题去思考

4. 解决一类问题，而不是解决一个问题

• 能否通过什么方式找到现有代码中的同类问题，并把它们处理掉
• 有没有办法能够一劳永逸地避免此类问题的发生，比如封装一个SDK或写一个组件，尽可能用一种低侵入的通用方式将问题扼杀在摇篮里

5. 遵循KISS原则，写尽可能简单的代码

• 不单单是程序员，任何化繁为简的能力才是一个人功力深厚的表现，没有之一。
• 越简单，越接近本质

6. 选择忍受某些问题

• 当前的这个问题现在到底有没有必要解决？
• 值不值得，为什么之前没去解决？
• 它是不是你当前所有待解决问题列表中优先级最高的？

7. 打造‘T型’专业技能

8. 构建自驱动的‘闭环’

• 只要做一件事，尽可能多的对外输出自己的知识
• 做团队里最权威的人，是构建子驱动‘闭环’的好机会
  02-think_selfstudy_close-cycle
  ‘专业技能’、‘连接外部的能力’、‘领导力’三维组合:
  02-think_thrid-dimension-ability-relationship.png

参考：
CTO被裁，离职前给组了的高级开发们8个建议