正文
最初的现象是：bug下降的慢，延伸bug反而增加，每个人都累的半死，代码风格极其杂乱，为了赶工导致的临时方案层出不穷；
到了中期：人员离职越来也多，代码难以维护，新加的需求与之前的临时方案冲突。
到了后期：想做一些修复，想调整架构，又要保证正常运行，其难度好比在一架飞行的飞机上拆换零件。
然后我也急忙离职了。。。。实在看不到成功的可能性。
后来到了腾讯的团队，感觉流程就规范多了。需求和bug有Tapd跟踪，产品发布按照节奏，需求提出前会和开发反复讨论可行性，有专门的质量跟踪，有专门的用户反馈，每天知道要做什么，也知道明天要做什么。有产品需求，也有开发需求！这个非常重要。很多团队，都是只有产品需求，开发好像牛一样，耕完地就不管了？
流程其实没那么复杂，就是各司其责+节奏。我们都是“哆瑞咪发梭拉西多”中的一员，各自有各自的责任，然后组合在一起，按照一个节奏跑起来。把该做的事情与该跑的节奏定好。
网上有一个段子，说有人要用JS实现一个简单的功能，然后朋友给他推荐了几十个库。
真的有必要吗？具体情况具体分析。
居家过日子，你只需要一套普通的工具就可以了；如果你是修车的，你需要一套修车的工具；如果你是光头强，你需要一台伐木机。 吃饭用筷子，用刀叉，都可以，但不要用杀猪刀，不要用丈八长矛！，当然也不能用牙签。
用什么工具，用什么库，问问过来人，多在KM上搜索一下。举个例子：android上加密，用SQLChpher就可以了，微信也在用，你当然可以学习；数据库ORM思想，用KM上推荐的GreenDAO就可以了；PC上3D引擎，用OGRE就可以了；小型游戏DEMO，用Irrlicht足够；写WebGL，用ThreeJS足够。
首先想想：一些大库hold的住吗，后续发展如何？这些库对安装包的体积影响有多大？有没有调研过同样的产品在用什么？
想清楚了再决定用什么，最好是跟随成功项目的脚步。
很喜欢曾国藩的一句话：结硬寨、打呆仗。
一字长蛇阵、八门金锁阵，哪个好？iOS都是单个进程，微信Android版本3.5以前是单进程，3.5以后有独立的网络进程； PC浏览器的进程架构更加复杂，UI进程、内核进程、Render进程，而且还有根据页面多少的进程调节模型。
这些设计都很好，各有各的道理，都适用于当前的产品。所以我的观点是：首先分析当前产品的规模、性质，然后再设计架构。
