您知道代码的特定部分对项目至关重要但可能需要花费大量时间才能完成吗?你有没有感觉到你宁愿在别的东西上工作(可能不那么重要)或根本没有代码而不是在那部分工作?那个野兽,你努力避免并使用你知道的每一个懒惰技巧来推迟其不可避免的实施?

现在,我可能只是在懒惰,但我总是不得不处理这样的代码。写一些我不喜欢写的东西(如果你是为了好玩并且没有得到报酬,那就更糟了!)。一个庞大的系统,需要花费大量时间才能进入一个阶段,在这个阶段你可以获得任何有用的结果或指示它的工作。你如何开始这样的编码?大多数人可能会建议分而治之和类似的建筑技术,但这不是关于你如何做到的;这是关于你如何让自己开始这样做。你采取的第一步是什么?

有帮助吗?

解决方案

我将讲述一个案例,其中发生了这件事。

我想为x264实现一种新的帧类型决策算法,该算法使用前向动态编程(Viterbi算法)。但它会变得复杂,混乱,丑陋,等等。我真的不想这样做。我试图将这个项目归结为Google Summer of Code,但出于某种可怕的运气不好,我们那个仅仅依赖于他的项目的学生就是选择该项目的学生。

因此,经过两个月的抱怨和躲避它,我终于开始研究算法。这就是我做到的。

首先,我与其他开发人员进行了交谈,他们显然已经对如何做到这一点有了一些想法。我们讨论了它,直到我从算法的角度充分理解这个过程之后,他向我解释了它。这是任何此类项目的第一步:理解其背后的算法,以便您可以对整个事物进行伪代码。

然后,我和另一位同事交谈。我们上了白板,然后我把它描绘出来,直到也明白了。通过向其他人解释,我获得了自己的理解。这是第二步:将算法很好地解释给其他人他们可以对其进行伪码。这是编程过程的仿真,因为编程是“解释”的形式。计算机的算法。

然后,我写了一个简单的Java原型,它使用任意伪值作为成本函数,并且仅用于测试维特比搜索。我完成了它,并在一次详尽的搜索中检查了它 - 它完美匹配。我的动态编程是正确的。这是第三步:在最简单的环境中编写最简单的算法形式。

然后我将它移植到C,x264的母语。它再次起作用。这是第四步:将算法的简单形式移植到完整的环境中。

然后,最后,我用真实的成本函数替换了伪成本函数。经过一些打击和修复后,它起作用了。这是最后一步:将算法与环境完全集成。

这个过程只花了一个星期,但从项目一开始的我的角度来看,这是完全令人生畏的,我甚至不能让自己开始 - 但是把它分解成这样一个步骤步骤过程中,我不仅可以完成任务,但比我预期的要快得多。

其好处远远超过x264;我现在彻底了解维特比,现在我可以向其他人解释......而其他人可以从中受益匪浅。例如,其中一个ffmpeg开发人员正在使用我的算法和代码的改编来最佳地解决一个稍微不同的问题:音频文件中的最佳标题放置。

其他提示

一般来说,我喜欢大而复杂的部分。它们是实际扩展挑战的部分,迫使我仔细考虑我正在做的事情。这是我不喜欢的所有小而乏味的东西。然而,当谈到做任何我一直推迟的事情时,我发现一条简单的建议很重要:

只做它!!!

说真的,一旦开始它就更容易完成。我总是发现我把它放好,直到我启动它们,然后突然我发现,现在我已经开始了,它没有我想象的那么糟糕,看,它几乎已经完成了!

划分和征服不仅仅是构建代码,它还可以作为一种方法,使项目在概念上可管理。如果我很难开始一个项目,那几乎总是因为它是大而且可怕的。通过划分为概念上可管理的部分,它变得不那么可怕了。

我也相信“ tracer bullets "正如务实的程序员所描述的那样。 将项目减少到绝对最简单的“概念证明”。核心部分,例如,没有UI,特殊情况,错误处理等。也许它只是一些核心例程与相关的单元测试。有了这个,你已经征服了可怕的部分,并且可以从核心构建。

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

我同意你的观点,软件的许多重要部分都不好玩。我通常会在一些较小的东西开始我的开发日,比如在这里添加一个功能,或修复那里的bug。什么时候,我从大部分开始,但是当我再也看不到它时,我会做一些与众不同的事情。如果你仍能按时完成所有事情,那就没关系了。请记住,如果你在做这件事之前与其他人谈论这个大型野兽,那么你可能会做得更容易。这不仅会释放你的思想,而且你也可以从不那么主观的角度来看待别人的意见。一起规划这些事情也有帮助。

好笑,我是另一种方式。当我开始解决问题时,我会首先选择大问题。问题的核心通常是我感兴趣的。

如果我正在为自己做一个项目,我通常不会费心去实现边缘的所有模糊位,所以它们永远不会完成。如果我正在做一些真实的事情,我最终会得到所有模糊的部分,但这不是我最喜欢的部分。

我认为这里有两个问题。

首先是实际入门。如你所说,这可能相当棘手。就个人而言,我只是从任何一点开始,只是为了在纸/屏幕上得到一些东西。这可能是错误的,需要编辑,但总的来说,批评比创作更容易,甚至是你自己的工作。

然后是解决难题的实际过程。有一本很棒的书叫做“概念性阻塞”(Conceptual Blockbusting)。讨论了解决问题的各种方法。我学到了很多关于如何解决问题和使用那本书的盲点。强烈推荐。

我试图建立一个系统试图做的隐喻。当我用隐喻来描述行为时,我总觉得更舒服。

然后,我从测试驱动的开发角度处理它,即通过设置将验证正确行为的测试开始描述系统需要做什么。

HTH。

欢呼声,

罗布

该项目最困难的部分是从完成任务到第一线。只要将任何东西放在纸上,就可以开始这个过程,其余部分从这里流出的速度令人惊讶。

我是“分而治之”类型方法的粉丝我。

当系统中有一个特定的大任务挂在我身上时,我会离开计算机,拿笔和纸,并将任务分解为所有逻辑组件和工作流程。

然后执行其中的每一项任务,并将其分解为所需的最基本功能/调用。

然后我可以输入我认为我需要的存根方法。并逐一充实他们。此时,这些“子任务”中的每一个都是“子任务”。并不比围绕同一个项目的较小的开发任务大,所以感觉就像一个不那么繁重的任务笼罩着我。

我通常在家里使用笔和纸来解决这类问题。我想象算法和/或逻辑流程然后存根(在纸上!)类和方法存根以及当我进入时在电脑的前面我可以做得更轻松......可能只是我......

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top