从非专业编程到专业的开发者，从 BASIC、C++ 到 Rust，在本篇文章中，已在软件开发行业摸爬滚打 30 年的老兵将带来自己最为深刻的 11 个经验教训。

作者 | Dean Roddey

译者 | 谭开朗，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

我先是从事了多年的非专业编程工作，直至1988年，才开始从事专业编程工作。我入门时正值软盘时代，我高中的计算机课程是主机终端上的BASIC程序。从那以后，我在这方面投入了大量的时间和精力。我只期盼着，在编程领域上度过50年的年华，将从中学到的或相信的一些东西丢掉并探索多方面问题领域，跟随内心的接受或忽略它。

复杂性是噩梦

根本上说来，对于我们这种处于软件频谱十分重要一端的人来说，复杂性是噩梦。很遗憾的是，优化和灵活性都是噩梦的间接产生者。之所以说很遗憾，是因为我们无法真正避免它们，且在某种的程度上它们是非常有用或绝对必要的。但显然，它们是复杂性的重要来源，而复杂性不仅仅是糟糕决策或普遍冷漠无视的结果，即使是最好的设计系统也无法避免，我们有目的地创建它们。

显然，在小局部范围内，这些工具可以提供很多帮助。但从更大的范围来看，没有什么能帮到我们。这里有一个实际问题，无论是在开头还是中间，我们在不同的代码之间创建链接，这样我们就不能向工具充分传达信息，来确保我们正在做正确的事情。我们不可避免地会创建始终不一致的对象内部状态，以便避免不必要的消耗，或者支持一些必需的或期望的功能(可能像C++中的move语义)。

30多年过去了，我对此依然没有答案。可能就是没有答案的吧。除非有人能在一个预先解决所有问题的框架内‘完全按照我的想法去做’，否则每一项重大任务都将面临那些复杂的问题，而在我看来，只有人们极度的谨小慎微才能做到。而我们对此并不擅长。

顽固的持久性问题

我学到的一件很重要的事情是，始终确保保存的数据都经过了版本控制和使用了精心设计的构架，以便支持扩展。如果没能做到这一点，它总会在不经意的地方出现问题。一旦你拿到的存储数据是不受版本控制的，如果该数据类型反过来仍维持不变而作为其他类型的一部分，解决问题的唯一方式可能是：对每一种包含的类型做处理，因为你可能必须依靠版本的包含类型来确定你处理的是哪个，是旧的，坏的格式那个还是新修复的一个。

早期我曾经犯过一些错误，但直至今日，我也不想考虑要去弥补它们，它们仍然存在，而且很可能永远不会改变。

我早期犯的另一个错误是：先写出包含的数据值，然后再写关于包含数据类型本身的内容。但是，这意味着你甚至不能使用包含数据类型的版本来纠正包含未受版本控制值的持久性中的错误，因为在读取所有包含的值之前，你无法获得包含数据类型值的版本。在早期的几个项目中，这一点让我很难受。因此，得到的教训是，如果数据是分层的，请确保你的版本控制信息与之匹配(我想应该是预排序)。如此一来，你就可以纠正包含值持久性的错误。

在家就能创造的帝国

我是如此幸运。这是这样一个事实：软件最棒的事情之一是，你可以在卧室身着内衣的去做很多可能改变世界的事情，或创造一个小公司进而发展成一个商业帝国，从而极大的改变你的银行资产和创造了大量的就业机会。当然也有一些其他的，尽管其中很多是创造性的，但你的劳动价值更多的是一个观点和流行趋势，而非一个实际效用的东西，因为它更有可能是软件。

有了一台计算机、一个编译器和一个概念，你就可以以某种方式使世界发生真正的变化。

说你所想

虽然持续努力是理所应当的，但一些轻松的工作对此可能不是那么敏感,因为他们没有那么复杂,达到一定复杂性反而变成了麻烦,明确的意向声明是最好的。

语言上可能总是存在一定的压力，以使更容易实现快速编写代码。大多数产品都是如此。那些能让人坐下来，以最快的速度进入轻松愉悦的演示阶段的人，更容易被接受。这对于那些较轻松一端的东西来说是一个巨大的优势，或者通过创建演示取得风投也是一个巨大的优势。

但是对于你所创建的复杂系统来说，你所要做的就是把它写出来，然后你要永远为其负责。因此，任何以显式语义表达为代价来提高开发速度的方法(向工具表达你真正的意思，这是唯一让工具做你真正想让它做的事情的方法)都不是一个好的折衷方案。在我看来，所有的语言都应该优先提高表达语义的能力。例如，Rust在这方面做了一些有趣的事情，尽管我不同意他们的一些其他决定。

中年的必然性

语言似乎随着人们的生活轨迹而变化。他们开始的时候非常专注，然后他们慢慢地增加了越来越多的东西。我猜其中的部分原因是“游泳还是死亡”定律，在这种情况下，你觉得你必须不断地添加功能，否则你会被认为是落后了，且变得无关紧要。部分原因是为了让越来越多的人接受更多的东西来增加吸引力和适用性。还有部分原因是在与用户打交道时，他们总是在争论那些他们特别着迷的内容，但这些内容往往千差万别或相互排斥。

最终，这个语言就好似一个穿着speedo泳装的中年胖子，它有点肥胖，过于复杂，过于分散，试图满足很多人的很多要求。在某些情况下，它甚至可能是为了与之相反而被创造出来的，这在更广阔的世界中通常是正确的。这让我有时有点期待朋克革命。

与此相关的一个观点是，我认为语言必须得有底气：我本身就是这样的。这就是进化的终点。它将得到维护，仅此而已。我们需要放下进化的包袱，在相当高的高度上建立一个新的大本营。很明显，这很难做到，但不这么做的后果也是非常明显的，因为进化的包袱在不断累积，而且很可能在语言的整个领域都对根本的改进有了免疫，因为当空间被占用时，它们根本无法重建。

过去的错误变成未来的希望

时间足够久后，那些过去在现实生活中被证明是不成形的和次优的，然后以巨大牺牲来纠正的东西，将作为激进未来的新愿景重新出现。一旦有足够多的人，在艰难地实施解决方案后开始了他们的职业生涯，他们将成长于这样一个世界：他们受挫的唯一目标就是解决最初遗留的问题。

最终，许许多多的人没有了以前糟糕的记忆,他们只看到现存的问题，他们看到糟糕决策的后果并怪罪于工具和技术,或相信固有复杂性问题实际上是工具和技术的复杂性，然后，他们开始认为旧的东西是他们所有问题的答案,因为它优于当前的模式。他们经常把这些想法当作现代主义来推行，而实际上他们可能是倒退的。他们并没有意识到，如果他们回到过去，他们仍然会作出那些糟糕的决策，同样存在固有问题和复杂性，但在现在的技术背景下，这些技术在几年前因为恰当的理由而被彻底拒绝了。

企业家与雇佣兵

在我看来，开发人员有两种基本类型。有些人想创造自己的东西来销售，有些人则为别人工作。这是很明显的，而且似乎与开发无关，但是这两个方向创造了一个截然不同的软件世界版图。对于前者，语言主要只是一种工具，一种达到目的的手段，没有必要追求最新的和最好的语言特性，因为客户可能不太关心，他们只关心功能和质量。因此，如果一种新的语言特性对产品或代码质量没有真正的贡献，企业家可能根本不在乎。

另一方面，在我看来，雇佣兵似乎更痴迷于语言本身，因为他们相信(通常是有理由的)了解所有最新的功能对他们进入下一份工作很重要。也就是说，语言对他们来说可能是职业发展的一个工具。因此，他们更有可能采用新功能，因为他们可能会在下次的面试中被问及这些功能。

在我看来,这就是为什么有很多人在面向语言的论坛讨论新语言的特性,而且这些特性不可能沿用多年,就算有,实际公司也不可能使用的两次修正回来的功能特性。

网上讨论中产生了一些不和谐之音，因为参与者的潜在观点可能是截然不同的，但双方都没有真正清楚地理解对方的出发点。不得不说，编程论坛上的大多数人似乎都倾向于谋取私利，所以创业的观点往往并不一定被很好地接受或理解。

少数特殊需求需特殊处理

我们从小学习就知道过度优化的弊端，这是正确的。你可以花费数月的时间来优化代码，并引入大量额外的复杂性，但收效甚微，而在非常有限的代码区域内进行简单的调整，最终可能会提供数量级的性能提升。而且很多程序根本没有显著的性能限制。

但是，比如C++，它对性能的优化有时也会造成底层基础设施和应用程序中的复杂性，即使它实际上可能只是在一个非常小区域内的项目中。虚拟方法或运行时的继承往往是谨慎使用，因此在大部分项目中无需担心，应该直接选择最适合实现的方案。

显然，通用代码在这方面确实有一些额外的义务，但总的来说，引入大量的复杂性来优化通用代码并不是一种整体上的胜利。这些代码变得更难维护，更难安全快速地向前推进，也需要更多的大脑周期，而这些周期本可以应用到其他事情上，再且更容易引发bug。所以这实际上是花费90%的份额获取10%的收益，或者不管实际的相对比例是多少。

我想说的是，那些有特殊性能需求的人请自给自足，而那些在更一般的程序中真正需要进行重大优化的少数地方，则需要特别处理。这并不一定意味着他们每个人都必须自己动手，但他们至少应该为那些程序或真正需要它的小程序使用专门的工具。这意味着更多的时间投入到对我们大多数人都有好处的事情上，并且随着时间的推移，我们所有的代码都不太可能会引入bug。

从第一天开始就认真对待项目结构

虽然常说：哦，我们后面可以重构。但我们都知道，现实中的大型团队和大型代码库以及粗糙的代码都没人愿意接手。做任何重大的重组很难解释说我们的努力是为了追赶之前的轨迹。甚至也很难为自己辩护，知道这事情确实需要去做，因为不管你是否有心脏病发作的风险，你都只能得到相同的报酬。

所以我主张从一开始就认真对待项目的结构。提前考虑一些相当糟糕的情况，并为大量扩展做好计划。就算永远不重构，也不会太费力。如果是这样，你会更有准备。即使你一开始看起来过于小心翼翼，最终你可能也不会后悔。

显然，这不是最大的问题。我之所以提到它，是因为开始一个项目的时候，很容易就会想，好吧，让我们做点什么，然后我们就能知道下一步该怎么做。然后你得到了一些有用的东西，商业现实开始发挥作用，突然间，多年以后，这将是一个混乱残酷的局面，所以你现在就必须做好。

你可能仍不太能预先完成它，但是一些认真的准备思想和预先的基础设施设置工作对于非琐碎的项目通常是值得的。作为一个单枪匹马的开发人员，我的情况比大多数人都好，因此更容易停止开发，并在整个代码库中进行大规模更改。但这可能是灵魂和脑细胞的损耗，也可能是本可以避免的时间浪费，而这些时间本可以花在更有成效的事情上。

数据和表达的分歧

这是一个很常见的问题，但仍然很容易出错。万事开头难，当你开始一项新的工作时，就很容易忘记这些问题，而要把这项工作安排好通常需要更多的精力。这样的问题我可是受够了。我仍想做个辩解：我的大多数错误(其中一些错误由于处理起来很困难，至今仍未完全处理)都是在很久以前就犯下了，至今已成为我们日常生活的一部分。

我造成的最大问题是自动化系统的触摸屏系统。这是非常复杂的。仅仅是完成最初的部分就已经是一项艰巨的任务，而且从那以后它已经得到了巨大的发展。像许多类似的东西一样，它是一组图形化的、通常是交互式的小部件，你可以通过设计器将其放置在屏幕上，并配置成你想要的样子和行为/反应。最后，配置这些小部件的数据是类层次结构的一部分，其负责实际显示这些小部件，因此这两个小部件被绑定在一起。

尽管大约15年前当我做最初的工作时，我并没有意识到这些类型的问题。我可以解开这个结，但这需要大量的工作，由此也需要牺牲其他一些重要的东西。

永不放弃，永不投降

最后，对于像我这样的技术极客，以及可能正在阅读本文的许多人来说，软件是一个完美的挑战，是在对抗混乱时的黑暗势力。它包含了数学或纯逻辑等智力挑战，但它(至少潜在地)具有实际结果。而且一般来说，它的薪酬相比起来也高得多。

如果你刚加入这个行业，那就请坚持下去吧。就像无止境的努力一样，通过时间的打磨才能让你变得更好。你不可能通过思考来解决这个问题。如果你想成为一名真正的大师，你必须披襟斩棘，并牺牲你的大部分时间在这个领域之中。

对我们中的一些人来说，这并不是一个坏的权衡，因为我们并不能一开始就如鱼得水。但是，无论哪种方式，你都不可能通过偶然的努力就成为大师，这将需要作出相当大的承诺。尽管如此，生活中的大多数事情都能达到一定高度以获取丰厚的报酬，但如果它很容易的话，那每个人都能做到了。

如果你愿意投入时间，我认为这是一个很好的选择，因为可以获得许多智慧、开拓视野和积累经验。每个人几乎随时随处都要用到软件。所以你可以把你的职业生涯聚焦于一个领域，或者培养一项有用的技能，然后深入到许多不同的领域。鉴于其高于平均水平的薪酬，很多情况下在家就可以完成工作，以及在一天工作结束时身体毫发无伤，这优势就更不用说了。

原文：https://www.codeproject.com/Articles/5152541/Lessons-from-a-Life-in-a-Chair

本文为 CSDN 翻译，转载请注明来源出处。

【END】

 热 文 推 荐 

☞小鹏员工承认备份特斯拉源代码；Apple Watch 现漏洞；Python 3.7.4 发布 | 极客头条

☞JavaScript 的函数式编程与面向对象编程区别在哪？

☞如果微软开发了 Android，会有何不同？

☞我在阿里的十年：从 BI 到产品经理，曾被程序员踢翻桌子骂

☞Libra的Move编程语言到底是个啥? 美女程序员通读26页的白皮书后, 找出了这些精华… | 技术头条

☞文末送书啦！| Device Mapper，那些你不知道的Docker核心技术

☞BigBiGAN问世，“GAN父”都说酷的无监督表示学习模型有多优秀？

☞学好正态分布有多重要？

☞实测！华为鸿蒙比 Android系统快60%！

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

你点的每个“在看”，我都认真当成了喜欢