我如何写代码
我如何写代码
原文：https://medium.com/hackernoon/how-i-write-code-d250203ecd61
我想分享一下我是如何编写代码的。不是因为我特别好或者特别或者什么蹩脚的。我只是希望当年有人能和我分享这种经历。从幻觉中清醒过来。
你看，我总是想象一个职业程序员是这样工作的:
- 分析并定义问题
- 思考/讨论/处理/无论如何想出一个计划
- 坐下来写代码
- ???
- 利润！！！
但是我总是觉得第三步不够。我不是开始、前进和结束，而是缓慢而单调地前进。写一点，改一点。多写一些，改变很多。重写一些，然后移动一些东西，然后重命名，然后检查，然后再修改一些。有时候发现边缘案例会迫使我改变很多已经写好的和正在工作的东西。一张图胜过千言万语:
Applies to many things, including writing code
这困扰了我很久。但是时间和经验——我自己的和监督别人的工作——告诉我，我实际上在做正确的事情。让我们来分解一下:
循序渐进是可以的
我写很少的代码，然后运行它。有多少？非常少:一次 2-3 行代码或一个很小的功能。这看起来很荒谬，因为我已经做了好几年了。我希望事情会有所不同。但是每次我试着写更长的代码块，我都会变得效率更低，更沮丧。
此外，我清楚地记得几年前的一个标志性事件。我写了一页简单的代码——大约 10 个小函数/块，然后运行它。它真的成功了！
I couldn’t believe it
我肃然起敬。它所花费的是 20 年与计算机打交道的时间，其中 7 年是每天编程！
因此，如果你发现自己无法编写大的工作代码块，那就尝试小的。顺便说一下，这与软件开发最佳实践非常一致。比如关注点的分离和编写只做一件事的简短函数。
创作软件是从 A 到 B 的一条简单的线的概念是错误的
我的想法是:假设你知道自己在做什么(这本身就是一个谬论，因为(a)我们写的软件以前从未存在过，(b)我们一直在学习新东西)，让我们观察一下其他专业人士。一个木匠手艺不重启七次。也不需要多次修改他/她的整个设计。更有甚者，牙医根本做不到，因为这项工作是破坏性的。
那么软件开发有什么不同呢？我从鲍勃大叔那里得知的答案(如果你知道确切的语录，请分享！):
“软件的主要价值在于其改变的能力”
—鲍伯·马丁叔叔
这一惊人的特性对于软件创作和生命周期的后期阶段都是有效的。当我编程时，我会修改、改编和重写我之前写的东西。有时这种情况发生得太多了，以至于我不得不重新思考我的整个方法或问题领域。这个过程导致对已经编写好的和正在工作的内容进行重大修改。这是棒极了，因为这意味着我最初的方法是有缺陷的，我发现并修复了它！
This is a Good Thing™
这与最近关于测试驱动开发(TDD)的帖子产生了共鸣。它的一个要点是，TDD 最大的优势是从提炼 设计 和重构 实现的 过程中产生的代码——并且不是测试本身。换句话说，在正确的 TDD 中，你必须进行重构。另一方面，在 TDD 期间不进行重构的开发人员会产生完全相反的结果:测试糟糕的代码，使糟糕的设计(或 API 或实现)永久化。
因此，如果你发现自己一遍又一遍地重写同一段代码，这是一件好事。是时候重新思考你想出的解决方案，甚至是问题的定义了。如果问题是要解决的正确问题，并且解决方案也是正确的，那么您将为这项工作编写正确的代码。如果不是，你会想出一个更好的选择。
那么我的信息是什么呢？
如果你的开发风格感觉错误、不充分、缓慢或者需要多次尝试才能达到你的目标——你可能做得对。
我意识到这可能与你的经历不符。像生活中的其他事情一样，编程有各种风格和方法。我只是分享对我有用的东西，我经历的过程和今天的感受。这也是可以改变的:)
这篇文章的每一部分都被重写了太多次(包括这句话)。我希望时间和实践能提高我清晰表达思想的能力。