红宝书>新度>正文

做开发十年,我总结出了这些开发经验

2019-01-14 09:06:48 产品中国 分享

在一线做了十年的开发,经历了网易、百度、腾讯研究院、MIG等几个地方,陆续做过3D游戏、2D页游、浏览器、移动端翻译app等。

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

一、对于团队而言,流程太重要了

行军打仗,你需要一个向导;如果没有向导,你需要一个地图;如果没有地图,至少要学习李广,找一匹识途的老马;如果你连老马也没有,那最好可以三个臭皮匠好好讨论,力图胜过一个诸葛亮;如果三个臭皮匠连好好讨论也做不到,那就是典型的乌合之众了,最好写代码前,点上三炷香,斟上一杯浊酒,先拜拜菩萨,再拜拜谷歌。

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

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

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

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

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

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

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

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

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

到了中期:人员离职越来也多,代码难以维护,新加的需求与之前的临时方案冲突。

到了后期:想做一些修复,想调整架构,又要保证正常运行,其难度好比在一架飞行的飞机上拆换零件。

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

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

流程其实没那么复杂,就是各司其责+节奏。我们都是“哆瑞咪发梭拉西多”中的一员,各自有各自的责任,然后组合在一起,按照一个节奏跑起来。把该做的事情与该跑的节奏定好。(web前端学习交流群:328058344 禁止闲聊,非喜勿进!)

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

网上有一个段子,说有人要用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与崩溃率。

声明:本站部分资源来源于网络,版权归原作者或者来源机构所有,如作者或来源机构不同意本站转载采用,请通知我们,我们将第一时间删除内容。本站刊载文章出于传递更多信息之目的,所刊文章观点仅代表作者本人观点,并不意味着本站赞同作者观点或证实其描述,其原创性及对文章内容的真实性、完整性、及时性本站亦不作任何保证或承诺,请读者仅作参考。
编辑: