干货分享:十年经验高级程序员的开发经验总结

2019-04-02  本文已影响0人  勤奋的码农
干货分享:十年经验高级程序员的开发经验总结

1、引言

在互联网一线做了十年的程序开发,经历了网易、百度、腾讯研究院、MIG 等几个地方,陆续做过 3D 游戏、2D 页游、浏览器、移动端翻译 app 等。积累了一些感悟,但必然有依然幼稚的地方,就当抛砖引玉,聊为笑谈。

干货分享:十年经验高级程序员的开发经验总结

2、关于作者

康亮

3、对于开发团队而言,流程太重要了

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

为什么说流程重要呢?

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

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

这是我做开发的一个习惯,但这个习惯肯定不适用于买房。

怎么划清底线呢?就是假想团队中没有孙悟空了,光靠你唐玄奘、猪八戒和沙和尚,应该怎么去取经。

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

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

2011年在百度浏览器团队时遇到几件让人影响深刻的事情。 有一次开会,产品拿出 Google 某个产品的 DEMO,里面有一段很酷炫 3D 效果,要求开发加上,只给2天时间,大家目瞪口呆。后续的开发为了赶节奏,导致非常多的 bug ,又为了修改 bug ,leader 将所有的 bug 按照人员平均分配,导致不同模块间的同学相互修改......实在难以想象。好比让做花卷的厨子,去修改西湖醋鱼的味道。

然后我也急忙离职了......实在看不到成功的可能性。

后来到了腾讯的团队,感觉流程就规范多了。需求和 bug 有 Tapd 跟踪,产品发布按照节奏,需求提出前会和开发反复讨论可行性,有专门的质量跟踪,有专门的用户反馈,每天知道要做什么,也知道明天要做什么。有产品需求,也有开发需求!这个非常重要。很多团队,都是只有产品需求,开发好像牛一样,耕完地就不管了?

流程其实没那么复杂,就是各司其责+节奏。我们都是“哆瑞咪发梭拉西多”中的一员,各自有各自的责任,然后组合在一起,按照一个节奏跑起来。把该做的事情与该跑的节奏定好。

干货分享:十年经验高级程序员的开发经验总结

▲ 图左 - “精英团队”,图右 - “乌合之众”

4、不要炫技,老老实实写代码

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

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

吃饭用筷子,用刀叉,都可以,但不要用杀猪刀,不要用丈八长矛!当然也不能用牙签。

用什么工具,用什么库,问问过来人,如果是腾讯内部,可以多在KM上搜索一下。

举个例子:

首先想想:一些大库 hold 的住吗,后续发展如何?这些库对安装包的体积影响有多大?有没有调研过同样的产品在用什么?

想清楚了再决定用什么,最好是跟随成功项目的脚步。

干货分享:十年经验高级程序员的开发经验总结

5、架构上要遵循:实用+适用的原则

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

一字长蛇阵、八门金锁阵,哪个好?iOS 都是单个进程,微信 Android 版本3.5以前是单进程,3.5以后有独立的网络进程; PC 浏览器的进程架构更加复杂,UI 进程、内核进程、Render 进程,而且还有根据页面多少的进程调节模型。

这些设计都很好,各有各的道理,都适用于当前的产品。

所以我的观点是:首先分析当前产品的规模、性质,然后再设计架构。

在当前阶段达到:开发效率+架构的平衡;并向后展望3个月或者半年左右:看看架构能不能适应。

我做腾讯翻译君时,曾反复犹豫要不要模仿微信加入独立的网络进程。后来逆向了有排在第一二位的竞品,最终采用了现在的主功能单进程模型。

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

干货分享:十年经验高级程序员的开发经验总结

6、既要有攻城之力,也要有改Bug的熬战之气

产品开发完成后,必然有 bug 。其实开发人员在工作过程中,是有一定的直觉或者心理预判的,即:某个功能模块的质量如何。 这里面的质量包括:可维护性、扩展性、算法渲染效率,还有就是bug与崩溃率。

干货分享:十年经验高级程序员的开发经验总结

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

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

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

7、自审、反思

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

如果之前程序代码质量不好,后面修改问题的时间就会比较多。到了开发的中期,得多问问自己,你在不停的改正以前的错误,还是在做新的东西。 如果修改错误的时间多一点,那就要注意自己的代码质量了!

干货分享:十年经验高级程序员的开发经验总结

▲ 程序员的“进阶之路”

8、注释!注释!

我很喜欢写注释。

有大牛说:代码就是最好的注释。 可惜我还没有达到那个程度。

所以,我会把注释写的非常清楚:

干货分享:十年经验高级程序员的开发经验总结 干货分享:十年经验高级程序员的开发经验总结

上图两个截图,是我在翻译君项目中写注释的方式:

我一般不用英文写。虽然这样看起来格调很低,但胜在大家都能轻松的看懂。写代码不能太傲娇,写注释也不要太傲娇,目的是让你的搭档或者接手者,更轻松的理解,让她/他少加班。

干货分享:十年经验高级程序员的开发经验总结

9、代码结构

代码结构要清晰。有按照功能划分的,有按照 UI 结构划分的。还有公用工具类,有数据管理,有主逻辑控制。不管用哪种思想,有序的代码结构,可以让每个人感觉很干净。好比日本的收纳整理技巧让很多小资推崇,无非就是干净、整洁、便于管理。

而且,还有一个重要的好处:代码结构表现出来的其实是——程序的一个模块逻辑思想——让大家工作在不同的区域。

10、代码风格

代码风格统一!好比一家人,有叫 Tom 的,有叫安东尼的,还有叫流川枫、石破天、圣杰夫拉斯基,无所适从。

理论上,看一个函数,就能从名称上区分哪些是成员变量,哪些是局部变量,哪些是全局静态值。

除了命名统一外,还有一行代码最大的宽度,函数的连续调用长度等,头文件的包含风格,也最好有一个约定。类的出现时间,创建人名,最好也加上,看起来没用,但到了追踪问题时,就能看出时间线的好处。

这方面可以看看阿里团队做的几个编码规范方面的规约,《重磅发布:《阿里巴巴Android开发手册(规约)》》、《阿里技术结晶:《阿里巴巴Java开发手册(规约)-终极版》》。

干货分享:十年经验高级程序员的开发经验总结

11、安全与逆向

这是针对Android说的,还有PC插件也需要考虑。Android 上首先要防止被别人逆向,我成功逆向并重新打包过有第一位和第二位的竞品。这似乎有点不可思议,但确实做到了。加固+混淆+代码判断,最好都有。

安全上,可以看金刚扫描的漏洞,逐一修改就行。

12、开发效率

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

1.png

获取以上Java高级架构最新视频,欢迎

加入Java进阶架构交流群:142019080。直接点击链接加群。https://jq.qq.com/?_wv=1027&k=5lXBNZ7

上一篇下一篇

猜你喜欢

热点阅读