3. 难点代码（关键需求）的开发主程必须写代码 ， 写那些大家都认为风险大的代码 。
有的系统对于性能要求很高 ， 他就必须去完成容易出性能问题的部分 。比如IO操作或者设计数据库索引 。有些系统的需求非常飘忽 ， 他就要去想办法完成框架代码或者脚本引擎 ， 以便众多小弟可以跟着产品人员疲于奔命 。这种工作内容会让主程不必完全的读过所有代码 ， 而能牢牢的“掌握”代码 ， 以免团队成员甩耙子的时候能充当备胎 。因为融入团队的代码开发 ， 也是一个让架构设计从日常工作中真正控制系统的工作 。而且主程代码通常会被别人接触 ， 能直接教育其他团队成员 ， 同时也能建立——威信 。
在大公司中 ， 由于团队成员普遍素质比较高 ， 所以都这部分的需求会比较少 。但是还是有一些部分的代码 ， 应该亲自操刀 。如果不能对最核心的实现模块下手 ， 起码也应该对客户使用界面有一定的编码经验 。
比如游戏开发中 ， 某个比较复杂的业务逻辑脚本；在发行的产品或库中 ， 编写针对用户演示用的DEMO等等…… 。究其原因 ， 是因为客户是最重要的 ， 而领导者起码应该直接参与面对客户的部分 。店长不迎宾 ， 厂长不进车间 ， 事情是绝对做不好的 。
而中小型公司里面 ， 如果编码工作还是放给别人做 ， 到头来还是给自己找麻烦 。因为小型公司人力本来就紧张 ， 而质量低下的代码 ， 造成的故障和BUG ， 会更加消耗不多的时间成本 。自己做的越多 ， 项目成功的几率就会越大 。
文章插图
4. 救火和杀虫这个工作其实和代码开发是一致的 ， 如果没有平日的开发 ， 通常紧急问题的解决也是比较难处理的 。但是这个也有一个调试技巧的要求 ， 比如要求会使用各种诊断工具 。这些工具一般的开发人员可能会比较少使用 。找问题的过程本身也可以提高团队其他人的技术水平 。
二、培训培训的工作应该占用30%左右的工作时间 。培训是稳定团队人员最重要的手段 。也是提高团队开发效率最有效的手段 。工具、过程、制度、奖惩 ， 这些都代替不了程序员一行行的去写代码 ， 最直接的方法是让他们做的更快更好 ， 这些需要经验和知识的积累 。
1. 代码审查关于代码审查 ， 有太多的论述 。但是代码审查还是一种“强迫”推行某种风格或者技巧的手段 ， 这是最真实的“控制”系统的手段 。也是推广知识和经验最直接的手段 。一个人写的代码通常应对的问题不会特别“广泛” ， 因此只要审查其中一部分代码 ， 就能给大部分别的代码带来好处 。
代码审查的实施 ， 应该有一定的基础 。需要代码作者进行问题描述、代码结构的讲解 。而且也需要作者自己来挑选重点代码段 。主程序员应该指出自己关心的重点代码应该符合什么特征 。
2. 技术方案评审什么事情应该写一个技术方案 ， 然后进行评审 ， 这是一个关键的问题 。一般认为开发时间在2周以上的单项工作应该先做个方案 。往往技术方案是系统架构的完善和补充 ， 或者是挑战 。所以主程的参与是非常必要的 。但是要注意不需要去做的太琐碎 ， 而是要提炼出“关键”的需求和“关键”的解决方案进行评审 ， 而这些“关键”往往不是功能 ， 而是质量上的需求 ， 如这个系统的扩展性 ， 是否能方便后续开发等等 。也有可能在这些会议上会发生争吵 ， 但是决策人是主程的地位是不容动摇的 。君子和而不同 ， 每个程序员都可以拥有自己的看法 ， 但是代码必须能按方案运行起来 ， 主程必须经常申明这点 。
技术方案在差距较大的团队中评审 ， 一般来说可以视为一种培训；而在水平相当的团队中评审 ， 可能会变成各自想法的争执 。不同的项目经历 ， 绝对会造成意见的大分歧 。其实这就是所谓“非功能需求”没有被明确出来造成的 。这个时候主程就应该履行自己的义务 ， 去提炼争论中的“非功能需求” ， 然后做出决断 。
推荐阅读
- 1999年大事件发生了什么 1999年轰动全球事件是什么?
- 招聘|大学毕业生找到一份销售工作，却发现做的事违背良心，该怎么办？
- 博美犬吃什么 博美犬饮食注意事项
- 蜂蜜菊花茶的做法,喝菊花茶的注意事项
- 马航失踪事件 马航客机失联真相大白
- 吉娃娃吃什么 吉娃娃饮食注意事项
- 右眼肿痛怎么回事
- 吉娃娃好养吗 吉娃娃养护注意事项
- 化妆这事儿 男人的8句真心话
- 女性切忌 那些不能公开的梦