2018工作总结

一. 成就和进步

回顾2018年的工作历程，主要成果与改进大致如下：
1) 为芬兰的安装系统做准备
2) 在安装期间提供support
3) HouseHolding 与Spliting的设计
4) 安装后的bug fix
5) Archive功能的设计
6) 第一次系统的性能优化（解决大数据量后执行SQL效率问题）
7) pull与Unpull逻辑的修改与设计
8) 配合Costing设计Demo系统
9) Delivery功能的实现
10) 第二次性能的优化（主要针对Transaction队列的优化，减少与DB的交互）
11) Archive功能的实现
12) 同步的优化
在这一年的改进和设计中，见证了Norstar从一个Demo系统到可以安装到生产系统上的软件，是一个质的改变，但是离真正的软件系统依然存在着不小的差距。

二. 学习到的技术和经验

2018上半年还是一个即将毕业的实习生，现在不知不觉已经在我们公司的开发岗位干了1年多了，在这期间受益匪浅：
最开始设计一个新的功能时，每次都是直接上手写代码，粗略看来完成新的功能的效率较快，实则不然，在以前这种做法下导致存在许多的Bug，而且写的代码都是写到哪再考虑下一步，这样造成了代码可读性也不是很高，代码逻辑混乱。后来在开会中提到的在开发时，先做需求文档和伪代码设计后，改善了不少，虽然看上去增加了完成的时间，但是从总体考虑对于一个功能和一个Bug实现作出分析后，然后将改进&设计写成文档后，再和大家一起讨论弥补自己设计考虑不周的地方或者有出处的地方进行调整，最后再写代码效率高上不少，减少了后续维护的不少麻烦。在刚开始的时候我每周最期待周四的Code View,在代码分享的例会上对于还是实习生的我能够学习到不少前辈们的设计思维方式以及代码的规范，记得最清楚的就是任总当时说的代码规范的三要素——代码块的注释、对参数的判断、异常处理，还有就是刘工对于代码的封装，实现的通用代码很多，这些都是初步我学习到的经验。
在对BPMS System代码逻辑进行梳理的过程中，整理了系统主要的框架模型：winform窗口、WCF服务、Configure配置、ServerDaemon以及各个机制的组成。在这些架构下，我学习到了一个最为核心的技术——线程，以前对于线程只是停留在线程和进程的概念上，但是通过对事件机制、Archive功能设计以及同步机制中体会到了线程能够发挥的作用是巨大的，但是当时我粗浅的理解一个单线程就是new Thread、start Thread、维护一个队列、doaction、停止线程；这样的线程能运行吗，当然能，但是这样的线程能在系统中运行时，你会发现当维护的队列数量较多的，cpu的消耗急剧上升，原因就是忽略了在线程工作的重要的一点——时间片，在多个线程同时工作的系统中，要时刻保证其他线程能够获得时间片去完成他要完成的指令和任务，还有一点在于不能一直保持这个线程的“活跃”状态，需要根据整体考虑线程的优先程度定义执行线程队列的时长。对于多线程，一直是让我后怕的一个地方，每次出问题大部分是由于多线程的地方导致的，例如之前的死锁，还有在多线程中对数据库进行即时的交互导致连接数的不稳定 ，其他线程无法连接到数据库的问题，而往往这种问题又是不好复现也不好从代码的逻辑性去梳理调试能够解决的，对于多线程就提现了系统中Log的重要性，从log中可以大致地分析出那一块出了问题，然后有针对性的去检查整体的逻辑，这点我在开发中还有待欠缺，Log的可读性以及完成性都不强还有待提高。
在维护Deno系统中，我学到了一个新的技术——Socket。之前我一直不理解软件与软件之间在没有API的情况下是怎样进行数据的交互的，后来在为Costing做Demo时发现期间Demo总是有些数据无法接收到，或者工作时间长后会stack，这些都影响了正常的Demo流程，通过对Socket的工作接收机制的认识以及在任总的帮助下，查询到了两个问题，一个是在python中开启了过多的socket造成了资源的浪费，还有一个是在接收时不是对每个byte单独new,而是统一采用的一个byte的使用，这样就在高速的接收过程中造成数据的缺失等问题。从Demo上引申到BPMS System，在于其他软件进行交互时也用到了TCPListener,接收触发机制也是这种原理，但是对于指令的传输、接收、和执行Command机制上理解还是不足，没有深刻理解其中的逻辑思路，这些都是我需要自主去学习的地方。
对于大数据的处理问题也是今年学习到的一个宝贵的经验。以前对于功能设计的思维模式是即时即用，系统的核心就是处理APT传输过来的piece状态变更，而在这个逻辑中我们涉及到需要查询数据和修改数据，涉及的表包括OrderJobPieces、OrderPiece、OrderTicket、OrderPieceCounting，而且这些表的数据量都是越来越庞大的，所以对于不论是直接查询数据库和直接当时执行对数据库的数据进行Update操作都是非常耗时的，这样导致在系统长期运行后效率急剧下降、Web无法及时响应等问题。第一次的优化中首先将Order信息加载到了内存中，当然维护内存中的Order List 是一个重要的问题，不仅如此，在内存中还储存了与Order相关的表，这样做的好处是我们在对数据进行Select的效率上会有很大的提升，需要注意的是要时刻保证内存中的数据的准确性，还有多个线程在访问的锁定。在组装好一个piece状态变更的SQLS后我们提交给专门执行 sql 的队列，在队列中同样也做了优化，将Transaction中的SQLS进行批量的组装，用以减少和数据库的交互，达到提升执行系统效率的目的。将数据库的数据放入内存固然可以提升访问速度，但是需要格外注意的就是内存的管理问题，在系统运行中，要时刻清理移除不必要的内存占有，比如长时间未使用到的Order和已经完成了的Order等，这些都要及时从内存中拿掉，不然在运行后会造成内存的疯涨，对于这块的核心是Transaction队列的执行效率，也就是向数据库写入数据这块需要不断优化，用以保证在系统高速运行中以及大数据量的处理中达到高效的目的，不然这块的效能如果不搞的话，那么数据库与内存的数据会长时间无法保持一致，并且遗留在系统内存中需要处理的信息会越来越多，造成系统崩溃。对于性能的优化以及大数据量的处理这点还需要继续向大家学习，希望吸收APT的宝贵经验，不断完善OrderTracker的性能。

三. 未来计划

Norstar的系统目前还只是初具雏形，未来还有很多地方需要完善的地方，力争向APT看起，在明年的规划中，主要包括：
1) OrderTracker性能的改进，状态变更的优化
2) Norstar整体功能分析，兼容用户管理与APT Web中的功能
3) 项目迁移2017后BPMS Archive的启用
4) 对于Norstar整体的Report Delivery的设计
5) GUID唯一Server连接的设计

四. 团队建议

在一年的工作中，衷心感谢大家对我的帮助，让我在工作中成长不少。同时，通过平时的工作，我觉得我们团队还需要：
1) 能够仿真模拟生产系统。即需要大数据库的支持和高速运行的生产测试，通过芬兰系统的安装，我看到很多问题是在大数据量和大的工作量的基础下产生的，然而这些问题在我们这边往往无法复现，所以我建议我们需要一个针对线上的一个仿真测试系统，这样我们甚至可以第一时间发现问题，从而得到解决
2) Code View和软件技能共享。通过之前的Code View能够学习更好的编程习惯，而且在分享的过程中也能够加固对代码逻辑的理解，同时也能通过大家的提问弥补代码的不足，并加以改进；对于自己负责的软件操作也可以拿出来演示，大家能够更好地理解这块的工作流程大致思路，为以后的设计提供新的方向

五. 缺陷不足

由于刚从学校出来，在平时的工作上还依然滞留这学校的工作方式，在这期间也感谢大家的包容和及时的提出，在以后的工作中，将努力改善这几点：
1) 思维方式的改变，对于系统而言，需要我去思考系统中还存在的问题并且及时加以优化和改进
2) 加强代码学习，对于问题难点认真加以思考，作出全面的调查，再和大家进行讨论，作出问题的方案
3) 加强责任心，对于软件的运行，时刻保持高度的关注，及时分析系统运行的log，查出存在的问题，予以改正
4) 对于细节方面的加强，软件更新交互的准确性需要注意