smart ui

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方图片可了解培训详情。 引言 本文获得阿里巴巴《第二届研发效能征文》优秀文章奖，并在阿里第二届能效峰会上展出。 看标题感觉这个东西很理论，比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点，软件体系知识显得很“湿”，似乎人人都有自己的认识，但又很少有人能说完整，有一点可以确定的是，如果你未来需要独立设计一个复杂的系统中台，并使之未来能快速应对各种需求变化的话，科学合理的领域划分和边界界定需要我们“处女座级”的坚持下去，这对防止人力失控、减少项目烂尾很有帮助。合理的界定了边界后，即便某个微服务很糟糕，也可以就输入输出以很少的人力投入进行重构，相反的就是牵一发而动全身，加上业务需求频繁而来，很容易烂尾或是达不到如期的效果。 其实很多技术大神都是某一个技术点的好手，但可能在整体软件体系上思考并不多，每个人都有自己的设计方法，大部分容易想到的设计方法处理一般的系统已经够了，后面发生问题慢慢打补丁就行了，当我们面对各种需求变化陷入开发困境的时候我们就该想想了，咱们系统的体系设计上是否出了问题？本文不打算涉及领域建模和设计模式等代码级别的详述

甲方爸爸，大概你要的是代码生成器吧？ 一 1） 有一天，我的朋友Y童鞋分享了他正在做的一个内部开源项目，这个开源项目从外表上看，跟目前市场上那些代码生成器本没有特别大的区别，所以我兴趣并不大。 在他给我介绍了一下具体需求之后，我才体会了他的意思，并提起了那么一丢丢兴趣。。 毕竟，听起来有点“鬼扯”，为啥？因为，他居然试图依靠这个项目来生成”单元测试“。。。。 他：定义好数据库表和结构，然后就生成逻辑方法和代码、以及界面，还同时把“单元测试”代码给生成了，免得程序员要花时间去思考代码逻辑之余，还要想怎么写出可测试代码。 我：这样生成的代码还有灵魂么。。 他：有啊，编写高可测试代码，不就是我辈中人，这些有追求的码农应该实现的目标么？ 我：这种模式怎么越看越像埃里克埃文斯大佬说的“Smart UI”模式啊。。 他：你倒这么说，也有那么一点点像。 2） 我：当然，能够生成单元测试倒也可以。毕竟大部分单元测试看起来似乎是一模一样的。无外乎就是“ Arrange\Act\Assert”，AAA操作猛如虎，测试代码一把梭。 他：我这个东西，生成的代码，除了看起来提高了单元测试覆盖率之外，其实，并不能提高代码的质量。 我：是什么逼得你要花时间去开发这样的代码生成器呢？ 他：还不是被这班菜鸡开发者们产出的劣质产品闹腾的。我不是想着省测试的钱，又能提高产品的质量么？就自然而然只能靠压榨“程序员