技术工作的习惯

2019-02-23

非暴力沟通

• 遇到不能理解的事，直接提问，不发评判
• 拒绝只是因为是客观条件不允许
• 建议是以对方的利益为出发点。比如，你的时间很宝贵，所以我自作主张拟定规则
• 评价对方的情况可以放大范围，令对方容易接受，比如：
  • 离职主要是上司不能令他们满意，不是说你们公司的实际情况，而是大多数情况
  • 你说卡林是一个要求苛刻的人，这不一定是坏事，我听到过许多更加糟糕的评价
  • 也许你是对的，她应该更好，但没有上司必须是下属的良师，下属应该主动上报部门事务和成绩。你认为她应该负责与你建立起良好的关系，这点你是对的，如果她没有做到，你应该主动点，负起这个责任。
  • 开始面试及招聘时，首先你要明白。自己也许并不是个很好的面试官。我不是在贬低你——不是说你做得不好。只不过你不经常使用面试的技巧罢了。如果你不经常运用面试技巧的话，就要借助良好的体系来帮你做最佳的决策。我相信人力资源的金能给你指点迷津 ，也许你还会请她一同参与招聘的过程。
  • 问题并不罕见，大家都必经

建议和帮助

• 谨慎无条件的要求和给予。无关原则的事，除非别人不主动请求，否则不做评论
• 听对方的问题，也听对方对问题的分析
• 倾听不为久，不着急打断和表达自己的见解，确定听清楚问题和需求
• 垂头丧气只会浪费时间，定计划，让情况尽可能发生转机
• 旁观者能提供另一个角度的建议
• 智者也更愿意帮助一心求助的人

敏捷工具和习惯

• 敏捷套件：Wiki支持协作、版本控制、单元测试、自动构建
• 每天下班之前，应该测完代码完成提交，并开始集成测试
• 做项目不走捷径、先难后易
• 掌握开发节奏，不要持续加班，对待加班的态度是：救急不救穷
• 在一个Scrum周期内，不应该发生需求变化，迭代周期是1到2周
• 每4周迭代安排一周维护，持续地重构
• 休息时远离键盘
• 内部发布不需要告诉外部客户
• 清楚项目的真实进度，关注功能，而不是日程表
• 保持可以发布，尽早CI/CD，自动化的安装/卸载/Upgrade/Rollback
• 不要警告，警告就是错误，通过日志记录问题，日志要轻量级和简单
• 保持有不被干扰的时间，集中注意力高效地做事
• 不开没必要的会议

职业化的态度

• 想把事做好，认清要事（客户/公司/员工），专注于要事
• 事事有交待，要么把球踢出去，要么把问题终结掉
• 交付问题前需要自测，准备好了再共享
• 缺少功能或者稳定性时不演示
• 守时，提前准备，留足余量
• 对事不对人，解决问题第一，不指责，不争斗
• 解决问题不推诿，互助分享
• 当日事当日毕。不要明日复明日，如果现在不做，明天也不会做

单元测试

• 测试应该能快速运行完成
• 单元测试是必要的，但简单的代码不值得单元测试
• 基本功能和Patch必须要有单元测试
• 抗议单元测试往往是代码中有设计缺陷，往往抗议越强烈，设计越糟糕
• 单元测试覆盖率到一定程度才有价值，没有到位的单元测试，不要进行任何的设计和代码修改

Code Review的注意事项

• Review不指责，是为了大家好，不是为了发泄
• 追根溯源，同时想好提问的理由。为什么要加1？加了有什么影响？
• 代码的清晰度比执行效率重要，要防御式编程，要正确地使用和命名异常，减少注释。注释中应该包含：Why/Input/Output/Exception，How意义不大
• 看代码的设计和清晰程度（是否容易被读懂和理解？）
• 看是否有明显的逻辑错误
• 看是否会对其它部分产生不良影响？
• 看是否存在重复的代码？可以复用？
• 除非你可以让某段代码明确地变得更好，否则不要随意批评别人的代码

公司和产品

• 越是靠高科技和技术突破的行业越难出头
  • 绝大多数公司能吃满一波产品或者技术周期就很幸运了
  • 迭代是一件很可怕的事情
  • 早期的投资、积累的专利和产品……价值会随时间迅速化为乌有
  • 先发未必有优势，规模可能变拖累
  • 历史的辉煌有时候不是验证却是误导
  • 长久成长的假设建立在概率串联乘积的脆弱基础之上
• 这样的公司
  • 应该对每一轮产品和技术生命周期保持十二分的警惕
  • 牢记自己分分秒秒都走在悬崖上
  • 要时时确保自己有交付优质产品的能力

持续学习

• 迭代和增量式的学习，记下那些术语，然后再计划的时间中去研究它
• 正确的把握自己投入的精力
• 对新技术，What/Why/Howto=>PoC
• 要持续分享

关于设计

• 战略设计与战术设计，好的设计是正确的而不是精确的。让设计指导而不是操纵开发。不用过多过细的设计。
• 对特别重要的议题，要再特别的会议上解决，要记录团队做出一个重要决定的原因
• 懂得丢弃，用合适的新技术替代旧技术
• 让客户参与需求决定，提出几种选项给客户，标明优缺点、成本/利益。记录用户选择的原因。
• 不要开发你能下载到的东西
• 每一个抱怨背后都是一个事实
• 简单而可用即优雅，但功能上不妥协
• 命令与查询分开。命令是告诉他做什么，不关心他怎么做。查询则绝不能有副作用

技术架构

• 砍需求是优化的第一步
  • 抓住核心需求，不该要的东西都不要
  • 上层业务少写少插少依赖，要能容错
• 群集设计规则
  • 前端复制，前端逻辑无状态-会话保持-弹性伸缩
  • 后端拆分，后端数据有状态-业务拆分-拆库拆表拆键值
  • 实时改异步
  • 网络和磁盘IO / CPU计算力 / 磁盘和内存空间 可以互换
    • 比如，数据压缩：算力换IO和空间
    • 比如，缓存：空间+IO+换计算压力
• 理解硬件天性
  • 如果一个服务依赖硬盘，就不适合扛性能压力
  • 不让内存抗持久
  • 不让网线抗稳定
• 数据会凭空消失
  • 容错校验、关联复原、冷热备份、安全删除
• 各个环节都不可盲信
  • 既不能不做冗余，又不能无限冗余吓唬自己
  • 在尽人事和听天命之间做好权衡
  • 业务应用不可靠：快速重建+不阻塞其它应用
  • 支撑性服务不可靠：不丢数据+SLA 99.95%
  • 操作系统故障：硬件驱动兼容性 / 傻瓜乱改默认参数
  • 网络不稳定：少提复杂需求内网就能很稳定
  • 硬件不稳定：单点硬件和系统、服务绑在一起做可靠性设计
  • 人力误操作：只要不是蓄意破坏，就是群集健壮性设计不到位
  • 监控和备份：确认目标的正确性
• 所有优化架构的手法都要说清楚选型的道理