程序员的那些反模式

作者：张铁蕾

来源：微信公众号“张铁蕾”， 老刘做了修改。

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

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

这些反行为模式，并不针对某些特定的个人。如果你不幸中招，千万不要懊恼，因为这实在太正常不过了，很多反模式的坑我也是亲身踩过的^-^

稍微修改几行代码就调试

对所有程序员来说，这个行为有一点心理上的原因：工程师都喜欢在做完一点修改之后，立即看到它的效果。这是一种诱惑。

除此之外，这种做法一般多见于新手。

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

但是，不得不说，这种做法是低效的。

首先，稍微大一点的项目，手动调试一遍都会比较花时间。

更重要的是，不停地中止编码工作来进行调试，很容易打断思路，甚至漏掉一些关键流程。

更好一点的方式是：动手编码之前，提前想好一个完整功能或模块的关键逻辑，然后一口气敲完所有代码，最后一次性调试所有case。

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

不经意间使用翻译插件

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

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

所以，如果你的浏览器有这样一个翻译工具栏，那么想办法卸掉它或关闭它。

阅读英文技术文档，其实对英语基础的要求并不太高。英文技术文档，所涉及到的词汇量很有限，而且一般句式比较简单。之所以有人感到困难，很多时候是一种耐心的缺乏或心理的恐惧。

对于我们团队内的每个人，我都会这样告诉他：阅读英文技术文档的能力，是一个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版。结果一发而不可收拾，各种群消息不停地蹦出来，简直是专注力的一剂毒药。

最终，忍痛卸载。

（完）

你看到的只是冰山一角， 更多精彩文章，请移步《2016文章精华》或者《2017文章精华》

码农翻身

用故事讲述技术