重复造轮子的话题

看了 《“山寨”框架3宗罪》 这篇贴有感。

关于是否应该重复造轮子的话题我觉得本身就是一个轮子，参与进来的不管是支持的也好反对的也好，在我看来倒是大都颇有兴致。
他们中有泼冷水放冷话的貌似已然站在某个技术制高点上口气颇为沧桑的“过来人”，也有充满理想就是不怕浇凉水的“技术小强”

据粗略的观察，“过来人”比较有力的一个观点是强调程序员应该怀着开放的心态，不要闭门造车。“技术小强”们的观点则主要是强调，实践是检验学习成果的最好办法。即使是一个写过某一不成功的 MVC 框架的人，对于流行的 MVC 框架的理解也往往比那些只是看过《XXX in action》，然后在某个公司级别项目里写过几个XML的人要深刻。

所以这些关于“闭门造车”的争论，其焦点并不在于该不该“造车”，而在于是不是应该“闭门”。 我觉得“闭门”是不对的，但是“造车”确是对程序员大大的有利。

于是我想起了小学课上讲的“小马过河”。对于“技术小强”们来说，别人的话随便他们说去，只要自己知道自己这次造轮子的目的就好。

另外，根据我不太仔细的观察，在JE上写 Java 的，造的轮子多半是 MVC, Dao ，由此看来MVC， ORM  是多么没有技术门槛的轮子，随便什么人就造了。不过话说回来，当初写 Hibernate 的那位仁兄，当初连 SQL 都不太熟就敢操刀，的确是颇有勇气的。现在看来，Hibernate 颇高的学习曲线是这个框架的败笔，毕竟复杂的框架方便的只是实现者，而不是使用者。这也从某些方面说明了一个框架的好坏。Hibernate 在学习曲线方面，无疑是不值得学习的。

 

“你确信需要吗？你真的确信需要吗？”
写一个框架不难，难得是写一个在高并发环境下经得起考验的，切实解决了某些开发不利方面问题的框架，框架切不可人云亦云，“别人也有咱们也做”，那种情况下几乎99%写的不如别人好，写一个框架是在充分透彻研究别人框架后才可行的，如今框架盛行是由于这么一个事实“没有任何一个框架能适应所有环境”，不断发现主流框架在现有环境中的“水土不服”点，才能给造一个框架提供非常充分的理由，换言之，框架如同文章，要有核心思想和目标。

自己真正动手写一个基础框架,
收益是很大的
事非经过不知难

同意这种观点，小学老师就教过，要想写好作文，就要平时多练习。

嗯，有时间，我也回去看你的框架的，希望你的介绍能更丰富一点

兄台看读库的 哈哈


确实是如此， 所以最BS那些几乎不写代码只画图的所谓架构师

不会编码 或 总也编不明白  ，由这些人来设计~~~~~ 我来实现。


苦命的说~~~~

对于抱着陈旧的技术，不动手研究新事物的专职架构师来说，只能是害人害己。专职的应该是业务分析人员，而不是系统架构人员。

大家老拿轮子打框架的比方，根本就是不对的。所以才有那么多争论。

先好好想想吧，框架是轮子吗？做框架是发明轮子吗？这个问题都没弄明白就别先辩来辩去了

http://baike.baidu.com/view/166497.htm

 

现在天儿热了，这是一个让人很凉快的观点，哈哈