我们知道代码中对项目至关重要的特定部分，但可能会花费大量时间来完成它吗？我们是否有一种感觉，我们宁愿从事其他工作(可能不太重要)，或者根本不编写代码而不是从事那部分工作？我们是如此努力地避免使用该野兽，并使用我们知道的每一个懒惰的技巧来延迟其不可避免的实现？

现在，我可能只是很懒，但是我总是不得不处理类似的代码。写一些我不喜欢写的东西(如果你只是为了娱乐而没有得到报酬，那就更糟了！)。一个大型系统将花费很多时间才能进入一个阶段，在该阶段中，我们会获得任何有用的结果或者工作正常的指示。我们如何开始编写类似的代码？大多数人可能会建议分而治之和类似的建筑技术，但这与工作方式无关。这是关于我们如何开始做这件事的。我们要采取的第一步是什么？

解决方案

我同意观点，认为软件的许多重要部分并不有趣。我通常以一些较小的事情开始我的开发日，例如在此处添加功能或者在此处修复错误。时间到了，我将从大部份开始，但是当我再也看不到东西时，我会做一些不同的事情。如果我们仍能按时完成所有工作，那就太好了。请记住，如果我们在做某事之前，做某事时以及完成之后与其他人谈论那头大野兽，这可能会使事情变得容易。这不仅可以解放思想，而且还可以从不太主观的角度获得其他人的意见。一起计划这些事情也有帮助。

有趣，我反过来。当我开始解决问题时，我首先要解决大问题。问题的核心通常是我感兴趣的。

如果我要为自己做一个项目，通常不会费心去实现所有模糊位，所以它们永远都不会完成。如果我做的是真实的事情，那么我最终会发现所有模糊的地方，但这不是我最喜欢的部分。

我认为这里有两个问题。

首先实际上是开始。正如我们所说，这可能非常棘手。我个人只是从一点开始，只是为了在纸上/屏幕上得到一些东西。这可能是错误的，需要进行编辑，但是总的来说，批评甚至比创作都容易，即使是在我们自己的作品上也是如此。

然后是解决难题的实际过程。有一本很棒的书叫做"概念性大爆炸"，讨论了解决问题的各种方法。通过这本书，我学到了很多关于如何解决问题和盲点的知识。强烈推荐。

我将讲一个发生在我身上的案例的故事。

我想为x264实现一个新的帧类型决策算法，该算法使用前向动态编程(维特比算法)。但这将变得复杂，混乱，丑陋等等。我真的不想这样做。我试图将这个项目当做Google的Summer of Code典当，但出于某种可怕的厄运，我们让那个学生简单地保住了他的项目的那个学生就是选择了那个项目的学生。

因此，经过两个月的抱怨和回避，我终于开始研究该算法。这就是我的做法。

首先，我与另一位开发人员进行了交谈，他显然已经对如何进行开发有了一些想法。我们进行了讨论，他向我解释了这一过程，直到我从算法的角度完全理解了该过程。这是任何此类项目的第一步：非常了解其背后的算法，以便我们可以对整个内容进行伪编码。

然后，我与我的另一个同事交谈。我们上了白板，我画了草图，直到他也明白了。通过向其他人解释它，我对自己有了了解。这是第二步：向其他人很好地解释该算法，以便他们可以对它进行伪编码。这是对编程过程的仿真，因为编程是对计算机"解释"算法的一种形式。

然后，我编写了一个简单的Java原型，该原型对cost函数使用了任意假值，并且仅用于测试Viterbi搜索。我完成了它，然后对它进行了详尽的搜索，以确保它完美匹配。我的动态编程是正确的。这是第三步：在最简单的环境中编写算法的最简单形式。

然后，我将其移植到x264的本地语言C。它再次起作用。这是第四步：将该简单形式的算法移植到整个环境中。

然后，最后，我用真实的成本函数代替了虚假的成本函数。经过一些错误查找和修复后，它起作用了。这是最后一步：将算法与环境完全集成。

这个过程只花了一周的时间，但是从我在项目开始时的角度来看，这完全令人望而生畏，而且我什至无法开始使用它-但将其分解成这样一个逐步的过程，我不仅能够完成它，而且比我期望的要快得多。

而且收益远不止x264. 我现在对维特比非常了解，现在我可以向其他人解释它了……那些其他人可以从中受益匪浅。例如，一位ffmpeg开发人员正在使用我的算法和代码进行改编，以最佳地解决一个稍微不同的问题：音频文件中的最佳标头放置。

通常，我喜欢大型而复杂的部分。它们实际上是挑战的一部分，迫使我认真考虑我在做什么。这是我不喜欢的所有细小而乏味的部分。但是，在执行任何我一直推迟执行的操作时，我发现一条简单的建议很重要：
去做就对了！！！
认真地说，一旦开始，完成起来就容易得多。我总是发现我推迟了一切，直到我开始，然后突然间我发现，既然我已经开始了，那还没有我想像的那么糟糕，而且看起来，它已经差不多完成了！

分而治之不仅是结构代码，它还可以作为使项目在概念上可管理的一种方法。如果我很难开始一个项目，那几乎总是因为它又大又吓人。通过分成概念上可管理的部分，它变得不那么恐怖。

我也相信实用的程序员所描述的"示踪子弹"。将项目缩减为核心部分的绝对最简单的"概念验证"，例如没有用户界面，特殊情况，错误处理等。也许仅仅是一些带有相关单元测试的核心例程。有了这个，我们就征服了令人恐惧的部分，并且可以从核心开始构建。

基本上(至少对我来说)入门的诀窍是：不要从整个项目开始。从一个小(最好是核心)部分开始，然后从那里开始构建。如果我仍然很难入门，那是因为我决定的一小部分仍然很大，所以我必须进一步划分和减少它。

我试图为系统试图做的事情建立一个隐喻。当我可以用隐喻来描述行为时，我总是会感到更自在。

然后，我从测试驱动的开发角度着手解决这个问题，即通过设置将验证正确行为的测试来开始描述系统需要做什么。

HTH。

干杯，

抢

该项目最困难的部分是从什么都不做到第一行。只需将所有内容放到纸上就可以开始此过程，而且令人惊讶的是其余部分可以从这里流走得如此之快。

我本人也喜欢"分而治之"式的方法。

当系统中有一个特别大的任务挂在我身上时，我离开电脑，拿笔和纸，将任务分解为所有逻辑组件和工作流程。

然后执行所有这些任务，并将其分解为所需的最基本的功能/调用。

然后，我可以放入我认为需要的存根方法。并一一充实。在这一点上，这些"子任务"中的每一个都不比围绕同一项目运行的较小的开发任务大，因此感觉像是一件繁琐的任务笼罩着我。

我通常在家中用笔和一张纸来解决此类问题。我想象算法和/或者逻辑流程，然后对(在纸上！)类和方法存根进行存根，并且当我站在前面时， /计算机，我可以更轻松地完成操作...可能只是我..