一周小结（你不要小看业务）

      工作依然在有条不紊的进行着，但是由于开发计划发生了一些变化，我们在本周多次加班来争取尽早完成当前的任务，及早的投入到下一个项目当中。本周我们的任务就是根据需求分析人员提供的需求分析说明书，创建Information模块的详细设计说明书，然后根据详细设计说明书，完成流程从创建开始到生命周期结束的编码工作。

     详细设计是软件生命过程中很重要的过程，软件质量的好坏就是由它所决定的。详细设计包含了数据库设计，界面设计等过程。界面设计是软件设计中尤为重要的部分，如果界面设计不符合客户的要求，即使程序的运行效率再高，软件的架构是多么好，系统是如何的灵活，那么这个软件产品也是垃圾。数据库设计的重要性是仅次于界面设计的，因为它关于到系统的灵活性。良好的数据库设计，不但能够减少程序的编码，还能够让程序更加灵活。

     界面设计一般都是由客户直接出来的，这个在设计上没有多大的难度。在美学上面，找专门的美工做些处理就可以了。而数据库设计则有很大的灵活性，一个系统中的一条业务，不同的软件师有不同的设计方案，虽然有多种途径可以实现我们想要的结果，但是如果按照数据库设计法则去设计，我们的编码工作量则会大大降低，而且又能够保证程序的灵活行。所以，为了保证程序的灵活性，应该将数据库设计的足够灵活。

     而数据库设计又来源于业务，所以软件的重要性应该规划到业务的重要性。但是业务通常很难引起程序员的认真对待，因为业务不像程序听起来那样晦涩难懂，很多程序员在对业务有了一知半解之后，就自认为理解业务，然后开始Code的编码工作。等到编码需要处理业务时，又对业务产生迷惑，这时才真正理解了业务的重要性。这时又反过头来重来认真看需求分析，重新分析业务需求。

     殊不知，业务需求直接关联到数据库设计，关联到系统的灵活性。如果业务理解的不到位，数据库设计可能就出现差错，相应的编码工作就是“豆腐渣工程”。如果重新正确理解了业务需求，就会出现两种结果：一是原有的基础上修改程序，使之兼容现有的业务。二是重新做数据库设计。第一种方法就会造成程序的灵活性降低，出现强耦合，系统模块的重用性和可移植性大大降低。第二种方法就要抛弃原有的程序，白白浪费原有的开发时间。无论采用哪种方法去弥补，耽误时间，影响系统的开发都是必然的。

     做应用软件开发，业务是最重要的。切记不要因为业务容易理解就小看了业务。