2017年6月反思、半年工作反思

上半年的主要工作：

1、 企业定额平台的两版迭代工作。第一迭代，主要完善了企业定额的测算、形成定额库的解决方案；第二迭代，完成了配合企业成本工具的相关功能改造，主要包括模板设置、标准项目划分、主材指标、定额库与专业之间的关系。

2、 工程量清单数据管理平台的开发工作。此平台主要是基于工程量清单项目计量规范(2013-全统)进行web版的开发。用户可以在此基础上进行数据导入、加工。

3、 解耦智慧营造平台。因为平台重构、解耦是一个复杂而漫长的过程，所以智慧营造平台解耦分三个阶段进行。第一阶段，将信息价从智慧营造中拆分成独立的工程，与企业定额平台进行整合。并开发独立的API接口工程，以后对外的所有接口（现阶段主要考虑对成本工具）只有这一个出口。第二阶段，将智慧营造与工艺工法拆分。第三阶段，将智慧营造与标准体系拆分。截止6月底，信息价已经完成拆分。其他阶段还要在后续工作中，不间断的进行。

 

需要改进的地方：

1、 在企业定额平台开发过程中，对业务的理解不够熟练。

2、 重构、解耦，本来是在系统开发过程中逐步进行的事，但是恰恰相反，我们在开发中一味追求开发速度，并没有从整体上去考虑系统的可用性、扩展性、安全性、伸缩性。

 

反思：为什么重构解耦这么难？

好不夸张的讲，在解耦智慧营造平台的过程中，自己的脑袋仁都快炸了，真是扎心啊。我们团队自己都觉得，不可思议。这不是代码，是一团浆糊啊。无论相关的还是无关的业务逻辑、完全混在一个庞大的工程中，看是无关的业务逻辑，却总是有这藕断丝连的关系。剪不断、理还乱，不是离愁是耦合。

作为程序猿，本不该对重构有多大的抱怨之词。重构，是软件开发过程中必不可要的工作，贯穿于系统开发的每个阶段。也许在材价、造价GB等成熟的产品线，可用性是系统好坏的最重要指标。但是在我们组、或者类似产品孵化的组，面对这频繁变化的业务策略和产品需求，是不是应该更多的考虑扩展性？将扩展性作为最主要的指标，进行系统架构设计。引入已经被广泛应用的互联网技术来解决扩展性问题？

抱着传统的基于SSH的MVC架构，已经不能满足三天一小变、两周一大改的现状。可以引入maven3.x来构建系统，在架构设计阶段就当系统解耦；引入阿里开源的zookeeper dubobo来构架微服务系统，将基础数据、不同的业务进行服务化管理；引入MongoDB来进行日志管理，以便为后续的大数据处理做好铺垫……

身在研究院，不仅仅业务方面要关注前沿的信息，在研发体系，更要及时关注程序猿世界的最新动态，在研究院有着其他产品线无法比拟的优势，就是试错的机会。所以我们更应该紧跟行业动态，应用前沿的技术，不仅仅可以更好的为我们组、我们部门服务，如果有成熟的应用方案也可以输出到公司范围。