如果你的团队没有一个斗战胜佛，那么最好三个臭皮匠商量出一个规范出来。
怎么说呢，产品和开发讨论出方案的可行性，产品发布按照节奏，有质量跟踪，专门的用户反馈，知道今天干啥，明天要干啥。
需求、开发要互相反馈
架构我不懂，但是参考竞品是一个很好的思路
怎么说呢，就是最好拿到行业老大、老二的产品，看看他们都怎么架构，他们的痛点基本也是我们将要踩得坑
开发完成后，开发者对各个模块的质量应该心里有个大致的数。
什么是质量——可维护性、拓展性、算法效率、bug崩溃率
bug分三种：
注意这三点，大部分问题都会少犯一点
我后面的时间是越来用于修改以前的错误，还是做新的功能。如果老是承担过去，那么就要问问自己的代码质量了
什么叫好的代码风格呢？就是别人接受你的摊子的时候，没一边读你代码，一边骂你祖宗十八代
emmm，好吧，我不是大牛，我不能做到代码就是最好的注释。那么，就好好的写好注释吧。
清晰的注释可以：
典型的，如果涉及的类的逻辑有点多，最好按照1 2 3 4 5 6一一列出来，写清楚，把逻辑说明白了。想象一个新同事刚加入项目组，怎样让他快速看明白我们的代码
一些公共工具类，里面的参数必要的最好解释清楚，这些参数干嘛用的
如果按照功能划分，公共工具类一块，配置类一块，公共常量一块，公共异常一块，他们又都可以放在common包下面
按照每一个功能模块，每一个大功能用一个大包，子功能用一个小包
为什么这么分呢？我觉得，写代码的时候大家肯定按照功能块分工的。每一个功能模块一个package，大家互相不干扰是最好的。然后一些公共工具类很可能是leader写的，毕竟是团队最能打的
怎么说呢？如果洋里洋气就都洋气一点，国产特色就大家都国产一点，总之高大上也罢，土里土气也好，商量个合适的风格出来，大家保持一致
开发效率和很多相关，程序员的技术熟练度，工具趁手与否都有关系
可以从下面几点考虑提升效率，
主要涉及到项目的质量管控方面的一些忠告
原文：https://www.cnblogs.com/Franken-Fran/p/project_manage.html