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

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部分自动就更新了。

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

文章来自：技术人成长