有鸡汤就有反鸡汤，有模式就有反模式。
今天，我们来谈一谈程序员的行为中的那些反模式，涉及程序员的日常工作和学习的各个方面。
这些反行为模式，并不针对某些特定的个人。假如你不幸中招，千万不要懊恼，由于这实在太正常不过了，很多反模式的坑我也是亲自踩过的^-^
略微修改几行代码就调试
对所有程序员来说，这个行为有一点心理上的起因：工程师都喜欢在做完一点修改之后，立即看到它的效果。这是一种诱惑。
除此之外，这种做法一般多见于新手。
新手对于敲下的每一行代码都不太有确信的把握，因而需要依靠高密度的调试来一步步确认。当一个老手在项目中初次用一个新的技术时，情况也与此相似。
但是，不得不说，这种做法是低效的。
首先，略微大一点的项目，手动调试一遍都会比较花时间。
更重要的是，不停地停止编码工作来进行调试，很容易打断思路，甚至漏掉少量关键流程。
更好一点的方式是：动手编码之前，提前想好一个完整功可以或者板块的关键逻辑，而后一口气敲完所有代码，最后一次性调试所有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版。结果一发而不可收拾，各种群消息不停地蹦出来，简直是专注力的一剂毒药。
最终，忍痛卸载。
