搞开发这11年，我总结出了这些开发经验

在最初的11年发展中，经验丰富的网易、百度、腾讯研究院、米格等地，先后做过3D游戏、二维页面导航、浏览器、移动翻译等应用。

积累了一些见解，一定还有幼稚的地方，当抛砖引玉时，聊笑话。

1、流程对团队来说太重要了

如果你没有地图，至少要向李光学习，找到一匹知识渊博的老马。如果你连一匹老马都没有，你最好在三个臭皮匠中间好好讨论一下，试图超越诸葛亮。如果三个臭皮匠连讨论都不好，那就是典型的暴徒。写代码前最好戴上三个冰香，倒上一杯浑浊的酒，先拜菩萨，再拜谷歌。

就个人而言，我属于温和的性格（程序员大多都有良好的性格），但我确实遇到了一些坚强的人，说了很多坚强的话。在技术方面，一旦听到任何反对意见，一个词就会引起私人的不满。无论这种风格是自私自利还是老于世故，都需要仔细判断。

为什么流程很重要？事实上，如果团队中有孙悟空的话，那么去西方取佛经可能不需要任何过程，只要方向可以。但作为普通战士，他们应该先被打败。在找算命师的时候，我们应该先听听那些不好的地方。好地方不需要听。他们总是好的，坏的地方必须听他们的，这样我们才能避开他们。

这就是我的态度：先悲观一点，划清底线，考虑在这个底线上你该怎么做？

这是我养成的一个习惯，但它肯定不适用于买房子。

如何画底线？假想的队伍里没有孙悟空。你怎么能从你的唐玄藏、八戒和沙僧身上学到东西呢？
这个月去哪里，遇到山怎么走，过河怎么走，遇到一个抢劫道路的怪物，谁会反抗呢？如果有女孩在营救途中呢？这就是过程，原则。

我经历了一个非常混乱的阶段。这一切都发生在很多年前。可以说它不涉及一个人。

2011年，百度浏览器团队遇到了几件影响深远的事情。在一次会议上，该产品展示了一款谷歌产品。里面有一个很酷的3D效果。它需要开发和添加。只花了两天时间。所有人都惊呆了。后续开发为了跟上节奏，导致大量的bug，为了修改bug，领导会根据人员平均分配所有bug，导致不同模块的学生相互修改……很难想象。就像让一个厨师做一个面包卷来改变西湖醋鱼的味道。

最初的现象是：bug下降的慢，延伸 bug 反而增加，每个人都累的半死，代码风格极其杂乱，为了赶工导致的临时方案层出不穷；

中期：越来越多的人离开，代码很难维护，新的需求与以前的临时解决方案冲突。

以后：要做一些修理，调整结构，保证正常运行，就跟在飞机上拆卸零件一样困难。

然后我很快就辞职了…我真的看不到成功的可能性。

后来，当我们来到腾讯的团队时，我们觉得这个过程更加标准化了。需求和缺陷由TAPD跟踪，产品按节奏发布，需求提出前反复讨论可行性，有特殊的质量跟踪，有特殊的用户反馈，每天都知道该做什么，明天该做什么。有产品需求和开发需求！这很重要。很多团队只有产品的需求，发展就像牛，不管土地是犁？

其实，过程并不那么复杂，也就是说，每个部门都有自己的责任+节奏。我们都是多雷米法·索拉西多的一部分，我们每个人都有自己的责任，然后我们一起以一种节奏奔跑。设定要做什么和要跑什么的节奏。

2、不要炫耀你的技能，踏实地写代码

网上有一个段子，说有人要用JS实现一个简单的功能，然后朋友给他推荐了几十个库。

真的有必要吗？具体情况具体分析。

要想住在家里，你只需要一套普通的工具；如果你是汽车修理工，你需要一套工具；如果你是个光头党，你需要一台伐木机。用筷子、刀叉吃饭，你可以，但不要用小猪刀，不要用八把长矛！当然，你也不能用牙签。

要使用哪些工具和库？要求人们以公里为单位进行更多搜索。例如：在Android上加密，使用SQL chpher和微信，你当然可以学习；在数据库上使用ORM理念，使用KM推荐的Greendao；在PC上使用3D引擎，使用Ogre；小游戏演示，使用irrlicht；编写webgl，使用threejs就足够了。

首先，思考一下：一些大股东是否生活在其中，未来的发展趋势是什么？这些库对安装包大小的影响有多大？你有没有调查过同样的产品在使用什么？

在决定使用什么之前，最好遵循成功项目的步骤。

3、架构上实用+适用

很喜欢曾国藩的一句话：结硬寨、打呆仗。

哪一个更好，长蛇阵还是金八门锁阵？iOS是一个单一的进程，Android版本的微信3.5之前是一个单一的进程，3.5之后有独立的网络进程。PC浏览器的进程结构比较复杂，用户界面进程、内核进程、渲染进程、进程调整模型都是根据页数而定的。

这些设计都很好，每一个都有自己的原因，它们适用于目前的产品。所以我的观点是：首先分析当前产品的规模和性质，然后设计架构。

目前阶段：开发效率+架构平衡；并期待三个月或半年左右，看看架构是否能适应。

当我是腾讯翻译的时候，我犹豫着模仿微信，加入独立的网络进程。随后，它扭转了排名第一和第二的竞争局面，最终采用了主功能单过程模型。

分析了产品规模、人员规模、功能阶段、具体问题。

4、既要有攻城之力，也要有熬战之气——BUG

产品开发之后，一定会有缺陷。事实上，开发人员在工作过程中，有一定的直觉或心理预测，即功能模块的质量。质量包括可维护性、可扩展性、算法呈现效率、错误和崩溃率。

功能开发完成后，城市将开始戒备。

部分由体系结构（如更复杂的体系结构）引起的错误可能导致复杂的实现细节。

但是仍然有很多错误，这实际上是由以下三个原因造成的：

1。不了解API、平台或SDK版本。例如，Android中的非主线程不能直接处理UI相关的事物，Java的内存释放不是绝对的，交互的方向是不能释放的，函数的数量受到DEX问题的制约。这就是学习广度和熟练程度的问题。

2。还有一些错误是由粗心引起的。例如，空指针的问题和野生指针的问题。在C语言的开发过程中，野生指针的问题和GDI句柄的释放都是严格的代码需要避免的问题，一些工具或方法可以避免这些问题，如在Android中使用@nullable和@nonnull来增强对空指针的检测。

3。还有一些错误，是由不同的用法引起的。例如：我现在有一个模块崩溃。其本质是逻辑异常边界处理不当。例如，Android上的OOM问题和用户界面引起的对象发布问题主要集中在PC上，其中一些异常是通过测试发现的，一些是通过用户反馈发现的，还有一些是通过自己的异常处理发现的。例如，Android中的Try-Catch机制实际上是在遇到异常时纠正错误的一个机会。

5、自审

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

如果之前的程序代码质量不好，以后修改问题的时间会更多。在发展的过程中，你必须问问自己，你是在不断地纠正以前的错误，还是在做一些新的事情。如果您更改错误的时间多一点，那么您应该注意代码的质量！乌苏鲁语

6、注释

我非常喜欢写笔记。丹尼尔说：代码是最好的评论。不幸的是，我还没有达到那个水平。所以我会把笔记写得很清楚。一是为了方便自己将来的维修；二是为了方便别人接管。

这就是我在翻译项目中写笔记的方式。1：对于非常复杂的逻辑，需要按12345的顺序写清楚；2：对于函数中的一个参数，需要解释为什么要设置这个参数，特别是对于实用程序类中的函数——要澄清参数的背景含义，以便其他调用方能更清楚地理解它。

我通常不用英语写作。虽然这看起来很低调，但每个人都更容易理解。不要对编码和评论过于自大。这样做的目的是让你的合作伙伴或继任者更容易理解，让他们减少加班时间。

7、代码结构

代码结构应该是清晰的。有些按功能分类，另一些按用户界面结构分类。还有公共工具、数据管理、主逻辑控制。无论您使用哪种想法，有序的代码结构都可以让每个人感觉干净。像日本的整理技术一样，许多小资产阶级称赞它们干净、整洁、易于管理。

还有一个重要的好处：代码的结构实际上表明——程序逻辑思维的一个模块——人们在不同的领域工作。

8、代码风格

统一的代码样式！就像汤姆，安东尼，柳川枫树，石头破碎，圣杰夫拉斯基的一家人一样，他们都处于困境中。理论上，如果你看一个函数，你可以区分哪些变量是成员变量，哪些是局部变量，哪些是全局静态值。

除了统一命名之外，还有一行代码的最大宽度、对函数的连续调用的长度以及头文件的包含样式，最好有一个约定。添加类出现的时间和创建人的姓名似乎没用，但在跟踪问题时，您可以看到时间线的好处。

9、安全与逆向

这是针对Android的，需要考虑PC插件。首先，Android必须避免被其他人逆转。我成功地扭转和重新包装了第一和第二竞争对手。看起来有点不可思议，但确实如此。强化+模糊+代码判断，最好是全部。

在安全性方面，我们可以看到菱形扫描的漏洞，并逐一修改。公司的许多工具都非常有用！

10、开发效率

开发效率可以用这些方式提升：

1 . 构建公用工具类，方便大家使用

2 . 使用开源的一些包，例如 ORM 思想的数据库等

3 . 可以很快的找到问题。开发中，找 bug 的时间，往往是很多的。我用的方法有3个： 使用 try catch； 拦截所有 crash 到我指定的地方；超多的 Log，Log 有统一的控制开关。

4 . 借力：数据上报用灯塔，崩溃上报用 bugly，公司 KM 上很多经验，拿过来用。

11、安装包体积

1 . TINY 压缩图片

2 . 删除无效的资源文件

12、UI渲染效率

用户界面是用户的第一感觉；用户界面快速稳定，第一感觉不会太差；良好的内存管理，基本的半崩溃管理；良好的用户界面管理，相当于人机交互管理。

UI 上的开发是：渲染效率与渲染效果的平衡。

很匆忙的写的，必然有很幼稚的地方，欢迎斧正。