这批中的第一部漫画是迄今为止最流行的 Cube Drone 漫画之一。看看 JavaScript 生态系统的疯狂，它最终仍然设法让它变得可行。
坚持不懈
问题 ：编译代码不是解释代码，即使它编译为解释代码。 解决方案 ：Grunt watch 问题 ：Promises 解决方案 ：IOUs 问题 ：Javascript 是一种与文档标记绑定的玩具语言，不知何故它已成为互联网的通用运行时。 问题 ：在这一点上，围绕 Javascript 的生态系统层次如此密集且变化频繁，以至于在任何重要时期内维护任何项目都将是一场噩梦。
有时，为什么？
我们简要概述了迁移到威尔士语的计划，但在发现威尔士语缺乏任何语法、句法或词法并且这些年来威尔士人只是假装相互理解后取消了这些计划
版本牺牲
本漫画由Threepanel 0.gassy.0.0.potato.1436966326.7提供
完整的无人机版本规范
这也存在于 drone-ver.org 。
无人机版本 v.1.sleepy.0.0.calamitous.1437363538.7
概括
给定版本号 MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN，按照 本漫画中的 布局管理您的发布：
- 当您觉得自己添加了一些很酷的东西时，MAJOR 会增加。
- 心情是你发布这个版本时的感受。
- ISSUES 是针对您的项目的未解决的 GitHub 问题的数量。
- SOCIAL 是您项目的 GitHub 分支和收藏夹的数量。
- DICTIONARY 是一个随机的字典词。
- UNIXTIME 是 unix 时间，并且
- 七始终是数字七 (7)。
介绍
在软件管理的世界里，有一个可怕的地方叫做“旧金山”。你的系统越大，你集成到软件中的包越多，你就越有可能有一天发现自己陷入绝望的深渊。
在具有许多依赖项的系统中，发布新的软件包版本很快就会变成一场噩梦。如果您不想和其他开发人员一起在旧金山结束——或者更糟的是，在硅谷——您将不得不尽一切努力使版本 控制变得更加困难 。
作为这个问题的解决方案，我提出了一组简单的规则和要求来规定如何分配和递增版本号。这些规则主要基于我第一次想到 Drone-ver 时认为最有趣的内容。为了让这个系统发挥作用，你需要冷酷的决心和从你身体的每一个毛孔中渗出的疯狂，影响你的工作和你与他人的关系。最好不要与其他开发人员一起从事 Drone-ver 项目，因为你们各自的情绪可能会变得非常纠缠不清。
一旦您决定使用 Drone-ver，您通常会使用 Twitter 来传达对项目的更改。如果使用您的图书馆的人没有收到更新，您将再次发布，但会在当天晚些时候发布。尽力劝阻这些人。他们正试图窃取您的库以在他们自己的代码中使用。你不欠他们什么，老实说，当你不看你的餐具抽屉时，他们是否在偷你的黄油刀。
我称这个系统为“无人机版本控制”。在这种方案下，版本号几乎不传达任何有用的信息。
无人机版本控制规范 (Drone-Ver)
关键词“MUST”、“MAST”、“MIGGITY-MIGGITY-MIGGITY-MACK”、“AWESOME TO THE POWER OF COOL”、“ALWAYS”、“GROOVITATIONAL PULL”、“REQUISITE”、“SHALL”、“SHANDY” , "EQUINE", "SCATTERBRAINED", "NOT RECOMMENDED", "PLEASE STOP", and "WHY ARE YOU DOING THIS TO US" in this document are being interpreted as the described in RFC 2119 .
- 使用 Drone Versioning 的软件必须具备酷炫的力量。
- 我们为什么要大喊大叫？
- 正常的版本号必须采用 MAJOR.MOOD.ISSUES.SOCIAL.DICTIONARY.UNIXTIME.SEVEN 的形式。如果是其他形式，请立即呼叫驱魔师。你处于危险之中。
- 我不知道我们在吵什么。
- 主版本零 (0) 用于初始开发。任何事情都可能随时改变。生活也是如此。凝视窗外，花点时间思考这个问题，或许可以边喝威士忌边思考。
- 构建元数据可以通过附加一个加号来表示，然后是一段描述您夏令营夏令营的简短段落。你在夏令营的夏天应该很神奇。
- 优先级是指在订购时版本之间如何相互比较。在进行优先级计算时，始终丢弃除 Unix 时间之外的所有内容并按其排序。不建议您改用随机字典词，但它可能会更令人兴奋。
- 总是 我想和你在一起并相信你 。
为什么使用无人机版本控制？
这不是一个新的或革命性的想法。一点儿都没有。事实上，您可能已经做了接近此的事情，因为您阅读了 SemVer 规范并且您就像“呃， 标准 。不适合我！”。
问题是“你的标准”不够好。如果不遵守某种正式规范，您的版本号将永远不会真正成为 spectacularicento，这个词是我编造的，它是宏伟、壮观和字母“O”的合成词。通过为上述想法命名和明确定义，可以轻松地将您的意图传达给软件用户。一旦明确了这些意图，您的用户就会让您安静地编写代码，再也不会在星期六早上 7 点给您发送电子邮件。
QIIPAM（我想象人们问我的问题）
这很糟糕。
这实际上更像是评论而不是问题。
我听说 TenVer 不错。为什么我不应该使用它？
TenVer 是一种不同的版本控制标准，它与 Drone-Ver 不兼容，因此非常缺乏。
SemVer 呢？这不是一个实用的、严肃的标准吗？
语义版本 ？从来没有听说过。
这不是阻碍快速开发和快速迭代吗？
你他妈的是对的。往前走，把 pip 变成一片荒地。
如果这样，您可以将 npm 排除在外，它已经是一片荒地。
我怎么知道什么时候发布 1.0.0？
这是一个无效的无人机版本。你为什么要问我这个？
是“Drone-Ver”还是“Drone-ver”？您似乎可以互换使用两者。
我可以看出你是一名 软件开发人员 。
“无人驾驶飞机”怎么样？
不，强调不。我看起来有钱注册 两个 域名吗？
如果我不小心发布了向后不兼容的更改，我该怎么办？
麾。拥抱 Drone-Ver 就是拥抱混乱本身。
我应该如何处理弃用的功能？
兴致勃勃。
关于
Drone-Ver 规范由互联网漫画家和互联网 gadabout Curtis Lassam 撰写。
如果您想留下反馈，我相信您会找到办法的。
归因
本文档是 SemVer 的混音。除了这个标准更好。特别是比 TenVer 更好，它是由一个真正的无赖编写的。
执照
电话会议
为这个笑话找到正确的视觉语言出奇地困难。它涉及从一个地方到另一个地方的大量切割。我希望它能走到一起。
小班大班
问题
昨天我在和我的老板讨论编码的一些细节问题，我们在某些方面有些截然相反。最后，他将我的建议作为“风格差异”置之不理，但我认为这更像是一个可维护性问题，我很好奇你们其他人的想法。我会尽量中立地介绍双方。
在 OO 环境中设计系统时，是使用更少、更大的类和同样少的方法，还是使用更多的类和方法更可取？在什么时候您在一个方向上走得太远了？
我的答案
感觉“少类/少函数”与“多类/多函数”二分法有点漏洞。在具有较少类的系统中，这些类将需要许多功能，因为每个类将处理更多状态并执行更多任务。所以它是“很少的类/很多功能”与“很多类/很少的功能”。
我宁愿让班级 尽可能小 。想象一下你的类的一个孤立实例，作为它自己的应用程序。每个实例变量在功能上都是全局的！这个单元变得越大，就越难测试、维护、管理和推理。在编写代码时，全局状态需要 始终 缓存在内存中，因此如果一个类有超过 7+-2 个需要推理的实例变量，您就会出错。有很多变量也会大大增加你的类可能处于的潜在“错误”或“无效”状态的数量。你能合理地检查所有这些吗？
Martin Odersky 将“共享可变状态”描述为万恶之源，而他的语言 Scala 非常专注于迫使开发人员要么将状态视为不可变状态，要么将其严格保密。可变性检查被静态编译到语言中。说真的，如果不是因为运算符重载的猖獗滥用和 JVM 的持续噩梦，我会成为一个彻头彻尾的 Scala 拥护者。类越大，该类共享的可变状态就越多。
不过，“尽可能小”可能很难管理。代码想要交织在一起。你如何保持小类和最小化共享状态？
我严重不信任深度继承树。不是出于 C++ 程序员的原因，例如“vtable 查找”——如果我关心性能，我就不会成为 Python 程序员。我对深度继承树的问题是，随着你越来越接近你实际使用的对象，状态的雪崩越来越大，越来越丑陋。对树底部的代码进行推理需要了解整个链条上的每一步。深继承树中的小类就是大类。
坚持使用 Java 的人被迫偏爱组合/接口而不是继承（https://en.wikipedia.org/wiki/Composition_over_inheritance）——而 C++ 和 Python 提供多重继承，而 Scala 和 Ruby 提供混合和特征——使之成为现实可以构建非常 广泛的 继承树，其中各个类只关注管理类的一小部分。
Scala 还借鉴了 Haskell 的重点，即允许程序员构建函数，这些函数仅将小的不可变对象作为参数并生成小的不可变对象作为输出，它可以 像他妈的那样组合 ， 易于测试 ，并且 非常酷 。
好吧，我在这里犹豫不决
很多小班！如果可能的话是不可变的！尽量少分享！没有很深的继承树！
看看我是如何制作漫画的：