原副标题：程式结构设计 ≠ 代码！
她们都误以为，自学程式结构设计是卖报标识符，但一位副教授程式结构设计的同学表示：程式结构设计≠代码，更多天数都花在了辅助工具难题上。
原文镜像：https://occasionallycogent.com/programming_isnt_coding/index.html
作者 | James Cash
翻译者 | 弯月 白眉林 | 郑丽媛
公司出品 | CSDN（ID：CSDNnews）
自学程式结构设计的这时候，事实上 我们花在方法论自学上的天数极少，多半天数都花在了自学和管理工作程式结构设计辅助工具上；开发人员指出她们把所有天数花在了建立精心结构设计的结构设计和繁杂的抽象化上，但事实上更多天数都花在了处置辅助工具和暗含发展史本钱的生活习惯读法上。
有甚么难题？
依照我副教授程式结构设计的实战经验，她们极少花天数让小学生去自学怎样撰写标识符：在起初的一段天数里，初学者要自学“演算法观念”，接着自学新词汇或实例。她们会协助小学生自学方法论和程式结构设计，但在“自卖报标识符”的专业课程中，标识符这类并并非她们需要自学的文本。
相反，导师须要处置的难题主要是辅助工具，比如“EADDRINUSE 错误，接着崩溃了”；“git 出错了”；“npm 分段错误”。她们须要尽最大努力消除配置的难题，让大部份小学生都使用标准化的编辑器，并在虚拟环境中写标识符，这样可以保持环境完全相同。
如今“每个人都应该自学程式结构设计”的说法很流行， 但如果没有事先设置好环境就开始自学，情况会很糟糕吗？如果没有良好的基础，是否也可以自学程式结构设计呢？
实战经验丰富的开发人员一般不怎么讨论工作中多么须要依赖辅助工具，她们喜欢把自己塑造成才华横溢的概念艺术家，着重强调她们掌握了演算法和数据结构等极其繁杂的知识。虽然有些职位确实须要这种抽象化级别，但我敢打赌，绝多半数开发人员更多天数都花在了解决程式结构设计工作中遇到的各种辅助工具难题。
一些具体的例子
烦人的辅助工具有一箩筐。
使用终端
对于多半数非 Windows 开发人员来说， 使用终端浪费了大量天数。不幸的是，对于多半数初学者开发人员来说，在终端中写标识符似乎是非常新鲜的事情，当然遇到麻烦的情况另论。
我经常看到小学生通过 cd 命令，层层深入目录（而并非执行一个命令 cd dir1/dir2/dir3），她们也不知道使用 Tab 键可以自动补齐，会奇怪为甚么不能直接用鼠标点击来移动光标，以及许许多多奇怪的难题。
怎样退出程序
关于 使用终端的麻烦，还有一个例子是退出各种程序。
相信很多人都听过一个笑话：“怎么退出 vim？”当默认的 $EDITOR 设置为 vi 时，这就真的会变成小学生的一个难题。不仅仅是 vi，很多小学生不知道多半数程序可以按 Ctrl-C 中断，另一些可以按 Ctrl-D 结束，q 可以退出分页，\q 可以退出 PSQL。
有些小学生偶然发现按 Ctrl-Z 可以暂停进程，她们觉得很有趣，对她们来说这就相当于退出。这种想法会引发一些非常奇怪的难题，尤其是她们误以为自己已经退出了服务器，但仍有一堆副本在后台运行。
Git
关于 git 难以理解的讨论已经是陈词滥调了，但其实这种说法确实有充分的理由。
在这个领域，我知道我的 git 实战经验水平不足以协助小学生。长期以来，我已经生活习惯于从命令行使用 git，更不用说我曾花大量天数阅读实现细节了——这就导致在教学的过程中，我根本不记得不理解 git 是甚么感觉。
我指出，如果小学生们学会使用 GUI 辅助工具来使用 git，就可以享受到更好的服务，至少一开始是这样，但这非常不利于开发。有人可能会说，GUI 辅助工具并没有公开 git 的大部份功能。但你知道吗，命令行界面也没有公开。至少在使用 GUI 时，用户可以看到按钮和提交的可视化图，协助她们了解 git 都有哪些用途。
编辑器
我喜欢使用 Emacs 和 vim，但我不推荐小学生使用这两款辅助工具。因为小学生须要付出很多努力，才能学会使用这两款辅助工具的基本功能，更不用说自学怎样让这些编辑器发挥真正的力量了。
在我的专业课程上，小学生们使用的是 VS Code，这也是一款非常强大的编辑器，但小学生们并不知道怎样利用它。当我告诉小学生们可以使用 Cmd-p 或 Ctrl-p 跳转到文件时，她们大受震撼，但在我看来这只不过是 VS Code 的基础操作。
与多半数专家辅助工具一样，文本编辑器程式结构设计可误以为专家提供更强大的功能，但初学者来说不太容易上手。
React
React 教学周总是很艰难。以前，她们自学的是基于类的 React，那时的教学就非常别扭，因为小学生必须自学 ES6 的类语法，其中包含一大堆奇怪的语法。自学这些很难，但 Hook 似乎更难。
我很喜欢基于 Hook 的 React，因为我曾通过 Clojure 使用 React （起初使用的是 Om，现在使用 reagent/re-frame）。然而，对于还没有生活习惯函数式程式结构设计风格的人来说，就须要做很多功课了。
使用纯 Java 进行函数式程式结构设计须要特别小心， 因为这门词汇 根本无法协助你 避免突变。更糟糕的是，React 也根本没有任何措施来避免你犯错。
小学生很难学会正确使用基于 Hook 的 React，因为即使用“错误”的方式，似乎也能正常工作，比如直接改变状态变量或进行不安全的状态更新 （例如在设置新值的这时候使用旧的状态值）。小学生写了一堆标识符，看着似乎没难题，还可以运行，没有错误或警告，但如果之后她们添加一些其他更改，就会导致程序以很奇怪的方式出错，比如更新莫名其妙地丢失，重新渲染没有完成，接着小学生也不知道为甚么。
不过至少 React 还有一些入门教程 create-react-app，如果她们在自学 React 之前必须自学使用 webpack、babel 等，那么就真的不可能学会了。尽管这样，她们也会遇到一些奇怪的难题。最打击人的是自动构建停止工作，小学生们修改标识符，但是不起作用，因为事实上她们的标识符根本没有运行。
数量庞大
如果小学生只须要自学其中的一两个辅助工具，倒也还好。大部份学科都有须要自学的辅助工具和实践，这些辅助工具和实践提供了一定程度上的辅助作用。
然而，对于程式结构设计，你须要自学的新知识非常多，薅牛毛（Yak Shaving）一词诞生于程式结构设计界而非机械师，这是有原因的。人们在自学程式结构设计时，有无数令人费解的辅助工具令她们头昏脑胀，很容易产生疲劳，变得非常沮丧：当所做的一切只会招致更多麻烦时，每个人都会感到沮丧，所以你只需让标识符跑起来，不要深入研究背后的原因或怎样更有效地完成任务。
她们应该做甚么？
我一直指出，真正有用的专业课程不一定要教大家学程式结构设计，而是让大家学会怎样像开发人员一样使用计算机。很多这时候，这才是她们须要培养的最厉害的技能：并非演算法观念，而是对怎样使用计算机有深入了解。
人们须要成为专家才能使用基本工作，作为软件开发人员，这算不算是她们的失败之处？我不知道。
许多任务这类就很繁杂，但她们肯定能找到方法降低难度。我只是担心，开发人员会为了寻找某种成就感不想让程式结构设计变得太简单。她们当初付出大量努力来自学怎样使用这些辅助工具，如果这些工具变得更容易使用，可能会让她们觉得曾经大部份的努力都是白费。
我想这可能是一代人的变化，随着如今人们开始自学使用 Glitch 这样的辅助工具撰写标识符，也许将来她们无法忍受如今这些笨拙辅助工具，自然就能诞生更好的辅助工具。如今的开发人员似乎更喜欢用户友好的东西（解释性词汇、图形辅助工具），尽管仍有很多人主张回归到“更简单”的做事方式，比如使用 C 而并非 “高级词汇”，反对语法高亮显示等。
目前，我正在尝试一些事情：
▶ 安慰小学生们，遇到奇怪辅助工具难题时耗费大量天数并不罕见，这也并非她们的错。
▶ 尽我最大的努力慢慢向小学生介绍新的特性和功能，不要一下子给她们灌输太多知识。
▶ 不要执着于用“正确”的做事方式，例如 “真正的程序员只在命令行中使用 git”。
但这些措施治标不治本，她们怎样才能让程式结构设计专业课程专心副教授程式结构设计呢？或者说，有这种可能性吗？无论怎样，我认为如果她们认识到这是一个难题，就应该尝试为了下一代开发人员而努力改进。
毕竟，梦想还是要有的……
☞ “数学天才”陶哲轩也爱上 GPT-4： 节省了大量繁琐工作
☞ GPT-4 让 Python 程序实现自修复 Bug，国外小哥将辅助工具命名为“金刚狼”，并开源！
☞ 让你的类ChatGPT千亿大模型提速省钱15倍，微软开源 DeepSpeed-Chat
