今天无意间在CSDN中看到一篇“前端软件”相关文章，一下子又找不到了，感触还蛮深的。由于最近一年的时间内我几乎都是在从事这方面的工作，所以也写一下我段时间的一点点感受。
另外说明一下我对“前端软件”的理解：我的理解是跟产品用户最有直接关联部分的代码，如：用户事件处理、UI刷新等。因为这是所有项目中修改最为频繁的部分，不同客户有不同的功能需求和UI需求。
先说说一年前在刚离职的公司所做工作吧！（下文用A公司代替）
由于A公司一直使用的代码是大家公认的难维护、垃圾太多、毫无架构可言，后来公司成立一个小组重新搭建一套代码（ 称SDK code）。也就是在差不多一年前这套代码出炉，恰巧这个时间我被调到这个部门，开始了这套代码维护、开发工作……
刚开始接触时，就被一堆一堆的文档、一堆一堆的规则所要求，要这样做，不能那样做。一下子感觉对A公司的软件发展看到了新的希望，接下来就一切按规矩办事，有时还为没完全看明天软件架构而写出不完全符合这套代码要求的code而感觉愧疚。可接触一段时间后，才慢慢发现这套代码并不是完全按照所要求的规则及流程写的，经后续的维护工作带来诸多不变。比如：要求driver层与AP分开，而实际并非完全如此；要求AP与UI分开，而实际并非完全如此；还有存在较多不变于维护的全局变量等等……
在后续的一套UI开发过程中，越来越感觉到这套代码架构的不完善性。比如：我无法添加一套新的UI进去；或者我添加一套新的UI，需要去详细了解AP功能层的流程；无法存在多套UI；或者无法在多套UI下选择一个或几个进行编译；几乎所有AP功能模块都有用到系统的字串宏定义，这对多套UI的开发带来了很大麻烦，也就是要求所有UI都要有这些地方引用的字串，即使你这套UI完全不需要这些字串……
以上只是对这套软件的一个小小总结。接下来就是按需求修改软件架构，主要本着这样的原则：driver与AP完全独立；AP与UI完全独立；UI与操作完全独立；多套UI的可选择性；新添加功能对现有代码尽可能小的修改；后续维护工作尽可能将到最低。几个月的慢慢长路就这样开始了……
再说说刚工作三周的公司吧！（下文用B公司代替）
由于在B公司是做蓝牙模块，所以一开始接触RDA的软件（做过RDA的应该多少有点了解）。
第一周下来，勾起了我对A公司最早的代码的回忆。
软件的大框架看起非常合理，包括目录结构的建立，及Makefile的书写。目前我主要是对AP层的了解，各AP之间的独立性还算好，但AP内部就完全无规则可言了。如：全局变量一大堆，且到处调用；函数内部结构不合理；函数太长（几百行的大有人在）；UI与AP混在起。
第二周下来，让我对RDA的软件有点失望，准备修改其架构。
由于客户较多，目前我拿到的是一个客户一版code，其实除了功能需求和用户操作不太一样，其他都一样。这给我在维护上带来很大的麻烦，所以准备修改一下架构，让所有客户能其用一版code。
首先，研究一下Makefile，使用各个客户差异化的部分能独立开发编译，且不能相互有影响。这一步还算好，因为之前的Makefile有考虑这一点，改起来还算得心应手。
接下来，得研究一下系统各类消息的使用了，仔细看了一遍后感觉我快晕了。消息、事件、用户操作的key这向类混到一起，这一点是最至致命的，也将给后续的维护及架构修改带来很大麻烦。在这样的软件情况下，又有多家客户在使用中，进行running change的动作，实在是比较痛苦，经常两三天的努力，只修改了几个消息的处理流程，使各客户间相互独立。这一步实际为第三周的工作，路慢慢长也……
再者，得研究UI架构了，需要将UI中AP分开，这样才方便多个客户使用同一个AP。（这一步暂未进行，只是计划中）
此文仅为个人对之前工作的一点小总结，着重点皆在说明前端软件的架构及可维护性在整个项目中的重要性，并希望能给大家一些提示及启发，使大家在今后的编程生涯越来越轻松，越来越简单。
文笔有限，写得不好的地方望各位大虾多多指教。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！