冗余,到底要不要冗余?
现今的软件业进展神速。各种新技术拚命抬头,各种应用与解决方案的设计不断涌现,各种Framework、各种Library、各种Component如雨后春笋,个顶个地瞧上去翠绿、清新、可口。软件开发工具也越来越智能、高效、快速。
有趣的是,大部分的东东在设计的时候都有一个共同的特性--高冗余度。
问题是,我们真的需要这么高的冗余度吗?
人脑的开发度也大约只有3-4%,不到5%,历害的人象什么老爱之类的也不过10%。剩下的都是冗余。
一个通用的开发包,偶最多只使用了25%的功能,不知各位老大们如何?
一个通用类型的东东在设计的时候的保障一定的冗余度也就是为了保障可伸缩性、可扩展性、可订制性、等等方面,不一而足。
可是我们又有多少人在做通用的东东呢?
照偶看来,偶们大多数应用都只是小应用,算不得多么宠大,纵观国产系统的广告词与系统说明,可接入性可移植性可扩展性可XX性有多好多好,真的拿到产品了一看,就乏善可陈了。现在的开发工具这么智能与高效,偶看还不如直接建立一个Code Library,然后立足应用、利用工具编修针对应用的代码。冗余度只保持在10%左右。至于什么扩展、升级、接口什么的,都是狗屁。能够做好Review就不错了。
说说看,有多少成熟的应用需要整天地去扩展/升级/订制呢?
敏捷软件的开发模式是可取的。国内,当然有大型的、极大型的应用是不能用这种轻量级的模式的。但,大多数人碰到的也大都是中/小/微型的应用。偶觉得象什么金X的财务系统乃至于什么(Xxx)RP,整个也只能算个中型的东东。最终用户真的需要整天扩展、订制、或者移植吗?狗屁。
放弃那种考虑周全的东东吧~~ 冗余度,要,,但是多不能超过10%。对于可要可不要的设计,干脆就不要。对于锦上添花的的东东,还是等锦先做出来再说罢。别搞成了破布添花了。
有趣的是,大部分的东东在设计的时候都有一个共同的特性--高冗余度。
问题是,我们真的需要这么高的冗余度吗?
人脑的开发度也大约只有3-4%,不到5%,历害的人象什么老爱之类的也不过10%。剩下的都是冗余。
一个通用的开发包,偶最多只使用了25%的功能,不知各位老大们如何?
一个通用类型的东东在设计的时候的保障一定的冗余度也就是为了保障可伸缩性、可扩展性、可订制性、等等方面,不一而足。
可是我们又有多少人在做通用的东东呢?
照偶看来,偶们大多数应用都只是小应用,算不得多么宠大,纵观国产系统的广告词与系统说明,可接入性可移植性可扩展性可XX性有多好多好,真的拿到产品了一看,就乏善可陈了。现在的开发工具这么智能与高效,偶看还不如直接建立一个Code Library,然后立足应用、利用工具编修针对应用的代码。冗余度只保持在10%左右。至于什么扩展、升级、接口什么的,都是狗屁。能够做好Review就不错了。
说说看,有多少成熟的应用需要整天地去扩展/升级/订制呢?
敏捷软件的开发模式是可取的。国内,当然有大型的、极大型的应用是不能用这种轻量级的模式的。但,大多数人碰到的也大都是中/小/微型的应用。偶觉得象什么金X的财务系统乃至于什么(Xxx)RP,整个也只能算个中型的东东。最终用户真的需要整天扩展、订制、或者移植吗?狗屁。
放弃那种考虑周全的东东吧~~ 冗余度,要,,但是多不能超过10%。对于可要可不要的设计,干脆就不要。对于锦上添花的的东东,还是等锦先做出来再说罢。别搞成了破布添花了。