由于对可能出了什么问题的了解增加而克服了缓慢的问题解决方法

这已经困扰了我一段时间了，非常感谢其他专业人员的投入。

背景简介：1988年，我父母给我买了我的第一台计算机（当时14岁，现在39岁），我开始编程。在1997年最终成为一名专业程序员之前，我遵循了其他一些职业道路。也许是后来者，但这就是事实。我仍然对自己的选择感到满意，我喜欢编程，并且我认为自己擅长于自己的工作。

最近，我注意到我获得的经验越多，完成项目或项目中某些任务所花费的时间就越长。我还不衰老。只是我已经看到了很多出错的不同方式。我知道并记得的潜在陷阱和陷阱正在越来越多。

一个简单的例子：过去只是“好吧，在这里写文件”。现在我担心的是权限，锁定，并发，原子操作，间接/框架，不同的文件系统，目录中的文件数量，可预测的临时文件名，PRNG中的随机性质量，任何中间的电源不足操作，我正在做的事情易于理解的API，适当的文档等，等等。

简而言之，问题早已从“我该怎么做”转移到“什么是最好/最安全的方法”。

结果是，我比新手花更长的时间来完成一个项目。我的版本可能是坚如磐石的，而且据我所知如何坚不可摧，但是需要更长的时间。

上面的“创建文件”示例仅是一个示例。实际任务显然更复杂，但不适合这种通用问题。希望您能理解我的发展方向。我想出高效的算法没有问题，我热爱数学，喜欢复杂的科目，专心致志。我认为我确实有经验上的问题，因此有对错误（内在或外在）的恐惧。

我每天花将近两个小时来阅读有关新开发，新技术，语言，平台，安全漏洞等的信息。难题在于，我获得的知识越多，完成项目的速度就越慢。

您如何处理？

您完成项目的速度并不慢。以前，您认为您的新手项目实际上是在没有完成时完成的。您应该将这种质量卖给客户。

“这家公司可能会更快，更便宜地完成它，但确实做到了吗？还是您会寻找bug多年？”

除此之外，您还需要了解并接受古老的成语：“完美是善的敌人”。

听起来是时候加入您的阴暗面了：管理。

我不建议您放弃编程而成为经理。但是看来您到目前为止所引用的所有经验本质上都是技术性的。通过写文件的简单操作，您可以想到10个不同方面，而一个较不成熟的开发人员将永远不会考虑这些方面。不一定是坏事，但是...

阴暗面是关于现值。这是关于进行最小的投资以获得最大的收益（成本效益分析）。在业务中，一切都归结为这将花费我多少钱，成功的概率，失败的概率，重大失败的概率和潜在的收益。算一算; 按指示行动。

当您是开发人员时，效果也一样：创建一个临时文件，忽略权限和名称冲突-5分钟。净收益，团队的其余成员可以开始研究任何依赖于该文件存在的代码。这是一个完美的解决方案吗？绝对不。它会为您带来99％，95％或90％的收益吗？是的，可能会。

另一个要问的问题：您对技术债务有何看法？有人认为必须消除它。我认为这些人是错的。就像在业务中一样，技术债务使您可以借“现金”或“时间”以更快地交付东西。哪个更好：两年内完美的解决方案，或者客户可以在四个月内使用和购买的完整黑客工具？每种情况都不同，但是在某些情况下，如果您等待2年，您的客户将已经加入竞争。

关键是管理技术债务的方式与经营良好的企业管理金融债务的方式相同。如果您承担的费用不足，则无法获得最佳的投资回报率。如果承担太多，利益会杀死您。

因此，我的建议是：根据您是在最大化自己的价值，而不是最大化彻底性，开始评估工作。而且，如果您练习此方法，您将获得与在技术领域已经开发的直觉相同的直觉。

作为旁注，我最近开始使用番茄技术，它起到了很大的作用。与其进行切线的切线，不如将其集中在较小的时间间隔上，然后将番茄酱分配给以后的工作/研究。我记笔记多少次来研究一个主题，这真是令人惊讶，但是一个小时之后，我对自己心想：“今天，我还有至少3件事可以做，这更有价值。”

多年前，我遇到了（可能）相同的问题，这个问题持续了几年，但我克服了。因此，即使我不确定我的方式也将对您适用，也许知道我是如何实现的对您来说会很有趣。

您还应该在这里看看：软件工程专业知识的七个阶段它表明生产力在很大程度上是技能水平的副作用。您可能仍处于当前正在使用的技术的第3阶段和第4阶段之间的某个时间（技能水平取决于技术，您可以掌握某些技术，同时还可以学习其他技术）。

现在，我从传记作证开始。

有点背景。我今年47岁。我从80年代的12岁开始编程。在高中时，我还担任兼职专业游戏程序员。基本上，它没有给我太多钱，仅能买到硬件，但我很喜欢它，学到了很多东西。我从18岁开始对计算机科学进行正式学习。

结果，当我20岁时，无论何时开始任何编程任务，我都知道许多解决给定问题的方法，并且非常了解手头的许多参数和陷阱，以及任何方法的缺点和局限性。

在某些时候（比如说大约26岁），对我来说编写任何程序都变得非常困难。打开的可能性太多了，我再也无法在它们之间进行选择。几年（使之成为6），我什至停止编程，成为一名技术新闻撰稿人。

尽管如此，我从未完全停止尝试编程。在某个时候它又回来了。对我来说，关键是极限编程，更具体地说是简单性原则：“编写可能可行的最简单的东西”。

基本上，我强迫自己不关心代码效率（这是我的主要障碍，避免效率低下的设计），而是走最简单的方法。在编写引发错误的测试（确实是TDD）之后，我还强迫我不太关心错误，并将错误处理延迟到以后。

那是我在写作时学到的东西。当我不知道该写什么，或者我知道我在写什么不好的时候。什么都别管，继续。实际写坏东西。我最终将在以后纠正它。或者，如果确实很糟糕，则将其擦除并重写，但是写两次东西的速度更快，第一次写的东西就完美了。

实际上，您认为一开始擅长的代码很可能需要与真正不好的代码一样多的改进。

如果您遵循“简单性”道路，您还将获得额外的奖励。您很容易接受删除/更改初始设计/编码。您会有更灵活的想法。

我还养成了在代码中添加临时注释的习惯，解释了我现在不打算做的事情，并打算在代码在正常使用情况下可以正常工作时稍后再做。

我还参加了XP Dojo，与其他程序员一起练习了代码集，以内部化XP的实践。它有帮助。它使上述形式方法具有本能。结对编程也有所帮助。与年轻的程序员一起工作会产生一些动力，但是通过经验，您还会看到他们没有的经验。例如，以我为例，我经常看到他们从事过于复杂的设计，并且我知道可能会导致设计梦night。那样走了。做过某事。有问题。

对我来说，最重要的是保持流程顺畅。保持速度确实是成功的关键。

现在，我又回到了专业程序员的状态，我相信对自己正在做的事情有更深入的了解，我会变得越来越好。练习TDD时，我可能仍会比年轻的时候慢一些（并且没有进行任何测试），但是我也没有恐惧的重构，并且肯定会花费更少的时间进行调试（几乎没有时间，将其花费少于10％的时间） ）。

总结：我使用敏捷方法（XP）克服了我的代码块，为简化起见然后进行重构，并尝试使这种本能成为可能。它为我工作。不确定是否可以将其推广到其他任何人。

在技​​能掌握水平方面，我大多数时候学会接受的是，每当我改变技术（学习新语言，新框架等）时，我都会经历一个放慢脚步的阶段。这是正常现象，并将最终克服。我还可以通过良好的方法论和通用编程技能来弥补这一点，这不会成为问题。

编程的重要部分是管理和控制复杂性，对我个人而言，这是最重要的问题之一。如果忽略，则缺陷频率激增，或者完成的软件的ETA急剧增加（如您的情况）。

可以从许多不同的级别和方式来控制和管理软件的复杂性，但是获得一些观点的一个很好的经验法则是：“任何软件项目的头等大事是客户满意度，这是他们期望的函数。”

换句话说，软件的复杂性在很大程度上取决于您控制客户期望的技能。

当一个人采纳这种观点时，两个重要的点就变得显而易见：

1. 必须明确表明客户的期望（以任何形式）；
2. 始终可以通过协商的方式来修改客户的期望。

您的例子是一个很好的例子，“简单地编写”与“无数其他考虑”。考虑一下-如果有人要写下这两种变体的详尽要求，那么描述的功能是否等效？

虽然F16和Cessna都可以飞行，但它们却不同于塞斯纳。

简单的答案是：接受它。

在所有系统中，您都必须在可靠性，鲁棒性，安全性，速度，硬件成本，开发成本，上市时间之间进行权衡。您不会总是同意客户如何进行这些折衷，但是您不是那种做出决定的人。您所能做的就是提供周到的意见。从“我的个人网页”到“运行核反应堆”，软件开发涵盖了整个领域，并且必须相应地编写代码。如果崩溃意味着“重新加载我的个人网页”，那么谁真的在乎这种情况呢？但是，如果崩溃意味着“切尔诺贝利”，那么您对可靠代码的偏爱是我喜欢的任何随便的东西。

有些客户会很乐意接受“概念验证”级别的代码并在其实时系统中运行它，并且经常有习惯于此的系统管理员。IME他们的系统通常在深夜一个小时左右无法使用，同时发生了许多计划的重新启动。但是他们已经做出了商业决策，那就是他们想如何滚动。理想情况下，因为他们的领域变化如此之快，以至于高质量的代码永远无法准备就绪，但是经常因为他们看不到价值（如果系统“正常运行”，他们就永远不会注意到它，因此该系统不代表价值）钱）。如果麻烦太多了，请尽量避免那些客户。

与时俱进是我们所有人都必须花费的时间，或者至少应该花费的时间。有时候，这会使您工作，而其他时候，这只会使您的思想保持良好状态。无论哪种方式，请尝试享受它。

听起来您的技能对于高质量的关键任务系统开发非常有用，例如与金融/交易相关的应用，广播，航空航天，国防...

这类应用程序中的错误造成的损失非常大，而且他们雇用的人像您一样思考，因为您可以解决所有情况。

事实是，现代系统正在变得越来越复杂。现在，计算机类似于该游戏“ Jenga”，您需要将所有这些作品都依赖于其他许多作品。拉出错误的零件会出现错误，拉出正确/必要的零件仍然会产生错误。系统越复杂，您就可能会花费更多的时间来思考使代码更健壮并希望更安全的方法。速度会很好，但我认为最近几天来，当您听到有消息称“ XYZ”公司被黑客入侵并盗取了600万个客户的信用卡号时，速度就倒退了很多。

您的客户可能不想听到他们的程序需要安全，可靠等。但是您可以告诉他们，他们的汽车不需要安全带和安全气囊，他们的房子不需要锁和门...因为谁想听到所有声音？那？

如果您考虑过度，那么您将以正确的方式进行处理，只是您需要选择一个看起来“具体”的策略，然后继续使用它。

听起来您已经意识到了考虑所有可能出错的趋势的倾向。

经验丰富的谨慎开发人员经常YAGNI在失败模式分析杂乱无章的情况下试图返回精简，敏捷和高效的工作流程时，经常会学会遵循该原则，而您并不需要它。

但是，如果您确实在某个领域中写东西，而该领域的照料水平不低于专业水平要求，那么您应该意识到，用净值来衡量您的“速度”，“生产力”可以用多少来衡量（ （或损害）您对公司，客户，正在构建或维护的软件套件或产品系列的行为。

记得：

• 当您考虑更改方法时，包括维护总成本，总拥有成本以及部署和维护解决方案的总成本。走得更快，犯更多错误可能会使事情变得更好。

• 如果您在一家好的公司工作，您可能可以在自己的团队中与自己的主管讨论此事，而这绝不是职业限制举措。如果您做不到，那么现在是个很好的时机，找到并找到一份新工作。

我只能看到的是：“您变得越来越有价值”。

随着您获得更多的经验，您会了解一些应避免的事情，这就是使您比其他人更好的原因。

您可能会注意到一件事，您的代码现在将更安全，更可维护。

• 您唯一需要做的就是向您的客户解释为什么要花时间，以及如何对他们有用。
• 您需要向他们展示您的知识深度。
• 您需要告诉他们您为什么做，您做了什么以及对他们及其业务有何影响。

我的建议是专注于这一部分。

如有疑问，默认情况下会错误地引用Knuth ...

“过早的优化是万恶之源。”

这是我的建议，因为您似乎不时遇到一个问题...

对我真正有效的是...

1. 编写单元测试，就像完成所有代码一样。
   
2. 记录接口。
   
3. 实现接口。

您真正完成的工作：

1. 遍历模型层需求
2. 真正建立了工作分工，哪些对象负责什么
3. 在实际可以逐步浏览工作代码的环境中开始工作，这使事情变得更快，更准确。

在早期开发中还依赖于断言……然后找出需要实施的补救措施，并且您不会编写无法访问或难以测试的代码。

我认为您应该遵守自己的编码标准，但要确保与客户保持领先。许多客户不知道构建好的软件需要什么/花费多少。对他们进行培训是专业开发人员工作的一部分。

无论您是敏捷的还是瀑布式的，您都会从客户端获得有关他们期望应用程序执行的某种协议。太多的开发人员（好的，也许更多的销售人员）犯了沙包罪。“他们没有说他们想要一个高度安全的网站。” 在大多数情况下，这是因为没有要求他们。“您介意您的电子商务网站被黑客入侵吗？” 他们当然在乎，您为什么要构建它以使任何人都可以穿透安全性？你必须教育他们。

只要确保您只在做客户付钱给您的事情即可。服务的一部分是您的经验。客户希望您知道这些陷阱，而不必询问。包括要求取决于他们。您可能希望将想要便宜的东西传递给客户。

与其他所有需要解决的问题相比，考虑一下错误的实际后果。

请考虑以下内容导致的不良代码编写：

1. 整个数据库每隔一个月转储一次。恢复备份时，有48小时的停机时间。
2. 客户记录被交叉链接。每月将200美元的订单运送给错误的客户。
3. 订单每周一次陷入错误状态。订购船舶时，仓库必须在每次发生时致电服务台。
4. 一旦大约两周左右，该应用就会崩溃，用户必须重新输入2分钟的数据。
5. 每月一次，该应用在启动时挂起。用户必须终止进程并重新开始。

第一个显然是不可接受的。＃2-＃5可能会或可能不会，取决于业务的性质。＃2-＃5需要在业务面临的其他问题的背景下进行评估。

理想情况下，＃2-＃5永远不会发生。在现实生活中，优先级相互冲突，签署您的薪水的人可能希望您从事其他工作，而不是编写从来没有问题的完美代码。如果不解决＃5而以不修复另一个程序中更严重的错误为代价，则不会给他们留下深刻的印象。

解决方案是创建具有常用功能的库的集合，您可以在各个项目之间重复使用这些库。例如，我有一个StringFunctions.dll .NET库，它执行诸如编码，加密，解密，正则表达式求值之类的工作。通过这种方式，我不必不断重写那些不变的东西。

具有用于文件创建任务的包装器也很有意义。您的库可能会公开一个名为GetFile（）的方法，该方法将为您执行所有检查，并返回null或文件（或您认为有用的任何文件）。

我认为您需要学习决定哪个项目需要完成多少工作。有些项目可能是微不足道的，您实际上不需要花费所有时间来完善它。并非所有内容都需要坚如磐石的加密，也不是所有内容都可以扩展到数百万用户。

编写一个可以很好地扩展到超过一百万用户的程序将需要您花费的时间和经验，但是如果您知道您的应用程序最多将不能被超过1000个用户使用，那么花所有的钱是没有意义的那个时候完善它。

我认为这是您编程生涯中的重要阶段，现在您需要进入下一个级别，这与成熟度有关，而不是与编程有关。您需要能够正确地决定对于任何特定项目来说足够的时间和代码。

像其他所有事情一样，您也可以通过练习达到这一目标。因此，在开始一个项目之前，甚至是在您已经在进行项目的某个时候，尝试决定这一点，并从中获得经验。刚开始时可能会碰碰运气，但随着时间的流逝，您会完善它（决策而不是代码）。

@Zilk，我不是一个优秀的程序员，自1998年以来我一直在编程。即使现在我也面临这个问题。但是我意识到最终质量是至关重要的。如果我今天去世，那么某个人应该可以从离开的地方接走我现在正在做的事情。这应该是编程的标准（通用）。

我现在已经从开发人员转到建筑师。转向管理正在改变这条线。如果您想继续保持热情，可以选择成为一名建筑师。

最初是技术架构师->解决方案架构师->企业架构师->首席架构师等等。

作为建筑师，您将引导人们走向成功。像您这样的人已经有数十年的编程经验，您可以利用这些经验来指导他人。

就像高高的鸟，它可以飞越更多的土地，您的体验也是如此。

让我也告诉您，正确编程比快速编程错误实现重要。最近，我的一个大三学生编写了一些错误的东西，这花了很多钱。当然我们早些按时送达了，但这没用！即使同一个初中生会编码该问题也不会发生，我是否被赋予了指导角色。我举这个例子来强调，提供良好的指导也很重要。有人称这项工作为顾问。

另一个选择是：停止编写代码，而是出售您的专业知识以提前发现问题。

换句话说，成为顾问。

许多组织很乐意花高昂的钱（如果不是最高的钱）让某人发现问题，然后花数月时间来创建产生问题的代码。众所周知，修复设计中的错误要比对其进行编码，测试和部署之后的修复便宜/容易。

你会不会写的代码量，你可能会错过，但随后似乎实际代码行是不是你的核心力量，但在明知该行代码应写入-并且不应该。

专注于自己的优势。
（好吧，如果那是您喜欢的……）

我对您的最佳建议是：构建基块。

制作一个您可以始终信任的文件构建块，为您的API编写一个，不再浪费时间重复编写相同的内容。一次思考每个问题，一劳永逸地解决。

没有人会赶上这一步，当然不是新手，他们会花费80％的时间来调试由于无法理解的极端情况而失败的代码。

最重要的是，不要解决无法发生的问题，例如错误的权限。

如果权限错误，则说明已经存在问题，您应该解决此问题，而不要使程序成为项目符号。

在某些时候，您不必只是朝自己的脚开枪，而不必总是检查自己是否照做。

不要花时间在文档上，而要花时间使代码自文档化并尽可能地简短。替换所有那些重复的功能。缩小库，精确地重命名。

不要对自己太苛刻。您正在从事越来越复杂的职业，该职业比以往需要更多的人类智能，知识和经验。

计算机处理能力正在减慢-也许很快会停滞-导致需要引入多核芯片，采用gpu的数字，并行性等。只能在芯片上放置如此多的晶体管。

因此，当前和将来的重大进步将来自程序员-先进的算法和更高效的代码。

如果您查看GTA 4和GTA 5，差异是惊人的。但是它们都在相同的硬件上运行。这是10年前根本不需要或无法使用的一些非常智能和高级的编程实践的结果。

这也可能意味着经验丰富的程序员将来可能会变得更有价值-就像其他行业（例如工程学）一样，峰值收入通常出现在职业生涯的后期。

就像您一样，我从14岁起就开始编程，也就是当我有了第一台计算机时（尽管那时我已经学习了几个月）。但是，我现在只有33岁。:-)

我的建议是，在开发某些东西时，您会担心每一个问题（文件许可权，目录中的文件数量等），然后本着这种精神，运用您所有的丰富经验来回答一些问题：

• 在您的代码中正确处理该问题需要花费多长时间？
• 如果处理不当，以后这东西会咬你的可能性有多大？
• 如果它咬了你，后果是什么？

有了这些答案，这样一个有经验的人就不会有问题做出明智的决定。;-)

像您这样的“退伍军人”有责任提出这种要求，其中包括确定可能出问题的地方和确定您应注意的潜在问题。

在开发应用程序时了解所有可能的标准是开发高质量产品的最重要的事情。您在这方面做得很好。您可以做的一件事是，您可以将需求分类为质量级别，然后在给定的期限内映射级别。这样，您就可以轻松地完成项目的截止日期。

用Edsger Dijsktra的话来说：“如果调试是消除软件错误的过程，那么编程就必须是将其引入的过程。”您要做的只是减少后者，因此您必须减少前者。这只是学习花时间编码正确的问题。我仍然是一个相对年轻的程序员（读20本书），我渴望能够一次完全正确地编写某些东西。一个小时的计划和10分钟的编码比10分钟的计划，一个小时的编码和三个调试要好得多。