Bright LGM's Blog

EfficientNet是谷歌AI科学家们在论文《EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks》中提出的模型。这篇文章不仅提出了这个模型，还系统地研究了模型扩展的问题，大家感兴趣的，可用阅读一下论文原文。EfficientNet的亮眼之处在于，其在保持领先的性能的同时，将模型的参数数量和预测速度都提升了一个数量级。请看下图的性能对比：

在Python的世界里，将一个对象以json格式进行序列化或反序列化一直是一个问题。Python标准库里面提供了json序列化的工具，我们可以简单的用json.dumps来将一个对象序列化。但是这种序列化仅支持python内置的基本类型，对于自定义的类，我们将得到Object of type A is not JSON serializable的错误。

TDD有很多好处，但是广大程序员却总是难以接受。即便在我们ThoughtWorks，有着非常浓厚的TDD氛围的公司里，接受起来也依然不是一件简单的事情。我曾经见过一些在我们公司工作过一年甚至两年的同事，对TDD的理解都还停留在比较粗浅的认识上，平时的实践也难以跟上。

我们每天都在用某种编程语言写代码，但是我们真的了解它们是如何工作的吗？代码是如何转换为计算机可以识别的机器码的呢？

了解编程语言的工作原理，不仅可以让我们深入理解某一种编程语言，某些时候还可以帮助以一种更优雅的方式实现想要的功能。比如我们平时谈论很多的DSL（Domain Specific Language），在定义了DSL之后，我们如何做更进一步的支持呢？事实上我们还可以实现DSL的自动错误检查，还可以将其转化为某种可以执行的程序等等。还比如我们经常遇到的模式识别问题，状态机相关问题等等。对于这些问题，编程语言的实现原理可以给我们很多启示。

随着机器学习的流行，Python近几年的热度一直在上升，再加上Python本身语言设计的简洁直观和易用，Python越来越得到开发者的青睐。但是我们却时常听说Python性能低，不如java，更比不上C。在这些抱怨背后到底是什么原因呢？Python真的性能低下吗？有没有什么优化的办法呢？

对于单纯的复杂计算过程，Python性能是比较低的，这是由于Python本身在设计时首要考虑的是如何快速完成工作（get things done），所以在性能上难免会有一定的牺牲。但是由于python和c有着非常好的互操作性，这类问题都可以通过实现一个c语言的版本来解决。当然从代码编写技巧的角度也有一定的优化空间，如果我们想做极致的性能优化，可以参考官方的性能优化技巧。

中台的概念从阿里17年开始提出来就快速成为了年度IT热词。阿里这样体量的企业的成功无疑论证了中台建设的正确性，让大家对于中台这样的解决方案跃跃欲试。而阿里顺理成章成为了中台的最好代言人，大家学习中台的榜样。那么什么是中台？事实上，对于中台的定义大家也一直在探讨中。阿里内部业务系统有其独有的特点，诞生其中的中台自然也带着阿里独有的特征，这一点从《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书中我们也能读出来。直接复制阿里的中台方案真的能解决广大企业中的共性问题吗？可能未必，这应该也是当前大家关于数据中台有着各种各样的解读的原因。

随着微服务和DDD的兴起，领域这个词逐渐成为了一个大家每天讨论中的高频词。对于经验稍欠缺的同学们，刚接触领域这个词，总会感觉有点神秘。到底什么算是一个领域呢？我们经常在谈论领域模型、领域服务、领域事件、领域边界等等，如果对领域概念没有一个清晰的认识，在接受这些相关概念上想必也会遇到阻碍。本文将结合我个人的理解以及一些实践经验来谈谈对这个概念的理解，希望能帮助大家更好的认识领域，进而更好的理解和运用相关的概念，最终更好的指导软件开发实践。

在文章开始之前，我们先回顾一下TDD带来的好处。当我们理解TDD之后我们至少会发现下面这三点：

1. TDD是一种更加自然的编程方式，因为我们总是要先弄清需求再编写代码，而这跟TDD先写测试（通过测试清晰的定义需求）再写实现的顺序是完全一致的。
2. 先写测试还要求我们站在使用者的角度来编写测试，这样我们可以自然的驱动出来更好的设计。
3. 由于TDD天然的特性，测试在编写代码之前就有了，自然我们也就无需担心测试覆盖率不够带来的质量问题了。

TDD给我们编写代码带来的好处多多，我前面有一篇文章主要分析了如何从改善设计的角度理解TDD，相信大家能感受到TDD给改善程序设计带来的好处。这里我想再次分享一个用TDD改善设计的例子，我们将从中看到不用TDD时我们的代码可能会变成什么样，而用了TDD又将变成什么样。

我时常在项目中听到一些经验稍欠缺的开发人员在Code Review时这么讲：

这里为了方便测试我抽取了一个纯函数，这个函数包含了主要的业务逻辑，测试覆盖率也比较高，我们可以认为这一部分质量不错。
使用这个函数的地方由于集成度高不好测试，我们就不做自动化测试了。

他的代码可能写成下面这样：

1
2
3
4
5
6
7
8
9
10

// some_file.ts
function someEasyToTestMethod() {
    ...
}

class A {
    someMethod() {
        someEasyToTestMethod();
    }
}

有一个技术人员都知道的很老的段子。如果我们想将一个技术论坛搞火起来，那么我们只需要发一篇帖子“php是世界上最好的语言”。虽然是很老的段子，但是就算现在我也常常能听到有人谈论它。很有意思的一个段子。

不仅仅是在论坛中，在我们日常的团队合作中，其实也常常有这样的事情。回忆一下我的 Code Review 活动，是不是常常有某一行代码引起了大家的广泛讨论，把整个会议给“搞火”了？大家可能就一个问题讨论很久，争执不下。

对于这样的讨论，如果大家能心平气和，互相理解，可能能较快的达成一致。但是事实上常常会出现这样的情况，双方争论很久争执不下，后来可能有人说，“这你都不知道啊”，或者“这我理解不了，你这里明显有问题”，或者“你说的都好，我用我的方式”，或者“你这里就明显是在#define true=false”等等。在这样的讨论中，我们比较容易情绪化（可能没有情绪化这么严重，但是这里姑且先用这个词），最后本来应该心平气和的讨论演变成了针对某个个人的互怼，或者直接拒绝交流。一旦情况变成这样，那么不仅讨论效率会大大下降，而且常常在相互心中产生芥蒂，影响后面的高效合作。