开发者应该多一点软件工程思想

软件工程这个东西，很多开发者感觉很虚，是一个虚无缥缈的东西，不太实际，还不如直接来点设计模式等直接。

但恰恰是这些很抽象的东西，构成了成熟稳定软件产品的基石。

最近的一个项目，与几个工作时间差不多年的开发者，一起合作开发一个项目，作为项目的组织者，初期完全按照自己的经验和意识，进行软件的需求分析和组织，项目成员也认可需求，并且同意一些需求与历史项目的不同造成的变更。

但是到了软件交付阶段，却发现完全不是自己需要的交付产物，功能只是在堆叠，根本没有组织和条理性，自己认为很简单的一个软件模型，也被搞的七零八落，后来我意识到了，这是由于缺少软件工程的指导，很多时候项目组成员只是在为完成功能而完成功能，没有任何模型转换。结果可想而知，交付产物迟迟交付不了，拆了东墙补起西墙，交付的产品也像学生的毕业设计一样，完全没有商业化软件应该具有的稳健、安全、通用性。

由于交付延期，项目组开发者被逼着加班赶项目，老板还认为项目组成员努力，在不停的加班，其实是工作效率低下，很多时候是在返工和修改bug,由于功能组织不严谨，又造成逻辑性的bug，基本上一个功能点是在反复被迭代修改。

如果项目组的开发者在开发自己的模块前，先停下来，把基本的功能接口定义出来，流程图活动图绘制出来，类图模型定义好，用例图组织好，就不会存在软件模块之间业务逻辑耦合度太高，拆了东墙补西墙，就不会流程不明确，只会堆砌功能点，而不知道业务组织，就不会出现，软件交付产品的用户体验差。

这真是一次比较惨痛的经历，这在几年的从业经历中是从来没遇到过的，即使在高节奏的项目中也是没有遇到过的，因为在以往的从业经历中，项目的组织一直遵照着标准的软件工程在执行一些项目，项目从开发到递交，中间返工很少，尤其是基于领域模型的模型构建，很多实际的需求，被转化成对应的行业领域知识模型，需求的递交和转化，完全是按照几方能理解的领域知识进行说明，最后一步的编码完全是模型的转化过程。

有时人都喜欢举着自己的大拳头，说明自己多么多么有能力，作为项目组织者，在进行项目人员组织时，尤其要小心这些举起大拳头者，他们往往没有足够的评估能力，盲目应承一些东西，后期又无法完成，反而抱怨项目需求的变更。