读完本期周刊，大概需要花费您15分钟的宝贵时间，不过超值哦。
- 1. 新冠病毒与指数增长
- 2. 技术债务知多少
- 3. 金字塔原理中的结构化思维
- 4. Apache/CentOS/Nginx等名字考古
- 5. 一图胜千言：Git传输命令
- 6. OpenJDK选型分析-咖啡还是绿茶？
- 7. 初识国密算法SM
- 8. 微服务部署策略图解-金丝雀与AB
- 9. 自研小工具介绍：1分钟不到轻轻松松给MySQL表造个百万数据
- 10. 历史周刊回顾-好密码：破解它竟然需要3万亿年
周刊每周五准时发布，欢迎您提交Issue或者联系主编黄老邪(wx: bingoohuang)，向本周刊投递有值得分享的内容哦，简短的一张图一段文亦可。
新冠病毒与SARS病毒有啥区别呢？
新冠疫情，促进了远程办公网上教学等，比如下面一篇介绍”海外疫情增长“的图，网上教学也可以做得如此生动：
什么是技术负债，wiki
技术负债（英语：Technical debt），也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的一个比喻。
指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。
这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。如果不偿还技术债，则会积聚“利息”，从而导致之后更难以实施更改。 (硬币的另外一面：技术债不一定是一件坏事，有时恰恰需要技术债才能推动项目前进。)
软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。
图来自1
渐渐地，我们学会了用技术债当借口。“之前欠了太多债，所以开发慢”、“历史遗留问题，我也没办法”，后来，我们失去了热爱开发的灵魂，只剩下痛苦而缓慢的完成业务的躯壳。
技术债有如冰山没有露出水面的部分，很多问题可能被隐藏了起来
图来自2
技术债与俄罗斯方块→
开发者 Jonathan Boccara 将技术债比作俄罗斯方块。
游戏初始，需要从一个空白的页面开始进行，就像从什么都没有的编码项目开头一样。
接着，方块开始掉落，每个方块被放置的位置都会影响游戏的其余部分。如果你在没有太多思考的情况下让方块自由滑落，那么接下来的游戏会变得更为艰难。反之，如果设法构建干净、紧凑的结构，在后期将更易于管理。
每个新的修复程序或开发都像一个新的方块一样，需要与现有代码集成。如果以快速而肮脏的方式对其进行破解，就好像在俄罗斯方块结构中留下了漏洞。
若希望少留些空白或漏洞， 则需要花时间设计一个干净的解决方案，来集成修复程序或开发程序。这不太容易实现，但从长远来看会有所回报。
-
复制-粘贴式开发模式。
技术债的认识感知是有延迟的，就像在高速上超速开车，直到一周后你收到罚单，才知道自己要付出代价。很多团队不顾后果的复制粘贴，直到体会到业务发展缓慢，但是已经来不及了。
-
“必须马上上线。”
技术界流传最广的三大借口：
- “我们的领域非常复杂，所以我们有很陡峭的学习曲线”
- “我们的情况特殊，所以没办法写单元测试”、
- “我们时间紧急，必须尽快上线”。
首先这些假设从来没被证明过，其次假设“我们时间紧迫，所以必须牺牲质量”成立，但是不代表着“牺牲质量就能赶时间”。最后，在一个必须马上上线的论调充斥的团队中，那些想要做更多重构和更优设计的人会有深深地负罪感，陷入不断创造技术债的怪圈。
-
“暂时赶下进度，后面再重构”
如果能够经过合理分析，为了短时间赶工做出一定的牺牲，后面再有计划地重构升级，技术债本身并不一定是全是坏事。但是很多时候这句话成了空头支票，最后，就是变成了上一种恶性循环。
-
“解决问题的最好办法是写代码”
我们最喜欢的一句话就是“用代码改变世界”。但是恰恰相反的是，如果能够不写代码就能解决问题，才是最好办法。我们喜欢崇拜代码量，但是无休止的复制黏贴带来的大量代码不但没有价值，反而带来更大的成本。
内容摘自于3
-
团队/技术负责人，对技术宅的认知态度
如果团队/技术负责人，不觉得技术债是个问题，那就还“真不是一个问题”
-
识别技术债，形成列表，暴露出来
根据观察者效应，将问题暴露出来本身就是一种解决问题的办法。人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。
-
保持团队良好的Code Review的机制
在Code Reivew过程中，对技术债进行跟踪
简单来说就是要有逻辑、条理（《阿里工程师自我修养》——逻辑+套路）,智力不是关键，普通人的智力差不多，思路、套路（路径、方法）才是提高效率的关键。整理自1
四种组织思维的逻辑顺序：
- 演绎（因果）顺序
“大前提、小前提、结论”的演绎推理方式就是演绎顺序。 比如，经典三段论：所有人都要死，苏格拉底是人，苏格拉底要死
- 时间（步骤）顺序
“第一、第二、第三” “首先、然后、再者” 很多的时 间顺序同时也是因果顺序
- 空间（结构）顺序
“前端、后端、数据”， “波士顿、纽约、华盛顿”，化整为 零（将整体分解为部分）等都是空间顺序
- 程度（重要性）顺序
比如“最重要、次重要、不重要”
套路是解决问题的方法论（没有金刚钻别揽瓷器活——金刚钻啊），非常重要。 5W2H 分析法，就是一个帮助我们分析问题的非常好的“套路”，如下图：
建立中心，明确目标，解决 what、why 的问题，然后才是 how。建立中心两种方式如下：
- 自上而下，适用于问题比较明确，按照核心要素展开即可。
- 自下而上，问题不明确，各种材料杂乱，需要分类、剪掉枝丫、归纳汇总出一个中心。
分析的策略，即按照演绎顺序、时间、空间、重要性四个维度进行分析。其中，空间分析要注意满足 MECE（Mutually Exclusive Collectively Exhaustive，相互独立，完全穷尽）原则。
- Ansible
名称 “Ansible” 直接来自科幻小说。Ursula Le Guin 的著作《罗坎农的世界》（Rocannon's World）中， 有一种设备允许即时（比光速更快）通信，它被称为 ansible（从answerable派生）。 Ansible也成为了科幻小说的构成要素，包括在 Orson Scott Card 的《安德的游戏》（Ender's Game）中，该设备远程控制了许多太空飞船。对于控制分布式机器的软件来说，这似乎是一个很好的模型，因此 Ansible 的创建者 Michael DeHaan 借用了这个名字。
- Apache
Apache 是一个开源的 Web 服务器，最初于 1995 年发布。它是指对原始软件代码修复的补丁，“A-patchy server”（一个补丁服务器）。
- Kubernetes
Kubernetes 源自希腊语中的“舵手”。该项目创始人 Craig McLuckie 想坚持航海主题，他解释说，技术驱动容器，就像舵手或飞行员驾驶容器船一样。有趣的是，它和英语单词 “governor” 具有相同的词源，与蒸汽机上的机械负反馈装置一样。
- CentOS
CentOS 是 Community Enterprise Operating System（社区企业操作系统）的缩写。
- Debian
创建于 1993 年 9 月的 Debian Linux，名字来源于创始人 Ian Murdock 和他当时的女友 Debra Lynn。
- Nginx
该名称实际上应该被读作 “EngineX”，指功能强大的 web 服务器，就像引擎（engine）一样。
- Python
Python 的创建者 Guido Van Rossum 是喜剧团 Monty Python 的粉丝，Python 的名称也由此而来。
Git Data Transport Commands
Oracle 2018年9月17日在官方博客上宣布：
- 对个人用户(Personal Users) ， Java 8官方支持时间持续到2020年12月；
- 对商业用户(Commercial Users)，2019年1月之后不再提供免费更新。
于是，去年5月，我做了一个选型分析，对比了一下”咖啡“和”绿茶“，最终决定选”咖啡“。
这是小编使用GO写的一个小工具pump，目前支持MySQL的UTF8字符集和LATIN1字符集，随机给表造数据。开源在https://github.com/bingoohuang/pump上。
