程序员的十大思维误区

作为老码农老程序员,日常工作中打交道最多的也是程序员,在这个过程中,我发现不少程序员在技术、产品等方面的思维有各种各样的小问题。现在我就来回忆一下,把这些我认为不太好的思维习惯记录下来,在提醒自己的同时,也供程序员朋友们参考,不必对号入座,有则改之,无则加勉,或者你甚至认为这些不是思维误区都可以的,我也不知道起怎么样的标题比较合适,且称“程序员的十大思维误区”吧,祝阅读愉快!

1. 测试人员不按我的实现来测

前端界面有几个下拉列表框,需要选择后才能点“提交”按钮,但前端的实现是,即使不选择下拉框,也能点击“提交”按钮。而如果没选择时就提交,会出错。前端开发人员会说,你不按我的要求来使用,才出错的啊。嗯,嗯,好像有点道理哈。

从测试的角度来看,粗暴点说,就是要把你的东西搞垮,当然不会按照开发人员想象的流程来测试,前端开发人员必须力求保证无论用户怎么使用,都不能出现崩溃的现象,用户使用流程不合理时,进行适当提示,而不是挂掉。比如不满足输入条件的情况下,“提交”按钮最好变灰,这样也有助于引导用户按照正常流程来使用产品功能。

2. 接口没有数据,当然就出错

APP或网站出错了,找前端开发人员过来看。看完之后说:“接口返回空数据了,前端没有问题”。真的没问题吗?

前端需要进行防御式编程,永远不要假定后端接口有数据返回或者数据格式一定是合理的,因此需要针对这些情况做处理,比如进行一些转换然后展示给用户。而不是:后端接口没有返回数据,我就崩溃给你们看,跟我没关系!

3. 把数据库的错误返回给前端

后端开发人员有时候会将操作数据库的异常信息返回给前端,如果你跟他说需要屏蔽掉这种信息,然后转换成前端可以理解的信息再返回,他会说正常情况下不会这样的,只是因为数据库的数据是测试数据,数据关系不合理。

就像前端开发人员不能假设后端接口一定返回数据给他一样,后端开发人员不能对数据库的数据做任何假设。在操作数据的时候,需要想象如果这个数据不是你想要的格式时,要怎么处理,然后再返回给前端相应的信息,而不是把异常信息返回给前端。 

4. 功能开发完成,万事大吉了

有些开发人员在写完某个功能后,常常就觉得没什么事情了。功能开发之后,测试就不用说了,但此外,开发人员最好能多从运维、运营的角度去思考。比如怎样的信息有利用运维人员快速定位问题,也有助于自己快速找到应用代码中的问题。同样,得想想,怎样的数据信息可以帮助运营人员做决策,怎样的策略具有更好的安全性。

功能开发完成,只是第一步,一个系统要完整运转起来并运转得好,还需要很多其它的辅助工作,因此,开发同学具有运维、运营式研发思维,才有可能成长为一个能统领全局的技术负责人之类的角色。

5. 口头禅:我电脑上没问题啊

听到某个功能出问题时,技术人员往往会说:我电脑上没问题啊。这倒是可以理解的,毕竟开发人员完成某个功能后,一般都是在自己电脑上测试过的,测试没问题了才发布出去。

但是开发人员自己测试,往往不能测出问题,因为他已经按自己的实现思路去使用了,但很有可能测试得不全面。而且,别人电脑和自己电脑环境可能不一样,兼容性是个问题。“我电脑上没问题啊”,这句话给我们码农挣回一点尊严是可以的,然后,应该认真对待别人提出的问题并解决掉。

6. 怀疑操作系统或者硬件问题

听到产品有问题时,经常怀疑是操作系统或是硬件问题,而不主动想办法解决。倒不是说操作系统和硬件是完美的不会出问题,而是这些东西都是经过千万次测试后才推出来的产品,我们写的代码可能没有经过足够的测试就发布出去了。

从经验来看的话,99%的情况下,是开发者不理解系统机制,或者是自己代码有问题。因此,一般遇到问题时,先想想自己代码哪里比较可能出问题,然后再考虑其它方面的问题,当然,有些问题很明显就不是代码问题的,那另当别论。

7. 假设代码都走“Happy Path”

Happy Path,也可以叫欢乐路径。有些开发人员总会假设,程序运行时,配置文件好好地躺那里了,网络连接总是好好的,因此程序都会按理想中的流程运行着。

而实际上,程序在运行时,各种异常情况都有可能发生,可谓如履薄冰。因此处理异常的代码是非常必要的,甚至有时候,处理异常的代码比正常流程的代码量还要多,这都是为了程序的健壮性。

同样的,因为欢乐路径的思维,开发人员在估计开发时间的时候,也往往会以最顺利情况下的时间作为进度计划,而实际上在开发过程中,还会遇到各种各样难以预料的问题,都需要花时间解决,因此程序员估算时间,一般差个2-3倍是比较常见的。

8. 主与次、抽象与具体分不清

技术人员有时候分不清主次,该理解的不去仔细理解,不该背诵的选择背诵。有些东西其实理解了原理,使用时候再查一下文档就可以了,没有必要花费精力去记忆。

还比如,舍不得花时间做设计,就早早动手写代码了,理由是没有时间设计。但到头来,因为没有提前做好设计而需要返工,导致花的时间更多。因此,除非不得已,建议先稍微想好再动手干活,没必要太急,这就是所谓的慢工出细活。 

9. 少沟通,以为都理解需求了

技术人员有时候跟业务人员、产品经理寒暄几句,就以为都理解了需求,于是回头就蛮干起来。等到做得差不多了,拿给业务人员看时,可能会发现做的东西不是他们想要的,或者相差甚远。

还有些时候,是因为不深入理解需求和环境,导致了复杂性。举个例子,比如要给自动化部署的服务器集群分配内网IP,刚开始可能想到要生成各个网段的IP然后让服务器通过DHCP来自动获取属于这个网段内的IP,网段还不能重复。但如果理解了具体场景,比如每一次部署,在同一网段内的服务器都不超过200台,那其实就不需要用代码生成网段了,使用固定的网段就可以,因为不同的部署相互之间是隔离开的,不同次的部署,即使IP相同,也不会冲突,这就简化了问题,本来要写的代码现在也不需要写了。有一种比较拗口的说法大致可以描述这种场景,就是:解决问题的最好办法就是不去解决它。

10. 抱残守缺不主动学习新知识

以前有位码农问我,知不知道MVC模式,我只好苦笑。尽管我不敢说自己对一些模式的理解有多好,但这种东西在刚开始编程的那些年,也早就接触了是不是。我估计他平时很少跟人沟通,或者看技术文章、技术资料比较少,以为自己偶然学过的东西,很多人都不懂,而实际上并非如此。

他还说,使用具有MVC模式的PHP框架后,后端的Model被修改后,浏览器前端立即有响应。我估计他受VC++里面文档视图编程的方式影响比较深,在单一的桌面程序里面,MVC模式确实会这样的。但是到Web编程时,代表数据的Model在后端被修改了,前端浏览器并不能看到View的变化,需要刷新才能从后端获取View的新内容,或者需要使用Ajax请求,又或者需要使用WebSocket之类的技术从后端向前端推送。这种时候,后端框架使用MVC模式,是为了模块划分和更好的代码组织方式,并不是后端数据修改了,浏览器上显示的View部分自动就更新了。

技术的更新实在太快了,即使身处于这个行业中,我们也时常会因为要跟进新技术而疲于奔命。比较有效的办法是,尽量去理解一些本质性的原理性的知识,这些知识往往通用性比较强,同时选择学习某些新框架。选择的依据可以是这种框架的社区活跃程度、遇到问题时网上找解决办法的难易程度、开发周期长短、市场上人才储备情况等等。

微信扫码,进入【技术人成长】社群逛逛。


程序员的十大思维误区》有1个想法

评论已关闭。