Richie

Sometimes at night when I look up at the stars, and see the whole sky just laid out there, don't you think I ain't remembering it all. I still got dreams like anybody else, and ever so often, I am thinking about how things might of been. And then, all of a sudden, I'm forty, fifty, sixty years old, you know?

对最近讨论的看法

最近的讨论比较激烈,我看来其实主要思想偏向有两种,一种是学院式的研究探讨,另一种声音是希望讨论能更偏重于如何进行实际运用。
我的观点是支持后面一种。

例如book.Save()到底是否面向对象,用法是否优雅;例如面向对象是否一定要使用泛型,什么才叫面向对象。基于这个话题至少已经不下十几篇帖子,上千的回复争论。我觉得无论大家得出个什么结论对我而言没有任何价值,因为它对我这么多年来产品开发、项目实施、团队开发模式面临的困扰没有任何实际意义。是没有银弹,但总得找到有点力量的东西来解决问题。
就如同生活,一定是有了面包,再谈精神建设。对于软件思想、开发模式,大家先探讨好如何运用、实践,解决现实中的难题,再来讨论这种思想的好处、本质、某些场景如何有特色的运用、改进,这样才符合发展规律。无法针对实际问题说话,最终就是柏拉图式的空想。现在软件业的进步速度已经飞快,也许会成为软件技术历史中的一个跃进时期,副作用是心态浮躁,大家是愿意成为这一波发展里面的受益者还是他人的垫脚石?
所以我的观点是多脚踏实地,针对现实开发过程中的疑难困惑来谈这些思想怎样运用。
也许某一个时候实践的结果是面向对象+过程式的开发能很好的达到目的,过了一段时间你会觉得那些过程式的代码是错误的;也许某时你觉得自己很好的使用面向对象开发了一个项目,经历一阵之后发现那个设计是愚昧的,不正确的面向对象理解造成软件越来越难维护,这时你才发现你对面向对象理解深入了一些,或者在那样的开发环境下根本不应该使用面向对象思想。基于这样一些经历,针对大家的很多实际运用状况去谈论是否该面向对象,某些场景下如何运用继承多态,这种情况下,不管声明自己的观点还是反对意见,都是有支撑的,对自己和对他人都是最有意义的,这就是探讨。
没有任何支撑肯定是陷入空谈,咬文嚼字的口水战,因为以后很可能自己都会否定这些想法,这样的观点、想法拿什么说服人家,跟人家形成探讨?

一种技术思想,先是入门,了解该怎么用;然后是实践、思考,掌握怎么用;接下来是反思,什么状况环境下可用,如何灵活运用;最后是融合,你可以在前面的过程中迭代,更进一步掌握它的本质,思考它的改进,将其它思想与它融合起来思考,运用。目前博客园的这种讨论,我是看不清应该对应到那种层次。

设计的范畴不止技术框架的设计,也包括业务设计等其它各方面,否则软件产品是什么。不针对实际运用场景空谈技术思想,很容易造成技术人员成为一个理想的技术主义者。这里一些典型的表现是什么呢,技术人员严重的抵触需求、需求变更;管理人员一味的认为技术是解决一切的本源,现在产品不好只是因为技术运用不好,没做灵活,一想到要改进产品,就想到这个框架是不是得改一改,是不是得使用另外一种技术实现。
从开发模式的发展也可以看到,瀑布模型到迭代模型,现在的敏捷呢,配对之间从需求开始一路包办,小范围内不断迭代,技术人员别再期望不管需求了。
领域驱动思想呢,不也是从需求到开发一线串起来吗。领域驱动那本书,前面几章就已经把领域驱动思想讲明白了,后面为什么还要那么多章节的啰嗦,就是为了指导团队运用过程中各种各样可能遇到的困惑之处。
看Martin Folwer,设计模式到解析Eclipse、企业应用架构、分析模式等,层次也是感觉越来越具体化。

整个大环境趋向于针对于具体实际问题,把各种上下文紧密结合起来运用,而这里却感觉要将剥离上下文的空洞讨论进行到底。

最近又谈起了Java开源社区。
Java资历老,项目多,巨型的微型的,成功地失败的,各行各业各方各面,有这么多基础,社区里面充斥各种思想和讨论很正常;讨论交流的主题有侧重于实际运用的,有谈思想的,这也很正常。大量实践的结果必然是思想的碰撞和演化。
对于Java社区大量的开源项目,我的观点是,那些基本都是汇集众家之长、无数项目经验的结果,所以请大家用尊重、认真的态度去对待,哪怕它不是适合于.Net的最好解决方案,因为越用认真地态度去对待,你理解、学到的也越多。马克思著写自己的理论,还认真的研究、对待古希腊哲学、德国古典哲学,虽然这些并不一定是真理,但马克思得到了自己的理论。
.Net年轻,把开源项目搬过来,这是站在巨人肩膀上让自己发展更快,恐怕有人根本没有理解消化那些开源里面的思想、经验,就对它说不。谁要是把它们全都研究透了,然后大谈特谈它们的优点缺点,.Net里面应该用什么方案,这样的文章我会很乐意、很仔细的看。

.Net缺的就是Java那样大量的项目应用,所以微软ERP一买就是4套,早时财务也想买但没买成,MBS大力进军企业应用市场。微软的产品里也有不少东西借鉴开源社区中的做法,自己申请开源协议也是希望跟开源社区走的更近,采用合作而不是对立的方式。这是很好的做法,非常有利于.Net平台相关东西的实用性、完善发展。
当然,现在.Net社区里面很多思想也在影响Java社区的思考和发展方向;以后肯定会有.Net开源、.Net解决方案往Java实现上搬,但现在还不成熟。只因为学了用了.Net几年就一味的认为.Net已经足够强大,这是不切实际的想法。.Net很多技术、思想需要大量的项目运用,才能证明它的好与坏优与劣。

最后说一句,根基不牢,上层越庞大就越危险。当然,我认为的根基是大量的实践探索,而上层是各种思想的理解、探讨、挖掘。当然,如果大家在这两方面都掌握了,再来讨论哪个是根基的问题,这就确实是鸡生蛋还是蛋生鸡的问题。
从另外一个视角来看,摔过跟头获得的经验是更深刻的,所以莫大的错误也许正意味着莫大进步的开始。错的也好对的也好,实践过才知道,不实践永远不知道。只怕大家这样谈过之后发现根本用不起来这些东西,或者根本不去用。所以讨论空洞也好,实际也好,能够激起一大批人去实践,那效果也是很大的。即使造就很多眼高手低的人,毕竟一将功成万骨枯,我没必要否定。孰是孰非,you are the boss,你说了算。

posted on 2007-09-26 23:50  riccc  阅读(2863)  评论(42编辑  收藏  举报

导航