一、对于团队而言流程的重要
为什么说流程重要呢?举个例子，如果团队上有孙悟空存在，去西天取经，大概也不需要什么流程，只要方向就可以了。 但作为普通的人，应该先虑败。找人算命时，应该先听听不好的地方，好的地方就不用听了，总归是好的，不好的地方一定要听，这样才能规避。
怎么划清底线呢?就是假想团队中没有孙悟空了，光靠你唐僧、猪八戒和沙和尚，应该怎么去取经。
这个月走什么地方，遇到山怎么走，遇到河怎么过，遇到路上有妖怪劫道，谁去抵挡。遇到路上有少女要搭救，怎么办?这就是流程，是原则。
我经历过一个流程很混乱的项目。 有一次开会，产品拿出某个产品的DEMO，里面有一段很酷炫3D 效果，要求开发加上，只给2天时间，大家目瞪口呆。后续的开发为了赶节奏，导致非常多的bug，又为了修改bug，leader将所有的bug按照人员平均分配，导致不同模块间的同学相互修改。。。。。实在难以想象。好比让做花卷的厨子，去修改西湖醋鱼的味道。
最初的现象是：bug下降的慢，延伸bug反而增加，每个人都累的半死，代码风格极其杂乱，为了赶工导致的临时方案层出不穷;
到了中期：人员离职越来也多，代码难以维护，新加的需求与之前的临时方案冲突。
到了后期：想做一些修复，想调整架构，又要保证正常运行，其难度好比在一架飞行的飞机上拆换零件。
后来我到的开发团队，流程就规范多了。需求和bug有Tapd跟踪，产品发布按照节奏，需求提出前会和开发反复讨论可行性，有专门的质量跟踪，有专门的用户反馈，每天知道要做什么，也知道明天要做什么。有产品需求，也有开发需求!这个非常重要。很多团队，都是只有产品需求，开发好像牛一样，耕完地就不管了?
流程其实没那么复杂，就是各司其责+节奏。我们都是小零件中的一员，各自有各自的责任，然后组合在一起，按照一个节奏跑起来。把该做的事情与该跑的节奏定好。
二、老老实实写代码
居家过日子，你只需要一套普通的工具就可以了;如果你是修车的，你需要一套修车的工具。 吃饭用筷子，用刀叉，都可以，但不要用杀猪刀，不要用丈八长矛!，当然也不能用牙签。
用什么工具，用什么库，问问过来人，多搜索一下。举个例子：android上加密，用SQLChpher就可以了;数据库ORM思想，用KM上推荐的GreenDAO就可以了;PC上3D引擎，用OGRE就可以了;小型游戏DEMO，用Irrlicht足够;写WebGL，用ThreeJS足够。
首先想想：一些大库hold的住吗，后续发展如何?这些库对安装包的体积影响有多大?有没有调研过同样的产品在用什么?
想清楚了再决定用什么，最好是跟随成功项目的脚步。
三、架构上实用+适用
首先分析当前产品的规模、性质，然后再设计架构。
在当前阶段达到：开发效率+架构的平衡;并向后展望3个月，或者半年左右，看看架构能不能适应。
产品规模、人员规模、功能阶段，这些具体问题具体分析。
四、与BUG的抗战
产品开发完成后，必然有bug。开发人员在工作过程中，是有一定的直觉或者心理预判的，即：某个功能模块的质量如何。 这里面的质量包括：可维护性、扩展性、算法\渲染效率，还有就是bug与崩溃率。
功能开发完成后，就要开始守城了。
bug的出现一部分产生是由于架构带来的，例如比较复杂的架构，会导致复杂的实现细节。
但还有很大部分bug，其实是基于如下三个原因产生的：
1 . 对于某个api的不了解，或者对于某个平台，或者SDK版本的不了解。
2 . 还有一些bug，是由于粗心大意导致的。例如空指针、野指针的问题。
3 . 还有一些bug，是由于“使用情况各异导致的”。例如：偶现在某个模块crash。这里的本质还是因为逻辑的异常边界没有处理好。例如android上的OOM问题，还有PC上UI焦点导致的对象释放问题。
五、注释
我很喜欢写注释。并且会把注释写的非常清楚。
其一：为了自己以后维护的方便; 其二：为了其他人接手的方便。
1：对于很复杂的逻辑，务必用12345的顺序依次写清楚;
2 ：对于函数中的某个参数，需要解释为什么要设置这个参数，尤其是公用工具类里面的函数---说清楚参数的背景含义，可以让其他调用者理解的更加清晰。
写代码不能太傲娇，写注释也不要太傲娇，目的是让你的搭档或者接手者，更轻松的理解，让她/他少加班。
六、代码结构
代码结构要清晰。有按照功能划分的，有按照UI结构划分的。还有公用工具类，有数据管理，有主逻辑控制。不管用哪种思想，有序的代码结构，可以让每个人感觉很干净。好比日本的收纳整理技巧让很多小资推崇，无非就是干净、整洁、便于管理。
而且，还有一个重要的好处：代码结构表现出来的其实是——程序的一个模块\逻辑思想——让大家工作在不同的区域。
七、代码风格
代码风格统一!理论上，看一个函数，就能从名称上区分哪些是成员变量，哪些是局部变量，哪些是全局静态值。
除了命名统一外，还有一行代码最大的宽度，函数的连续调用长度等，头文件的包含风格，也最好有一个约定。类的出现时间，创建人名，最好也加上，看起来没用，但到了追踪问题时，就能看出时间线的好处。
八、开发效率
开发效率可以这样提升：
1 . 构建公用工具类，方便大家使用
2 . 使用开源的一些包，例如ORM思想的数据库等
3 . 借力：数据上报用灯塔，崩溃上报用bugly，公司KM上很多经验，拿过来用。