编写代码的优先级

Question

我已经关注了一段时间了，我经常看到人们询问最快的做事方式。我当然承认代码必须写得很好，甚至经常调整，但在我的日常工作中，我更关心代码的可维护性，偶尔我只需要调整代码以使代码更快。

因此，我想知道其他人在编写代码时遵循的优先级。换句话说：代码最重要的属性是什么？作为后续问题，我想知道是谁做出了这个决定（管理层或开发人员）？

Answer 1

代码必须在足够短的时间内执行其预期任务才能使用。应用程序之间的差异很大。当你无法理解需要的速度时，努力使你的代码“快速”是浪费时间;同时，当你缺乏对代码意图完成的清晰，高层次的概念时，努力使你的代码“可维护”是注定要失败的。因此，必须优先考虑理解你想要解决的问题;其他一切都来自于这种理解。

另请参阅： When is optimisation premature?

Answer 2

mdbritt's answer非常接近我的态度，但其他一些事情：

• 我个人认为可读性高于正确性。从可读但不正确的代码到可读和正确的代码比从正确但不可读的代码到达更容易（IME）。
• 我知道这听起来像是给定的，但我认为在开始编码之前理解你真正要做的事情是非常重要的 非常重要。我并不是说你在开始之前就需要了解整个应用程序的所有内容 - 你可以随时改进某些领域的设计;但是当谈到单个课程时，你至少应该知道你正在寻找什么样的结果以及你为什么要这样做。
• 性能对于体系结构很重要，但实现起来却少得多。如果你开始使用体系结构错误而无法扩展，则会遇到麻烦 - 但如果体系结构正确，您可以稍后修复实现。我知道这是一个陈旧的格言，但是首先编写最简单的工作代码确实是有意义的，然后分析应用程序并优化瓶颈，直到您满意为止。 （这在我的mdbritt版本的答案中简化了效率 - 对于大多数的代码。）

Answer 3

Software Quality应位于每个代码编写优先级列表的顶部...

• 可维护性
• 灵活性
• 可移植性
• 复用性
• 可读性
• 可测
• 可理解

Answer 4

我的优先事项：

1. 代码必须可读。

2. 代码应该做一些有用的事情。

3. 在很多情况下，它必须快速出门，在这种情况下，我可能会对下面的事情做出妥协。

4. 代码应该很好地分解为模块。

5. 它应该足够快。

上次我的代码不够快是在我编写方程求解器并需要将方程转换为代码时，这意味着用有效的程序标识符替换任意变量名。结果是30个单一替换的序列不是很聪明---分配太多了。在一次通过中对所有30个变量进行单次替换可以节省当天的时间。

Answer 5

编码时：

1. 正确，
2. 可读性，
3. 效率，
4. 简单

按此顺序。

设计时：

1. 组织（很多事情，包括OOP和单任务问题），
2. 清洁度（无冗余代码），
3. 可测试性（包括关注点分离）。

按顺序。

Answer 6

测试是我重要属性列表中的首要任务。让路上的生活变得更加轻松。这是我决定在我工作的地方做，因为没有其他人做TDD。

Answer 7

关注点分离对我来说非常重要。如果每个类的目的有限（希望是一个），那么无论何时需要维护代码，您都可以查看更少的位置。这也避免了只有Bob可以修复或工作的数千行怪异。结合适当的单元测试，每个类的范围和测试都会减少，从而确保每个代码段更易于理解和诊断。

Answer 8

这实际上取决于您正在开发的软件以及它的用途。

如果您正在为企业编写LOB Web应用程序，其中每个人都使用相同版本的IE进行所有Web浏览，那么导致您的应用程序在Fire Fox中可怕地中断的错误并不重要。

如果您是谷歌开发Gmail，那么这样的错误将变得更加重要。

有时候，表现会影响正确性。例如，如果您有一个影响0.1％客户的错误，修复它会要求您大幅减慢其他99.9％的应用程序速度，那么性能就变得更加重要。

所以，我说这实际上取决于你的个人情况。

Answer 9

开发IME的最快方法是积累了很多部分解决方案，这些解决方案大部分都很容易组装成新问题。例如，我有一个我一直使用的数据引擎，我有一个服务基类，一个调度程序，复制文件和检查它们的哈希等功能。我通常可以相当快地推出一个程序，因为我有这些先前开发的和测试的代码。

Answer 10

除了批量处理数千个数据文件外，性能通常不是问题。简单性带来了很多性能，这是我的优先事项之一。我会按以下顺序看到我的优先事项：

1. 可靠性
2. 简单（在算法，界面等中）
3. 通用性（我可以让我的程序以更通用的方式解决问题，以便将来的更改更容易吗？）
4. 鲁棒性
5. 可重用性（我可以让我的程序解决其他问题吗？）

Answer 11

我的优先级是 LTFCE ： L 非常， T estable， F 灵活， C < / strong> ompliant， E conomical，按顺序排列。有关这些优先事项的更详细讨论发布在this question的答案中。

正如你所看到的，我同意你的看法，几乎总是速度远远不是最关注的问题。

Answer 12

我的首要任务是，要求的变化，无论多大，只需要代码中的小更改。无论你怎么想，或者他们告诉你什么，他们 都会改变要求。而且没有一个是安全的。

• 假设一切都会改变。
• 参数化E V E R Y T H I N G。
• 消除依赖关系。

如果需求发生变化，我必须在多个地方更改代码，我觉得我失败了。但后来我弄清楚如何重写代码，以便当需求第二次更改时（你知道它会），我可以在一个地方更改它。

为什么人们会发明像n层和MVC以及其他解耦技术这样的东西。

-
BMB