Комментарии 53
Хочу заметить, что то нарушает копирайт facebook. Они уже начали рассылать официальные обращения убрать код к авторам блогов, в которых размещён этот код.
Через google можно найти всех сразу:

http://www.google.com/search?q=%22%2Flib%2Fsecurityq.php%22
А чего в нем интересного? Без остальных исходников он бесполезен.
Интересного, там много, с точки зрения организации кода. Мне допустим было интересно посмотреть как разбили на модули, и есть ли MVC. Какой стиль программирования у "гигантов".
НЛО прилетело и опубликовало эту надпись здесь
Очень жаль, что «лучшии PHP-программисты мира» до сих пор пользуются функциональным подходом в программировании.
Я сам сейчас также пишу. Я был рад, что я не один. Хотя жду книжучку от SoftTime по ООП, чтобы тоже понять всю прелесть ООП.
НЛО прилетело и опубликовало эту надпись здесь
Возможно, это сделано для увеличения производительности
Как вы себе представляете поддержку большого проекта где все функции в одной области видимости (вобщем написано без ООП или хотябы неймспейсов). Это просто большая помойка.
Карамба! Ладно, ладно. Честно говоря, я не разбираюсь в подходах и не могу уверенно утверждать где функциональный подход, а где нет; не думаю, что когда все в одной куче --- это функциональный подход, все-таки это не очень удобно для программистов.

Там, где все в одной куче и ничего не разобрать --- там вообще подхода нет никакого.
Судя по успеху как то поддерживают.

Хотя код ужасный. Не верю что это их.
имелось в виду "процедурным подходом"? Функциональный подход ничем не хуже ООП, а в некоторых случаях и гораздо лучше.
Хм, помоему, это ужасно - все в перемешку, сплошные if и else, циклы... Наверное, ООП спас бы «лучших PHP-программистов мира» :) Хотя, не мне судить, может быть им так легче эфективнее.
Странно, заметил я у себя такую особенность - чем больше смотрю на PHP-код (в особенности этот), тем больше мне нравится Python.
Можно подумать что в питоне подобную гадость не накодить. Разве что смотреться будет красивее за счет отсупов.
Самый бесполезный исходник, который я когда либо видел.
НЛО прилетело и опубликовало эту надпись здесь
Этот пример обычно используется в учебных пособиях, где он небесполезен.
>так что на чёрном рынке вы можете без проблем купить клон того же Facebook за $200.
И как же это сделать? Что-то из профиля на блогспоте этого не видать.
НЛО прилетело и опубликовало эту надпись здесь
Нет уж, спасибо :)

Вообще конечно есть PHP-код куда более ужасный. Жаль, что его слишком много...
Даже не представляю, сколько нужно программеров, чтобы тащить такое чудо. Я бы поседел на пятый день работы над таким кодом :(
> код одного из самых успешных проектов Веб 2.0
:) вот так сегодня на кухне посидели и решили "не успешный" :)
Нереальное количество include. Даже страшно предположить сколько времени займет генерация этой страницы (считаю, что полсекунды - уже много). А если нагрузка сильная? Вообще капец? Я, конечно понимаю, что библиотеки нужно дробить по функциональному набору, но не до такой же степени. Все таки для фронтальной части можно немного свернуть все это хозяйство в кучу. Ну и кэширование не помешало-бы. А за утечку исходников сисадминам башку снести, чтоб за веб-сервером нормально следили. Мое мнение.
"А работает" за аргумент не считаю. Сегодня работает, а завтра - нет.
1. Я насчитал всего ли 25 инклюдов - это вполне реальное количество. Бывает и по 100 и по 200 в итоге - и неичего работает.
2. Если бы вы присмотрелись, то уведели бы что кэширование там есть.
Смею предположить, что здесь собрались люди, занимающиеся PHP. Думаю, что все в курсе того, что при выполнении PHP сценария одна из самых тяжелых команды - include. Не потому ли она тяжелая, что серваку приходится двигать бошки над поверхностью диска в поисках нужных секторов (в случае подключения сценария)? Дак давайте же делать по 100 или 200 инклудов и смотреть, когда же у нас наступит предел возможностей сервера. Все правильно, уплочено и за RAID и за SCSI, нечего железу прохлаждаться, пусть пыхтит. Я понимаю - есть нормы и правила ведения сложных проетов, которые диктуют необходимость в четком структурировании кода. Но почему нельзя хотя бы задуматься о компромиссе и найти золотую середину между производительностью и ясностью?

Осмелюсь подумать на эту тему. Потому что программист приходит на работу к 9 и уходит в 18 (к примеру). Потому что он знает, что ему заплатят н-ное количество тугриков в месяц и ни больше. И что он делает? Делает маскимально ясный и понятный код. Нет необходимости париться о тяжести кода, о нагрузке. Контора поставит н-ный сервак, сисадмины сделают кластер и все будет хорошо. Раньше люди писали код, потому что им это нравилось и было очень неплохо, если за это платили. Сейчас пишут код, потому что за это платят.

Мы в разных лодках
самое интересное что ничего плохого по большому счету в этом нет. т.е. в такой ситуации нет недовольных:
а) программист - он получает свои деньги, пишет плохой, но понятный ему код, может быть он и самнедоволен своим кодом, но если он пишет - значит его это устраивает
б) пользователи продукта - им вообще пофиг какой там код - контора поставит n-ный сервак, и сколько там инклюдов пользователям уже не будет важно
в) контора - на первый взгляд как раз им меньше всего выгодно такое положение дел, но... судя по капитализации того-же facebook их это совершенно не волнует. не волнует то что этот код требует бОльших мощностей, не волнует то что его сложнее повторно использовать. единственное что здесь важно - это скорость разработки в самом начале и возможность поддерживать (хотя-бы и с большими затратами) впоследствии

а писать код "писали код, потому что им это нравилось и было очень неплохо, если за это платили", это хорошо, но это непрофессионально (хотя это вполне работает в Open Source, там действительно люди заботятся о качестве кода, но это немного другая тема)
Ребят, да вы что? какие обращения к дискам? ОС кеширует частоиспользуемые файлы, к которым обращаются, таким образом даже если каждый файл по киллобайт 50 то 20 - это около 1 мб, это все довольно удачно лежит в памяти и подгружается мгновенно. А если учитывать что данные куски инклудятся в большенстве их сценариев. Так что говорить о "тяжелости комманыд инклуд" это глупо.
Когда-нибудь интересовались назначением утилиты ab, которая входит в дистрибутив Apache? Советую сделать лабораторную работу. Для этого потребуется сервер под nix-системой с Apache и тестовым хостом. Попробуйте сделать тест кода с 20 инклудами и без них. Поупражняйтесь
и после этого сделаете выводы. На всякий случай нарисую команду

./ab -n 500 -c 5 ваш_хост.ru/путь/

-n число запросов
-с число выполняющих запросы клиентов
-n количество запросов
-с количество конкурентных(одновременных) запросов

исходник:
/* include_once 'a.php';
include_once 'b.php';
include_once 'c.php';
include_once 'd.php';
include_once 'e.php';
include_once 'f.php';
include_once 'g.php';
include_once 'h.php';*/

function a(){
echo 'a';
}

function b(){
echo 'b';
}

function c(){
echo 'c';
}

function d(){
echo 'd';
}

function e(){
echo 'e';
}

function f(){
echo 'f';
}

function g(){
echo 'g';
}

function h(){
echo 'h';
}

a();b();c();d();e();f();g();h();
?>

результаты без include_once:
[timon@localhost ~]$ ab -n5000 -c5 http://localhost2/
Server Software: Apache/2.2.8
Server Hostname: localhost2
Server Port: 80

Document Path: /
Document Length: 8 bytes

Concurrency Level: 5
Time taken for tests: 6.403327 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 990198 bytes
HTML transferred: 40008 bytes
Requests per second: 780.84 [#/sec] (mean)
Time per request: 6.403 [ms] (mean)
Time per request: 1.281 [ms] (mean, across all concurrent requests)
Transfer rate: 150.86 [Kbytes/sec] received

c include_once:
[timon@localhost ~]$ ab -n5000 -c5 http://localhost2/
Server Software: Apache/2.2.8
Server Hostname: localhost2
Server Port: 80

Document Path: /
Document Length: 8 bytes

Concurrency Level: 5
Time taken for tests: 4.786561 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 990000 bytes
HTML transferred: 40000 bytes
Requests per second: 1044.59 [#/sec] (mean)
Time per request: 4.787 [ms] (mean)
Time per request: 0.957 [ms] (mean, across all concurrent requests)
Transfer rate: 201.82 [Kbytes/sec] received

apc отключен, после каждого теста делался httpd_restart и echo 1 > /proc/sys/vm/drop_caches

вопросы есть? :)
p.s. для тех кто не умеет читать цифирьки, с include на 25% быстрее
Не думаю, что этот пример корректен. Не против, если я его немного модифицирую, так сказать, для чистоты эксперимента. Совсем чуть-чуть.



Вариант 1 (без инклудов)


f1();
f2();
f3();
f4();
f5();
f6();
f7();
f8();

function f1() { echo 'f1'; }
function f2() { echo 'f2'; }
function f3() { echo 'f3'; }
function f4() { echo 'f4'; }
function f5() { echo 'f5'; }
function f6() { echo 'f6'; }
function f7() { echo 'f7'; }
function f8() { echo 'f8'; }

for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }
for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }

?>



Вариант 2 (с инклудами)


include_once('./t2_1.inc.php');
include_once('./t2_2.inc.php');
include_once('./t2_3.inc.php');
include_once('./t2_4.inc.php');
include_once('./t2_5.inc.php');
include_once('./t2_6.inc.php');
include_once('./t2_7.inc.php');
include_once('./t2_8.inc.php');

f1();
f2();
f3();
f4();
f5();
f6();
f7();
f8();

?>

В каждом файле t2_1.inc.php код соответствующей ему функции и цикл:


function f1() { echo 'f1'; }

for ($i = 1; $i < 100; $i++) { $a = 2 + $i; }

?>


Тестовая платформа - PIII600/256Mb/ATA100/Mandrake Linux/Apache 1.3.X/PHP 4.4. Рестарт httpd соответственно перед каждым тестом. Ну а теперь результаты:

ab -c5 -n1000 http://localhost/t1.php (без инклудов)

Concurrency Level: 5
Time taken for tests: 4.166 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 132264 bytes
HTML transferred: 16032 bytes
Requests per second: 240.04 [#/sec] (mean)
Time per request: 20.83 [ms] (mean)
Time per request: 4.17 [ms] (mean, across all concurrent requests)
Transfer rate: 31.75 [Kbytes/sec] received


ab -c5 -n1000 http://localhost/t2.php (с инклудами)

Concurrency Level: 5
Time taken for tests: 5.088 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 132000 bytes
HTML transferred: 16000 bytes
Requests per second: 196.54 [#/sec] (mean)
Time per request: 25.44 [ms] (mean)
Time per request: 5.09 [ms] (mean, across all concurrent requests)
Transfer rate: 25.94 [Kbytes/sec] received


Уважаемый timosha, если PHP и откешировал 8 файлов длинной по ~80 байт, содержащих
по одной примитивной функции, это не значит, что он сделает тоже самое на "тяжелом" проекте, содержащем сотни файлов сценариев. А если один сервер будет тянуть несколько хостов с подобными проектами? Хотя, я ни в коем случае никого ни в чем не убеждаю. Вы вольны делать что хотите и использовать свои методики построения и оптимизации проектов.
Мало того, что ОС кеширует, так еще и PHP кеширует, причем не исходники, а итоговый байт-код.
> Раньше люди писали код...
Раньше — это как именно давно?
Да ну. Инклуды лучше, чем весь код в одном файле. Разделённый код легче читать, легче обновлять. А замедления от него, особенно если стоит тот же Зенд Оптимайзер, не почувствуешь особо. Всё кешируется.

Что же касается вообще ситуации с тем, что кодер делает, чтобы платили, то тут ничего не поделаешь. Если кодер начнёт гикствовать с оптимизацией, то не уложится в сроки. Может вообще давайте всё на асме писать, нэ?

Лично я сейчас всё ещё пытаюсь писать красивый код, чтобы не было стыдно. Но реалии жизни ведут к противному.
Минусуйте, минусуйте, я все равно своего мнения не изменю :) Чем обоснована критика? Давайте обсудим.
не считаю себя хорошим программистом, но честное слово, испытываю отвращение.
даже сам, задумываясь о последствиях, переписывал свои классы по 10 раз, чтоб все было максимально ясно и функционально.
могли бы и опытных нанять...
Забавный код. Функциональный кодинг, плюс волшебные названия функций. check_and_fix_broken_emails($user) особенно порадовала.

Хотя ведь работает, а значит здорово. И, наверняка, работает быстрее, чем ежели было объектным.

Хотя та же викимедия объектна, и ничего страшного.
if ($orientation) {
if ($post_leave_orientation) {
orientation_update_status($user, $orientation, 2);
notification_notify_exit_orientation($user);
dirty_user($user);
redirect('home.php');
} else if (orientation_eligible_exit(array('uid'=>$user)) == 2) {
orientation_update_status($user, $orientation, 1);
notification_notify_exit_orientation($user);
dirty_user($user);
redirect('home.php');
}
}

Чорт, эпичный код :)
непонятно, зачем юзеров пачкают.

Хотя, вообще не могу понять, что этот кусок делает :)
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.