onedaycbfly的专栏

核心： UT很关键，非逻辑代码可能不是太能体现UT带来的重要性，但是对于逻辑代码 UT是质量的保证和FT同等重要，现在任何开源项目都要求，在提交push申请的时候 需要带上UT。 以前经常习惯，写逻辑代码验证其正确性的时候用main方法来验证，其实用UT也是一样， 工作量差不多，并且如果不改变接口的情况下，进行重构，UT还具有验证重构正确性的 关键依据，还可以找出错误。

前言：一蹴而就的设计是危险的设计。过度设计也是不应该的，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。 本章主要是讲如何通过遵循四个原则的迭进方式，来实现简洁的设计。 重要性从高到低排： 运行所有测试再一次强调UT的重要性。UT写的越全面，越顺手，那么代码结构就越好。 常说的一句话就是，如果你UT不好写，或者跑不过，那么就需要回去看看业

前言之前在中兴开发者社区看到过一篇，关于软件设计的演变过程的帖子。 结构化(1969) –> 面向对象(1983) —> 设计模式(1995) —> 设计原则(2002) —> DDD（2004）—> DCI（2009）—> DSL(2010) —> 2012(微服务)这一章主要是从系统的层面来讲述，现有的架构是如何在系统层面来遵循CC原则。 工厂 Spring的核心技术“依赖注入”(DI)

Junit 框架内幕 单元测试的最佳实践

核心： 1、如何快速的学习和掌握第三方框架、接口或者组件。 书中讲的是，以测试为驱动学习。其实也就是边实战，边学习。驱动式的。并且需要反复的进行。

核心： 不使用错误码，使用异常。 里面有个例子，测试驱动开发的。 先写测试用例，异常测试的。 然后写出占位代码，再跑测试用例，通不过，修改占位代码，测试通 过，然后重构代码，重构后测试用例 正常跑过，那么重构成功。 自定义异常类 将第三方API进行打包处理。其实就是对第三方API进行封装处理，这样也减少了对它的依赖。 别返回null 有返回值的，直接返回零长数组。public String

主要面向对象和面向过程。

原则： 1、作为开发者，不要以为“功能实现”是代码的最终目的。可维护、易读性会对以后维护或者二次开发带来深远的影响。       代码不追求行数，不追求有多复杂，追求的是最简单实现功能，当然也要易于扩展。 2、团队应该有团队自己的代码风格，使用能够实现特有代码格式的自动化工具会很有帮助。       在eclipse中，添加相关的文件，进行格式刷的时候，就会刷成指定的格式。 3

原则就是： 1、对外模块公共的API需要提供正确、规范的JavaDoc 2、自己模块使用的API，最好不用注释，因为代码一直在修改，在重构，可是注释却没有人维护。       错误的注释或者坏的注释会带来巨大的损失。 3、所以要求我们写的代码具有足够的表达力，用代码代替注释。 4、自从敏捷开发以后，模块的说明文档已经不存在了。和注释一样，代码一直在改，在重构      但是文档却没有，

核心： 命名：工程的命名、包的命名、类的命名、方法的命名、变量的命名、参数的命名 名副其实：每个命名都应该能够表达出其相关的作用。 包的划分：每个包的作用独立性，命名独立性。  类的名称：实体类，服务类，工具类，接口，接口的实现，枚举类。           实体类：一般都是定义一个实体。只有属性和get、set方法   服务类：一般以service结尾，比方说Cach

核心： 从前期的变量到函数再到类，一步一步走向更高的整洁。 根据Java的约定，类应该从一组变量开始， 公共静态变量 > 私有静态变量 > 私有实体变量 > 公共函数 > 公共函数 >使用到的私有工具函数 这样符合了自顶向下的原则，让读文章像读报纸一样。class Demo{ public static final String NAME = ""; private sta