ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: don't repeat yourself / copy and paste programming



On Wed, Nov 23, 2011 at 08:29:00PM +0200, Gena Makhomed wrote:
> On 23.11.2011 18:38, Igor Sysoev wrote:
> 
> >> даже при 50-100 сайтов неудобно делать много include на каждый сайт,
> >> гораздо удобнее все-таки подход "1 сайт == 1 конфигурационный файл".
> 
> >> но в этом случае получается много copy/paste и нарушение принципа
> >> don't repeat yourself, что приводит к снижению скорости работы
> >> администратора по сопровождению такого дублированного конфига.
> 
> > Спасибо, я на эти don't repeat yourself насмотрелся. Больше не хочу.
> > Нужно критически подходить к приницпам.
> 
> все-таки DRY - это достаточно важный принцип, и он соблюдается
> даже в исходниках nginx - общие части кода выносятся в макросы
> или в отдельные функции, и там нет дублирования через copy/paste.
> 
> в конфигах nginx например, директивы "include fastcgi.conf;"
> или "include fastcgi_params;" встречаются с той же целью,
> насколько я понимаю - избежать лишнего дублирования кода.
> 
> мне очень трудно критиковать принцип DRY / SSOT, потому что его
> противоположностью является чрезмерное использование copy/paste,
> что в случае программирования приводит к т.е. "индусскому коду".

DRY - это миф. Есть два подхода к решению задач - выпиливание лобзиком
и квадратно-гнездовой метод. Обычно продукт, выпиленный лобзиком,
со стороны выглядит как образец DRY. Однако, если заглянуть в
репозитарий, то можно увидить, сколько времени ушло на выпиливание DRY.
Там будет сплошной repeat: repeat немного по-другому, возврат к прежнему
repeat и так далее. Мне почему-то кажется, что 99% админов, настраивающих
nginx, не хотят выпиливать лобзиком. Им нужно сделать это по-быстрее,
затратив минимум мозговых усилий. Собственно, это видно уже по началу
настройки - а давайте-ка всё, чего у нас нет, будет обрабатывать /index.php,
а сам /index.php будет обрабатывать ~\.php$. Причём лучше, чтобы
так было для всех сайтов, а то неохота возиться. В дальнейшем желание
выпиливать лобзиком так и не появляется, а вот делать по-быстрому уже
не получается - зависимости множаться и конфигурация превращается
в стройную систему костылей и подпорок.

Поэтому nginx предлагает конфигурировать квадратно-гнездовым методом
со сложностью O(1), а не экспоненциальной. Да в начале писать немного
больше, но это объем редактирования будет постоянен.


-- 
Игорь Сысоев
http://sysoev.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.