读《A Philosophy of Software Design》——（15）

🤔☕️🤔☕️🤔

• 读《A Philosophy of Software Design》——（15）Write the Comments First

• 📖：先写注释，作为设计过程的一部分。

  🤔：直觉上，有点怪，不都是代码先写嘛，注释跟设计又是啥爱恨情仇呢？设计，工程化的设计，不是创作类的设计，后者是为了表达，前者是解决约束，解开约束的结，打开通向功能的通道。那注释在这条通道上可以起到什么作用呢？可以变成路标。代码能把逻辑和过程表达清楚，但是路标可以指出从哪里来，到哪里去。写完代码加路标，那是事后注释，架起路标写代码，这是事前注释。如此说来，注释的确可以成为设计的一部分，在通往功能的路上，注释以路标的形式存在，很合理的样子。

  🤔：代码，所谓详细设计之后照着写，个人经验，极难。开始，代码写出来都不成样子，谈何详细设计。后来，详细设计这点活，代码造就敲完。实际，没遇到过一方详细设计，一方代码实现。这么说来，势必有些代码是写着想着敲着出来的，自己回头看，发现不太对劲，再补个注释的情况还真不少，当然看到眉头皱起，也没补上一行注释的情况也少不到哪里去。

  🤔：再想起来，码前注释，有点像码前画图，如果注释写不出来，如果逻辑图和时序图画不出来，本身就是没想明白怎么写。这种情况下，憋着把注释和图先弄出来，还是先敲起代码呢？想来想去，还是先画图，至少标出来有几个主要对象，它们谁在先、谁在后，谁跟谁之间有什么消息、动作、数据，这些方面如果都画不出来，那真的会写出稀奇古怪的代码，就是那种自己怎么说都说不明白的代码，然后就是以稀奇古怪的方式各自异常给我看的代码。这样的代码也不是一无是处，至少可以告诉自己思路都乱成啥样。处理这样的代码的唯一方法，就是删除重写，千万别当宝贝留着，尝试把这样的代码改对，就是在已经打百个结的绳子上，再打千个结上去。

        —— By 术子米德 @2022.04.02