@
ql562482472 2. 我说的不是 all in code （代码） 而是 all in coding （写代码），是个动名词，我想表达的是（念着咒语祭起粗壮高大的巨型 IDE ，用久经产业考验的软工领域热爱的编程语言）来写（业务功能之外的、已有很多“进程外”基础设施组件的）（基础设施功能）代码这个行为。
3. 对于信息化岗位上的人没有技术能力或者没有技术意愿，甚至可能没有专门的信息化部门，只是归在综合管理办公室里的一个科员岗的“文科式”甲方信息化人员来说，可能不管技术细节的 turn key 工程是最好的。而我只是作为一个懂技术也想去考虑技术细节的苦逼又装逼的甲方信息化小主管，希望，乙方能有真正的能通盘做技术考虑的人跟我对应。而不是让 all in coding 蔓延。提到 fat jar 并不是说我认为 fat jar 不好，war 好，而是我遇到的太多阿猫阿狗做的技术“选择”（甚至可能并不是有意选择，而是师傅怎么带我的我就怎么做，网上的 tutorial 怎么写的我就怎么做）图省事，并不是像你说的经过了利弊分析思考的结果。
另外 1 ，如果乙方在文科式甲方只提功能要求的情况下交付了软件代码，要求甲方提供其他基础设施，当然是很扯鸡九蛋的，哪怕是 all in coding 的结果交付了也比这样做好；另外 2 ，在甲方有自己积累下来的 best practice 基础设施意向的情况下，应用交付也应该涵盖对甲方基础设施意向的适配。
再重复一遍，我不是说 fat jar 不好，而是我特喵的特氖氖的特烙烙的遇到的只会用 fat jar 的阿猫阿狗们实在是大概率让我想砍人。我宁肯自己累一点，作为甲方拔拔里的苦逼运维人员，自己来负责基础设施的调校，而不是看着写业务代码的阿猫阿狗们自以为是地重复造烂轮子实现各种非业务的基础设施功能各种不靠谱而我却眼睁睁无能为力。