设计杂谈

        在设计时会碰到两种类型的设计，一种是框架级产品的设计，一种是项目产品的设计，在面向这两种进行设计时觉得还是非常不同的，框架级产品的设计强调一种通用性的抽象上，在这点上通常依赖开发或设计经验来进行抽象，难度不仅在此，通常框架级产品的设计都会面对技术性的问题，也就是说在设计阶段根本就是无法进行细化的一些部分，这种现象在框架级产品中通常出现，这时在进行设计时就要慎重考虑，通常按照敏捷工程的方法的话是先进行spike，spike后再进行相应的设计；对于项目产品的设计强调的是对项目需求的实现，这个时候通常需要的是业务角度的抽象，当然，这点也是具有难度的，通常来说项目产品上不会出现太多的技术难度，也不希望出现。
其实想想，觉得这两种在设计上又是一样的，需要的都是业务的抽象能力以及技术的实现设计能力，对于框架级产品的设计来讲，业务的抽象能力即为软件行业的业务的抽象，而技术的实现设计能力在两者都是相同的，即当出现技术难点时都应选择先进行spike，spike后再进行相应的设计，否则做出来的设计是没什么意义的。
        现在经手了一个东西就是先经过设计，再进行开发的，典型的瀑布方式，设计要做的非常的细，觉得这种方式挺依赖系统设计师的，也真正的感觉到一次完整做设计的过程，应该说，这个时候会发现自己的很多不足，建议系统设计师都经历一个这样的过程，从架构到概要到详细，要详细到足够编码的程度，觉得挺容易出现矛盾的时候，因为象框架级的产品来讲最终的详细设计可能是经过N次抽象的具体实现的设计，如果真的想让其他的人仅凭文档就读懂，我觉得还是挺难的，同时由于框架级的产品通常会面临不少的技术难点，这个时候的设计就更是不好把握，因为会有一些风险点的出现，这个时候设计做的过细就显得不是那么得有意义，总体而言，我还是更喜欢先做初步设计，在实现过程不断重构最终形成设计的方式，觉得那样的过程非常的好，在这样的过程中详细、架构都是在不断的被重构，设计慢慢的就会变得非常的不错，不过这个要根据团队而定，只有实力较强的团队才可这么做，否则会出现无设计和不可控制的现象。
        还是信奉自己的一句话：“不要求高质量的实现代码，但要求高质量的测试代码”，我相信一个具有优秀习惯和掌握足够重构技巧、OO思想等的开发人员很容易就可以将不是高质量的实现代码变魔术般的变为高质量，但依赖于高质量的测试代码。