讨论帖，关于系统开发方式和效率的问题

Question

系统的定位是大中型网站，两种开发方式
1.最原始的方式，系统不分层，动静不分离，表现在php、html、css、js都写一个文件里 到处是include、require，数据操作不封装或及其简陋的封装，每个数据操作都长串的写sql 等等
2.现在主流的开发方式，mvc、模板引擎、模块化
效率方面，第一种运行效率很高，第二种开发效率高第一种方式，系统没有多余的代码 在规模大的时候能体现出它的效率优势，能为服务器节省很多开支，但是缺点也特明显，这样的开发方式会让开发者痛不欲生，而且不是每个开发者都是全面手
第二种方式的优势就不多说了，虽然运行效率低了，但是完全可以从硬件方面来弥补当然看问题的角度非常多，上面只是我的观点，可能片面了，大家从多方面说说自己的看法以及选择吧，欢迎讨论~

Answer 1

楼主的考虑我认同, 虽然还没在公司里干过Web方面的工作，但我了解到自己公司里是没有用第三方框架的（不排除某些非推广产品的下载页面这种小需求可能负责的员工会用自己熟悉的框架快速实现），应该是因为公司文化的原因，比较相信员工的能力，而且的确进公司门槛挺高。但我知道，不是每个员工都是多面手，我前面坐的同事就是多面手，平时就自己建站，公司给的task它前后端全部自己写，没有框架可谈，就是爱好。 但不能指望php程序员都会html/css/js，所以前后端+产品之间的沟通很频繁，不过程序员一般没耐心叨叨。作为一个下属：先听领导说想怎么做，然后大家看看团队有没有这个执行力，你说用框架也不是每个人都会框架，但起码每个人都会PHP，结果得反馈给领导，一起再做个定夺。个人是没有参与过网站建设的，只是自己工作期间的耳闻与自己的想法。管理与团队最重要，性能永远是最后要考虑的，很少会因为单机硬件性能问题而困扰，架构合理这都不需要纳入考虑。

Answer 2

你的命题是“关于系统开发方式和效率的问题”，所以不涉及运行。
不应该将“运行效率”拿来对比，何况并不间的代码量少“运行效率”就高正因为代码不分层次的堆砌在一起给开发和维护带来很多不便
所以一开始就出现了函数和过程，为减小单个文件的大小出现了include
进一步，出现了对象和命名空间无论项目的大小，只要不是只有单一的功能，都应该尽量模块化每个数据操作都长串的写sql
不知是否针对大多框架的 ORM 而言
目前除 java + oracle 外，并不存在真正的 ORM。
对于关系型数据库 ORM 只是组装各个成分到长长的 SQL 串，的确有点画蛇添足
不过框架也是提供直接 query 的

Answer 3

举个例子，第一种方式echo一个hello world如果换成第二种，他要读取各种配置啊检查环境啊神马的，有些时候甚至会初始化整个系统，做很多没必要的工作，效率消耗在这些工作上面了

Answer 4

刚学习好初步的php时，接触了框架smarty，也做了小多个功能项目，但是运行速度是有些慢。但是后来进公司以后，看见一个完整的系统使用封装函数的方法，而没有用框架技术，运行的速度也确实很快。
后来慢慢从过程化语言 到 mvc 再到 函数封装，整个走了一圈。感觉混合使用的方法确实有其独到之处。原本以为现在很流行框架，一般公司都要用，结果才发现不起然啊。可能没有做过大项目的缘故。
个人偏向混合使用的整合，因为他只需要在用的着的地方include就可以了，而模板会加载整个页面内容，有时确实会造成资源浪费。
当然这只是初级的阶段，还有好多路要走。还是看自己的处境决定怎样熟练怎样来，当然领导的决定也很重要。

Answer 5

原始的开发方式也有模块化
比如你写个函数，include 一个文件

Answer 6

我一贯不赞同使用框架，但并不反对使用他
框架是应用程序的模板，如果你的项目恰好与某个框架一致，当然是使用那个框架要好多啦
至少你不需要再去书写管理、排错的代码了现在的一些框架也改进了不少，提供了“伪编译”功能。可以在调试完成后只抽取项目所需的功能代码，而脱离框架环境工作
有点像 vb、vfp 那样

Answer 7

都是用MVC开发的 下个项目3个月。

Answer 8

都写文章了...
不知最后怎又讨论成php框架了。= =我个人还是坚持推荐使用框架唉。我现在想想，可能我是退化了还是怎的了。
如果让我用传统的方式写我那系统，我都不知从哪下手好了。
最后写出来的话可能逻辑到处飞，调试问题得到处找，表现的数据到处取……
后期维护可能上下蛋都疼了。
那框架吧
没别的，条理清晰，应用自如。
至于效率，也就是前面多走了几步，这效率真的可以忽略。
不知版主为何不赞同使用框架?
如果熟悉掌握应用一套框架有什么不好呢

Answer 9

还是用MVC模式吧。这个效率差距几乎可以忽略

Answer 10

老大的意思呢是“我一贯不赞同使用框架，但并不反对使用他”
其实他一直反对的是那种框条吧，不知道现实世界里是怎样的一个人，这让我想起勇敢的心里最后的那句 Freedom!!!
想起来我还一度为这部片热泪满眶

Answer 11

可怜的是 百万千万级系统 可能php不能够挑大梁呀...

Answer 12

其实你希望的就是一个公司在成长过程中积累出来的框架, 只是一些通用的开发组件, 一个规范的开发规范或者说叫做框架, 这些通用组件可以大幅提高开发效率, 其实任何语言在一个公司里都是一样的... 都会有这样的库, 绝大多数时候员工是不得不用的, 因为已有代码都是那么写的, 得保证代码风格一致性, 不能自己再造轮子. 按道理说, 这些库都是足够安全和高效的, 尤其是Web开发这一块, 重复的东西太多了.

Answer 13

感觉版主还是比较反感使用框架的说。也并不觉得框架有约束了开发者的思维，或是有什么框条……。
觉得他是有一定程度上规范了开发的方向，条理更清晰，思路更明细，后期更好维护。如东城门走至西城门，框架的mvc方式就如一已知的路线，
走路的时候就去走路、搭车的时候就去搭车，看风景的时候就去看风景。
是有一个比较明确的方向。而传统那样就是你想怎么走就怎么走，有的时候去搭火车、有时候去坐飞机就随便了。
东门走到西门还好说，地图大点可能就有些散乱了，也许会走丢了或是迷路了或许会走错方向了。
但什么有得都必有失，懂得取舍得了，
也不能说从卧室走至厨房也画条路子走是吧。
总的来说应用框架说是很利于开发的,
推荐使用框架也不是推荐框架使用者硬背框架的使用方法，
现在大大小小的框架都数不胜数了，用也用不完，应该让使用者更好应用这种模式去开发。就目前经常使用与讨论的也就是楼主说到的两种方式，
版主是不是应该换个角度好点呢，而不是持不喜不厌的态度，
还是很希望有更多人参与进来，以后有更好的模式出现，
而不是只走传统的路子。

Answer 14

我最喜欢看讨论帖了....哈哈哈
因为可以瞎说.....哈哈哈我觉得吧,楼主说的第一种情况是不存在的......"最原始的方式，系统不分层，动静不分离，表现在php、html、css、js都写一个文件里 到处是include、require，数据操作不封装或及其简陋的封装，每个数据操作都长串的写sql 等等"可能吗? 
"最原始的方式，系统不分层"
"php、html、css、js都写一个文件里"
"到处是include、require"
"数据操作不封装"
.....
这样可能开发成一个软件吗? 尤其是"大中型网站"?!这样的写法,只能写个小script吧,做点一次性或偶尔的处理还差不多,就像我们有时候用shell写的那些小东西....能找到一个我们能看见的软件符合上面的精神吗?----------------------------------------也许换个问法比较好:一个软件,究竟原始到何种程度你认为它是"原始"的?
又如何就算是第二种形式的?

Answer 15

如果你有耐心, 可以针对不同的应用做个可编译的高效率框架
如果偷懒就用现成的框架,虽然有70%的程序运行效率损失, 但开发速度快小功能还是自己写写native代码吧作为一个php程序员, 必须有1-2个拿手并精通的框架

Answer 16

面向过程的编程确实会造成代码冗余，虽然部分的可以拿来include or require，但是还是会有较多的代码冗余。而相对来说，面向对象会好很多，程序几乎全部函数封装起来，使用的时候直接拿来使用，方便简洁。以后的编程也可以直接使用拿来主义政策。
框架这东西也挺好，你可以避免很多不必要编辑的代码，可以直接使用。不过相对于小型网站有点大材小用了，挺赞同楼上一位朋友的看法的——大型网站用框架，小型网站没必要。

Answer 17

此回贴甚得我心 :) 嘿嘿只要你在不断完善优化你的程序,你必然在向第二种方式前进....当然你可能选择不同的方式, 你可以不MVC,可以不模板,可以不OO,但是你不可能追求原始....

Answer 18

   我目前的项目开发周期20个月，使用SSH，多人开发。不知道算不算大项目（100K行以上），一想到10k～100k行的代码不用框架会乱成什么样子，或者能否开发成也是个问题！
   使用第一种方式的人很明显没有做过维护！如果你维护了，你会恨死前面那个写代码的，并且从此以后你再也不会用这种方式！！！