ARTS 16 - 如何构建并发布自己的 docker 镜像

jerry.mei

2020年11月29日 • 3 min read

ARTS 是左耳朵耗子提出来的一个打卡任务。每周一个 Algorithm，Review 一篇英文文章，总结一个工作中的技术 Tip，以及 Share 一个传递价值观的东西！我希望这个事可以给大家得到相应的算法、代码、技术和影响力的训练。

这是我的第十六周打卡。

🤖 Algorithm

其实很久之前，我就发现了使用调试器来编程对开发者来说是个巨大的伤害。对我自己来说，工作的头几年很多复杂的业务都是通过调试器慢慢调试，从而得出来代码。而且对于业务的错误定位，测试都是依赖它完成了。这就导致了以下问题：

算法能力得不到提升。算法是需要我们的抽象思维和空间想象思维的，特别是对于递归算法来说。所以一开始接触函数式编程，感觉特别困难。因为之前写代码靠调试器一步步调出来，但是递归不是这样玩的。
不会写Unit Test。对于没有接受过正规训练的程序员来说，甚至都没有听说过Unit Test 和 Tdd 等测试技术，他们认为测试应该是测试人员该做的事情。
代码中缺乏错误捕捉。对于一些错误流程，基本上不会进行处理，像记录一些日志等等。出了错误就一步步进行调试，直到找到问题。这个思维方式是很危险的，对于大型的项目来说，或者说线上故障，没有那么多时间等着我们去打开调试器一步步去 debug，甚至线上的错误很难在生产环境去复现。

这篇文章的作者是 Daniel Lemire ，他是一个大学的计算机科学教授。最初他的观点是：“使用调试器进行编程是未来”，这也许跟个人的经历也有关。

后来他发现很多著名的程序员都是反对调试器甚至声称从来不使用调试器。

Linux 的创建者 Linus Torvalds 不使用调试器。
Robert C. Martin 是敏捷编程的发明者之一，他认为调试器是一种浪费时间的工具。
John Graham-Cumming 讨厌调试器。
Brian W. Kernighan 和 Rob Pike 写道，单步执行一个程序的效率不如更努力地思考并在关键位置添加输出语句和自检代码。Kernighan 曾经写道，最有效的调试工具仍然是仔细考虑，再加上明智地放置打印语句。
引用 Python 的作者 Guido van Rossum 的话说，他 90% 的调试都使用打印语句。

在处理一个困难的项目时，我的最终目标是当问题出现时，就像他们经常做的那样，几乎不需要任何努力来查明和解决问题。依赖调试器作为您的第一道防线可能是一项糟糕的投资，您应该始终尝试首先改进代码。

最近一直都在学习 Elixir 这门语言，总结了一些基础的知识点。虽然这些知识官方文档都有，但自己敲一遍代码然后总结出来，效果还是比直接看文档要好得多。