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