流程管理与规范
如果你的团队没有一个斗战胜佛，那么最好三个臭皮匠商量出一个规范出来。
怎么说呢，产品和开发讨论出方案的可行性，产品发布按照节奏，有质量跟踪，专门的用户反馈，知道今天干啥，明天要干啥。
需求、开发要互相反馈
库、框架、架构的选型
库、框架的选择
- 我的产品要做什么
- 我需要用到哪些技术，用到什么程度
- 在心里或者文档上清清楚楚描述出我的技术、功能需求
- 拿着需求（拿在心里），去搜索别人的使用案例
- 或者问问别人用的啥
- 大框架、大库很能打但是团队hold的住吗？
- 小库简单，功能够用吗？这些都是要问的问题，选择合适自己的
- 团队技术学习成本、库能够做的事、坑多不多、文档多不多社区活不活跃都是参考标的
架构选型
架构我不懂，但是参考竞品是一个很好的思路
怎么说呢，就是最好拿到行业老大、老二的产品，看看他们都怎么架构，他们的痛点基本也是我们将要踩得坑
bug之战
开发完成后，开发者对各个模块的质量应该心里有个大致的数。
什么是质量——可维护性、拓展性、算法效率、bug崩溃率
bug分三种：
- 对api的熟悉程度不够,如jdk、java机制、sdk等。java内存释放不是绝对的，相互指向无法释放
- 粗心大意，空指针、野指针
- 逻辑上的问题，逻辑情况没考虑全面
注意这三点，大部分问题都会少犯一点
简单的自省标准
我后面的时间是越来用于修改以前的错误，还是做新的功能。如果老是承担过去，那么就要问问自己的代码质量了
代码风格
什么叫好的代码风格呢？就是别人接受你的摊子的时候，没一边读你代码，一边骂你祖宗十八代
注释
emmm，好吧，我不是大牛，我不能做到代码就是最好的注释。那么，就好好的写好注释吧。
清晰的注释可以：
- 自己以后能看得懂自己代码
- 别人接受摊子的时候少骂娘
典型的，如果涉及的类的逻辑有点多，最好按照1 2 3 4 5 6一一列出来，写清楚，把逻辑说明白了。想象一个新同事刚加入项目组，怎样让他快速看明白我们的代码
一些公共工具类，里面的参数必要的最好解释清楚，这些参数干嘛用的
代码组织结构
如果按照功能划分，公共工具类一块，配置类一块，公共常量一块，公共异常一块，他们又都可以放在common包下面
按照每一个功能模块，每一个大功能用一个大包，子功能用一个小包
为什么这么分呢？我觉得，写代码的时候大家肯定按照功能块分工的。每一个功能模块一个package，大家互相不干扰是最好的。然后一些公共工具类很可能是leader写的，毕竟是团队最能打的
命名风格
怎么说呢？如果洋里洋气就都洋气一点，国产特色就大家都国产一点，总之高大上也罢，土里土气也好，商量个合适的风格出来，大家保持一致
开发效率
开发效率和很多相关，程序员的技术熟练度，工具趁手与否都有关系
可以从下面几点考虑提升效率，
- 构建公用工具类，大家都用
- 使用名声好的开源包
- 快速找出问题，主要是try-catch，打log的相关配置、操作有关。就我个人而言，目前就是一手debugger和单元测试或者直接蒙一个地方
小结
主要涉及到项目的质量管控方面的一些忠告