有效编程策略

最近我一直在做一些项目，这些项目涉及大量的学习和使用各种不同的框架和语言。一路走来，我记录下了一些感到沮丧、缺乏动力或效率低下的时刻。在本文中，我想总结一下我一路走来学到的一些经验教训。

每一次旅程都始于一行代码

任何有意义的项目都需要一段时间才能达到完美状态。我学到的最重要的一点是，过分关注最终结果并非明智之举。

为了保持高效，我认为最好设定一些可以在一周或更短时间内实现的可实现目标：设定一个目标，实现它。然后设定下一个目标，依此类推。即使目标很小也没关系。重要的是要明确目标是否已经实现。

设定具有明确完成标准的详细目标是关键。

样板的痛苦

开始一个新项目时最令人沮丧的事情之一，尤其是第一次使用某种语言或框架时，可能是让项目的基本样板代码和配置运行。

我发现，与其立即尝试在实际项目中这样做，不如先完成一些基本的框架项目，这样会更有帮助。这样做的目的是尽可能多地记录和自动化这些样板代码，这样克隆项目，然后稍加修改，就能立即启动一个新项目，变得非常容易。

我通常会先创建一个只包含一两项内容的项目。然后，我会创建多个项目，添加更多元素。最后，当我拥有所有需要的核心元素后，我会为我的“真实”项目克隆一个起始仓库。

例如，在 React 开发中，我首先弄清楚了如何用 Webpack 配置来构建和部署标准的井字游戏示例。接下来，我克隆了这个项目，并修改了现有代码，使用 Redux 进行状态管理。即使如此简单，我也发现我必须弄清楚如何在 Redux 中完成一些不太明显的操作。

一旦我把所有核心部分都准备好，并且通过结合脚本和 git 中的预配置文件合理地完成了自动化设置的工作，我就可以使用它来开始处理我的实际代码。

退一步看大局

有时候，我感觉自己像是在钻牛角尖地钻研代码，又或者陷入了编写抽象框架代码的泥潭，看不到尽头。对我来说，这些问题如同一枚硬币的两面。在这种情况下，停下来反思自己真正想要实现的目标，会大有帮助。

举个例子，有一次，我开始为一个面向 Web 的 API 编写一些验证逻辑的框架代码。我暂停了一下，然后勾勒出我希望返回给客户端的 JSON 格式。一旦我花时间理清并简化了这种表示形式，执行验证逻辑的进展就变得容易多了。

创建一个代码游乐场

我经常遇到这种情况，意识到自己需要更好地理解某些东西才能取得进步。这可能是某种语言或库的工作原理，也可能是我需要弄清楚用什么样的算法来解决某个问题。

尝试在项目代码库中直接解决这个问题可能很诱人，但我发现这样做有时会把分支弄得一团糟，最终不得不重新开始。因此，我创建了一个dev/playground目录，定期在其中添加一些小程序或脚本来测试我的想法。我会尝试移除所有不必要的依赖项，并仔细地隔离我正在处理的具体问题。一旦解决了问题，我就会回到正在进行的工作中。以下是一个例子：

仔细检查 JavaScript Await

Nested Software ・ 2018 年 4 月 6 日

#javascript #async #await #promise

研究模式与编程模式

我发现，有时候急于取得实质性进展，反而不愿意先停下来做些研究。专注于前进固然好，但如果不真正理解自己在做什么就贸然前进，可能会适得其反。

我现在尽量多注意这一点，并在适当的时候切换到研究模式。当然，这也有另一面：一旦开始研究，就很容易陷入一个永不翻身的兔子洞！所以平衡至关重要。研究要足够，但不要太多。

举个例子，最近在实现登录功能时我有点困惑，所以我花了一些时间阅读有关JWT、OAuth、CAPTCHA、XSS和CSRF的一些资料。了解了情况后，我就可以继续了。

很多编程都是在脑海中探索问题空间，而不是编写代码，所以研究并不一定意味着查找信息。它也可以简单地意味着将问题可视化，或者在笔记本上勾勒出各种方案。

进步并不总是线性的

焦虑感可能源于在解决问题时被拉向不同的方向。重要的是要意识到，这也是解决问题过程的一部分。

如果我无法决定下一步该怎么做，有时不妨先把这个问题放在一边，集中精力处理其他事情，同时在后台继续琢磨这个问题。当新想法涌现时，我可以重新拾起它，一点一点地处理，直到最终开始理顺。我发现这种情况发生得如此之快，真是令人惊讶。我可能觉得自己离完成既定任务的目标还有点距离，但经过几步尝试之后，一切突然就迎刃而解了。

另一个有时有效的策略是选择最简单的方法继续前进。即使这种方法以后可能需要改变，但目前拥有一个由自动化测试支持的基本实现可能就足够了。如果问题与我的主要目标有些无关，但仍然会阻碍我前进，那么这种方法尤其有效。

无论一个人如何应对前进道路上的障碍，重要的是要明白，进步并非总是一条令人愉悦的直线前进之路。有时我们会感到停滞不前。任由自己被这种困境压垮只会进一步阻碍进步。关键在于保持冷静，找到建设性的方法，继续朝着目标努力。