又是一盘面条啊

By 小明 at 2015-10-08 • 0人收藏 • 5310人看过

看了一眼index.php的代码,真是一种不能忍受的coding风格

31 个回复 | 最后更新于 2015-10-12
2015-10-08   #1

风格我觉得看个人喜好吧。

<?php    
require(__DIR__ . '/common.php');    
require(__DIR__ . '/language/' . ForumLanguage . '/home.php');    
$Page      = intval(Request('Get', 'page'));    
$TotalPage = ceil($Config['NumTopics'] / $Config['TopicsPerPage']);    
if ($Page < 0 || $Page == 1) {    
	header('location: ' . $Config['WebsitePath'] . '/');    
	exit;    
}    
if ($Page > $TotalPage) {    
	header('location: ' . $Config['WebsitePath'] . '/page/' . $TotalPage);    
	exit;    
}    
if ($Page == 0)    
	$Page = 1;    
$TopicsArray = array();    
if ($MCache && $Page == 1) {    
	$TopicsArray = $MCache->get(MemCachePrefix . 'Homepage');    
}    
if (!$TopicsArray) {    
	if ($Page <= 10) {    
		$TopicsArray = $DB->query('SELECT `ID`, `Topic`, `Tags`, `UserID`, `UserName`, `LastName`, `LastTime`, `Replies`     
			FROM ' . $Prefix . 'topics force index(LastTime)     
			WHERE IsDel=0     
			ORDER BY LastTime DESC     
			LIMIT ' . ($Page - 1) * $Config['TopicsPerPage'] . ',' . $Config['TopicsPerPage']);    
		if ($MCache && $Page == 1) {    
			$MCache->set(MemCachePrefix . 'Homepage', $TopicsArray, 600);    
		}    
	} else {    
		$TopicsArray = $DB->query('SELECT `ID`, `Topic`, `Tags`, `UserID`, `UserName`, `LastName`, `LastTime`, `Replies`     
			FROM ' . $Prefix . 'topics force index(LastTime)     
			WHERE LastTime<=(SELECT LastTime     
					FROM ' . $Prefix . 'topics force index(LastTime)     
					WHERE IsDel=0     
					ORDER BY LastTime DESC     
					LIMIT ' . ($Page - 1) * $Config['TopicsPerPage'] . ',1)     
				and IsDel=0     
			ORDER BY LastTime DESC     
			LIMIT ' . $Config['TopicsPerPage']);    
	}    
}    
$DB->CloseConnection();    
$PageTitle = $Page > 1 ? ' Page' . $Page . '-' : '';    
$PageTitle .= $Config['SiteName'];    
$PageMetaDesc = htmlspecialchars(mb_substr($Config['SiteDesc'], 0, 150, 'utf-8'));    
$ContentFile  = $TemplatePath . 'home.php';    
include($TemplatePath . 'layout.php');

https://github.com/lincanbin/Carbon-Forum/blob/master/index.php

index.php这几十行代码我觉得并没有什么问题,这里面甚至主要还是SQL,易读也易懂,没感觉出有什么不好的地方了。

2015-10-08   #2

回复#1 @lincanbin :

20150507151330042.png

sdfdfdf

2015-10-09   #3

回复#1 @lincanbin :

你真的觉得自己的代码易读易懂?


真的易读易懂是   

别人不用通读你的代码,也知道你的代码是干嘛的。


如果index.php上来就拼sql的代码也叫没有问题,那世界上就没有垃圾代码了。

不晓得你coding时间多久啊,可以告诉你,过一阵子你就会憎恨自己现在写的代码的。

2015-10-09   #4

回复#3 @小明 :

我知道你想说用ORM,几年前我就用ORM。 但是ORM的抽象能力是有限的,在需要分页优化的复杂SQL情况下,你的ORM实现后也不见得能看。

并且简单的SQL本身也非常易读,不易出错,ORM化后反而失去了这个优点。


原来版本:

$TopicsArray = $DB->query('
SELECT `ID`, `Topic`, `Tags`, `UserID`, `UserName`, `LastName`, `LastTime`, `Replies`     
    FROM ' . $Prefix . 'topics force index(LastTime)     
    WHERE IsDel=0     
    ORDER BY LastTime DESC     
    LIMIT ' . ($Page - 1) * $Config['TopicsPerPage'] . ',' . $Config['TopicsPerPage']);


这是你十分推崇的ORM写法:

$topics = new Topics();
$topics->show(
    array(
        'ID', 
        'Topic', 
        'Tags', 
        'UserID', 
        'UserName', 
        'LastName', 
        'LastTime', 
        'Replies'
    )
);
$topics->find(
    array(
        'IsDel' => 0
    )
);
$topics->sortBy(function($topics){
    return $topics->LastTime ;
});
$topics->limit(
    ($Page - 1) * $Config['TopicsPerPage'], 
    $Config['TopicsPerPage'])
);
$TopicsArray = $topics->getAll();

这还只是最简单的SQL,如果是我第二条为了分页性能优化的SQL,ORM化后会如何呢?

可想而知,第二条SQL ORM后写个50行不是问题。这种ORM就属于垃圾代码了,又臭又长,你通读一遍可能都忘了前面是什么了。不通读更是什么都不懂。


我知道有很多人学框架里的傻瓜工具,学到SQL都不会了,这种情况下其实就是ORM化了他们也看不懂。

2015-10-09   #5

回复#3 @小明 :

你自己问问自己,说不要直接拼SQL,那么:

ORM除了把select,from等sql关键字和符号换成类的方法名外,跟SQL有区别吗?

如果这些SQL都看不懂,那实在也不可思议。


SQL是一门精心设计的声明性高级语言,已经被广泛使用接近30年,热度一直也没有下去,还不至于像你说的这样不堪。

2015-10-09   #6

回复#5 @lincanbin :

不可思议

2015-10-09   #7

回复#6 @小明 :

我也想问问你对于分页优化的一句SQL语句,写成50行ORM有什么看法?

2015-10-09   #8

回复#7 @lincanbin :

别扯啥orm,咱说的是基本的分层和封装

2015-10-09   #9

回复#8 @小明 :

blob.png

不能直接拼SQL不是你的看法吗?

如果不拼SQL,那也就是ORM了不是么?

2015-10-09   #10

回复#9 @lincanbin :

这理解能力,也难怪代码写的跟面条一样。

2015-10-09   #11

回复#8 @小明 :

如果你说的是MVC,那也是经典架构,在Java中非常流行。

可是PHP的设计有所不同,文件本身就可以充当Controller,这是解释器中实现的,Rewrite更是可以非常好地实现Controller,也算一种另类的MVC实现。

根据PHP 之父 Rasmus Lerdorf 的看法:

Q:这种规画网站的方式,什麽是最重要的关键?

A:关键是你必须建立分离、模组化的独立端点,而不是全部放在同一个大篮子裡。大多数现今MVC架构(MVC framework)的开发框架(Framework),使用所谓的前端控制器(Front Control),每一次浏览器提出Request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义都没有。


在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充性来自架构,很多开发框架,将所有事情绑在一起,限制了架构。选错开发框架,你就没有扩充性。


Q:你是说MVC模式不利于网站扩充性?

A:MVC模式比较适合用在网页控制器(Page Control)的层次。基本上,每一个网页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一个端点使用MVC模式来打造小型的网页控制器,是不会有问题。但是,大多数採用MVC模式的框架,预设在网站中採用前端控制器,而非用网页控制器的方式,这样的MVC模式,只适合在小型或单一伺服器的网站。


Q:你会如何选择开发框架呢?

A:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。


Q:难道开发者不需要框架或架构吗?

A:网站的确需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!


用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除Runtime检查、拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介于两者之间。

2015-10-09   #12

回复#10 @小明 :

不妨展示一下你的代码让我看看?

2015-10-09   #13

回复#12 @lincanbin :

之前的代码版权不归我所有,这里倒是没有办法展示。

我本身对基于标签组织的社区感兴趣,我会抽时间在这个系统上重构一版或衍生一个新的分支的。

2015-10-09   #14

回复#13 @小明 :

我是来留名的

2015-10-10   #15

火钳刘明~~~~~~~~~~~

2015-10-10   #16

小明 挺可爱的


不辩不明


2015-10-10   #17

回复#16 @twor2 :

我不懂,说说观点,关键是这个代码排布,要是感觉不对,也列出一个感觉对的例子来分析分析呀,也不说的例子就说不好,哪知道说的什么,不利于进步

2015-10-10   #18
作为一个小白,作者的代码我真能看懂一些,但对于另外一种orm,我完全看不懂了
2015-10-10   #19

1、我说代码有问题,是缺少封装和重用,各种过程式的代码书写对后续的维护并无多大好处,举一个简单的栗子,就那个取TopicsArray,其他地方如果调用的话,难道你再copy一遍你的代码吗?



2、我有点无语了

如果你说的是MVC,那也是经典架构,在Java中非常流行。

对于这个我只想说,php中也非常流行,让代码结构清晰好维护


3、至于orm

我知道你想说用ORM,几年前我就用ORM。

这个真的是你自己的臆想

并且我想说,orm的实现看水平了,我不想多说。


4、请不要断章取义,请看作者想要表达的是什么吧

Q:这种规画网站的方式,什麽是最重要的关键?

A:关键是你必须建立分离、模组化的独立端点,而不是全部放 在同一个大篮子裡。大多数现今MVC架构(MVC framework)的开发框架(Framework),使用所谓的前端控制器(Front Control),每一次浏览器提出Request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义 都没有。


在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服 器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充 性来自架构,很多开发框架,将所有事情绑在一起,限制了架构选错开发框架,你就没有扩充性


Q:你是说MVC模式不利于网站扩充性?

A:MVC 模式比较适合用在网页控制器(Page Control)的层次。基本上,每一个网页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一 个端点使用MVC模式来打造小型的网页控制器,是不会有问题。但是,大多数採用MVC模式的框架,预设在网站中採用前端控制器,而非用网页控制器的方式, 这样的MVC模式,只适合在小型或单一伺服器的网站。


Q:你会如何选择开发框架呢?

A:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。


Q:难道开发者不需要框架或架构吗?

A:网站的确需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成 功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!


用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除Runtime检查、拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介于两者之间。


登录后方可回帖

登 录
信息栏

Carbon Forum是一个基于话题的高性能轻型PHP论坛

下载地址:Carbon Forum v5.9.0
QQ群:12607708(QQ我不常上)

donate

手机支付宝扫描上方二维码可向本项目捐款

粤公网安备 44030602003677号
粤ICP备17135490号

Loading...