创意编码有什么不好的地方？[关闭]

我今晚看着鲍勃·罗斯（Bob Ross）画一些“快乐的树”，而且最近我发现让我感到压力的是什么。

这里和Stack Overflow上的社区似乎拒绝任何不完善的想法。我的目标是通过提高技能来编写受人尊敬的（因此可维护和运行）代码。但是，我富有创造力。

让我解释一下“创造性编码”的含义：

• 我在项目中的第一步通常是坐下来并敲击一些代码。对于更大的事情，我会在这里和那里做一些计划，但大多数情况下我只是潜入。
• 除非与正在项目中创建其他作品的其他人一起工作，否则我不会绘制任何类的图。即使那样，那当然也不是我要做的第一件事。我通常不从事大型项目，而且视觉效果也不是很好。
• 当我测试，简化，重做并将原始hack转换为可重用，逻辑且高效的东西时，我编写的第一轮代码将被重写很多次。

在此过程中，我一直在清洁。我删除未使用的代码，并注释所有不明显的内容。我不断测试。

我的流程似乎与专业开发人员社区中可以接受的基本原则背道而驰，我想理解为什么。

我知道，糟糕的代码最令人困扰的地方是有人陷入了前员工的混乱之中，并且要花费大量的时间和金钱来解决。我了解。鉴于最终结果与从头开始计划所有事情类似，因此我不了解我的流程是怎么了。（或者至少是我发现的。）

最近，我对这个问题的焦虑非常严重，以至于我停止编码，直到我知道解决所解决的特定问题的每种方法的所有知识。换句话说，我几乎完全停止了编码。

无论您对此问题有何意见，我都非常感谢您的投入。

编辑： 谢谢大家的回答。我从每个人那里学到了一些东西。你们一直都很有帮助。

代码测试重构重复没有什么问题，只是告诉别人您正在制作原型。

另一方面，对于较大的项目，您会发现对设计的一些考虑会为您节省很多时间！

PS：制图技术可帮助您学习视觉思维技巧，即使您除了看过别人的图表之外，这些技巧也很有价值。

我总是更喜欢清晰，易读，简单的代码，而不是任何视觉呈现的，UMLed，设计模式的代码，其中类/接口包含模式名称，例如“ ItemVisitor”（?!）。设计模式，OO技术和其他所有东西都是用来规范规则的。该规则来自常识。

没有这种形式化就不可能进行工作（除非您独自处理自己的项目），而过度形式化会增加项目成本。永远不要忽视他人理解您的代码的需求。最好的代码是最简单的代码。

不要犹豫，重新编写您的代码。为此，我将获得X降票（X> = 10），但我将其设为大胆：代码的可重用性不是最重要的。

在开始编码之前，您应该考虑代码将要实现的用例。因为该软件是要使用的，而不是要开发的。可用性和实用性是两个最重要的目标，谁使用该软件（项目的相关部分的另一位开发人员或最终用户）无关紧要。

我的方式大致相同。当其他人告诉您有关对他们有用的事情时，请倾听，但请忽略任何告诉您“应该”做什么的人，好像有道德上的必要。如果您找到适合自己的东西，那就去吧。我的意思是，最终结果很重要，不是吗？谁真正关心您到达那里的道路？

记住：人是不同的。这是好事。不要听那些试图让您喜欢他们的人，并且拒绝让其他人喜欢您的冲动，您会做的很好。

看来您是：

1. 尝试找出最佳方法（实验，增量设计）
2. 重写代码以使其更整洁（重构）
3. 不断编写测试（测试驱动开发）

您在做什么很棒！看来您做得很不错，尤其是如果您自己弄清楚了它，而又没有从（敏捷）编程书中学到的时候。显然还有更多，但您已经确定了价值观。只要记住在添加代码时就重构和改进设计，就不需要BDUF了。

您是否考虑过一次专注于一项小功能，并在每项功能完成后发布？这可能会帮助您从遇到的任何分析问题中解脱出来，并向您的雇主展示真正的进步。

另外，我不知道您在说什么“专业发展社区”，但是如果您是我，我会告诉他们回到他们的象牙塔，这样您就可以继续工作！

布拉德，你并不孤单。我知道非常好的程序员，他们的工作方式与您描述的完全相同。:)

如果您清理代码并知道如何使其高效和可读性，那么您当然也已经对如何提前编写干净高效的代码有了一定的了解。

此外，没有任何东西可以事先进行充分的计划，发现细微之处的最短途径通常是运行代码并了解被忽略的细节。

我认为您做的很好，并且您描述的编程风格也很有效。

我认为值得用引自麻省理工学院著名书“计算机程序的结构和解释”（通常称为“ SICP”）的前言Alan J. Perlis的话来完成上述答案：

每个计算机程序都是真实或思维过程的模型。这些过程源于人类的经验和思想，数量巨大，细节复杂，并且在任何时候都只能部分地了解。它们很少通过我们的计算机程序来满足我们的永久满意度。因此，即使我们的程序是精心设计的离散符号集合，互锁功能的镶嵌图，它们仍在不断发展：随着对模型的理解加深，扩大和泛化，我们会对其进行更改，直到模型最终在另一个模型中达到亚稳态为止。我们奋斗。”

有好聪明和坏聪明。

良好的聪明-聪明的代码行与非聪明的选择中的行之间的比率很高。20行代码使您无需编写20000，这是Extremely Good Clever。好聪明是关于节省自己的工作。

不好的聪明-编写的代码行与保存的代码行之间的比率较低。避免编写五行代码的聪明行之一就是Bad Clever。不好的聪明是关于“句法手淫”的。

请注意：Bad Clever几乎从未被称为“ Bad Clever”。它通常会以“美丽”，“优雅”，“简洁”或“简洁”的别名旅行。

在您描述工作流程的方式中，我绝对可以认出自己。事情是这样的：当我开始在小组环境中工作时，几乎所有的东西都必须改变。

我从事大约8个月的工作，实际上是我在一个团队中开发单个项目的第一次经验。到目前为止，从字面上看，我的整个职业生涯都是作为独狼编码员，他不必处理团队合作带来的所有问题。即使当我在小组中工作时，也总是很孤单的工作-我的项目是MINE，或者我的部分是MINE，等等。这是一个有趣的学习曲线，因为我使自己快速适应了真正协作的团队工作环境。

这是我已经意识到的主要事情：如果您所做的工作不很明显，那么您可能正在写给同事的下一个头痛。您在此处看到的大多数“以过程为导向”的烦恼都与以下事实有关：我们中的许多人都对同事感到头痛。而且大多数软件过程管理理论都与最大程度地减少这种头痛有关。

因此，诸如提前计划达成一致的计划之类的事情……就是要有一个团队参与并保持同步。如果您是团队成员，那么您已经与自己保持同步了，这并不是必须的。

您作为创意艺术形式的做法没有错。如果您是为了个人利益而发展，而您正在做的事情为您工作，并且您觉得愉快，那么与产品本身的最终结果一样重要。

在专业的工作环境中，如果您的项目时间很短，大约2-3周或更短，那么您的方法就称为快速原型开发，非常适合将来的任务。

但是，对于较长的项目，即使是您自己工作的项目，这种方法对于您的雇主来说也可能是昂贵的奢侈品。将项目预算花在前期架构设计上几天，然后针对如果管理层决定通过以下方式更改规格进行测试，这通常是花费的时间，并且将使您的技能发展成为更有价值的程序员/架构师在你的职业生涯中。

两种观点：

1. 无需维护绘画。

2. 曾经看过鲍勃·罗斯（Bob Ross）画画的人都知道画具有结构。如果您要从鲍勃·罗斯（Bob Ross）那里上一课，那就是提前计划和有组织的工作可以使过程顺利进行并且看起来很简单。

我编写代码的方式几乎相同。我将开始写作，并且随着我看到模式的出现，我进行重构。您可以通过这种方式将自己描绘在一个角落，必须知道何时该坐下来思考问题，但是有时您只是为了真正理解问题而to之以鼻。

但是我对此感到好奇：

这里和Stack Overflow上的社区似乎拒绝任何不完善的想法。[..]我的过程似乎与专业开发人员社区所能接受的基本原则背道而驰，我想理解为什么。

Stack Overflow的任何人怎么会知道您的过程？您所说的“拒绝”是什么意思？自然，将严格审查发布到编程社区的代码。但是，如果有人发现可以改进代码的地方，那只会是一件好事，对吗？

希望在将问题发布到Stackframe时，清理代码并尝试将其简化为尽可能简单的形式，出于对读者的尊重（有时您会尝试使自己的问题呈现给其他人来解决您自己的问题），其中如果有任何反馈是好的。如果你的代码后，你知道是坏的，你知道为什么它的坏，你张贴之前，你不应该把它亲自如果人们注意到它的坏。

我也用你的方法。它对我来说效果更好，因为它减少了过度设计的风险。

我经常要做的是用可能最少的代码来解决问题，这通常会导致明显不必要的依赖关系或其他设计问题。然后，我将工作代码重构为漂亮的代码。
例如，我减少了不同模块之间的依赖关系以简化界面，并思考应该将哪些数据保存在哪里，直到每个模块仅依赖于其他模块的非常抽象的抽象。您可能会说，我推迟了最终决定，哪个模块应该承担哪个责任。我推迟了抽象。
过多地考虑将问题划分为不同的职责，划分为不同的抽象是不好的。它将迫使您弯曲实现以适合您所做的抽象。如果代码产生所需的结果且可维护，则代码有效。如果您可以通过良好的代码来实现设计，则该设计将起作用。如果代码不起作用，请对其进行更改。如此，如果某项设计不起作用，那么您也需要对其进行更改。实施设计后，您只能查看其是否可行。

因此，在开始将其变为现实之前，将一个简单的草图作为设计就足够了。根据需要重新设计，抽象和重构。

我认为，如果您要擅长编程，至少有时候它必须很有趣，这意味着要有创造力。

当然，当成组编程时，至少应遵循最低限度的标准，而不是出于“道德”的原因，而是出于实际的考虑（如果适用）。

除此之外，探究边界以查看在那里可以找到什么是有趣而有趣的。有一次，当我用汇编语言编写Mini时，我发现您可以创建可以使用1条指令从一个程序切换到另一个程序的协同程序。然后，我弄清楚了如何制作一个自我协作程序，该例程可以前进两步，后退一步，等等。它有用吗？我对此表示怀疑。那不是重点。

有一次我听到Edsger Dijkstra的演讲，谈论编程的创造力。他提到了一个学生如何找到一种方法来对n + m位的单词进行n位旋转。用3个bitwaps完成。首先交换n位，然后交换m位，然后交换整个n + m位。有用？不，聪明？是。

随时尝试在自己的头脑中没有人会做的事情是很好的。

这可能是“一种尺寸无法容纳所有尺寸”的情况。您已经为自己参与过的项目设计了风格，那么谁会为此争论呢？但是，您在此处和此处阅读的批评者可能正在从事较大的项目，或者需要团队成员之间进行复杂协调的项目。

如果您曾经参与过涉及多个开发人员之间的合作的大型项目，则您的开发风格可能会成为问题。很难安排它，很难跟踪您的进度，并且您的其他程序员无法根据自己的工作计划自己的工作。

您可能对阅读Dreaming in Code感兴趣，以了解大型项目采用与您相似的开发风格时会发生什么。

可以肯定地说，您的方法没有错，但是让我补充一些个人经验。我从您的方式开始，但是与此同时，我至少事先了解了总体结构的一部分，这有很多原因，其中包括：

• 最大的好处是，如果经过一些努力，可以更轻松地查看哪些代码可以重用。我经常写一段代码，在编写时突然看起来对我挂在屏幕旁边的通用方案的另一部分有用（以纸质的形式写在纸上）。

• 有了方案，您不仅可以重构代码，还可以重构方案。有时我正忙着写一堂对计划中其他部分似乎也有用的类。结果，当项目运行时，方案变得更简单

• 每次我用所需的输入/函数/方法的给定输出以及类中的可用插槽来更新该方案时。重用位的速度更快：我不必每次都深入研究代码来检查到底有什么内容可以输入和输出。即使在评论中，我仍然必须浏览以获取评论

所以实际上，我也使用您的方法。我只是开始，尝试，重构，再次尝试，更改另一位，依此类推，但是我的周期也包括该方案。完成后，我添加了适用于该代码的下一个信息。

请注意，这是针对我一个人从事的项目。如果您与更多人一起使用同一代码，则提前计划不仅是逻辑，而且是必不可少的。但是我想你已经知道了。

正如其他人所说：这是我的 方式，您的行程可能会有所不同。