高手问答：Java老A带你全面提升Java单兵作战能力！

楼主很有魅力啊 书刚刚已经拍下 楼主有没有什么技术交流群之类的？

这个我在问下出版社同学是否还有量，你可以先私信我下，大量送的话出版社的同学也招架不住，呵呵！

感谢您的理解，我大部分初衷确实如此，其实不是以讲解知识为重点，而是通过说一个点带面，让我们形成一种探讨问题的习惯和方法，让我们理解很多东西并不是我们表面上看到的那样，可以让我们提前预知到很多坑，以及为什么。

关于你的问题，上册不会提到，因为上册都是探讨一些技术的点，只是我认为一个Java程序员的基础应该去学习的方向，有些阐述我也未必到位，未必正确，不过大家都在不断学习和进步。下册会有一些介绍，但没有专门的快速开发相关的书籍。

其实就快速开发本身来讲，要看你做什么样的东西，或者你的目标是什么，短期和长期目标是什么。如果仅仅是为了快速迭代，有问题解决问题，有功能就往上堆的方式，这个怎么做都能快，而且不用选Java，因为Java搞环境麻烦。还有要看你是想以项目做还是做一个相对长远的产品规划，某些点上的慢可能会导致整体上的快，快不一定是好事，快中求到稳、准、狠的才是高手。给别人演示原型系统可以做到快，说明我们又能力开发并按期完成。但是真正的产品该快的地方要快，该慢的要慢，尤其是在思考一些方向和抽象功能模型、代码模型的时候最好有点思考的余地（如果业务较为简单除外）。

在单个模块的开发上，其实配合开发是最快的，Java的开发通常要么按照模块，一个人从前到后搞到底，要么是一个人与业务相关的处理，一个人处理交互，一个人处理数据，可能会有一些合并或更多复杂的情况，后面这种情况十分适合敏捷开发，因为相互配合，专注与自己的代码，可以让这层次代码风格统一，而且在编写过程中思路单一，如果几个人配合较好，一个普通的业务，花一点点的时间稍微商量下就可以快速开发出来，而一个人搞模块会不断切换思维做交互、业务、数据等方面的事情，因为每一项处理的思维方式和所使用到的技术手段都有所区别，并且各个模块之间的开发者有复用关系很难沟通到位，除非上面还有一个更高级别的程序员统一控制这个事情。

我说的开发方式似乎可以，不过也未必哈，这样开发的前提是这些人相互之间配合有一种默契，并且能力相当，还有一个更为重要的条件是大家对相关的业务也了解不错，如果要去完成一种新的复杂业务或核心代码的编写，这个是有一个强依赖关系的。在这个时候其它开发人员不希望强依赖，可以先基于接口或单独的方法返回一些常量用以代码运行，这个常量的对象格式可以预先预定，就像定义接口的输入输出那样，在核心代码开发OK后，就可以将接口的实现类动态接入了（刚开始就是写个default就可以）。写一层写久了开发人员也烦，觉得自己较为狭小，还得考虑他们的个人发展，从点和面上都要考虑下，不然他们没成长跑掉一个，新找来一个人这种默契配合是很难养成的。

快速开发平台，所谓平台最后会做成一个功能堆叠区，这种就是按照功能分的，什么人都可以上来开发，但是各种各样的诡异都会有，虽然依赖性可能不会那么强。功能没有抽象的话，说他是平台是好听的说法，不好听连产品也算不上，呵呵，因为没有明确的定位和方向，举个软件的例子，MySQL、Oracle它本身就是一款软件，它的目的很清楚就是为了数据库存储，它在为这个努力，不论有多少功能，你可以看他没有重复类似的东西，会让你感觉整体这个产品功能比较清晰，虽然很复杂。你要生产一个电脑也是这样，电脑也是一个产品，它里面的主板、CPU、内存各方面可以迭代升级，但是是有规划的，也是有清晰目标的，它也会开发周边插口，用以外部支持，就像10年前应该没啥USB口，后来USB大量使用，新的电脑都会有USB口，但是老的电脑不会去钻个孔去搞个USB扣，也不会在主板上面去焊一个线路去对接一个线路。外部的系统你可以来接入通信，不过满足通信规范，如果不满足，我可以生产一个转换口来转换，但是这个转换口绝对不是产品的发展主体，当这个转换口成为日常习惯，就会考虑将这个口子直接放在主板上。纵观JVM的许多发展集成越来越多的功能，版本升级也是类似的。

当然，当项目做和当产品做是完全不同的，行业产品也会跟着本地需求走，但如果被牵着鼻子走，就只是卖人力了。但是，很多未知领域其实并没有行业规范也不知道它会朝着什么方向去发展的时候，其实我们很难将它产品化，因为刚开始大家都不知道会把它做成什么样子，这个时候就必须要有“炮灰”，大家可能会根据自己的理解去尝试，可能有很多尝试最终有一个是被认可的，这就是一些新东西，这在很多互联网行业比较多。

至于异构系统的权限，这个其实和权限都没多少关系，只要是异构系统对接都会遇到问题，这就像俄罗斯方块的裂缝，和上面提到的产品类似，如果这些系统都是一家公司做的，这些方块可以有统一的规范接口，就不存在这样的问题（当然不排除一家公司内部也各搞各的，因为谁也不愿意去等谁做完再自己去做事情），如果是与别人对接要看你本身的地位，一般来讲是依赖对方的权限去接入（除非对方公司没有IT系统），你的产品如果定位足够明确，那么就应该有一套产品级别的权限控制，当然要足够灵活，满足行业需要，当去与别人对接的时候，其实就是生产转换口的过程。首先自己的权限要足够灵活除了配置化、层级化、继承性、个性化都要考虑外，还需要考虑权限的对象模型，通俗一点讲就是权限的属性和关系有那些，这些属性和关系要足以满足某个行业内灵活的权限架构，当这个抽象得足够好，对方的权限的管理的数据提取的时候，就是考虑如何将对方的模型转换为自己的模型，属性之间的映射关系，可以为它去专门写个适配器，将对象转换过来后转入自己的系统进行处理。

不过你要考虑到对方的数据可能不全或更多的情况，这两者都体现了你个人对于领域的理解和抽象是否灵活，如果做得足够好，如果对方数据不足以填充你的数据结构，要么是有默认值，要么就是降级服务达到目的（或者说它本身不需要，那么我不支持就好了）。如果它有更多的权限要求，就需要重新审该业务领域的视权限管理出现了一些新的变种如何灵活的融入到现有的产品中。

其实不论是权限还是其它数据都是类似的，中间的转换口是可以单独做单元测试的，只要转换口程序OK，产品是稳定的，就无需有几百人的叫唤式的大调试。不过我说得比较理想，现实往往会比较残酷，一般做软件外包的公司为了拿到项目刚开始什么都会愿意去做的，呵呵，扯得有点多，但是这个话题还没有真正展开，有很多是在做的过程中不断摸索出来的。

已在当当上购买，等待到货拜读大师力作。