大牛十年工作经验总结，值得学习.docxVIP

大牛十年工作阅历总结，值得学习 行军打仗，你需要一个向导；假如没有向导，你需要一个地图；假如没有地图，至少要学习李广，找一匹识途的老马；假如你连老马也没有，那最好可以三个臭皮匠好好争辩，力图赛过一个诸葛亮；假如三个臭皮匠连好好争辩也做不到，那就是典型的乌合之众了，最好写代码前，点上三炷香，斟上一杯浊酒，先拜拜菩萨，再拜拜谷歌。 我个人属于性情温存的（程序员大多性情不错），但的确见过少数强势的人，说很多强势的话。在技术上一言而决，一听到任何反对就上升到私人恩怨。这样的风格，到底是刚愎自用，还是胸中有数，就需要认真推断了。 为什么说流程重要呢？实际上，假如团队上有孙悟空存在，去西天取经，或许也不需要什么流程，只需方向就可以了。 但作为一般的战士，应当先虑败。找人算命时，应当先听听不好的地方，好的地方就不用听了，总归是好的，不好的地方肯定要听，这样才能规避。 这就是我的态度：先悲观一点，划清底线，考虑在这个底线上你该怎样做？ 这是我做开发的一个习惯，但这个习惯确定不适用于买房。 怎样划清底线呢？就是假想团队中没有孙悟空了，光靠你唐玄奘、猪八戒和沙和尚，应当怎样去取经。 这个月走什么地方，遇到山怎样走，遇到河怎样过，遇到路上有妖怪劫道，谁去抵抗。遇到路上有少女要搭救，怎样办？这就是流程，是准绳。 我经受过一个流程很混乱的阶段。都是很多年前的事情了，可以拿出来说说，不涉及单个人。 2021年在百度扫瞄器团队时遇到几件让人影响深刻的事情。 有一次开会，产品拿出Google某个产品的DEMO，里面有一段很酷炫3D 效果，要求开发加上，只给2天时间，大家目瞪口呆。后续的开发为了赶节拍，导致格外多的bug，又为了修改bug，leader将全部的bug依据人员平均安排，导致不同模块间的同学相互修改。。。。。实在难以想象。好比让做花卷的厨子，去修改西湖醋鱼的味道。 最后的现象是：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进程，而且还有依据页面多少的进程调整模型。 这些设计都很好，各有各的道理，都适用于当前的产品。所以我的观点是：首先分析当前产品的规模、性质，然后再设计架构。 在当前阶段达到：开发效率+架构的平衡；并向后展望3个月，或者半年左右，看看架构能不能顺应。 我做腾讯翻译君时，曾反复迟疑要不要仿照微信加入独立的网络进程。后来逆向了有排在第一二位的竞品，最终接受了现在的主功能单进程模型。 产品规模、人员规模、功能阶段，具体问题具体分析。 四、既要有攻城之力，也要有熬战之气——BUG 产品开发完成后，必定有bug。其实开发人员在工作过程中，是有肯定的直觉或者心理