如何更快地编码（不牺牲质量）

我从事专业编码器已有数年了。关于我的代码的注释通常是相同的：编写出色的代码，经过充分测试，但可能会更快。

那么，如何在不牺牲质量的前提下成为更快的编码器呢？出于这个问题的考虑，我将范围限制在C＃中，因为这主要是我编写的代码（出于娱乐目的）或Java（在许多方面都足够类似）。

我已经在做的事情：

• 编写完成工作的最小解决方案
• 编写一系列自动化测试（防止回归）
• 为各种事物编写（和使用）可重用的库
• 在运作良好的地方使用众所周知的技术（例如，休眠）
• 在适合的位置使用设计模式（例如，Singleton）

这些都很不错，但是我觉得我的速度不会随着时间的推移而增加。我很在意，因为如果我能做些事情来提高生产率（甚至提高10％），那将比我的竞争对手快10％。（不是我有。）

除此之外，无论是小型Flash开发还是企业Java / C ++开发，我都从经理那里得到了回报。

编辑：关于我所说的快，以及我怎么知道我慢，似乎有很多问题。让我更详细地说明一下。

我曾在多家公司的中小型团队（5至50人）中从事各种项目和各种技术（Flash，ASP.NET，Java，C ++）的工作。我的经理们（他们直接告诉我）的观察结果是我“很慢”。

部分原因是因为我的许多同仁为追求速度而牺牲了质量。他们编写的代码有错误，难以阅读，难以维护，并且难以为其编写自动测试。我的代码通常具有良好的文档记录，可读性和可测试性。

在Oracle，我将始终以比其他团队成员慢的速度解决错误。我知道这一点，因为我会得到对此的评论；这意味着其他（是的，更高级和经验丰富的）开发人员可以以几乎相同的质量（可读性，可维护性和可测试性）在比我花费更少的时间内完成我的工作。

为什么？我想念什么？我如何才能更好地做到这一点？

我的最终目标很简单：如果我今天能在40个小时内制造出产品X，并且我能以某种方式提高自己，以便明天20、30甚至38个小时就可以制造出相同的产品，那就是我想知道的-我如何到达那里？我可以使用什么过程来持续改进？我以为这与重用代码有关，但这似乎还不够。

我喜欢Jeff Atwood的方法，可以在http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html中找到。

基本上，他在文章中引用了David Bayles和Ted Orland撰写的《艺术与恐惧》一书中的一段。这段文字是：

陶艺老师在开幕日宣布，他将课程分为两组。他说，工作室左侧的所有人员仅根据他们制作的作品的数量进行评分，右侧的所有人员仅根据其作品的质量进行评分。他的程序很简单：在上课的最后一天，他将带上浴室磅秤并称量“数量”组的工作：五十磅的锅被评为“ A”，四十磅的锅被称为“ B”，依此类推。但是，那些按“质量”评分的人只需生产一个锅（尽管是一个完美的锅）即可获得“ A”。好吧，来了分级时间，一个奇怪的事实浮出水面：最高质量的作品都是由按数量分级的小组制作的。看来，虽然“数量”

从本质上讲，比花时间研究“完美”的完成方式并对其进行理论化处理，更快，更频繁地使双手变脏，可以更好地提高技能。我的建议，继续练习，紧跟技术，研究设计。

似乎没有其他人提到的一种可能性是，您做的很好，而您的经理也不是很好。他们如何衡量生产力？他们能给您具体的例子还是仅仅是一般的看法？与您相比，他们是否考虑了花费在修复他人工作上的时间？

我已经看到很多人因完成工作而获得荣誉，而其他团队成员则解决了他们留下的混乱局面。

人们认为重要的大多数都不重要。打字速度并不重要。更快的机器或工具并不重要。我们不是打字员或机器操作员。我们是思想工作者。我们是决策者。

什么是重要的使用反馈，不断提高您的决策过程。像获得任何其他技能一样，做到这一点的唯一方法是通过经验，有目的的实践和不断的反馈。

• 在辅助项目上工作。
• 从事开源项目。
• 与比您更好的开发人员一起工作。配对程序！
• 让自己接触新的工具和技术。保持有效。
• 做编程练习来训练您的决策仪器*。
• 根据客观指标（如缺陷率和速度）以及主观指标（如代码质量和适用性）监视您的改进。

最后：记住没有质量的速度是没有用的，反之亦然。为了最大程度地发挥效用，请在这些压力之间找到平衡。

* http://codekata.pragprog.com/

实际上，很有可能会要求您牺牲一些质量以提高速度。

在某些开发环境^1中，仅当“足够好”就可以生产出抛光的东西时，根本不值得花额外的时间。

^{1-我特别考虑的是“内部工具匠”，但可能还有其他人。}

听起来您在做所有的好事-从中期来看，这会让您更快，因此，如果您实际上慢一点，这并不明显。只有你真的知道。（但这是一个非常现实的可能性-PeopleWare声称同一任务的开发人员之间的生产率差异高达10倍）。

因此，我为您提供一些建议：

1. 时间是相对的，所以问题可能不在于您的实际速度，而在于您对时间的感知。您可能暗示这将花费一周的时间，但最终要花费两周的时间，而其他人则可能要花费3周的时间……但是您看起来慢了1周。

2. 由于您经常收到此反馈，因此也许有时间与您的经理和同事交谈，看看他们说了什么-必须向他们学习很多东西。

3. 与“快速质量”开发人员进行一些配对编程，以查看是否可以发现差异。

实际上，归结为经验。要像开车一样快地完成工作，起初您会感到害怕，因为其他人都是快速（或醉酒）的驾驶员（或两者兼而有之），并且您想安全回家（就软件而言，您要确保自己的代码就像开发的一样，并且效果很好）。

在过去的数月/数月中，一旦您掌握了驾驶和高速公路的知识，就会学到一些使驾驶变得有趣的技巧。这就是我们所说的经验。这些“技巧”（我称之为特质）是有帮助的。

就我而言，我已经通过编码（甚至@ home）并学习了其中的用法来学习了设计模式的实际用法。因此，当我遇到需要设计模式的问题时，我会根据过去的经验来了解哪些方法可行，以及为什么对我的情况不可行。

综上所述：

• 经验创造了可以增强信心和更好软件的特质。

PS：经验也来自别人的学习。例如，来自SO，结对编程，同行评审等的帮助。如果您无法回顾过去并从错误中学习（或者如果有人从不挑战自己的努力），那么您将没有经验。

问题是，从长期总成本来看，您是否较便宜。

换句话说，您精心设计的高质量错误修复程序（包括测试用例和文档）是否超过了维护更快的同事所做的错误修复程序所需的成本？

如果是，那么您需要使您的上司意识到这一事实。如果他们不进行测量并且没有必要的数据来确认您的评估，可能很难争辩。

如果否，那么您就必须认真考虑为什么会这样：

• 你太没经验了吗？
• 您是否花费大量时间来做一些您认为不应该做的事情？
• 您是否很难确定何时完成修复？
• 毕竟，您的代码质量是否比您认为的低？
• 您是否应该以一种不同的方式来进行代码开发，因为它花费了您太长的时间来加快您现在的工作速度？
• 您是否在此网站上花费了太多时间？

考虑一下，然后用您的发现编辑您的问题。

人们对你是否真的很慢的一切质疑都是愚蠢的。成为一个更快的程序员而不牺牲质量始终是一个好目标，无论您已经有多慢。这是我作为程序员的第一目标，而且我永远也做不完。我一直在努力提高速度而不牺牲质量，我对此非常着迷。到目前为止，以下是对我有用的工作，最后是一些实验性想法：

1）永不停止学习：全面学习有关编程和使用计算机的所有知识。找到您薄弱的领域并学习它们。即使它看起来与您的工作和C＃完全无关，我保证即使您正在寻找它，也经常会找到将其应用于您所做工作的方法。学习也是关于经验的，所以不要只是阅读东西，而是尝试并扩大自己的技能。如果您习惯使用Windows，请尝试Unix，反之亦然。如果您通常喜欢使用IDE的try命令行工具和文本编辑器，反之亦然。如果您听说过以前从未听说过的工具或技术，或者对此不太了解，请不要屈服于继续前进的诱惑。查一下！不要害怕跳出框框思考，学习别人认为不切实际的实验性新技术。

2）分解项目：尝试将您的项目分解成小型项目。尝试每天或最多每几天进行一次新发布。问问自己“我可以发布的最小功能量是多少，而仍然发布对用户有用的功能。” 这是您通过学习将学到的技能。您可能需要说服经理让您执行此操作，但是他们通常会很快对结果感到满意。通过这样做，您将开始注意到，您认为对该功能必不可少的东西实际上是可以在以后开发的其他功能。这样，您和您的经理就可以仅对最重要的功能进行优先级排序，而不必对与您正在使用的功能相关的所有功能进行优先级排序。通过保持头脑清晰和专心，您可以更快地思考。反过来，您将可以更合理地编程。您的经理或至少经理的经理也可能会认为您现在的编程速度甚至比实际速度还要快，因为您将发布更多的发行版。这样做的另一个巨大好处是，您将更好地估计发行需要多长时间才能完成，并且您的经理会为此而爱上您。由于您已经在进行大量的自动化测试，因此在进行稳定的频繁发行时应该没有问题。但是，您可能需要增强自动构建系统。我强烈建议阅读Martin Fowler系列丛书“持续交付”。这是一本很难读的书，因为它是非常重复的，但仍然很有帮助。s经理们还可能会觉得您现在的编程速度比实际速度还要快，因为您将发布更多的版本。这样做的另一个巨大好处是，您将更好地估计发行需要多长时间才能完成，并且您的经理会为此而爱上您。由于您已经在进行大量的自动化测试，因此在进行稳定的频繁发行时应该没有问题。但是，您可能需要增强自动构建系统。我强烈建议阅读Martin Fowler系列丛书“持续交付”。这是一本很难读的书，因为它是非常重复的，但仍然很有帮助。s经理们还可能会觉得您现在的编程速度比实际速度还要快，因为您将发布更多的版本。这样做的另一个巨大好处是，您将更好地估计发行需要多长时间才能完成，并且您的经理会为此而爱上您。由于您已经在进行大量的自动化测试，因此在进行稳定的频繁发行时应该没有问题。但是，您可能需要增强自动构建系统。我强烈建议阅读Martin Fowler系列丛书“持续交付”。这是一本很难读的书，因为它是非常重复的，但仍然很有帮助。您的经理会为此而爱上您。由于您已经在进行大量的自动化测试，因此在进行稳定的频繁发行时应该没有问题。但是，您可能需要增强自动构建系统。我强烈建议阅读Martin Fowler系列丛书“持续交付”。这是一本很难读的书，因为它是非常重复的，但仍然很有帮助。您的经理会为此而爱上您。由于您已经在进行大量的自动化测试，因此在进行稳定的频繁发行时应该没有问题。但是，您可能需要增强自动构建系统。我强烈建议阅读Martin Fowler系列丛书“持续交付”。这是一本很难读的书，因为它是非常重复的，但仍然很有帮助。

3）使用番茄技巧并适应/更改对您不起作用的内容。如果将其与此列表中的2相结合，您将获得巨大的生产力提升。

4）学习Vim。即使最终通过ViEmu在Visual Studio中使用这些命令，或者在Eclipse中通过插件或在Emacs中使用了这些命令，您也将获得生产力。学习Vim的最好方法是开始使用它，并强迫自己在精通它之前不要（禁用它/返回到旧工具）。刚开始时很痛苦，但是您永远都不想退缩，甚至在没有它的情况下不得不畏缩。有人会说这不会大大提高您的速度。但是越快越快，特别是当我们要阅读和修改代码时，我发现自己有时会节省很多时间。

5）不一定推荐最后一个，因为我不确定这是个好主意，它实际上可能会降低您的生产率，但是无论如何我都会通过它。您可以尝试进行更多的验收测试，而减少单元测试，或者至少确保进行一些验收测试。我在SpecFlow上取得了成功，但是我怀疑那里还有更好的东西。即使编写规范也可能是相当技术性的，因此您可能只想先让经理/客户编写一个草稿版本，然后进行重大更改，或者您可以自己编写整个内容，然后阅读并确定。这将帮助您使用此列表中的2。同样，验收测试比单元测试更实用，并且需要更少的代码。这并不是说它们取代了它们，它们是针对不同事物的不同工具。

6）这是更具实验性和争议性的。我本人实际上并没有这样做，所以我不能完全推荐它。从JetBrains学习和使用元编程系统。使用它来创建工具，经理/客户可以使用这些工具来自己创建所需的软件。如果您可以使用它来制作经理/客户用来以非常直接且不复杂的方式指定行为的工具，您甚至可以停止进行单元测试和验收测试。这个想法不是要摆脱程序员。当程序员（人员，而非工具）无法轻松创建某些所需功能时，程序员仍然需要向客户/经理使用的这些工具添加新功能。我确实相信MPS或与其类似的其他工具都是未来的方式。

多动脑筋，少做测试。坦白地说，测试固然有其用，但代价昂贵。

另外，请阅读《 Unix编程的艺术》（在线免费，物有所值）

最后，您可能不在正确的位置。方形作业中的圆钉等

最终就像是学校：“输出老师想要的东西”变成“输出管理层要求和付钱的东西”。

如果您完成一个比较庞大的项目，并获得每工时“最终”代码行数，您将发现程序员的代码比您想象的要慢得多。

我们每天只讲几行代码。剩下的时间都花在调试，重写和做一般程序员上。

您可能听过这句老话-如果在键入错误时发现错误，则在构建时发现错误将使您节省10倍的时间，这比在质量检查过程中捕获错误要好10倍。而不是释放后抓住它。

那么如何加快速度呢？我不会专注于任何形式的打字速度-减少错误并改善与代码的其他“未来交互”应该是对您时间的更好投资。

可读，清晰的代码至关重要。您只编写一次代码，但是它将被读取数十次。为提高可读性而写作将为您省去很多麻烦（这还将节省大量时间）。如果您曾经回过头来阅读代码，甚至不得不思考一秒钟，那么您就做错了。

结对编程可以减少QA时间，并且，如果您考虑一个程序员一天只生产几行代码，那么如果两个程序员可以以与一个相同的速度编写代码，并且错误更少，那么您就走了。

防御性编码（例如，参数检查）可以减少问题……如果您的团队中有一位非常优秀的分析师/架构师，则可以使用良好的入门设计节省一些时间。

否则，请继续提高您的设计技能。随着经验的积累，您将发现自己更有能力识别无效的模式并避免使用它们，从而能够更早地确定时间消耗等。

您是否考虑过在工作时对自己进行详细的审核？用笔和纸来跟踪您如何度过时间，或者使用诸如“ 救援时间”之类的方法来跟踪自己。

一旦您确切地知道如何花费时间，就可以更好地了解需要改进的地方并集中精力进行工作。

理想情况下，您也可以挑战一些同事来做到这一点，比较您的结果，并互相学习。您可能也拥有一些可以从中受益的优势。

也许您发现自己在流程的一部分上花费了太多时间，而这可能是自动化的，或者只是一天中的某一部分分心，而一天中的另一部分很安静，那么您就可以计划任务等等

或者，也许您发现测试花费的时间比您想象的要多，并且您必须重新考虑一下它正在使您变得更快的看法。

如果没有其他规定，它可以为您提供一些基准。

从您的清单来看，您还不错。

如果您的同事正在编写具有更高CRAP编号的代码，他们的处理速度将会更快。CRAP是可笑地命名的度量标准，结合了圈复杂度和测试覆盖率。

不要编写比您更需要CRAP的代码。;）

我为您建议的唯一更改是使用库，除非：

1. 贵公司出售图书馆
2. 您已将循环代码重构到库中

您正在阅读和做事，这很棒。但是您可能会陷入程序或OO代码的思考之中，您是否接触过函数式编程（例如Haskell？）和Prolog？

为了提高您的OO编程技术，您是否玩过Smalltalk / Squeak？

最后，理论。您至少对图论有基本的了解吗？（某些程序有时会使用树，DAG或只是纯图形。网络是图形）

我要引用鲍伯叔叔：

快速前进的唯一途径就是前进。

每当您屈服于以质量换取速度的诱惑时，您都会放慢脚步。每次。

- 《媒介平庸》，罗伯特·C·马丁

据我所知：

1. 好
2. 快速
3. 贱

作为经理，您可以选择任意两个。

不必担心您一直在关注的评论。作为一名程序员，我宁愿维护经过深思熟虑和编写得当的代码，也不愿将它们打成一片。

我能想到的主要内容如下

• 提高打字速度。
• 使用可提高生产率的工具。例如ReSharper。
• 更快的机器或工具。像更多的RAM或固态驱动器。

我敢肯定，您在编码技能领域也可以做一些事情，但是听起来像您已经完成了这些事情。我上面列出的内容通常被开发人员忽略。

您可以参加快速打字课程。我不知道输入速度是否有问题，但是“编码太慢”可能是由于输入速度过慢所致。

那代码生成器呢？有时代码会重复。重构可以删除其中的一些，但是即使那样，您也可能会重复调用相同的重构函数。根据您使用的数据和代码，代码生成器（用Excel，Perl，Java等编写）可以节省大量时间。使用代码生成工具进行UI开发通常是一件容易的事。

最后，也许指标是错误的。您是否考虑过在其他所有条件下都以最快的速度进行编码，并且时间轴太短，使您看起来是慢速的编码器？

根据您问题中的修改内容，您似乎可以选择某些同事的路线，并共同攻克可行的最快解决方案-而且文档和质量检查工作也该死！

或者...在特定领域获得更多经验和实践，以便您了解代码库和API，从而可以在睡眠中编写解决方案。可以这样做，但是需要更多时间。如果已知其他比您更快的开发人员更资深，更有经验，那么只有一件事要做- 您必须变得更资深，更有经验！

我反对OP的“牺牲质量，提高速度”的观点。

专业的编码人员（程序员）需要满足3个目标：
1）代码应按预期运行
2）交货应及时
3）具有良好的质量，文档等
。4）其他等。

我认为，OP被指为缓慢是因为OP没有及时完成。

这是很难绕开的捕获器22。尽管您可能仍然缺乏经验，并且许多方面的某些知识已经比大多数人要快，但是要注意的是它更难衡量。

就个人而言，此时您可以做的最好的事情就是衡量自己。提供有关工作方式的反馈，也许简单改变工作习惯可以提高工作效率。

我发现邮件的吞噬远远超出了我的想象，这仅仅是因为中断。现在，我每天只回答两次邮件，几天后几乎提高了1个小时的工作效率。尝试诸如pomodoro之类的方法，我将其用作测量手段。我会定期（15分钟）记下我当时的工作。这使我能够了解自己的日子如何安排以及如何才能最大限度地提高效率。

Squeak快速编码的优势远不只是“磨练OOP技能”。为什么在Smalltalk上发明现代的GUI和IDE是有原因的，更不用说JUNIT是SUNIT到Java的移植，术语“ OOP”是为了描述Smalltalk等而发明的。

必须始终使用最适合任何人希望完成的事情的语言和环境，但是对于一般的原型设计，至少我要对任何东西都使用吱吱作响，但HyperCard可能例外，即使那样，也需要进行基准测试才能确定哪个是考虑到Squeak中内置了类似超级卡的功能，因此实际上更快。