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

#1 楼

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

基本上，他在文章中引用了大卫·贝勒斯（David Bayles）和泰德·奥兰德（Ted Orland）的《艺术与恐惧》一书中的一段。这段话是这样的：


陶瓷老师在开幕日宣布，他将
班分为两组。他说，
位于工作室左侧的所有作品，
将仅根据其制作的作品数量
进行分级，而
的所有作品，则仅根据其作品的质量进行分级。他的程序很简单：在上课的最后一天，他要带上自己的浴室磅秤并称量“量”组的工作：五十磅的
/>锅的评级为“ A”，四十磅的评级为“ B”，
，依此类推。但是，那些按“质量”分级的人只需要生产一个锅-尽管完美的一个锅-
就可以得到“ A”。好吧，来了分级时间
，一个奇怪的事实浮出水面：最高质量的作品
全部是由
数量分级的小组制作的。看来，“数量”小组忙于进行大量工作
-并从他们的错误中吸取教训-“质量”小组
已经对完美进行了理论研究，
和最后的努力，除了宏伟的理论和一堆枯死的粘土之外，没有什么可显示的。



本质上是可以动手的比花时间研究和完善“完美”方法的理论，更快，更肮脏的方法可以更好地提高您的技能。我的建议是，不断练习，紧跟技术并研究设计。

#2 楼

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

我看到很多人都因为完成工作而获得赞誉，而其他人则在解决问题上他们留下来的烂摊子。

#3 楼

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

重要的是使用反馈来不断改善您的决策过程。像获得其他技能一样，唯一的方法就是通过经验，有目的的实践和不断的反馈。 。
与比您优秀的开发人员一起工作。配对程序！
让自己接触新的工具和技术。保持有效。
进行旨在训练您的决策制定工具的编程练习*。
基于客观指标（例如缺陷率和速度）以及主观指标（例如代码质量和适用性）来监控您的改进。

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

* http://codekata.pragprog.com/

#4 楼

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

在某些开发环境中1，当“足够好”时，根本不值得花额外的时间来生产抛光的产品



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

#5 楼

听起来您在做所有的好事-从中期来看，这会让您更快，因此，如果您实际上慢一点，这并不明显。只有你真的知道。 （但这是一个非常现实的可能性-PeopleWare声称同一任务的开发人员之间生产率差异高达10倍）。 br />时间是相对的事情，所以也许问题不在于您的实际速度，而在于您对时间的感知。您可能暗示要花一个星期，但最终要花两个星期，而其他人可能要花3个星期...但您看起来却慢了1个星期。
由于您经常收到此反馈，因此可能需要与您的经理和同事要看看他们说什么-必须向他们学习很多东西。
与“快速质量”开发人员进行一些配对编程，看看是否可以发现差异。

#6 楼

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

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

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

总结：



经验创造了可以增强信心和更好软件的特征。例如。来自SO，结对编程，同行评审等的帮助。如果您无法回顾过去并从错误中学习（或者有人从未挑战过您的努力），那么您将没有经验。

#7 楼

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

如果需要，则必须让您的上司意识到这一事实。如果他们不进行测量并且没有必要的数据来确认您的评估，可能会很难说服。 br />
您是否经验不足？
您是否花费大量时间来做一些您认为不应该做的事情？
您是否很难确定修复程序的完成时间？
您的代码毕竟质量比您认为的要低吗？您花太多时间才能加快自己的工作进度吗？
您是否在此网站上花费了太多时间？调查结果。

#8 楼

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

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

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

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

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

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

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

#9 楼

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

还，请阅读Unix编程的艺术（在线免费，物有所值）。

最后，您可能来对地方了。

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

#10 楼

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

每天几行代码。剩下的时间花在调试，重写和做一般程序员的事情上。如果在构建时捕获它的时间是原来的10倍，这比在质量检查过程中捕获它的时间要好10倍，比在发行后捕获它的时间要好10倍。.

那么如何提高它的速度？我不会专注于任何形式的打字速度-减少错误并改善与代码的其他“未来交互”应该是您花费更多的时间。

可读，清晰的代码至关重要。您只编写一次代码，但是它将被读取数十次。为提高可读性而写作将为您省却很多麻烦（这还将节省大量时间）。如果您曾经回过头来阅读代码，甚至不得不思考一秒钟，那么您就做错了。每天要写几行，如果两个可以以与一个相同的速率进行编码，但错误较少，那么您就走在前面了。如果您的团队中有一位非常优秀的分析师/架构师，则可以通过良好的入门设计节省一些时间。

否则，只需不断提高您的设计技能即可。随着经验的积累，您将发现自己更有能力识别无法使用的模式并避免使用它们，从而可以更早地识别出时间消耗等。

#11 楼

您是否考虑过在工作时对自己进行详细的审核？用笔和纸来跟踪您如何度过时间，或者使用诸如“拯救时间”之类的方法来跟踪自己。
一旦您更清楚地知道如何度过时间，就可以更好地了解需要改进和集中精力的地方您在那里所做的努力。
理想情况下，您也可以挑战一些同事来做到这一点，比较您的结果，并从彼此那里获得想法。您可能还拥有一些可以从中受益的优势。
也许您发现自己在流程的一部分上花费了太多时间，而这些流程可能是自动化的，或者只是一天中的某一部分而分心一天的另一部分很安静，那么您可以围绕它进行计划，等等。
或者您可能发现测试所花费的时间比您想象的要多，因此您必须重新考虑一下它正在使您更快。
如果没有其他帮助，您可以使用一些基准。

#12 楼

在您的列表中，您做的很好。

如果您的同事编写的CRAP编号更高，他们的处理速度就会更快。 。

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

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


您的公司出售库
已将重复执行的代码重构到库中

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

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

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

#13 楼

我要引用鲍伯叔叔的话：

追求快速的唯一方法就是走得好。
每次您屈服于以质量换取速度的诱惑时，您都会放慢脚步。每次。

-“车辆平庸”，罗伯特·C·马丁

#14 楼

据我所知：


好
快速
作为经理，您可以选择任意2个。

不用担心您的评论越来越快。作为一名程序员，我宁愿维护经过深思熟虑和编写得当的代码，而不是将它们打包在一起。

#15 楼

我能想到的主要内容如下：


提高键入速度。
使用可提高生产率的工具。例如ReSharper。
更快的机器或工具。就像更多的RAM或固态驱动器一样。

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

#16 楼

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

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

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


基于编辑在您的问题中，似乎您可以采用某些同事的方法，共同攻克将起作用的最快解决方案-而且该死的文档和质量检查！

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

#17 楼

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

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

我认为，OP被指责为速度缓慢，可能是因为OP没有及时完成。

#18 楼

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

个人最好的方法是测量你自己向您提供有关工作方式的反馈，也许简单地改变工作习惯可以使您的工作效率更高。现在，我每天只回复两次邮件，并且几天内提高了将近1个小时的工作效率。尝试一下番茄等方法，我用它作为一种测量手段。我会定期（15分钟）记下我当时的工作。这使我能够看到自己的日子如何安排以及如何才能最大限度地提高效率。

#19 楼

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

一个人必须始终使用最适合自己希望完成的事情的语言和环境，但是对于一般的原型设计，至少我会与任何东西相提并论，除了HyperCard之外，甚至还需要进行基准测试看看Squeak中内置了类似超级卡的功能，看看哪个实际上更快。