早期，我读完设计模式、面向对象设计、企业架构模式、领域驱动设计等书之后，形成了一个观念。在分层的架构中，严格意义上来说，每层都需要有自己的实体或者说对象（Object），这是防止业务被腐蚀的根本。但是，在多年的实践中，我的坚持其实是在一次一次的被拒绝，尽管我一直觉得是别人认识不够高。然而，现在，当我再次质疑这件事的时候（最近我补了一遍围棋基础，对围棋的审视改变了不少）发现，这件事是我存在问题。因为，现实永远是对的。
那么，是什么问题呢？这个答案，可能能从我最近想读的阿里的编码规范上找到一些线索。我发现了BO和DO，业务对象和存储对象。为什么说他们俩呢？其实，最近因为研发团队解散，公司整个系统都是我一个人填坑，从前到后。这工作量就很大了。但是，我觉得，这件事情是不应该的。我们其实没有多少业务，为什么会有这么大的编码量呢？反观编码，大部分都是重复性质的增删改查。为此，我找到了mybatis plus希望可以帮助我快速的编写这些操作。但是，没有几天，我就找到了nuxeo，一个BCM（企业内容管理）开源框架。虽然我还没有研究它具体怎么用，但是它的作用就是帮助我建立数据，并管理它们。我没有必要为此编码，它甚至号称提供了相应的前端组件帮助我快速得进行展示。反思我学到的知识，忽然发现，这才是所谓的子系统。这才是真正的领域建模。虽然这个构建是偏向技术的，但是，它稳定的存在，健壮的扩展。什么多层实体必须相互转化，健壮性也是王道。快速的，建立有用的系统，并且确保它是可控的，可扩展的。我似乎花费了更多的心思在纠结怎么更好看上了，而不是真正的对自己的技术系统进行建设。
另一个思考，对代码的管理。其实，很多时候我们都会发现不同的人写的代码天差地别。但是，除了通过机械的编码手册以外，我们很难让他们写出达到同样优秀的代码。而我反思这种代码上的优秀，除了常说的高内聚低耦合，可重用可扩展之外，我更喜欢说管理好你的代码。然后，就有不少人问我了，管理代码管啥呀？代码有啥好管的？其实，这个问题困扰我几年了。我不觉得我说的是错的，但我无法回答这样的质疑。不过最近我似乎想得明白一些了。所谓对代码的管理，更多的是针对研发或者说编码人员说的。研发人员日常编写代码并不总是从头开始的，他要和现有的系统打交道，要去阅读代码以搞清楚其中的逻辑。而这个过程，其实是研发过程中最耗时的过程之一。如果你把多个功能柔和在一起，那当我阅读到一个属性的时候就不知道它都涉及哪些功能。如果设计的不好，可能某个源码文件会涨的很快，或者某块逻辑，读者其实是很难找到其源头的。代码写出来虽然是给机器运行的，但也是给人读的。所谓代码的管理，就是让人可以快速的找到他想要的代码，快速的获得他想知道的逻辑信息，快速得实现对现有结构的调整以满足新的功能需求。所以，管理好你的代码。今天第三遍听《吴军的谷歌方法论》其中说到，一个软件工程师的水平很大程度上依赖于他可以驾驭多大规模的代码。我觉得，这说的其实和我说的管理好你的代码，是同一件事。
网友评论