一周技术学习笔记(第68期)-像练习硬笔书法那样写代码
像练习硬笔书法那样写代码
你如果认真练习过硬笔书法，而且小有成就，就会有这样的经历，写字不认真的时候，或者说不按套路来的时候，写出来的字还是挺难看的。
但是，当你认真的时候，就能写出很漂亮的字来。
这跟学习设计原则有点类似。
当需求时间压得紧的时候，你的程序中的代码就乱遭遭，当你想写出好的程序代码的时候，又能够符合比如开闭这样的原则。因为你已经知道了什么是美。如果你的“硬笔书法”确有成就，那么出手一直就是美的。在代码上永远是规范自己，造福他人。
我们阻止不了系统接受新的需求，我们也决定不了需求砸过来的频率，而且频率可能很大，会有频繁的需求砸过来。但是，我们可以让这些需求引起的修改局部化，最小化，也就是让这些需求引起的代码变动影响最小，也就是我们常说的代码设计要遵循正交性，按照开闭原则写出的代码就有这样的魅力。
通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。
要保证系统的调整是局部化和最小化的。
写出这样优雅的代码是要付出多一些的时间成本，就像你写硬笔书法一样。不过这个过程付出的成本能为你以后的修改带来维护上的便利。
如果，你认为这种便利不是我当下要考虑的。
那么，我也可以送你一句话，让你宽心一些。
在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。
那么，现在你走哪一条路呢。
软件设计是一个层次化分解与重新复合的过程
从宏观上，我们有很多个分开的微服务，最终又通过网关整合输出；从中观上，我们的系统有很多模块，最终又通过关系将这些模块维系成一个整体嵌入到微服务中；从微观上，我们的代码有抽象和具体实现，最终又通过弱耦被嵌入到模块中。
你肯定也听说过软件设计的首要任务是做好关注点隔离。层次化分解的道理也蕴含了关注点隔离的思想。我们以TCP/IP的四层模型举例，从底往上依次是网络接口层、网络层、传输层、应用层，从网络层开始往上每一层都要依赖它的下一层，它们每一层又都各司其职，专心的处理自己关注的事情。最终，四层模型的整体又支持了TCP协议的应用。通过网络的四层模型我们也认识了这样一个层次化分解与重新复合的过程。
软件设计就是在问题和解决方案之间架起的那座桥梁，通过这座桥你就可以抵达解决方案的那一端。你有没有想过软件开发的目的是什么，因为你有需求，这些需求背后是很多待解决的问题，然后通过软件开发最终产出一个可交付物。这个交付物可以是一个在线的系统平台，也可以是一段可本地运行的代码程序。而你又有没有想过，软件开发的过程就需要软件设计的环节。
有了这样的架构思维方式，或许能改变那些在意地贬低自己是码农，搬砖的人，会觉得自己的工作变了，变成了真正的软件设计工作，从而在工作中不断螺旋式的肯定自己。
从防腐层看空间这个概念
从网上看到一个网友对防腐层的认知感悟，我个人还是比较认可他的观点。
从商品到订单再到库存这样在不同的上下文切换，这样让我想起一个词：空间。
这周，工作上我们在一起讨论商家根据不同的业务规则处理不同的业务逻辑，订单根据不同的订单类型处理不同的业务逻辑，这样一件事情。这个事情本身也遇到了上下文，商家有一个上下文，订单有一个上下文，或者换做叫法，称它们的空间不同，也可以。
我在想，有不同的空间，就会有不同的方言，统一了不好么。
进而，又让我联想到我们在分层架构中的那些个对象，VO、PO、DO、DTO等等，当时也有一样的想法，转来转去，那么麻烦，有时候还会有性能的问题，统一一个对象不好么，不省事么。
其实，这个网友的感悟里面，提到了一个关键的地方：转换的意义在于隔离变化。
订单的上下文和商家的上下文，业务域已经变了，就像我们经常对国外喊得那样，不要干涉我的内政，每个域，它自己的空间内跟其它空间之间有太多不一样的规则。除非这两个域之间业务模型上有较多相似的地方，除非我们的分层架构中层与层之间有较多相同的对象属性，我们使用一种方言，使用一个对象，这样可以一竿子到底，快而省事。否则，我们就不应该使用同一个事物来硬表达它们之间的不同。
不同的空间，不同的层，它们的变化原因不同，变化频率也不同，我们就要进行隔离，不然我们就会自找苦头吃。
到底是先有模式还是先有方法
并不是先有了设计模式才想着做正交分解，也不是先有了MVC才有了控制分离，更不是先有了DDD才有了领域服务。是之前就存在要隔离变化的、要关注点分离，要模块化，要弱耦，有这样的问题存在了，就势必会出现各种各样的解法，最后再抽象成一个名词概念。即使没有DDD也会有CCC。
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。