读芯术|要理解好的代码，你需要多多编写“不好”的代码
【读芯术|要理解好的代码，你需要多多编写“不好”的代码】全文共2823字 ， 预计学习时长8分钟
本文插图
图源：unsplash网络上有许多 “切记不要…”的文章：不要使用继承（inheritance） ， 千万别用单例模式（singleton） ， scrum将被淘汰 。 这些真的都不能用吗？如果语句真的很差劲 ， 我们又该如何甄别哪些建议可取呢？没有完美的编程语言 ， 也没有最好的编码方式 ， 有的只是指南（也就是已知的缺陷） 。 很多编程建议十分夸张 ， 每个人都告诉你不要再做这做那 。 照这样发展 ， 每个指令都是故障之源 ， 我们很快就没有指令可用了 。 就如同人们并不指望开卡车过木桥能到达对岸 ， 但这不意味着木桥没有承载力 ， 也不是说人们不该开卡车 。编程语言只是工具 。 使用的时机、原因以及方法取决于我们自己 。 不能因噎废食 ， 我们该改进的是使用方式 。
本文插图
木桥上的卡车 | 图源：Ono Paiva
怎样辨别糟糕的建议？好的建议有三个组成部分 。 首先 ， 信息本身；第二 ， 何时使用；第三 ， 何时不用 。 糟糕的建议通常缺少第二和第三部分——通常呈现出永久适用的特征 。一个常见的话题是：“不惜一切代价避免使用继承机制” 。 如果没有适用和不适用条件 ， 你可能会盲从建议而舍弃面向对象系统（OO系统）最关键的工具 。 如果该建议变成：“继承机制是非常好的工具 ， 但深层次机构（deephierarchies）通常有害 。 ”这次问题很显然出在“深度”上 ， 这个解释精准且洞悉了问题——浅层次机构是好的 。另一个要注意的就是语言 。 很多作者往往“肆意下笔 ， 从不更正” ， 这样的基调在充斥着互联网 。 为了撰写“肆意”而“肆意”撰写是极有害的 ， 作者不会说明他的建议并非普遍适用 。 为了避免语气折损 ， 他们往往不点明不适用条件 。 好的建议应是友好的 ， 而不是强硬的 。 每个真诚帮助过你的人都不会是怒气冲冲的 。
本文插图
图源：unsplash经验之谈涉及到编码 ， 有两条经验尤其适用：· 创造和维护语言非常昂贵 。 如果新语言中不断加入某种机制 ， 那说明该机制十分重要 。 这就是全局作用域、继承机制和如果语句仍然存在的原因 。 任何一篇声称该摒弃它们的文章都忽视了这些机制的重要性 。举一个很好的例子：类型系统 。 Python和JavaScript因为不需要分类而吸引了许多开发者 ， 之后就会后悔用无结构语言写了上千行代码 。 “落伍的”Java和C#就不存在这个问题（也不是说它们就没缺点） 。这就难怪TypeScript会出现 。 类型系统会返回弱类型语言——你输入一部分 ， 编译器会补足剩下的 。 这一想法非常成功 ， 分别通过 var 和 auto关键词打入了C#和C++的世界 ， 甚至Python现在也引入了类型系统 。· 与之相反 ， 第二条经验是：现代语言从设计上淘汰了混乱的部分 。这就是宏、goto语句和显式内存管理消失了的原因 。 过去 ， Java的垃圾回收机制（GC）饱受抨击 ， 但几乎所有现代语言的GC都不再需要Java虚拟机（JVM）了 。最近移除的是空指针异常 。 像Kotlin和Swift这样的现代语言用设计执行null检查 ， C#8也是同样的 ， Raw threading和async callbacks也存在自己的问题 。 现在 ， 我们编写异步程序时就可以使用便捷的async/await语法 。
本文插图
图源：unsplash而这一切都说明：想做一个更好的程序员 ， 需要了解编程语言的历史 。大多语言由富有工具意识的人创造 ， 由社群指引着发展 。 每次加入新要素 ， 整个群体都会专注地探讨元素的相关性和对群体的价值 ， 也包括如何完善元素设计 。 改变和移除元素时也是如此 ， Python 3做了许多引人瞩目的突破性改变 ， 都卓有成效 。多编写不好的代码我们使用的是数十年以来的创新成果和失败设计 。只有潜心于“劣质的”C/C++代码 ， 你才能真正地领略到垃圾堆叠的语言之美 。 这之前你只是想象过去编码有多痛苦 ， 那些写过单例模式并深受其扰（有很多问题 ， 比如编写测试）的人才能真正理解那种痛恨 。教科书上的示例与实际操作千差万别 。 前者不过是个提示 ， 后者才会真正改变你的编码方式 。大多人开始的时候都不会使用Git或Unit Tests来编码 。 这些项目往往漏洞很多 ， 也经常不能运行 。 没有Git ， 你无法得知是否不小心更改了什么 。 没有测试 ， 你的代码会在某次故障后直接不再运行 。 诸如此类的体验是促使我们每天使用这些工具的原因 。要真正理解如何写好代码 ， 首先要会写不好的代码 。 有几种能促使自己编写糟糕代码的方式（或者找到现有片段的缺点） ， 其实归根结底一件事：试着用另一种方法编码 ， 从而得知你的方案有多好或者过去有多糟 。下面是你闲暇时间可以做的事:· 学习一门父系语言: 举例来说 ，Kotlin的父系语言是Scala ， Swift等语言的诞生是为了解决Objective-C存在的问题 ， C#取代了Java 。 学习父系语言能为你展示过去没有但“今天拥有的” ， 也使人们更加珍惜今天人们唾弃的很多工具 。· 学习一门“承继”语言: C++开发者应该尝试Rust ， Java开发者试试Go ， Python对应Julia或Nim ， JavaScript对应TypeScript或Dart 。 与学习父系语言不同 ， 学习承继语言将揭露现有缺陷及怎样解决 。· 学习LISP：很多人觉得这个语言很怪 。 LISP没有变量 ， 它是纯函数式编程语言（比Haskell简单） 。 你不需要精通这门语言 ， 只需尝试写一些算法 ， 比如斐波那契（Fibonacci）、快速排序算法（ quick-sort）或者哈夫曼编码（Huffman coding） 。 如果沉下心慢慢做 ， 你会发现变量在很多情况下并不重要 。· 用纯C语言写一个文本处理器: 为文本文件设置一个路径 ， 打开它并删除所有换行符 ， 在每个句号后(.)加入新换行符 ， 然后重组每个单词 ， 保持第一个和最后一个不变 。 如果处理后每一行都保持平行就值得表扬 。 它能快速反映出字符串处理的巨变 。· 找出设计模式: 准备一个设计模式的清单 ， 并打开你正在做的或做过的项目 。 花些时间阅读每种模式 ， 并找到某种模式适用的地方 。 想象每个模式运用在这个项目中将会多简洁 ， 这是将设计模式整合到项目中的最佳方法 。
本文插图
图源：unsplash这些技巧要么改变你的编码方式 ， 要么帮助你审视已完成的代码 。 无论哪种都会让你意识到一切都不是想象得那样光鲜亮丽 。我并不是在讲对与错 ， 也不是讲怎样编码 ， 而是在邀请各位多多编码 。 代码是一种新的语言 ， 尝试用两种方式完成同一件事情 ， 多写代码才是码农的终极进阶之道 。
本文插图
本文插图
编译组：岳馨妍、元艺博 相关链接： https://medium.com/better-programming/you-should-write-bad-code-more-often-388c6f1ba5a推荐文章阅读读芯君爱你
本文插图
推荐阅读
- 养老金|2021年上半年办理退休，养老金核算的这些知识要把握
- 小龙虾|三农探析：池塘养殖小龙虾如何高产？高产养殖技术全解析
- 兔子|兔兔这么可爱，为什么要吃屎？
- 3月必吃的6种「春菜」，降压减脂又刮油，错过又要等一年
- 萝卜做饺子馅时，到底要不要焯水？很多人都不清楚，吃完告诉家人
- 糖尿病|这根血管堵了，离死亡最近！三个预警信号，糖尿病患者尤其要注意！
- 吐司太阳蛋，吃早餐也要有仪式感！
- 春天，要多吃这肉，比猪肉便宜比羊肉温和，营养滋补更解馋
- 豆腐不要红烧了，教你做外脆里嫩的炸豆腐，家人吃到赞不绝口
- 炒土豆丝的时候，不要直接下锅！加上这个步骤，又香又脆