ME项目总结
这是关于SAP ME模块的一个客制化开发的一个项目。是关于车间作业控制的管理的一个系统。我被抽调到项目组一直到现在，依然还没有开发完成。整个开发过程已经持续了半年多了。如果再算上我加入项目之前的事件，现在差不多有十个月的时间了。其中项目延期了两次。其中也暴露出一些问题，我在这个项目中也学到了许多。简单在这里做一个总结。
项目简介
项目采用Java和jsp开发，（虽然我是一个前端，但是当时部门项目太多实在没人抽调，才把我抽调过去）前后端不分离。同时包括了PC端和移动端，其中移动端依然是JSP做的。这也让我了解到了前后端分离不分离的区别。其中也包括了一部分的C端程序（主要用于打包线与磅秤交互），但是这一部分并没有参与。
项目管理
1、开发模式依然是比较自然的瀑布流。
虽然说是瀑布流的开发方式，但是却并不是按照一定顺序的进行各个功能点的开发。时常有比较靠后的功能点放在之前开发。而有一些需要依赖某个功能实现的东西却排在了依赖项之前来开发了，这就导致了很多内容开发完之后，会和前置的依赖项发生一些矛盾。同时由于没有依赖项功能，也会导致这一个功能开发进度缓慢，造数据会花费许多时间。
导致这种情况发生的原因，可能在于业务需求在确认的时候，前期业务需求没有确认下来。而使开发人员闲置下来。于是，就提前做了已经确认需求的靠后开发任务。但是实际上这个开发需求，由于前置的需求都没有确认下来的情况下必然是很有可能会有所遗漏的。于是，自然而然的开发顺序会不断的被打破。
解决思路上，我觉得一部分原因可以利用更换如快速原型等的开发方式来规避。比如梳理出整个简单的工序流程之后。在预留较为充分时间的第一阶段中，设计扩展性好、质量高的基础流程原型。同时在第一阶段当中，一旦需求确立，那么在一个冲刺段就不再接收新的需求（当然这也要视情况定，如果是需求在确立时就有重大缺陷还是需要纠正的）。这样就能使，开发的流程顺序有一个基本的保证。项目初期开发人员精力充沛时，保证原型的开发质量和高扩展性，程序后期可以修改的余地大。也就避免了一些问题的存在，即使在前期设计当中有一些业务沟通不到的地方。在第一阶段结束后交付原型产品之后，交由业务体验使用后也较容易暴露问题，可以即使更改。
2、文档管理是做的比较好的地方，但依然有可以进步的空间。
在这个项目当中，文档是做的比较好的一个部分。这也在于这次的开发当中，有一个专门用于项目管理的平台。所有的任务需求和开发任务都会在平台上进行统一管理。可能这样的平台对于其他公司来说已经属于基础设施之一。但是这也是我们所暂时欠缺的一个部分，其实也是可以考虑开发一个的。文档主要包括：需求文档，开发文档。缺点可能在于文档依然不算特别的规范，在开发过程中也无法完全依靠开发文档理解开发需求，依然需要业务配合。文档当中图例依然缺乏，需要继续丰富。
几个反思
a、 部门内部需要一个对整体项目把握的一个平台，这个平台其实可能也并不需要定制化开发。可能使用现有的一些付费使用的管理平台，或者直接使用gitlab进行项目管理也是可行的。
b、 规范化我们部门本身的文档管理，并在项目过程中对整个文档相关进行监控。我也真正的认识到了 ***软件等于程序加文档*** 这句话的重要性。良好的文档有助于后期开发的顺利进行，以及项目结束后的长期常规运维。
c、 在文档中认证程序是否符合规范的测试用例，应当也要在需求当中体现。同时尝试以测试驱动开发的方式。当然这一点应当更适用于前后端分离的开发模式。当后端开发的成果大多都以接口的方式呈现，那么我所有的测试场景都是对于每个接口而言了。
程序开发
项目是前后端不分离的，而这一点也使我非常的不熟悉。因为一开始是做移动端开发，之后又开始做web前端开发。所以在一开始对于整个项目当中的各个技术都十分的迷茫。后台的各种XML配置和Spring框架都并不了解，而在写前台页面的时候的JSP又和我对前端的认识十分的不同。所以整体上这个项目对于我来说是一个十分巨大的挑战了。
也因为上述种种，我在整个项目当中也遇到了许多的问题。
前后端不分离带来的挑战
前后端分离是一个老生常谈的话题了，而每个人都对此有着自己的看法。其实在大多数互联网公司这可能已经是一个可以盖棺定论的话题了。因为可能百分之九十的公司都已经采用前后端分离的方式在进行项目的开发。而对于其他公司来讲，前后端分离的问题主要在于是否有相应的人员进行开发。
我认为一个良好的前后端分离的开发模式绝对是有利于加快开发进度的，而进度上去了之后人员的需求自然就下降了。除非是对于一个非常小的项目，可能只是几个开发就能完成的项目采用不分离的开发模式可能会更快。
当然上面所谈到的一切都是基于一个良好的开发模式支持下的。前后端分离最主要的问题，我认为在于沟通成本上。如果能够较好的执行前期的接口约定的话，是完全可以两边并行开发的。
而特别针对ME项目来讲，前后端分离是否可行，他又能解决一些什么样的问题呢？
-
移动端开发的问题。
移动端开发天然应当是前后端分离的，而本来这次的项目当中一开始考虑在移动端时使用SAPUI5最为开发的框架的（但是据我观察，在生产计划模块另一个公司使用其开发的移动模块兼容性是很成问题的。同时，为了单独一个项目引入一个市面上使用量极少的技术是十分得不偿失的）。但是由于开发进度的问题，最后所有的移动页面全部改成了由Web页面来模拟。这就造成了很大一个问题，移动端的交互逻辑和web端完全不一致。同时，由web页面再修改成移动样式花费的工作量较大。直到现在，移动端的页面依然美观度欠缺。如果前后端逻辑分离开之后，我们完全可以采用已经成熟的UI框架来支持开发。界面统一，也不用担心交互方式的差异。甚至可以做完全响应式的页面同时适配多种设备。
-
页面显示逻辑也放在后台。
由于使用的是前后端不分离的开发方式，所以每一次的动作都会重新加载页面（本质上应该是发送了一个和之前提交的页面类似的新页面）。这就导致了，你无法很轻量级的将一些信息保留下来，以便之后使用。在实际开发当中，使用了大量的标志位标签来存储信息去控制前台的显示方式（比如批量完工功能）。
我认为这是十分愚蠢的一种做法。
第一、他增加了大量的工作量去为一个在前端做十分简单的操作去配置大量的文件。
比如，为了删除表格当中的一行。你需要配置一个新的动作，配置webconfig.xml,编写Commen类，并在接口类中新增一个函数，再在具体的实现类里面实现这个函数。最后在这个函数里面循环遍历每个字段的数组去删除其中对应子项。
第二、标志位过多，导致页面复杂度剧增，后期运维困难。
还是批量完工功能，由于信息无法轻量的保存下来，于是许多的标志位在页面加载时，被读取。但是这使得页面的显示逻辑复杂度增加迅速。你很难预测你的一个改动会遗漏哪一个标志位没有写，特别是你的一些操作顺序很可能会漏写某些标志位。而漏写就会导致你的页面不按照你本来的预计运行。比如突然弹出毫不相关的提示，等等。
第三、弹窗、下拉框等控件使用困难。
弹框下拉框等没有太大的复用性，基本上每次一旦有小的改动，就必须重写一个。同时，默认封装的搜索辅助框也是只能拿到当前输入框的值，如果需要多个值搜索就必须特别重写。而每次刷新页面都必须重新请求一遍数据，也使得用户体验下降。
奇怪的数据结构
其实我并不太清楚该如何描述这样的数据结构，针对多个对象类都有可以从前台自定义的自定义属性。就好像一般我们接触到的数据结构是横向扩展的，而这样一张表则是竖向扩展的。而这样的数据结构导致的问题就是：
1、数据量增加速度激增。
对于一些这样的自定义数据表。比如你在物料上自定义了十个相关的属性，然后你每新增一个物料这一张表就会扩增十条数据来存储你这一个对象类。也许仅仅从物料这种数据来看可能是没什么的。但是如果对象时车间作业控制号，以及库存标识这样的对象而言呢？如果每天的产量是一万件，那么每天这张表对于库存标识，车间作业号可能就是二十万条数据的增量。而这张表存储了多个数据的自定义数据，这样每个月的数据增量可想而知。当然这样的数量级可能对于大公司来讲是很稀松平常的事情，而对于我们一开始的预期可能就相差甚远了。现在这依然是一个很大的问题。
2、结构复杂报表取数困难。
这样的竖行的数据结构导致做报表以及一些功能的时候，当你需要某一个对象类的两个自定义属性，你就需要链接同一张表两次。但是当你需要展示一个有十个自定义属性的对象类时，你需要做的是链接这个表十次。当然当你连接了之后，你会发现这个表还是上面那个巨大增量的表。这很让人崩溃。
从现在事后诸葛亮的分析看来，造成这样一个问题主要在于以下几点原因：
1、并没有很好的利用好二次开发的优势。
这次选型的SAP ME模块，其一开始的定位主要是面向欧美国际上的工业作业控制管理。而并不具备很强的适应性。也正因此，其中的原生功能使用起来十分的复杂。同时本地化程度并不是很好。而项目中也因此决定大规模的开发客制化功能。可以说现在几乎所有的功能都是后期客制化过后的功能了。这也可能正是导致之前开发上的问题的一大原因。在原本程序设计当中就没有预想到这种大规模的二次开发的存在，于是从数据库的设计到程序设计都有一些别扭。
2、数据库结构设计缺少整体性。
在开发过程中，数据库结构基本上都是由各个功能模块负责的业务来设计的。而基本的结构表则是用的原生的表。而这样很明显的造成了一些问题，比如一些信息的冗余、以及模块间的交互规则。造成这一问题的原因在于项目管理上存在的问题，没有在一开始有一个比较明确的设计，大多都是走一步看一步(又或者则是没有很好地执行一开始定好的计划)。而另一个很重要的原因，则是同时为两家分子公司同时定制化开发ME系统，同时提供定制化服务还是两家供应商各自负责每一个分子公司的一部分。也就是说从最大的整体上划分也就有四部分之间需要协同。沟通成本巨大，精力分散。
总结
从技术角度上来看，这个项目至此绝对算不上是一个成功的项目。不过在这个项目当中也获得了很多项目上的经验。这一篇文章从开始写到结束的时间跨度也十分之久了，因此可能会有一些前言不搭后语的问题存在。
网友评论