我是在谴责集成开发环境。
在过去而言，编程是一件很困难的事情。不是因为编程本身就过于困难，主要是因为编辑器太烂。很多在 70 和 80 年代遭人嫌弃的编辑器都没有流传至今（除了少数非常幸运的，以及那些很有可能用过 DEC 和 WANG 工具的编辑器）。我在打卡时代末开始从事编程工作。以前用打孔来写程序非常搞笑。曾几何时，如果你掉了一块用在分类机上的甲板，也会闹出很多笑话（好吧，也许两次，无一例外，分类机每使用三次就会堵塞一次，场面相当混乱）。我曾经工作过的银行在 1986 年还在使用那种分类机。
（如果你想看看顺序排列< source.cbl >的等同于穿孔卡的分类结果，mv 将看起来很有历史的 source.cbl 分离了出来，Youtube 上有一个不错的视频。）
幸运的是，电传打字机取代了穿孔打卡系统。接着它走上了 Mastodont 的道路（人们觉得他们都一样重要），不过最初的基于终端的通用型电脑监控器并未比玻璃制品的电传打字机好用。【停下来以稍作调整】
关注一下各种文档的不同功能（假设文档具有语言选择功能，但你不能认为文档理应具备），这些功能需要有直观的印象或者是非常严格的命令。否则你得花上一整天的时间去找‘那项功能’或者‘那个变量声明’。重新编写一块代码，代码块要求一行一行的重新输入。这样麻烦透了，所以你最好尽可能地避免。
有一些可以让你不用重写大量代码的方法：
▲在写代码之前先花很长一段时间思考程序，这样就不用频繁地改动
▲确信在整个程序中一次就把代码写好
▲尽可能多地将你的代码提炼到你的重用代码库中
探测性编程代价巨大
后来全屏式的编辑器出现了。相对于行式编辑器，这种编辑器无以伦比。真的。如果你不相信的话可以花一两天去试试’edlin’。到时候我们就会知道你是多么的爱不释手。至此，你就会知道，在头二十年的计算机操作中，所有的软件编码一点都不容易。
之后，你每天也要受 Irons 和 Djorup 他们二位的罪，每天两次。（伯乐在线注：Edgar T. Irons 和 Franz M. Djorup 两人开发过一个全屏式的编辑器：O26。）
我工作用的第一个编辑器不错，可以快速移动文本，拥有区块标记，复制，移动和删除等功能，是我集成在 6809 微型计算机上的编辑器。有些设计计算机设计工具的事情确实很烦人，这就是：工具绑定。无论你正做（build）什么工具，你都需要另外一个工具。为了写一个汇编程序，你需要一个编辑器和汇编程序，而且为了写一个编辑器，你需要第三方编辑器和汇编程序（或者编译器）。如果没有借助第三方编辑器来编写你自己的编辑器是很棘手的事情。
当编辑器做好之后，第三方编辑器虽然不完善但也还能使用。我将它命名为‘e’（我真的不喜欢键入长命令的名字，‘e’以及它的后续版本在 2000 年早期的时候作为我主要的 go-to 文本编辑器，用起来还不错，它摆脱了处于 vi 和 emacs 中间的地位。它已经退休了，现在版本控制系统库中安享晚年）。
在几年之内，“编辑→编译→测试”或者“编辑→汇编→测试 ”循环从几个小时缩短到几秒钟，就像以前社会劳动生产力得到了最大限度地提升一样。
曾经我能够进行模块复制，我注意到我的程序会瞬间很快变得很长，变成在一瞬之间从几千行扩展至1万多行的庞然大物。在变成有效的模块之前，这个庞然大物好像在短短的时间之内做了太多太多的事情。
在我可能将通用的行为抽象为一个函数，或者增加一个参数，设计若干可以调用一个已有功能的宏命令之前，一字一句地重复键入若干行代码的代价精简为三个按键就可以很快完成复制，这看起来是一个非常好的主意，我并没用花费太多时间就认识到了。
在我发现这个隐藏的坏习惯之前，我已经编写了很多代码。也许这个事实对我真的有所帮助。所以很自然地，我没用那样做，这是一个让我们很容易上当的陷阱，诱惑无处不在。这仅仅是一段代码，对吗？我碰巧遇到了，也许你也会碰巧遇到。剪切粘贴，那时候看上去是多么好的一个构想啊。
不过就像任何灵敏的工具一样，它有剪切的能力，就像你砍木头一样，所以你得小心运用。
随意使用剪切粘贴工具的代价可以用臃肿来形容，如此的臃肿把最简单的程序变成了一大串解释不通的语句，其中夹杂了许多的功能和仅仅在细枝末节上有所差别的部分代码。前段时间，我参与了一个项目，这个项目是用一种我在这篇博文中没有提到的语言（Java）编写的，而且该项目在“linecount部门”这一功能上有一些严重的问题。之前有个程序员一怒之下辞职离开，领导要求我接手，为代码增加一些特性。这个程序绝对是一个庞然大物，但看起来也不是全部都有用。从根本上来说，这个程序需要的是，无论什么时候都可以访问，更新数据库中的表，或者向其插入一条事务记录，仅此而已。
而且这些事务看起来都差不多。除了表的命名以及可能一两个参数之外，其他都是相同的。
这些事务的真实情况是，每件事务的代码都只有30行左右，但程序访问了一大堆表。剪切→粘贴（或者：复制→粘贴）。
我最近参与的一个程序，最初是由另外一个程序员编写的，乍看起来非常整洁。不过看得越多你就越发现，它完全是由很多个5到20行的通用模块（Chunks）构成。到处都是那些模块。“剪切→粘贴”。
现在，别误会我。剪切→粘贴有它们的用处。就像其他工具一样，你需要弄清楚它们的作用，它们有什么功能（比如，如果没有具备轻松改动周围代码的能力，你就不要重构代码了），以及它们的短处（写代码）。
现在的集成开发环境，演变成了通过一次简单的鼠标点击就可以产生几百行的标准代码。这种现象比以往任何问题都要更加严重。
当然，如果你确实不想了解你要维护的代码，这种做法也无可厚非。对此，我称之为“Fire & Forget”软件，或者是“职业安全感”和“噩梦”，这取决于你的观点。
（伯乐在线注：Fire & Forget 译为“射后不理”泛指武器在发射之后，就不再接受任何外界指挥、管制或者是射控系统的资料，更新自己的座标或者是目标的讯息。发射武器的载具能够进行其他的作业，包括搜索标定下一个目标，或者是离开发射地点。 via 维基百科）
不过，如果你的目标只是为了获取及保持对代码的控制权，让公司能够生存下去的话，那么，代码的规模越小越好。
小规模的代码更有好处，因为规模小，你就会很清楚代码的用途。这样的代码越好，因为它缩小了你关注的范围，正如它缩小了变量的总数一样。需要完全理解的代码行数减少了，并且一旦你完全理解了代码，bug自然也就藏不住了。因为你的程序会更加紧凑，运行将会更快（因为程序的较大部分适合在缓存中运行），我们也更容易维护代码了（因为更容易理解的缘故）。其他像减少编译时间的东东是不错，但不是主因。
以前的程序员，只能通过全屏编辑器才能了解世界，如果你从那时候就开始编码直到现在的话，我有几句话想告诉你：
考虑下复制、粘贴的顺序，下次你将会用到。这并非没有代价，你还得敲两下键盘。我讨厌这两下子……不过，每当我需要重构一堆别人编写的，用起来好像不用收费的剪切粘贴软件时，就觉得这两下子还挺受人喜欢的。
原文作者：jacquesmattheij
原文链接：http://blog.jobbole.com/9047/
【编辑推荐】
