04月09日
CODING 技术小馆 | 快速开发杂谈

本文为万科后端开发工程师 Helvetica 在 Coding 技术小馆 · 深圳站 的演讲内容整理。

我给大家带来的分享是“快速开发杂谈”。

我首先解释下题目的名字。“快速”的意思并不是你给我一个任务,我在两三天的时间内把做好扔回给你,你用两天觉得不 OK 又扔回给我,这不是快速。我理解快速是在项目的周期当中,所需要的时间最短,这个叫快速。狭义上“开发”的定义就是写代码,但是我这里定义的开发是从项目开始,到项目编码以及最后项目维护的过程。最后是“杂谈”,因为整个开发流程是非常庞大的,我无法从面面俱到的覆盖到,所以是“杂谈”,讲的是我在开发过程中的一些思考,希望给大家带来一些启发,也给大家推荐一本书,《代码大全》,里面讲的详细描述了整个开发的流程。

我先介绍下我自己。我最开始做的工作是运维,因为觉得不用跟产品经理沟通。在我的认知里,运维就是我自己做我自己的事情,专心研究技术的岗位。但实际上,虽然不用和产品沟通,但你还要跟其它很多人沟通。最后写代码研究技术的时间更少,我就又跑去做后端开发,后来被挖去做全栈,全栈的意思大概就是缺什么做什么[手动捂脸],做过 React Native,做过微信小程序,做过网页,同时也会做后端开发的工作。最后发现这样一直什么都学,学的不精,会比较焦虑,最后又跑去一家稍微大一点的公司做专职的后端开发。当然整个工作的过程中也自己会做一些好玩的项目,给自己使用的工具。

图片

今天分享的是“快速开发杂谈”,首先说“没有银弹”,意思没有一个万能的方法能解决你开发中遇到的所有问题。你需要在项目开发的过程中保持持续关注,想办法动用你的个人创造力,才能保证你的项目在保证质量的情况下按时完成。我后面会给一些小的 Tips,希望能帮助到大家。

首先我举一个例子,比如打扫房间,如果打扫完不一直耗费精力去收拾的话,那么过了两三天,房间一定又会重新乱回去。我觉得跟做项目是一样的,这个项目开始到完成的整个时间里,如果不去制定一些规范去来约束这个项目,最后这个项目会跟你的房间一样非常的混乱,任何人都不想碰它。这是我理解做项目与打扫房间的关系。

图片

开发前第一件要做的事就是需求分析,我觉得这是大多数程序员很不喜欢的一件事情。我不知道大家会花多长时间做需求分析,但是我个人而言会愿意花整个项目周期的 10%-20% 的时间去做需求分析。产品经理更关注的可能是功能应该怎么样,但作为程序员就需要考虑更多的边界情况了。这是一个很复杂的过程,如果产品经理会告诉你各种边界情况的话当然是最好的,如果没有只能自己的去做了。

相信大家都会遇到过产品经理提不合理需求的时候,那么这个时候该怎么办呢?下面我想通过一个例子来解释这个问题。

比如我去一家餐厅点餐,我要一盘西红柿炒鸡蛋,但是我跟服务员说西红柿炒鸡蛋里面给我加点麻辣牛肉,很明显这是很不合理的需求。软件开发也是如此,程序员在开发过程中会有合理的,不合理的需求。比如说我想要西红柿炒鸡蛋你给我炒的甜一点,这就是合理的需求,再确定好是不是合理需求的情况后,遇到不合理的需求应该怎么办?

比如说我是厨师,你跟我说要加麻辣牛肉,我肯定跟你说没人加麻辣牛肉的,这个需求不合理。如果顾客说不行我必须要这个,那怎么办?我会首先跟他说你加牛肉炒鸡蛋的口感会变得奇怪,其次牛肉也是要钱的,如果你坚持要在炒鸡蛋里面加牛肉给我多付多少钱。类比到软件开发流程过程中,会告诉他说你这样做很不合理,你这样做没人用,而且你加这个需求会延长这个项目的周期。但是最后拍板的人是你,我能做的就是提供给你各种各样的建议,最后我希望你来定夺,如果不合理我会跟老板来拍板,我不是拍板的,但我会尽可能提出我的意见和建议。

还有一种是产品经理提了需求虽然是合理的,但是从技术层面很难做,我相信大家都遇到过。这是我真实的遇到的一个案例,这边是一个类似于抽象的微服务的东西,是保存群聊有哪些群聊,保存群聊的名称和群主是谁,我这边是业务系统,我需要维护群聊与项目之间的关系,这个需求很简单,可能一两天就做出来。但是一旦产品经理会说我需要做一个管理后台,我需要提供给 App 各种各样的接口,如果做管理后台又会多出许多的需求。

例如他需要在管理后台搜索名称,由于一些历史原因,这个地方已经上线了,不能做很大的改变,如果你搜索把名字传到这边,这边是保存了其他项目群聊的信息,导致搜索量很大。从产品来讲搜索名称这个需求真的很合理,但是从技术来讲你要解决的问题很多,最后我提了方案我自己这边维护一套 Tag。

我与产品经理详细聊了需求,为什么要搜索名称呢?在使用运营工具的时候,他需要去搜索一些群给群发信息,我说我直接给你这些群打上一些 Tag。比如这个群叫游戏群,你通过 Tag 可以准确的找到那个群,这个是不是更好的解决方式,最后产品经理也接纳了我这样的建议,最后我们把 Tag 维护在我们这边,不要去搞划分的不太合理的微服务,最后就解决了这个问题。

如果你在开发过程中遇到不合理的需求,可以跟产品经理看看有没有更好的方式既能解决他的问题,也能保证你开发的时候是最简单的。

图片

Design Review 即设计评审,意思是在你开始写代码前,找自己小组的小伙伴,给他们讲你对这个系统的设计,分享在数据库的设计等等,让大家看看设计有没有合不合理的地方。因为每个人的信息是不对等的,大家会考虑到你考虑不到的地方。这样的一个过程其实是可以保证我们的架构是这一群人当中能想出最合理的架构。有一句话叫“每个傻子都能把事情搞的很复杂,只有天才才能把事情做的很简单”,我们希望通过 Design Review 设计出尽可能简单的架构去完成我们的需求。

图片

每一个团队都有各种各样的规范,有的团队规范很细,细到怎么写怎么做,有的规范很粗,大概你这样就可以了,有的团队不关心团队规范,只要给我一份能跑的东西就可以了,然而这样会带来很多问题。

我这边准备了这样一个议题,相信大家开发过程中会有很多要软删除的东西。用 True/False,删除掉的就是 True,没有删除就是 False。如果是一个用户的表,用户的表有手机号,你想把用户删除,就把省略号后面的字段变成 True,因为我们开发过程中应该严格在数据库层面做好字段约束,这个手机号与软删除的这个字段是做了唯一索引的。如果按我刚才说的 True/False 的方法,我删除了这个用户,这个用户又注册了一条,这个时候就没办法删除他了,这样逻辑是行不通的。

我也遇到过其他的删除方式,比如我删除它的时候改成 True,比如原来叫 Tom,删除后叫 Tom.abc,但是如果你这样字段长度是十,你为了做软删除所有的字段都需要增加长度,写的时候也得算这个长度原来约束的是多少,我要做软删除又约束的多少,其实是很麻烦的。

我后面提的团队规范是用 19700101 那个时间表示是未被删除的,其他任何时间删除都会改成删除时的时间,用这样的方法去解决软删除以及唯一性约束的问题,就不考虑其他方式的软删除了,这是我提的团队规范的一个例子。

团队规范我建议尽量做的更细一点,具体一点,一个好的团队,我看你的代码,看他的代码,应该感觉都是一个人写的,这样更利于团队成员之间代码的维护。不然我维护一个系统,其他人维护一个系统,那个人出去玩了,他的系统崩溃了我是没办法维护的,我搞不懂他的代码是怎么跑起来的,不知道它里面的东西是怎么约束的,团队规范做的目的我认为是降低复杂度和减少你们之间的沟通成本,这点是非常重要的。

图片

开发中“工欲善其事、必先利其器”。古代的侠客有倚天剑和屠龙刀,对程序员来说你所用的工具就是你的倚天剑和屠龙刀。不过我们比较幸运的是古代的倚天剑和屠龙刀只有一把,然而现在好用的工具是任何程序员都能方便的获取到的,这是我们不同的地方。

图片

比如运营和产品跟你说你这个页面怎么这么慢,你首先肯定是自己打开看了下,我这儿不慢,你那为什么慢呢?这个时候你就可以用 Chrome 的 Network 看原来是前端的代码是单页的运用,单个的 JS 文件非常大,它加载用了 5、6 秒,而我的接口响应只有几十毫秒,这个锅我不背,扔给前端背。再举一个例子,我之前做了一个东西,大家上过淘宝,淘宝有根据图片去搜索你要买的东西,但我就是想自己写一个爬虫,直接上传图片,之后获取到根据这个图片搜索到的内容。研究一下会发现淘宝里面有一套流程,所以你需要点这里把代码格式化,可以通过这种方式看单步调试,用这个工具可以看上传的时候浏览器干了什么。再比如 Chrome 一方面是可以用它自己的功能,另一方面你自己在这方面加一些功能。比如我当时刷公开课的网站,它其实是有中文字幕的,也有英文字母,可是只能二选一,如果你看习惯了美剧的话话,肯定习惯了双语字幕,我当时就写了一个 Chrome 的插件,就可以让 coursera 看双语的字母了。如果把 Chrome 比喻成一个武器,你不能用它自己带的招式,还能用自己发明的招式。

图片

这个是手机调试的一个工具,我以前做过手机网页的开发,遇到过如果浏览器开发和实际手机上看样式不对的情况,最简单的方法是改一下,去手机看一下。但其实有更好的工具直接连上手机调试的,使用的感觉就是像在 Chrome 上调试网页一样简单,所以这样的一个工具可以给移动的开发带来很大的便利。

不论你是哪个方面的工程师,都应该把自己那方面的工具用好,如果你是写代码的,你自己的 IDE 要用好,你可以选择集成度比较高的,也可以选择 Vim 这种的自己调试。还有一些相关的工具,比如一些运维工具,做开发的也需要了解,比如服务器为什么慢,看一下内存、CPU,这都是必备的技能,可以帮助你快速的找到问题。

图片

我相信每个人维护其他人的代码的时候都会骂。我提倡大家写代码的时候,想象一下其他人看这段代码是什么感觉。如果你觉得其他人看的会很舒服,那你这个代码合格了,如果你看一下太难懂了,我建议你加上一些注释,至少不会让人砍你。我认为你要做的首先是让你的代码写的可读,代码首先是写给人读的,再是写给机器读的。所以代码的可读性是非常重要的。

图片

Mental Flow 是开发过程中非技术方面的非常重要的一个部分。中文名叫心流,如果你遇到过写代码的时候你不知道你在哪,你忘记了吃饭,身边所有的事你都不知道,你能持续写上一两小时的代码,这就是进入了心流的状态了。

如果你想达到这样的状态首先肯定要屏蔽外界的干扰,像我们在公司办公会有微信、QQ、邮件一直来打扰你,产品经理跟你提需求,测试跟你提漏洞,这些都是一些让你没办法专注的琐事,我建议大家看一本书叫《深度工作》,里面提到一些工作的方法。我个人的话有时候我会去关掉微信,带上耳机专心的写代码,意思是你没事别来找我,给一个孤单的背影,如果你真的不行只能像图片中的人一样,就写不要打扰我。我认为每个程序员应该让自己的时间更完整一些,而不是被打的零零散散的,这样代码的漏洞也会变少吧。

图片

图片

沟通方面。人类本能的不希望被别人否定。但有时候更需要去接受别人的观点,变换到产品经理的角度去思考一下他是不是应该这样做,或者你应该变到一个公司产品的角度这样做是不是让产品更加的好,而不是应该带着情绪的去沟通。就我的观察来说,我觉得大多数的程序员是不善沟通的,这方面又是非常的重要,你不善沟通会吃亏,吵不过产品经理,那个需求就接下来,我觉得大家可以多尝试的沟通,该沟通就沟通,把事说清楚,不沟通的时候专心写代码。

图片

持续部署与集成,我个人建议是一定要做的,你想象每次去服务器拉代码,把服务器起起来,是很机械的操作。比如我当时写代码是自己在 web 里面写了一个接口,这个接口接收 Webhook 的回调,当我推送了代码之后到 Coding,Coding 给我 Webhook 回调,服务器自动拉最新的代码,重启,这是最简单的持续集成。

我做 iOS 开发的时候很繁琐,你要先打包,最后选证书,选什么类型等等,之后可能打完包要上传到一个地址让大家下载、测试,后来发现苹果提供一个命令是可以写一个脚本,自动把 App 的包打出来,通过写代码把打出来的包上传到服务器,让其它同事下载,如果你想做的更好可以集成到你们公司用的聊天软件,集成完之后给聊天软件发一个通知,什么包、什么版本打好了请大家去测试。我建议不管是个人开发者还是团队开发者都应该做持续集成的工作来减少你自己的工作量,并不是说一定要上 Jenkins 等等,自己写一个脚本,其实也可以叫持续继承。

图片

收集你的错误以及性能数据。

收集你的错误其实很简单,我遇到过有的团队虽收集错误,但是错误从来不管,反正也没用户反馈,错误一直让它在,但如果你不管那些错误,这些错误就从一些隐藏的漏洞变成巨大的漏洞,最终造成很大的影响。你可以集成第三方的服务去记录你的性能数据,比如调用时间等等,也可以直接打在日志里。我有时候写项目会打到日志里,这块比较适合追责,比如我调第三方接口,我会记录我调第三方接口的时间,假如有人跟我说你这个接口怎么这么慢,我会去看一看,之后发现第三方接口两秒多才返回,就是第三方接口的问题了,所以这个事你能很快的判断出来事情到底该谁负责。

这是我对开发过程中的一些经验和理解。

扫码关注 扣钉CODING 微信号,获得 CODING 技术小馆和产品更新 第一手信息。
图片

coding1251

1条评论

前辈讲的很棒,学习了!!!

liyutg4 个月前回复