GengMingHui_5的博客

引子近日崇左方就路侧运营以来反复出现的问题进行了汇总并抛过来。这意味着，伴随着问题/需求，路侧即将产生一些新得开发和改动工作。不安和抵触坦白讲，对于开发人员而言，面对问题和需求，我们或疑惑，或惶恐多少是有些不安和抵触情绪的。于我司实情，我们首先可排除一种可能，就是：开发人员缺乏责任心、懒惰。除开这种不分青红皂白一棍子打死的极端，探本究源，这种不安的情绪，还是来自于不确定。一方面，来自于问题的阐述。如问题抛出方，是否自己经过了审慎思考和论证，提出了合理的问题，可明白知道自己在讲什么？如果是UE（用户体验

维特根斯坦说“凡是能够说的，都能说清楚；凡是不能说的，就应保持沉默。”在我看来，这仍然是一个“边界”问题。之于软件工程，Team Leader经常教导我们一句话“编码是个次要问题”（兴许援引自《人月神话》）。当我们想要实现一个用例，一个功能时，我们的确不急于着手码代码，而是应该自问：你能否用自然语言，把这件事情（需求）像讲故事一样把它有条理有逻辑的表述出来，尤其用词要严谨，对于核心关键词的内涵...

如题，是个没有统一定义的概念；尽管在不同设计层面上，架构有不同的定义；但终归我们是在做架构；而做软件最重要的思维过程就是抽象，因此既然是做架构就一定能给架构抽象出通用的定义—— 通过否定之否定逐渐划清业务边界的过程；每一个阶段性的静态表达即狭义上的架构。在哲学上的立足点就是结合康德静态的认识论和黑格尔动态的认识论。...

在鲍勃大叔的《架构整洁之道》一书中的拾遗篇，西蒙布朗阐述了代码组织结构横切还是竖切的问题。按我理解，他结合着鲍勃大叔对于架构的通篇阐述后，指出了单纯的按照传统的MVC（横切）和SOA、微服务（竖切）等各自弊端，提出了自己关于端口-适配器模型的切分方式。这是一种充分考虑语言封装特性，利用访问权限关键字和包的概念进行代码组织的方式，兼顾了前两者的优点。既解决了当业务量扩大后MVC无业务...

python作为脚本语言，如果程序结构设计不当，在灵活随意的模块拆分中，就很容易发生循环依赖。这就涉及导入顺序问题了。由于脚本自上至下顺序执行，并且被导入程序在第一次被导入的地方会全部执行一遍，那么以程序入口文件来说，谁先发起的引用，谁就要先得到满足；否则离着程序主入口近的脚本要求什么资源还未得到满足，而被引用的模块却反过来索要主调程序所在文件中的资源，这就产生了循环依赖。此时，最理想的方...

近日，读刘宇博(liuyubobobo)老师发表在微信公众号”是不是很酷“文章”无解“时，很有感触。摘录几句如下：”原来，这个世界上有的问题，是没有解的“；”不合理的约束合在一起，让我们的问题无解“；”一个问题为什么没有解？因为问题的条件限制。说的文绉绉一点，叫做约束“；”在大多数情况下，解决方案，都是改变约束“；”我们必须承认：这个世界上很多问题，就是无解的。数学尚且如此，生...

编程中，相较于OOAD设计工作而言，编码实现是个次要问题。设计过程就是抽象归纳的过程。大抵有两种模式： 一是传统以数据模型驱动的设计思路，其特点是拿到一个需求，分析出一些基本的实体和关系（ER图）然后就去设计数据库和表关联了，这样做的好处就是建模速度快，缺点是实体类往往被数据库表牵着走，沦为数据模型的载体；由于着眼点偏于底层，没能从领域对象层面去抽出事物的本质，一旦需求发生变化，其维...

对于hibernate这种面向对象操作的框架，其带来方便的同时也对于业务逻辑和数据类型转换提出了更高的要求。因为做OOD设计时是从业务中抽象模型切入的；而前台和后台的DTO数据链路大体由VO-BO-PO不断进行相互转换的，实体类和业务模型虽高度契合，但要兼顾ORM的持久化问题，尤其处理数据库表关联和逻辑关联时、以及前台传参字面量对象和业务模型转换等，一定要保持清醒的头脑。一种传统办法是分开po...

近日在研习由Trygve Reenskaug（著名的mvc架构提出者）发表的论文"The DCI Architecture - A New Vision of OOP",其中提出的框架模式就叫DCI架构。由数据、场景、交互组成。我理解，这是一种用例驱动设计的OO编程范式式。原作中似乎希望对象在运行时执行相应的逻辑来完成不同的场景用例。关于这一点我还没有理解透彻，期间我想过使用AOP为对象切入...

近日随着对DCI编程范式的理解深入，结合java 8的语言特性，愈发觉得是时候可以把MVC架构放一放了。传统的mvc架构虽然结构清晰，但其肢解业务逻辑，使得开发跳来跳去，debug要像屡线头一样追踪代码，很是痛苦。而与MVC师出同门（同一理念提出者）的DCI架构，是基于用例驱动设计的，更加符合端侧用户的心智模型，也更符合程序员对于业务逻辑的理解，很容易上手。下面是我画的一幅丑图，并不规范，大概说明...

我们经常看到连缀调用的写法，一大长串类似obj.method1().method2().method3()……methodn();的写法；我在《JavaEE 7精粹》里看到其中一章才知道这叫流式编程风格(fluid programming style)，感慨于这种写法的优雅整洁，遂写一个小demo记录一下。之所以能实现连续调用，是因为每一次调用都返回相同类型的对象，demo示例如下：...