通过增加对可能出问题的知识来克服缓慢的问题解决能力

#1 楼

您完成项目的速度并不慢。以前，您认为新手项目实际上是在未完成时完成的。您应该将这种质量卖给客户。 >除此之外，您需要了解并接受旧的成语：“完美是善的敌人。”

#2 楼

听起来好像是您该加入黑暗面的时候了：管理。

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

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

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

另一个要问的问题：您对技术债务有何看法？有人认为必须消除它。我认为这些人是错的。就像在业务中一样，技术债务使您可以借“现金”或“时间”以更快地交付某些东西。哪个更好：两年内完美的解决方案或客户四个月内可以使用和购买的完整黑客工具？每种情况都不同，但是在某些情况下，如果您等待2年，您的客户将已经参加了竞争。债务。如果您承担的费用不足，则无法获得最佳的投资回报率。如果承担太多，利益会杀死您。

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

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

#3 楼

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

您还应该在这里看看：七人制软件工程专业化阶段表明，生产力在很大程度上是技能水平的副作用。


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

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

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

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

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

基本上，我强迫自己不关心代码效率（这是我的主要障碍，避免效率低下的设计），而只是走最简单的方法。在编写引发错误的测试（确实是TDD）之后，我还强迫我不去关心错误，并且将错误处理延迟到以后。（这就是TDD）。当我不知道该写些什么，或者我知道我在写什么是不好的时候。什么都别管，继续。其实是写坏东西。我最终将在以后纠正它。或者，如果确实很糟糕，请擦除并重写它，但是写两次可以完美完成第一次事情的东西会更快。

真的，您相信的代码起初很有可能写作将需要和真正糟糕的东西一样多的改进。

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

我也习惯在代码中添加临时注释，解释我现在不打算做的事情，以及打算在以后代码正常运行时打算做的事。用例。

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

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

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

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

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

#4 楼

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



可以从许多不同的层次和方式来控制和管理软件复杂性，但是获得一些观点的一个良好经验是：客户满意度取决于他们的期望。”

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

采用一种观点时，有两个重要的点变得很明显：


必须明确（任何形式）客户期望；期望总是可以通过谈判的方式来修改的。

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

制造F16不同于制造塞斯纳（Cessna），尽管它们都可以飞行。

#5 楼

简单的答案是：接受。

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

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

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

#6 楼

听起来您的技能对于高质量任务关键型系统的开发非常有用，例如与金融/交易相关的应用，广播，航空航天，国防等。他们雇用了像您一样思考的人，以便您涵盖所有情况。

#7 楼

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

如果您过分考虑，那么您将以正确的方式来做事情，只是您需要选择一个看起来“具体”的策略并继续使用它。

#8 楼

听起来您好像已经意识到自己倾向于考虑可能会出错的所有问题。在失败模式分析杂草丛生的杂草丛生之后，回到了精益，敏捷和高效的工作流程。谨慎不亚于专业精神的要求，那么您应该认识到，从净意义上讲，您的“速度”和“生产率”可以通过您对公司，客户和公司所做的贡献（或损害）来衡量。您正在构建或维护的软件套件或产品系列。

请记住：


包括维护总成本，总拥有成本和总成本考虑方法变化时的部署和维护解决方案。加快步伐并犯更多错误可能会使事情变得更好，也可能不会使事情变得更好。
如果您在一家好的公司工作，您可能可以在自己的团队中与自己的主管讨论此事，而这不是职业限制行动。如果不能的话，现在是寻找答案并找到新工作的好时机。

#9 楼

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

当您获得更多经验时，您会了解一些应避免的事情，这就是使您变得比别人更好的原因。

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


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

#10 楼

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

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

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

#11 楼

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

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

这就是我的建议，就像你我不时遇到一个问题...

什么对我真正起作用...


编写单元测试，就好像所有代码完成。

记录接口。

实现接口。

您实际完成的操作：


按照模型层的要求进行工作
真正设置工作的划分，哪些对象负责在环境中可以实际执行工作代码的工作，这使得事情变得更快，更准确...

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

#12 楼

与需要解决的所有其他问题相比，请考虑一下bug的实际后果。 />每隔一个月就会转储整个数据库。恢复备份后，将有48个小时的停机时间。
客户记录被交叉链接。每月将200美元的订单发送给错误的客户。
每周一次，订单处于错误状态。订购产品后，仓库必须在每次发生时致电服务台。
大约两周后，应用程序崩溃，用户必须重新输入2分钟的数据。应用在启动时挂起。用户必须终止进程并重新开始。

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

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

#13 楼

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

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

#14 楼

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

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

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

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

像鸟儿一样，它可以飞越更多的土地，您的经历也是如此。最近，我的一个大三学生编写了一些错误的东西，这花了银行很多钱。当然我们早些按时送达了，但这没用！我是否被赋予了指导角色，即使同一个初级将编码该问题也不会发生。我举这个例子来强调，提供良好的指导也很重要。有人称此工作为咨询服务。

#15 楼

我认为您需要学习决定哪个项目需要完成多少工作。某些项目可能微不足道，您真的不需要花费所有时间来完善它。并非所有内容都需要坚如磐石的加密，也不是所有内容都可以扩展到数百万用户。如果您知道您的应用程序最多将不能使用超过1000个用户，那么花所有的时间来完善它就没有意义。

我认为这是您编程生涯中的重要阶段现在您需要进入下一个级别，这与成熟度有关，而与编程无关。您需要能够正确地决定对于任何特定项目来说，足够的时间和代码是足够的。因此，在开始一个项目之前，甚至在您已经在进行某个项目的某个时候，尝试决定这一点，凭着经验，您也会从中受益。开始时可能会遇到一些失败，但是随着时间的流逝，您会完善它（决策而不是代码）。

#16 楼

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

换句话说，成为顾问。

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

您可能不会写太多的代码，您可能会错过这一点，但是看起来实际的代码行并不是您的核心力量，而是知道应该在哪几行代码书面-哪些不应该。

专注于自己的长处。
（如果您喜欢的话...）

#17 楼

我为您提供的最佳建议是：构建块。

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

最重要的是，不要修复无法发生的问题，例如权限错误。而不是使您的程序具有项目符号证明。

在某些时候，您不必脚踏实地，而不必始终检查自己是否做过。

与其花时间在文档上，不如花时间在文档上。代码自我记录并尽可能简短。替换所有那些重复的功能。缩小库，精确地重命名。

#18 楼

不要对自己太苛刻。您正在从事一个日益复杂的行业，与以往相比，它需要更多的人类智能，知识和经验。芯片，采用gpu运算的数字，并行性等。只能在芯片上放置如此多的晶体管。以及更高效的代码。

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

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

#19 楼

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

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


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

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

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

#20 楼

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

#21 楼

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