最近被客户的要求折磨快受不了了，包括不断的需求变革，性能上的要求，易用性上的要求都很多，还有修改代码片断凌乱、可读性差的情况下来修改代码的痛苦，慢慢的开始思考，怎么样才能快速的满足客户的区，而做的代码的修改最小？ 怎么提高系统的可扩展性？怎么才能提高代码的可维护性？怎么样提高系统的性能？怎么样提高系统的健壮性可以使系统运行稳定一些？ 呵呵，这些东西我想也是现在很多软件科学家在研究的东西，可能比较大，不过我觉得适合自己的实用就好。
最近在在大力的研究这些方面，包括看了很多相关的书籍，有了点微薄的感悟和如果做好软件需要那些系统知识的方向。然后一点点点的实施，这里暂不讨论项目管理方面，一个软件的成功与一个好的项目管理方法分不开的，采用比较清晰的分层实现方式我想对于解决上面的问题是必备的，这里先讨论一层一层的讨论。在设计方面开始采用UML的系统分析设计方式，开发领域模型，快速的对系统的边界做一个规划，然后根据领域模型分析出类模型，形成一个类与类之间的关系网，这里说的网也就是领域方面的类库，她不涉及系统是用.net开发的还是JAVA开发的，也不涉及是开发的BS系统还是CS系统，这些领域类库是对这些都适用了，只有这个设计强大的领域类库才能保证后面的系统的可扩展性，健壮性，可维护性的成功建立，这个应该是基础。看了一下目前写得程序，大都是用户事件驱动每个事件一个功能，然后把代码写在一起，虽然有了点分层的做法，但是功能之间的领域类都是孤立的，存在大量的代码重复，而且耦合度非常高，代码链震很严重，所以这也照成了，可能仅仅一点点的用户需求变化，导致大量的修改，还牵扯出其他与之代码关联的功能错误，也给测试带来了难度。不过这样做的唯一一点好处可能就是开发速度比较快吧，对于新手比较容易入门，大家都比较熟悉这种模式，特别是在项目组内部，每个人完成自己的任务也不知道，自扫面前雪，没有在一个更高一点的层次来关注和其他人员在代码级的协作。这也许就是敏捷开发要解决的问题之一。
在抽象出来这些领域类之后，接下去就是要细化这个网了（这个步骤要考虑一些技术实现方法了，必然有些语言不支持多继承等），这个阶段设计模式是必备的，通过各种模式的应用修改成自己需要的模式来适应这个网，实现系统层次之间实现松散耦合，面向接口的编成又成为必然，这可能就是面向接口编成解决的问题之一，考虑系统地可扩展性在这里应该是占有比较很重要的一块。
当这个对象网编织完以后，也就是领域层设计做完了，那么对于用例的实现这块来说也就只考虑业务流程实现就可以了吧，这一层其实也不用涉及到界面的一些东东，就根据用例把业务流程通过建立的领域对象网走通就ok，这就是架构中的业务逻辑层做的事。
领域业务流程，和相应的支持对象建立完以后，这就要涉及很细的技术了，对于web开发，界面传的参数，重定向，使用哪个业务流程等，用这个层来做，也就是控制层。
最后根据系统界面的设计实现界面的展示工作，具体展示成什么样，要用到那些东西，让他直接和控制层交互就完了。不过对于一些简单的控制逻辑，可能直接采用调用业务流程中的方法的时候，我是不用这个方法，多加一层麻烦一些也把他分清楚些好。
对于上面说的，首先设计分层，然后每层保存相对的独立，系统的可维护性和需求变更使代码的修改和链震最小化在采用清晰的分层设计会有很大的提高。然后设计领域对象关系网，然后细化重构对象关系网，然后设计业务流程，然后设计界面和控制器层。这里没有说数据访问层，因为这个层对于面向对象系统设计来说应该是透明的，是比较孤立的，数据访问层比较复杂，简单的处理就是建立实体类和实体控制类，复杂的就是采用O/R maping工具实现，这个要根据具体的开发工具和开发模式的熟悉程度来定，.net的开发工具对于数据集的处理比较好，我们现在用的就是包装了数据库访问的实体类和实体控制类来实现这个层，JAVA的架构O/R的比较多，现在.net 中也可以不用数据集采用O/R maping工具来实现，这个速度比较慢，但是可以跟内存中的对象和关系数据库很好的分离。
了解了上面的东西，感觉自己需要学习的东西还比较多，如果做需求，用例的编写需要学习，设计上界面的设计、领域高层抽象模型的设计、数据库设计等还需要学习，以前都是基于word的设计所以要实现面向对象的设计还要学习，技术上的实现对象关系图的设计需要学习等等，:) 要学的东西太多了，大家一起努力吧。呵呵
这些都是我个人对软件开发的一点认识，如果有不合适的地方，欢迎指正。:)
最近在在大力的研究这些方面，包括看了很多相关的书籍，有了点微薄的感悟和如果做好软件需要那些系统知识的方向。然后一点点点的实施，这里暂不讨论项目管理方面，一个软件的成功与一个好的项目管理方法分不开的，采用比较清晰的分层实现方式我想对于解决上面的问题是必备的，这里先讨论一层一层的讨论。在设计方面开始采用UML的系统分析设计方式，开发领域模型，快速的对系统的边界做一个规划，然后根据领域模型分析出类模型，形成一个类与类之间的关系网，这里说的网也就是领域方面的类库，她不涉及系统是用.net开发的还是JAVA开发的，也不涉及是开发的BS系统还是CS系统，这些领域类库是对这些都适用了，只有这个设计强大的领域类库才能保证后面的系统的可扩展性，健壮性，可维护性的成功建立，这个应该是基础。看了一下目前写得程序，大都是用户事件驱动每个事件一个功能，然后把代码写在一起，虽然有了点分层的做法，但是功能之间的领域类都是孤立的，存在大量的代码重复，而且耦合度非常高，代码链震很严重，所以这也照成了，可能仅仅一点点的用户需求变化，导致大量的修改，还牵扯出其他与之代码关联的功能错误，也给测试带来了难度。不过这样做的唯一一点好处可能就是开发速度比较快吧，对于新手比较容易入门，大家都比较熟悉这种模式，特别是在项目组内部，每个人完成自己的任务也不知道，自扫面前雪，没有在一个更高一点的层次来关注和其他人员在代码级的协作。这也许就是敏捷开发要解决的问题之一。
在抽象出来这些领域类之后，接下去就是要细化这个网了（这个步骤要考虑一些技术实现方法了，必然有些语言不支持多继承等），这个阶段设计模式是必备的，通过各种模式的应用修改成自己需要的模式来适应这个网，实现系统层次之间实现松散耦合，面向接口的编成又成为必然，这可能就是面向接口编成解决的问题之一，考虑系统地可扩展性在这里应该是占有比较很重要的一块。
当这个对象网编织完以后，也就是领域层设计做完了，那么对于用例的实现这块来说也就只考虑业务流程实现就可以了吧，这一层其实也不用涉及到界面的一些东东，就根据用例把业务流程通过建立的领域对象网走通就ok，这就是架构中的业务逻辑层做的事。
领域业务流程，和相应的支持对象建立完以后，这就要涉及很细的技术了，对于web开发，界面传的参数，重定向，使用哪个业务流程等，用这个层来做，也就是控制层。
最后根据系统界面的设计实现界面的展示工作，具体展示成什么样，要用到那些东西，让他直接和控制层交互就完了。不过对于一些简单的控制逻辑，可能直接采用调用业务流程中的方法的时候，我是不用这个方法，多加一层麻烦一些也把他分清楚些好。
对于上面说的，首先设计分层，然后每层保存相对的独立，系统的可维护性和需求变更使代码的修改和链震最小化在采用清晰的分层设计会有很大的提高。然后设计领域对象关系网，然后细化重构对象关系网，然后设计业务流程，然后设计界面和控制器层。这里没有说数据访问层，因为这个层对于面向对象系统设计来说应该是透明的，是比较孤立的，数据访问层比较复杂，简单的处理就是建立实体类和实体控制类，复杂的就是采用O/R maping工具实现，这个要根据具体的开发工具和开发模式的熟悉程度来定，.net的开发工具对于数据集的处理比较好，我们现在用的就是包装了数据库访问的实体类和实体控制类来实现这个层，JAVA的架构O/R的比较多，现在.net 中也可以不用数据集采用O/R maping工具来实现，这个速度比较慢，但是可以跟内存中的对象和关系数据库很好的分离。
了解了上面的东西，感觉自己需要学习的东西还比较多，如果做需求，用例的编写需要学习，设计上界面的设计、领域高层抽象模型的设计、数据库设计等还需要学习，以前都是基于word的设计所以要实现面向对象的设计还要学习，技术上的实现对象关系图的设计需要学习等等，:) 要学的东西太多了，大家一起努力吧。呵呵
这些都是我个人对软件开发的一点认识，如果有不合适的地方，欢迎指正。:)
