方案优于编程，设计优于编码，不经过实践不能真正的理解他的含义。
上一次写方案是license模块，由于当时不清楚程序具体什么走，非常急于写代码，详细设计文档也是改了很久。最后编码的整体效率和质量都不高。还没哟站到一定的高度去看到模块的划分。
这次又开始写方案了，时间很紧，只有一天，但内容也不多，结果还是预料中的，小组长只是想看考察和锻炼我的设计能力。
没能得到组长的认可，压力可想大大的，这不今天早上很早就醒了，6.45.
并且没起来就清楚的想出了昨天的设计方案-（针对网管系统新需求--信令软采）的实现思路。
此时，我才真正理解设计方案的重要性及编码其实真的不是最重要的。
说起昨天的设计方案，真的很惭愧，方案内容不完整，主要原因是经验积累不够，其实基本上都有描述，比如对告警的内容走告警流程，但不是很细，既然走告警流程，那么这个告警编号有吗？没有的话需要加到告警知识库中。
下午的电话会议小组长一个人和北京确认下关键的问题，我和另外一个同事补充了些有疑问的问题。
回来后我把会议纪要整理发到北京的同事那边，并对有疑问的问题进行了求证。方案基本在大脑中有了定型，该怎么去做都有了眉目。
今天早上想起的方案包括以下几点：
1，界面的设计（添加菜单，左树右表的方式显示，左树显示根元素，右表显示软采任务）
2，任务的管理（任务的新建，任务的暂停，任务的修改，任务的删除）
任务新建和任务修改的界面图昨天按照新的方案已经进行了修改和更新
剩下的就是任务的新建，任务的暂停，任务的修改，任务的删除都需要走配置变更流程，这个流程是原来已有的，调用的话不会出现什么问题的。
3，接口的设计 界面发起操作，需要通过ejb接口调用服务的服务，然后再调用配置变更进行处理。