/ uazw blog / 工程实践四总结

工程实践四总结

2015-06-02 posted in [总结]

foreword

很想说一下, 这次工程实践也是一个人做下来， 从前台到后台，以前觉得这是一件多么让人骄傲的事，
但现在看来，太过于愚蠢， 诚然现代框架的很大一块目的是为了简化开发难度， 但是即使一个小项目
在一个人头上也是很重，而且个人认为注重 量 的开发，是野蛮的，而开发应该是注重 质 的开发是优雅的。
但是即使如此我也觉得自己开始接触一些最佳实践。

best practice

测试推动开发

测试不是一个表面过程

由于我对TDD仍然不熟悉，所以并没有选择TDD来开发，而仍然先写好功能然后经行测试，在这里最重要的是
单元测试不是一个只是流程，而是一个对代码质量的重要保证， 在这里单元测试应该较为完备。

测试很有意思的是当测试的情形越多，那么就越能保证代码能在各种环境得到预期结果。 但当测试不够完备时，
基于这些代码构建更大代码，出现错误的时候，仍然要回头去看测试过的代码 并且很有有可能改变实现，
导致以前的代码无法通过测试，陷入死循环。

测试代码不是没用的代码

在最初开发生涯中，我讨厌测试，觉得是没用的代码，在随后的开发经历告诉我，测试代码应该是作为
API作者和使用者之间的文档，即通过看测试代码就可以知道代码的基本使用方式，既然测试作为了文档，
那么花精力在测试代码上，实现阅读性好，清晰。在另一方面，我们也可以用很有优秀的框架。

Lazy vs Eager

当出现这个选择时，很多时候顶着为了效率，直接选择用lazy，然后视图处理的时候为了获取数据，又得加上一个
OpenSessionInViewFilter。这种方式好与坏我并没有测试过，只是觉得不够优雅。 那么怎么考虑这个问题呢？

  1. 可以考虑一次性加载的数据的数目，较小的话可以完全的用Eager。
  2. 第二如果映射的另一边是值对象可以完全的开启二级缓存，即使比较大的数目也应该不是什么问题(未测试，只是提供思路

Java 8的运用

java8中最让人耀眼的是lambda的加入，和方法应用(method reference)，有了这两个利器以后我们可以减少一部分模板代码。

这可能是我们会遇到的一种情况，很明显这代码在形式上实在太重复了， 那我们该怎么样来改变呢？

//in method A
Entity entity = EntityRepository.findByName(String name); 	//find entity
entity.changePassword(xxx);  							    //make some change

//in method B
Entity entity = EntityRepository.findByName(String name); 	//find entity
entity.changeSex(xxx);  									//make some change

这里是另一段代码

//helper
public <T> void helper(String name, T t, BiComsumer<Entity, T> func) {
	Entity entity = EntityRepository.findByName(String name); 
	func.accept(entity, t);
}

// in method A
helper(name, String password, Entity::changePassword);

// in method B
helper(name, Sex sex, Entity::changeSex);

perfect!

anti-pattern

Optional

在 Java8中同样也引入了Optional类，我认为Optional是一种更好的空对象(Null Object)但是由于
我并没有仔细研究Optional的语义， 最佳实用时，在项目中滥用，导致了更多的模板代码。

待学习

测试的分区

我提出这一问题在于，在测试中我们需要不同的层，为了更快的测试，进行不同的配置，(例如在测试服务层的时候
为了快速可能需要用到内存数据库或者用集合(stub?)来取代实际生产中用到的Mysql之类的RDBMS。那么自然我们
需要用一种方式来快速切换配置，在spring-test中看到@Profiles这一选项但是由于时间关系，没有深入学习。

前端开发

很难想象的是前端开发如今变得如此的火，新的技术层出不穷，而前端的纷争也是很厉害啊。。

模块编写规范

CSS预处理器

(吐槽：我至今不知道这是个啥。。。

前端MVC框架

Grunt

同样不知

bower

也不知道