作者 | 苳天里的一把火

原文 | http://blog.itpub.net/31510618/viewspace-2151588/

今天给大家带来一个大牛的故事，希望给所有学习系统开发的编程人分享一点人生感悟。张生在一线做了十年的开发，经历了网易、百度、腾讯研究院、MIG 等几个地方，陆续做过 3D 游戏、2D 页游、浏览器、移动端翻译 app 等。

积累了一些感悟。必然有依然幼稚的地方，就当抛砖引玉，聊为笑谈。

张生个人属于性格温和的 (程序员大多性格不错)，但确实见过少数强势的人，说很多强势的话。在技术上一言而决，一听到任何反对就上升到私人恩怨。这样的风格，到底是刚愎自用，还是胸有成竹，就需要仔细判断了。

为什么说流程重要呢? 实际上，如果团队上有孙悟空存在，去西天取经，大概也不需要什么流程，只要方向就可以了。 但作为普通的战士，应该先虑败。找人算命时，应该先听听不好的地方，好的地方就不用听了，总归是好的，不好的地方一定要听，这样才能规避。

张生的态度：先悲观一点，划清底线，考虑在这个底线上你该怎么做?

这是张生做开发的一个习惯，但这个习惯肯定不适用于买房。怎么划清底线呢? 就是假想团队中没有孙悟空了，光靠你唐玄奘、猪八戒和沙和尚，应该怎么去取经。

这个月走什么地方，遇到山怎么走，遇到河怎么过，遇到路上有妖怪劫道，谁去抵挡。遇到路上有少女要搭救，怎么办? 这就是流程，是原则。

张生经历过一个流程很混乱的阶段。都是很多年前的事情了，可以拿出来说说，不涉及单个人。

2011 年在百度浏览器团队时遇到几件让人影响深刻的事情。 有一次开会，产品拿出 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 与崩溃率。

功能开发完成后，就要开始守城了。

bug，一部分产生是由于架构带来的，例如比较复杂的架构，会导致复杂的实现细节;

但还有很大部分 bug，其实是基于如下三个原因产生的：

对于某个 api 的不了解，或者对于某个平台，或者 SDK 版本的不了解。 举例而言：android 里面非主线程，是不能直接处理 UI 相关的事情的; JAVA 的内存释放也不是绝对的，相互指向是无法释放的; 函数个数是有 DEX 问题制约的 --------------------- 这些 bug 的产生，也是开发人员摸索学习的过程，经历过一次就不会再犯了。这是学习广度与熟练度的问题;

还有一些 bug，是由于粗心大意导致的。例如空指针的问题，野指针的问题。在 C 的开发中，野指针的问题，GDI 句柄的释放问题，这些都是严谨的代码需要避免的; 而又一些工具，或者方法是可以规避这些问题的，例如 android 中 的利用 @ Nullable 和 @ NonNull 加强空指针检测等方法;

还有一些 bug，是由于 “使用情况各异导致的”。例如：偶现在某个模块 crash。这里的本质还是因为逻辑的异常边界没有处理好。例如 android 上的 OOM 问题，还有 PC 上 UI 焦点导致的对象释放问题。这些异常情况，一部分靠测试发现，一部分靠用户反馈，还有一部分就靠自己的异常处理。例如 Android 中的 try catch 机制，其实就是遇到异常了，你能纠正错误的机会。

每过一段时间，都要站在高空俯视自己，问问：到底是在承担过去，还是在改变未来。

数领先机 智赢未来

DTCC2018

中国数据库技术大会（简称 DTCC）是国内数据库及大数据领域规模最大、最受欢迎的技术交流盛会，每年一届。自 2010 年以来，迄今已成功举办了八届，累计参与人次达到 20000+。DTCC 每年都将邀请百余位行业专家，就热点技术话题进行分享，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。

2018 年 5 月 10-12 日，第九届中国数据库技术大会（DTCC2018）将如约而至。本届大会以 “数领先机 • 智赢未来” 为主题，设定 2 大主会场及 20 个技术专场，邀请来自国内外互联网、金融、教育等行业百余位技术专家，共同探讨 Oracle、MySQL、NoSQL、大数据、机器学习、区块链、数据可视化等领域的前瞻性热点话题与技术。

点击左下阅读原文，立享购票8.8折优惠