我的软件开发方法论1：假设-验证-结果-修正_假设验证再修正方法有哪些

背景

小刘刚从学校毕业出来两年的新人。学校是个没啥名气的大专院校。专业对口，学的是软件技术。面善心软，不善外交工作，说实话，擅长外交工作的，都跑去做销售去了，有几个愿意呆在后端Java开发的岗位？

这个社会，对于新人，总是报以最大的善意。但是对于刚出校门没多久的人来讲，最怕的是让别人看出自己的短板。对于领导安排的任务，总是自己去想办法去完成，毕竟，领导经常挂在嘴上的一句话是，公司请你来是来工作的，不是来学习的。要是抱着学习的心态来的，趁早滚蛋！

领导的话，让小刘这个乡下孩子充满了压力和斗志。

这不，这天领导安排了个小活，让小刘去实现如何根据配置文件自动生成不同的jar包的功能。

小刘立马接过了这活，然后按照“假设-验证-结果-修正”这套吭哧吭哧造起来。

假设-验证-结果-修正

这个方法是一种演绎法（感兴趣的可以搜索下戴明环）。不断的用实验步骤去修订路线，以达到自己的目标。

假设

-要实现这个功能，那么就是假设在使用maven打包的时候，可以动态的根据内容去变更（拼接）包名。假设这个结论是成立的，那么接下来就是需要去验证其可行性。

所有的理论都是先建立在假设成立的基础之上的。

小刘想了下，根据动态编译原理，理论上这个是没有问题的。 那么接下来就干吧！

验证

-实践出真知。绝知此事要躬行

小刘看了下对应的代码，然后网上找了下度娘，看了下别人的操作方式。

然后对照自己的项目代码，然后就吭哧吭哧造了起来。

小刘按照自己的思路，分了以下几步：

1、搭建实验环境：先搭建一个新的脚手架项目（和原来的项目相似）

2、查看实验结果：按照网上的步骤，一步步的修改。然后编译，看是不是会编译成不同名字的包。

3、- 结果正确，该实验结果使用到项目中的话，有哪些需要进行调整和修改的。是否还有更优解，更优解的话要怎么处理，步骤怎样？

4、实验结果代入：然后把对应的实验结果步骤，平移到现有开发项目中来，再打包编译。

结果

-小刘把项目编译之后，结果确实可以实现根据不同的编译环境打造不同名字的jar包。

但是该jar包的名字都会带环境名字，有的时候不需要后缀名的也带上了，这个时候需要对结果进行对应的修改。同时生成的时候也不是很方便，需要手动去调整。虽然实现了功能，但是在性能上和操作上还有调整的空间。

修正

- 结果正确，该实验结果使用到项目中的话，有哪些需要进行调整和修改的。是否还有更优解，更优解的话要怎么处理，步骤怎样？

结语

按照这个思路，小刘很好的解决了领导安排的技术任务，同时小刘也反思了下，其实工作和生活中还是有很多可以用这个模式来解决的。正在阅读的你，想到哪些可以用这个了吗？