读完本期周刊，大概需要花费您15分钟的宝贵时间，不过超值哦。
- 1. TabNine让我从此愉快滴飞快滴写代码了
- 2. 编程思维"拆整析改"之动脑子的能力
- 3. 读写EXCEL再也不用在"格子里"晕头打转了
- 4. 代码规范之墨菲定律
- 5. CPU飙了内存爆了请用Arthas阿尔萨斯
- 6. YAML简单用用就好
- 7. 老家伙编程20年的指导原则
- 8. 纠偏：过早优化的谬误
- 9. 世界上最危险的药是什么?
- 10. 历史周刊回顾-高扩展性之开闭原则与依赖倒置原则
周刊每周五准时发布，欢迎您提交Issue或者联系主编黄老邪(wx: bingoohuang)，向本周刊投递有值得分享的内容哦，简短的一张图一段文亦可。
Tabnine 使用深度学习来帮助您更快地编写代码
TabNine很容易安装
通过 TabNine::config 指令可以打开配置面板，开启后可以看到一些基本信息，以及使用本地学习、云上学习、激活、申请 key、日志等等。
黄老邪一直用着它，只能借一句流行语来形容它：真香。
有了“动脑子”的能力，才能像被打通任督二脉，一通百通。
GO语言版本的excel读写库xlxs发布了。
肯定会有人问，我用JAVA，也想这样子玩，有类似的么？对了，我就知道你会这么问，已经给你也准备好了，叫做excel2javabeans。
都是黄老邪创造的“轮子”，可以放心用，因为，有问题都可以“当面提”了。
维基百科对墨菲定律的解释:
墨菲定律（英语：Murphy's Law），又译为摩菲定律，具体内容是“凡是可能出错的事就一定会出错”，指的是任何一个事件，只要具有大于零的机率，就可确定它终有一天会发生。
墨菲定律的原句是：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。在科学和演算法方面，与英文所谓的“worst-case scenario（最恶劣的情况）”同义，数学上用大O符号来表示。例如，对插入排序来说，最恶劣的情形即是要排序的阵列完全倒置，必须进行 n*(n-1) 次的置换才能完成排序。在实验上，证明了最恶劣的情况不会发生，并不代表比它轻微的情形就不可能，除非能够很有信心的推论事件的概率分布是线型的。在文化方面，它就代表著一种近似反讽的幽默，当作对日常生活中不满的排解。
阿里巴巴 MySQL数据库 索引规约 中提到:
【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。 说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据
墨菲定律，必然有脏数据产生。
Arthas 是Alibaba开源的Java诊断工具，深受开发者喜爱。 当你遇到以下类似问题而束手无策时，Arthas可以帮助你解决：
- 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？
- 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？
- 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？
- 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！
- 是否有一个全局视角来查看系统的运行状况？
- 有什么办法可以监控到JVM的实时运行状态？
- 怎么快速定位应用的热点，生成火焰图？
所有手册、源码、教程，都在官网可以找到。
阿尔萨斯是魔兽世界中的人物：
谁也不能阻挡我的复仇，老朋友。就算你也不行。现在，我召唤此地之灵。我愿意付出任何代价，只要你能够帮我拯救我的人民。 —— 阿尔萨斯·米奈希尔
面板：
在线教程：
工作原理：
我为什么开始用YAML呢？
- 因为想写注释，所以想到了YAML
- YAML基础语法很简洁
- K8S大量使用也使得它非常流行（或者反过来说也行，因为YAML很流行，K8S用了它）
下面一个简单的例子来自于Ansible中文权威指南
---
# 一位职工记录
name: Example Developer
job: Developer
skill: Elite
employed: True
foods:
- Apple
- Mango
languages:
ruby: Elite
python: Elite
因为对JSON很熟悉，所以把YAML转换为JSON，来验证是否符合自己的期望，例如以下实验YAML多行文本的写法：
作者作者 Alex Ewerlöf从 1999 年开始编程，今年正式编码了 20 多年了。
- 语言涉及：Basic、Pascal、Delphi、C++、2006年Java，2011JavaScript。
- 行业涉及：机器人、金融科技、医疗科技到媒体和电信。
- 角色变换：研究员、CTO、TPM（技术产品经理）、老师、系统架构师到 TL（技术领导）。
他总结了20条指导原则，我从中节选3条，以飨读者：
第2条： 不是为机器编写代码，而是为同事和未来的自己编写代码。为了能给后来者作为参考而写代码。 第11条： 复制和粘贴孕育了 Bug。这就是它们繁衍的方式。总是搞明白你复制过来的内容，总是审核你导入的内容。 第15条： 走出你的舒适区。每天学习。把你学过的东西教给别人。让自己接触其他语言、技术、文化，保持好奇心。
Tony Hoare说：“过早优化是万恶之源”。经过Donald Knuth大师推荐，这句话已成为软件工程师的口头禅。
不幸的是，它被误解扭曲了。许多软件工程师将这一准则理解成“你永远不应该优化代码！”，认为没有必要进行优化。
Tony Hoare 和 Donald Knuth 的真正意思是，代码微优化之前，开发者应该担心其他问题。
而且，原话并不是说：“在开发的早期阶段，关注程序的性能是有害的。” 他只是反对过早的优化。
以下几点理由，可以解释为什么不能忽视软件性能。程序员正确的做法应该是，在软件开发的早期阶段，就关注性能问题。
- 性能问题难以在软件开发的最后阶段解决。20％代码占用了80％时间，它们可能散布在整个源代码中，不容易一次性解决。
- 许多人相信，到软件发布时CPU性能将会提高，以弥补部分代码的性能低下。尽管在1990年代确实如此（摩尔定律），但在最近十年CPU性能非常有限。
- 软件师认为，他们的时间比CPU时间更有价值。因此，浪费CPU以减少开发时间是对的。但是，他们忘了用户的时间更有价值。（本条黄老邪持保留意见）
- 优化可能会导致产品延迟进入市场，并降低利润，这是对的。但这种想法忽略了性能不佳的产品可能很难销售，尤其是在市场竞争激烈的情况下。
- 有些程序员认为，几乎没有必要确保在软件的设计阶段，就使用最佳算法，先实现功能再说，因为以后总是可以替换更好的算法。所以，无需担心软件在开发阶段的性能，以后可以通过更好的算法对其进行提高。不幸的是，更好的算法在后期不一定可以实现，而且代码往往因为牵扯太多，无法轻易替换其中某个部分。
140斤的成年人，口服700纳克（0.00000007克）肉毒杆菌毒素，就会挂掉，真危险。但是这不是最危险的药...，那到底是什么呢，请看视频
废话不多说，请客官直接看图吧：
