1. 待改进项
代码
- 努力使项目中开发代码更易于理解(可读)、更易于修改、也更易于扩展和后期维护，因为只有代码质量这个底线才有可能谈稳定，谈伸缩，谈性能，谈架构
- 利用好他人的反馈来促进自己的成长，共同努力，共同提高；从他人的思考与想法中获益，比如代码评审反馈
- 前后端紧密配合，继续努力提高代码质量，提升产品质量，持续提升用户使用体验
需求
- 加强所有参与开发人员对项目需求的明确程度、理解程度、思考程度，从而形成更好的设计
- 必须确认需求中没有任何不确定因素，从而尽量提高开发效率
- 向项目管理人员及时同步需求完成进度、有问题及时沟通，及时反馈保证在开发过程中需求不会有太大的变更
沟通
业务方描述自己想要的东西，开发人员按照自己理解的业务方表达的需求进行开发，至少从理论上来讲，应该是这样的，但是在现实里，需求的沟通往往是极其困难的，容易出现：
- 不确定原则：东西画在纸上与真正做出来是不一样的
- 预估焦虑：即使拥有全面准确的信息，评估也通常会存在巨大的变数
- 模糊性：不仅来自于分歧或争论，有时候业务方会想当然的认为看懂文档的人懂得自己的意思
综上：
- 前期需求讨论会前尽量熟悉相关文档，梳理流程，记录好待讨论、待明确的问题
- 前期的讨论尽可能细化，讨论前思考大体流程及大体步骤，尽可能提前讨论好开发可能会遇到的问题
- 细化需求后内部开发人员组织讨论，遇到问题再回头看，反馈业务方继续确认
文档
- 前后端联合开发时优先提供API文档，确认数据结构及相关参数
- 针对于复杂功能、复杂权限页面记录可记录详细功能文档
- 需求管理文档、项目使用手册、项目代码规范等文档
项目
- 软件开发的任务应该是思考，思考手头的问题，设计出一个完美的解决方案，然后再把这个方案转变为可供用户使用的软件
- 项目实现业务板块化管理，对于不同的业务板块可以有一个主负责人和一个备份负责人
- 日常工作过程中当天遇到的问题当天解决、周内问题周内解决
- 平时注意识别风险：对需求任务阻塞或需求延期或即将延期的任务进行管控
- 多总结技术经验，积累工作文档，提升系统思维和管理经验
2. 团队思考
❶【结对编程(协作)】: 大多数软件都是由团队开发出来的，团队成员能够十分专业的互相协作
程序员之间通常很难密切合作，这会带来一些不小的问题；不正常的团队最糟糕的症状是每个程序员在自己代码周边筑起一道高墙，拒绝让其他程序员接触这些代码，从技术角度来讲，这无疑是个灾难，会导致大量重复代码，模块间的接口完全是杂乱混淆而非正交的
方式1>: 专业程序员不再拒绝别人修改自己代码，不会在代码上构造所有权的藩篱，而是尽可能多的互相协作，通过合作达到学习的目的
方式2>: 结对编程也是分享知识的最好途径，可以学习系统的不同部分和业务，这样在紧要关头，每位团队成员也能够协助其他人的位置
方式3>: 互相协作完成代码编写也是最有效率且最有效果的代码复查方式
方式4>: 搭档会捕捉你疏忽遗漏的事情，会提出有帮助的想法
❷【学会说”不“】：一些不太合理的需求或者更好的想法 勇敢说不 提出合理化建议
❸【TDD】
测试代码、产品代码 (整洁的代码更易于理解、更易于修改、也更易于扩展。代码更简洁了，缺陷也更少了。整个代码库也会随之改善，杜绝业界常见的放任代码劣化而视若不见的状况)、测试先行、以用户的需求进化为核心，采用迭代、循序渐进的方法进行开发（开发环境、测试环境、生产环境; 敏捷开发，小步快跑，快速迭代），最后验收达成共识
代码写的再快些了，忘记什么'抽象工厂'吧，用'for'循环代替组合吧，最后使尽浑身解数，用尽所有可能狂写代码，复制粘贴...，单元测试就免了...
❹【时间管理】
①会议内容：本周做了什么、下周计划、遇到的问题 ②注意力调整、时间拆分、评估每个任务的优先级，按照真实的紧急程度来执行任务
❺【预估】：面对的最简单也最可怕的活动之一
①结合前边的承诺；开发认为预估是猜测、业务方认为是承诺(必须做到/按时完成，据此拟定计划)
②计算方法(大任务拆成小任务预估)
③为业务方提供可信的预估结果，以便做出计划，如果做不到就不要给出承诺（协商） 如果承诺要解决某个认为可以解决的bug，但随后发现解决起来远比自己预想的棘手，提前发出预警信号，可以帮助我们解决在沟通中可能发生的不少问题
❻【压力】
①避免压力、承诺、让系统代码和设计尽可能保持整洁来避免压力(不要容忍错乱、混乱会降低速度，导致工期延误)
②预见压力、转移、消除压力-->寻求帮助-->从容不迫、专心致志-->多交流、多关心队友、竭力做到尽职尽责
❼【分享】
