正确的做事，做正确的事— 对工作方法与团队的思考

正确的做事，做正确的事

如何应对比较急的代码交付？
根据急的级别分类。

1. 写代码，以一次做好的态度，大处思考，小处落笔。
2. 语法上仔细，可减少编译错误带来的浪费与思维中断。
3. coding与单元测试分开，太急的，可跳过自测，编译通过交付后，由使用者来测试及使用，如有问题，再及时返工处理。以牺牲交付可靠性，来换取速度。但需要通过coding质量提高潜在一次通过率。此为平衡变通之策。
4. 慢即是快，前期注重可复用性，包含代码层变与环境搭建层面。比如：代码层面注意宏控制处理好，以少量的时间换取将来大量时间上的节约，实现任务量在时间层面的转移，与整体上的压缩。尤其是需求变动大的情况。环境搭建层面，成员以git来共享个人环境搭建成果，在搭建环境过程，避免低效的重复，第一次搭建环境的人，每一步要记录下来，最好的情况，搭建完成形成一键配置脚本或者文档或者git固化劳动成果。
5. 越快越好，临时性，是欺骗你的良好接口。糟糕和越来越大的浪费就是因为临时性的心态引入的。永远不要被欺骗了，程序员的个人素养需要自己去守护，在进度和代码质量上的平衡，需要程序员的坚持。差的程序员的退让，会让代码最终陷入不可维护的地步，也就是维护的成本越来越高，速度越来越慢。越忙得像无头苍蝇的团队越糟糕，因为缺少顶层的方法论与有效的实践，往往导致“将熊熊一窝”。代码的风格往往反映的是组织的风格。
6. “garbage in, garbage out” 无效输入，无效输出
7. 将熊熊一窝
8. 聪明的做事。高效的做事。于别人失败处，吸取经验，避开陷阱，于别人低效处，发现高效的方法，于浪费的环节，发现减少浪费的途径。
9. 垃圾代码复用之后还是垃圾。对于不整洁的代码和架构，重要的不是考虑其复用，而是考虑无情的重构。高质量的代码才有资格被复用，屎山代码首要考虑的是代码质量的提高。
10. 将大部分精力用于生产整洁的代码，而不是用于事后的修补，修补如售后。大量的工作应该在于生产整洁的代码，避免维护，而不是匆忙上线垃圾，事后维护累死。
11. 低质量代码不画uml，不值得浪费时间。优秀的代码画uml方便共享知识。
12. 用Doxygen 生成代码文档
13. 市场和需求保证做的是正确的产品，是市场需要的产品。开发人员保证正确的做产品，是产品质量达到至少最低标准，缺陷或bug可控，代码层面要适度兼顾代码扩展性、可维护性。在进度与质量冲突时，牺牲质量太多，达到可接受标准一下，赶上进度也是表面上的，因为牺牲的质量依然需要后期的修补。
14. 人人都是质量工程师，程序员要捍卫自己的代码质量，守住底线。如果人人都退让到底线一下，表面看进度赶上来了，很有可能会害人害己。自己忙于修补，公司资源和个人资源很可能无法创造出来价值。目标很重要，目标要始终保持在产品具有最低保证的价值。
15. 只有在自己跌倒的时候，才能学会如何爬起来。聪明的做法是，在别人跌倒的时候，观察和学习别人的经验，把防线向前移，尽量不让自己走到跌倒那一步而被动，掌握主动权，始终牵住牛鼻子。
16. 别人失败和做的不够好的地方，就是我们需要琢磨的地方，机会就在这里。
17. 两种不同需求，前期用两个分支来管理。需求变更，变更需求用新分支来做。最终确认后，决定用哪个分支或者做兼容。
18. 谁负责、谁决策。负责人与处理人分开时：处理人需要有效的输入，处理后，将有效的输出输出给负责人。负责人与处理人是同一人时，负责、处理、决策由一人承担。
    19.做长期有价值的事，固化重复的事，固化重复的知识，用个人知识库快速索引。
19. 聪明而高效的做事。高效的分步骤完成任务，高效利用碎片时间，减少浪费和无效。
20. 强调正面和积极的方法，避免负面的概念与词汇，以免因隐含信息缺失情况带来的误解。
21. 更持久的关注正面的意义与方式，朝着理想态小步快走。重要的是朝好的方向变化。
22. 面向长远做事，做可持续积累的事情。
23. 注意合适的言语，合适的场合与沟通方式
24. bug 是不能持续积累和创造价值的，但是好的架构与实现可以持续创造价值。解掉一个bug带来的收益，贯穿与今后每一个软件使用与开发中。但是产生一个bug以及代码混乱开发慢带来的成本，必然大于代码质量和审核发现问题所用的成本。如果强耦合到某芯片平台的sdk中，必然要为sdk的bug 付出成本，当切换平台后，这套强耦合的代码不能复用，过往的投入（体现为可复用的代码）在新平台没被继承，变成了0。如果能在项目初期，注意将操作系统接口封装到低层次，业务逻辑代码就可以有一定程度的可跨平台复用。这终究还是个短期与长期的权衡取舍问题。在短期的项目压力面前，很多人就忽视了长期的思考维度，导致团队代码和工作成果无法持续积累，甚至会出现恶性循环。
25. 野蛮生长，会导致墒增加，无序、混乱。如果在开始阶段，没有注意搭建一个好的框架，有可能导致后期浪费严重。好的开始是成功的一半。