回复：我觉得mootools的写法比jQuery好

像邮件发送这样万年不变的代码没必要重新写，即使我重构了个程序，我也可以从原来的程序里把这些不需要重新写的代码复制过去。就像一代计算机升级，升级的是主板上的东西，而鼠标、显示器、键盘这些东西完全没必要改变。也许一个程序重构之后表明上根本看不到变化，但是性能，安全性，这些无法直接看见的东西全都提高了。修改和重构最大的区别就是要不要重新制定大纲，一个程序设计的大纲如果全是补丁最后整个逻辑都会乱套了。补丁可以有，但是多了就会完蛋。假如一个程序修改了10次，谁能把这10次修改的内容全部记住呢？或者说用文档记录下来，可是如果30次呢？每次修改程序，要看30个大纲的补充条款，要综合考虑那么多因素谁能有把握不和曾经的代码冲突？正常做一个项目三分之一的时间是制定大纲，六分之一时间在敲代码，剩下时间是在调试。程序做出来后一两个补丁可以有，多了就直接重构。火狐的版本号以前每次只加个小数，现在版本号一路狂飙有没有。其实重构程序和初次开发程序需要的开发成本小，因为有了上一次开发的“失败经验”后面无论怎么重构都是游刃有余。
程序开发没有什么“早知道”，只有完成后投入使用，以用户反馈的问题作为参考。什么都能“早知道”的只有神。

其实我们一般对项目的补丁修改可以上千上万次的，因为几个同事在进行，不断给完善系统，系统又生成分支项目，升级主干到升级分支，都有SVN或者GIT做控制，并且框架上有使用约定，写错了位置都运行不起来，真的不会乱。
看下drupal的项目，我们做一个drupal的项目至少使用到八十多个module做扩展功能，代码量可非常丰富了，都没觉得乱。drupal重构到现在已经7个版本，千多个开发人员，用了近十年的时间，你从零开始，什么时候达到drupal的规模？

是的，那你参考了什么？其实有大把的框架可以参考，你有注意过吗？你的结构是否可扩展？是否模块化？是否应对需求快速增长？那些学问可多了。对于项目来说，重构是在浪费成本，最好的状态应该是团队的每一分一秒都在为新需求写程序。
很多时候，你认为一些小功能小程序很容易弄，只管实现不管结构，但项目再小，需求还是会增长，小项目会积累成大项目，到时结构问题就越来越明显。

= = 我个人认为，你的思维更偏向于商业化。 我想， 很多时候，技术的快速发展也是重构的原因之一。此外， 资金神马的，也对项目的结构带来挺大的局限性。 另外 “对于项目来说，重构是在浪费成本，最好的状态应该是团队的每一分一秒都在为新需求写程序。”，其实多数时候，对项目进行重构也是为了更好的满足新需求的～

为新需求写程序当然是必要的，但是新程序如何融入旧系统呢？当然通常的程序很容易融入，比如扩展一个功能模块。这些操作是不难，但是到了核心部分总是会遇到瓶颈的，这时候就不得不重构程序了。就像一台电脑，发现内存不够了就加一条内存，这没什么问题。但是如果是从二代内存想换成三代内存呢？难道要换主板？当然是重新买一台电脑了。随着用户需求的增加，旧框架很难适应新程序。每当我们学会一个新技术的时候就会想，这种新技术要是用到旧程序中会如何呢？如果感觉很好，就在旧程序中引入新技术重构一次，像蛇那样蜕皮着成长。
小项目累积成大项目是没错，就像百度，最早只有贴吧、知道、等，简单的几个程序，这些只是小项目。现在百度的程序目录一个页面都排不下了，因此百度本省成为了一个大项目。从公司利益角度出发这种模式是非常可赞的，包括微软在内的许多大公司都是这样的模式。不过以我个人的信仰和价值观来衡量，至少我不会去做这样的事情。

让我来终结此贴 像java这种面向对象的语言 一样可以写出面向过程的代码
javascript是面向啥的语言

是的，我是从市场角度去考虑技术问题。但你觉得市场重要还是技术重要呢？其实技术也是因市场而生，市场没有了，技术就会被淘汰。就像baba与webos这两个系统。

OOP是一种思想，不一定有OOP的特征的语言，才能有OOP的结构。能用代码实现OOP的特征，也算是OOP。如果javascript原生是OOP，那就没有用mootools的必要了，因为mootools是实现OOP特征的。

重构肯定会消耗资源，我知道有时候重构是不可避免的，重构的量应该把握好。必竟重构是因为项目结构已经无法满足需求，直接地说是对你过去对项目的部署上的一种否定。如果你能早一点去关注结构问题，你不必花更多的时间去重构上。

这就是我们考虑问题的不同之处，在我眼中市场只是技术的附属品；而在你看来，技术只是市场的需求罢了。这些观点没有谁对谁错，但是世界观一旦不同，就很难达成共识。这帖可以结帖了。

我也觉得。。
请求吧主用静止蛙终结此贴

你的技术高到可以影响市场吗？如果不是，你也只有跟市场走。

博士就是博士啊,还是G博士想的周到...

+10086110086110086110086...