程序员的那些反模式

有鸡汤就有反鸡汤，有模式就有反模式。

今天，咱们来谈一谈程序员的行为中的那些反模式，涉及程序员的平常工做和学习的各个方面。

这些反行为模式，并不针对某些特定的我的。若是你不幸中招，千万不要懊恼，由于这实在太正常不过了，不少反模式的坑我也是亲身踩过的^-^

稍微修改几行代码就调试

对全部程序员来讲，这个行为有一点心理上的缘由：工程师都喜欢在作完一点修改以后，当即看到它的效果。这是一种诱惑。

除此以外，这种作法通常多见于新手。

新手对于敲下的每一行代码都不太有确信的把握，所以须要依靠高密度的调试来一步步确认。当一个老手在项目中首次使用一个新的技术时，状况也与此相似。

可是，不得不说，这种作法是低效的。

• 首先，稍微大一点的项目，手动调试一遍都会比较花时间。
• 更重要的是，不停地停止编码工做来进行调试，很容易打断思路，甚至漏掉一些关键流程。

更好一点的方式是：动手编码以前，提早想好一个完整功能或模块的关键逻辑，而后一口气敲完全部代码，最后一次性调试全部case。若是有自动化测试+Daily Build系统，必定要充分利用。

固然有时候不免会碰到不太确认的技术点，这时若是可能的话，更好的方式是单独搭建一个轻量级的、便于调试和验证的工程，来把模糊的技术点系统地摸索一遍。

经过设置众多断点的方式来学习新项目

对于刚刚入职一家新公司的程序员来讲，首先要作的一件事也许就是学习和熟悉新的项目工程了。因而咱们常常看到相似以下的一幕：

经过设置大量的断点，来弄懂程序的运行流程，这种作法对于小项目来讲，实际上是没有什么问题的。但对于复杂的大型项目，容易令人陷入细节，形成“一叶障目，不见泰山”的后果。

并且，在那些大量使用异步和多线程的工程中，断点调试和真实运行的时候每每存在差别。特别是对于一个公司新人来讲，这有可能致使他对项目代码的片面理解，甚至误解。

对我的来讲，这种作法也容易养成一种“不调试就看不懂代码”的习惯。这是一种不太有益的依赖症。要知道，相对于咱们将要阅读的代码，咱们能亲自调试的机会少之又少。

个人观点是：断点调试是个很不错的工具，但若是把它做为新人学习新项目的主要途径，那么必定要警戒它所带来的弊端。

只依赖百度来搜索技术问题

程序员应该使用谷歌仍是百度，已经有太多人讨论过了。我以为在这里不须要再次强调它们在搜索技术问题方面的区别了。

通常来讲，即便你因为环境所限用不了谷歌的话，用一用bing.com的英文版，也是比百度更好的一个选择。

但这里须要说明的一点是，搜索技术问题，并非说用百度就确定得不到好结果。其实，当你想搜索某个固定用法的相关代码参考一下的时候，百度是能很快速地知足你的要求的。可是必定要记住，搜到的代码不要直接拿来就用，必定要从Spec和API Reference的层面找到使用的依据（Spec的概念参见个人另外一篇文章《技术的正宗与野路子》）。

不经意间使用翻译插件

当你访问英文网站的时候，你的浏览器是否会弹出相似这样的“翻译工具栏”？

这是现代浏览器智能化的一个体现。可是，对于程序员阅读技术文章来讲，仍是原汁原味的英文文档表达得更准确。

因此，若是你的浏览器有这样一个翻译工具栏，那么想办法卸掉它或关闭它。

阅读英文技术文档，其实对英语基础的要求并不过高。英文技术文档，所涉及到的词汇量颇有限，并且通常句式比较简单。之因此有人感到困难，不少时候是一种耐心的缺少或心理的恐惧。

对于咱们团队内的每一个人，我都会这样告诉他：阅读英文技术文档的能力，是一个must；不然，你在技术的路上就很难突破。

先实现简单的，其它后面再说

咱们老是习惯从擅长的事情出发来决定行为。当一个项目中出现一些复杂的、超出常规的部分时，不少人的选择是先把简单的部分作完，复杂的部分最后再说。

“最后再说”的意思是，等到项目的后期再来考虑它。这实际上是在逃避和搁置矛盾。

从另外一个层面来讲，这也是人们趋利避害的一种本能。一种鸵鸟心态。

到那时有可能已经临近项目截止日期，人们更没有足够的耐心来设想解决方案，而最终只能求助于一些折中，好比下降产品要求。

在比较坏的状况下，还可能出现因为关键细节没有在开始讨论清楚，从而最后推翻整个设计的状况。

因此，在项目开始之初，就要优先把那些看似复杂的、有可能超出掌控的产品技术点讨论清楚。实际上，可否把最复杂多变的东西在一开始就考虑清楚，反映了一个团队的综合水平。

IDE里看不到依赖工程的源码

我在另外一篇文章《技术的正宗与野路子》中已经提到过这个问题。这里我再展开讲一下。

无论是出于提高自身的目的，仍是因为工做须要，咱们都须要阅读一些优秀的开源源码。实际上，阅读开源的代码未必非要找一个完整的开源工程，从头至尾地去读。应该从平常工做须要的SDK源码入手，聚沙成塔。

每一个程序员，无论他是用什么语言来编写程序，通常来讲都要依赖某个语言的SDK，并且一般它们都是开源的。好比Java的JDK，好比C++的STL，再好比Android SDK。必定要把你的开发环境设置成一点击某个调用的方法就能跳转进源码实现。只有这样，你才能把日常开发的时间利用起来，随时随刻都点过去阅读源码。

有时候我发现某些工程师用的IDE很高级，各类快捷键用得也很溜，但就是点击不到源代码，这让人很难理解。在这种状况下编程，我会感受本身像是被蒙上了眼睛同样。

固然有些程序员面对的是一个闭源的系统，好比iOS程序员，彷佛这个方法不太适用。不过闭源的SDK一般注释写得比较详细，至少经过IDE把每一个调用的注释都仔细读懂。何况，如今iOS上的Swift的SDK不是也开源了嘛。

IDE里一点击就看到依赖工程的源码，这个习惯不只适用于阅读开源代码，也适用于在一个大公司内调用其它团队提供的接口的时候。在任何公司和组织内部，不断加深对于周边系统的理解，不断扩大你的知识边界，永远都是让你从众人中脱颖而出的有效途径。

懒得阅读前人的代码，由于它们太烂

当咱们有了一点工做经验以后，咱们老是会抱怨工程中前人留下的代码太烂，总有一种推翻重写的冲动。

不少时候，前人留下的代码质量如何，刚接触项目的人是会产生错误印象的。可是，咱们要知道，以前的代码做者掌握的信息可能比咱们目前看到的要多，咱们如今考虑到的和没考虑到的，可能做者都已经考虑过了。

更况且，编码犹如创做，有人说好就有人说很差。就像最近新获雨果奖的《北京折叠》，有些人以为是中国科幻的进步，而另外一些人则认为这不是一部成熟的做品。做为一名科幻迷，我也在朋友圈里对它进行了批评。对于一部原创做品来讲，虽然每一个人有坚持本身见解的权利，但咱们应该理解，争议是会始终存在的。

所以，对前人留下的东西，首先应保持敬畏，这样才有可能去了解它。

即便是前人的代码真的很烂，那么咱们在重构以前也应该完全读通它，以保证在进行代码结构升级的时候不至于丢掉逻辑。

要知道，读懂别人的代码，是一种更高的能力。

一有问题就找Leader提问

爱问问题，一般被认为是一种美德。

但有一种状况，却能够被认为是懒于思考或不得要领的表现。

假设你的Leader交给你一个任务：研究某项新技术，并把它用到项目中。很快，你就碰到一个解决不了的障碍。而后你去找Leader请教。

结果，你的Leader在了解完你的问题以后，反问了你一些问题，好比：“若是换另一种使用方式会怎么样呢？”，或者，“文档里提到的这个概念，好像跟另外一个问题有关，它是什么意思呢？”，再或者，“这个问题究竟是怎样产生的呢？它的底层原理你了解过没有呢？”

这时若是你的回答是“不知道，我还没来得及看”，恐怕你的Leader就会在内心把“不善思考”的帽子扣在你头上了。

这里其实有点像个陷阱。若是你的Leader问的这些问题你都能回答下来，那其实你多半已经能解决原来的问题了。

因此，在把你的问题抛给你的Leader以前，要确保你已经充分探索了全部可能性，最好已经有了一些解决思路，只是须要你的Leader来帮你作一些权衡，到底选择哪一条思路。

轻易说不可能实现

产品同窗们常常会找程序员确认一些想法的可行性，相似下面的对话：

产品同窗： 这个地方的数据可否换成像XX软件那样的展现形式呢？
程序员： 不可能。咱们服务端的数据存储格式根本不是那样设计的。
产品同窗： 那这里的交互能改一改吗？让用户更方便操做一些。
程序员： 不能。咱们用的这个控件这里是写死的。
产品同窗：这个控件不能改一改吗？
程序员： 改不了，这是一个系统默认控件......

做为技术人员，当被问及可行性的时候，应该仔细思考，必要的时候作一些调研，而后再给出答案。轻易地给出不可能的答案，可能会限制产品发展的思路。

实际上，不少的不可能，是局限于现有实现而作出的片面的判断。跳出现有逻辑，不少不可能就能变成可能。

要知道，许多伟大的产品都是突破了众多的不可能才产生的。而在不可能向可能转化的过程当中，旧的技术体系被扬弃，新的开发方式被引入，原有的局限被突破，技术自己也必将经历一场浴火重生的洗礼。

盯着QQ秒回消息

在一家公司工做一段时间以后，你负责的东西愈来愈多，跟你有关的事情也变得愈来愈多。因而，公司内常常有人在QQ上找你帮忙，或者问你问题。

天天从一上班开始，你的QQ图标就闪个不停。等你刚刚处理完，正准备编码实现一段算法的时候，QQ图标又亮了。

同事都夸赞你秒回消息，有求必应。但你的核心开发任务却老是一再拖延。

这里涉及到一个时间管理的问题。

这个问题对于一些一线的技术管理人员，尤为严重。一会沟通协调，一会被拉去开个讨论会，再过一会又有人跑过来商量技术问题。疲于应付了将近一天，眼看到了下午五六点钟了。这时终于安静一点了，但你整我的身心俱疲，俨然已是强弩之末，再也进入不了深刻思考的状态了。因而，白天原计划完成的工做，也只能晚上拿回家去开夜车了。

说实话，这个问题至关棘手。若是你能作到将注意力在不一样的事情之间快速切换，我只能说你真的很厉害！这样你在被打断后，就能快速回到原来专一的事情上去。

而对于普通人来讲，相似番茄工做法那样，将时间精细切割，可能会有些效果。前提是你确实可以坚持下来，并在须要的时候保持足够的专一。

如今咱们在教育小孩的时候都知道，专一是一种很难得的品质，有可能直接关系到他/她将来能取得的成就。但惋惜的是，愈来愈多的成年人正在丧失这种品质。

前段时间，我安装了微信的Mac版。结果一发而不可收拾，各类群消息不停地蹦出来，简直是专一力的一剂毒药。

最终，忍痛卸载。

（完）

其它精选文章：

• 技术的正宗与野路子
• 编程世界的熵增原理
• 程序员的宇宙时间线
• Android端外推送到底有多烦？
• Android和iOS开发中的异步处理（一）——开篇
• 用树型模型管理App数字和红点提示
• 一张图读懂RxJava中的线程控制
• 宇宙尽头的描述符（下）
• Redis内部数据结构详解(5)——quicklist
• Redis内部数据结构详解(4)——ziplist