Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
>>> Если вы работаете над сайтом, который размещается на LAMP стеке – какова вероятность того, что клиент сменит БД
Был какраз этот случай. С мускуля на постгрес через несколько лет разработки с plain sql запросами в коде. Внезапно понадобилось переходить. Шанс обысно мизерный, но если такое случится, сложно представить сколько человеко-часов придется затратить. В таком случае лучше использовать сразу какой-нибудь Zend_Query, заодно у вас будет единая точка для запросов куда можно воткнуть профилирование, кеширование и прочая. Менджмент рисков никто не отменял.
Был какраз этот случай. С мускуля на постгрес через несколько лет разработки с plain sql запросами в коде. Внезапно понадобилось переходить. Шанс обысно мизерный, но если такое случится, сложно представить сколько человеко-часов придется затратить. В таком случае лучше использовать сразу какой-нибудь Zend_Query, заодно у вас будет единая точка для запросов куда можно воткнуть профилирование, кеширование и прочая. Менджмент рисков никто не отменял.
Никто ведь не говорит, что нужно писать запросы в DB прямо в бизнес-логике. Можно ввести DAO — это тоже абстракция, но абстракция, покрывающая именно ваши проблемы. При смене DB вам потребуется лишь реализовать новые DAO классы, причём public contract и сигнатура методов сохранятся, равно как и юнит тесты. Кстати, даже используя Zend_Db, при смене DB вам также придётся переписывать запросы.
По поводу кеширования, профилирования и прочее — то при чём здесь Zend_Db? Вы серьёзно считаете, что без использования Zend_Db этого не достичь?
По поводу кеширования, профилирования и прочее — то при чём здесь Zend_Db? Вы серьёзно считаете, что без использования Zend_Db этого не достичь?
Если не секрет, какие были причины смены SQL сервера? Я человек в базах не сильно сведущий, Postgre даёт значительный прирост производительности или что-то ещё?
Компоненты-компоненты… Эх, а вы видели, что сейчас происходит в Google Play? Хочу я к примеру найти плеер для интернет-радио: огромный выбор чего только можно, каждое приложение лезет в телефонную книгу, в вайфай, в автозапуск и всем обязательно нужен доступ к GPS, ну или как минимум к данным сети. Без всего этого проиграть интернет-радио невозможно. После скачивания приложения что нужно сделать? Не, не читать Readme, даже не лазить в настройки, нужно обязательно авторизоваться через твиттер, фейсбук или что-то подобное. Мне интересно, там вообще есть приложения без социальных сетей? Каждое второе приложение в собственном стиле, изобретает свои UI-виджеты. Обязательно, в каждом плеере должен быть будильник, магазин треков и возможность отобразить обложку играющего трека.
И вот через все это прорываешься к строчке ввода адреса, откуда собственно играть радио, а этого самого адреса и нету. Потом идешь в FAQ на официальном сайте, находишь вопрос про добавление своего URL — а там сказано. что такое не поддерживается. Тихо материмся и удаляем приложение. Я это сделал множество раз, а радио-плеера так и не нашел.
А вы говорите про 80% затрат на 20% функционала. Где он, этот функционал? Нужный мне функционал на j2me был реализован в пределах 100 строк, включая UI. Видимо, придется не только заниматься своей версией Icecast, но и создавать плеер.
И вот через все это прорываешься к строчке ввода адреса, откуда собственно играть радио, а этого самого адреса и нету. Потом идешь в FAQ на официальном сайте, находишь вопрос про добавление своего URL — а там сказано. что такое не поддерживается. Тихо материмся и удаляем приложение. Я это сделал множество раз, а радио-плеера так и не нашел.
А вы говорите про 80% затрат на 20% функционала. Где он, этот функционал? Нужный мне функционал на j2me был реализован в пределах 100 строк, включая UI. Видимо, придется не только заниматься своей версией Icecast, но и создавать плеер.
Более того, такого легковесного simple-плеера с трудом найдешь и под винду :) Винамп 2.97 только молодец в этом плане…
AIMP.
foobar
Может, дело в бюджете? Например, приложение без социалок, магазина треков и ещё тысячи свистелок не монетизируется и, следовательно, может быть написано «для себя», но не в маркет.
Судя по комменту iFrolov он бы рад и купить такое приложение, но нет.
Эта статья как раз и призвана научить программистов писать код грамотно, не тратя времени на «нужные» (читай ненужные) фичи.
По поводу 80/20, в плане фич, есть старая, но очень хорошая статья.
По поводу 80/20, в плане фич, есть старая, но очень хорошая статья.
Читал оригинал, статья замечательная.
Вероятно, стоило перевести статью более литературно, а не так дословно. Всё-таки такие понятия как информация, знания и данные различаются по смыслу. Так же различаются понятия класса и объекта.
Например, сразу бросилось в глаза:
После прочтения оригинала, мне показалось, что под термином «piece of knowledge», автор статьи понимает как формализацию знаний о том, как что-то сделать, в виде алгоритма, выраженного на ЯП, так и некоторую информацию, представленную в виде данных, к которым можно обращаться, используя некоторую переменную. Таким образом, смысл цитаты можно свести к тому, что не надо повторять одинаковые фрагменты кода и дублировать данные без необходимости.
Например, сразу бросилось в глаза:
Принцип DRY требует, чтобы такие части информации встречались в вашем коде один, и только один раз.
The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.
После прочтения оригинала, мне показалось, что под термином «piece of knowledge», автор статьи понимает как формализацию знаний о том, как что-то сделать, в виде алгоритма, выраженного на ЯП, так и некоторую информацию, представленную в виде данных, к которым можно обращаться, используя некоторую переменную. Таким образом, смысл цитаты можно свести к тому, что не надо повторять одинаковые фрагменты кода и дублировать данные без необходимости.
Не могу не согласиться. Но мне кажется, если переводить эту цитату, вырвав из контекста — ваш вариант более понятен. Но если ее читать в рамках статьи — суть остается той же. Ну и вообще — довольно непросто философствовать о принципах ПО на литературном языке.
Ой, это ответ на этот комментарий.
Статья, если честно, неглубока. Я не знаю, кем должен быть читатель на Хабре, чтобы никогда не слышать о принципе Парето («20 % усилий дают 80% результата, а остальные 80 % усилий — лишь 20% результата») и о бритве Оккама («не плоди сущностей без надобности»). Ладно, это мелочи. Но про Эйнштейна, конечно, лихо. Если верить автору, Эйнштейн просто выкинул эфир и суждение что «время не является константой» и тут же изобрел ОТО. Между прочим, до подтвержения Хабблом факта расширения Вселенной Эйншейн на 12 лет включил в свою теорию космологическую постоянную, потому что придерживался теории статической Вселенной, а потом сокрушался своей ошибке. Тут у него kiss-принцип, видимо, не сработал.
Вообще, проблема разработки чего-то сложного не нова. Я помню интервью одного нашего космонавта, который верно заметил, что успех космических программ имел в основе не столько технологии, сколько способность разработчиков взаимно увязывать компоненты системы. Одному агрегату нужно больше питания, значит, нужны батареи потяжелее, значит нужно нарастить мощность ракеты, а она ограничена, в итоге ищем альтернативный способ подзарядки и т.д. Архитектору программных систем приходится решать эту задачу оптимизации постоянно. Для решения есть полный арсенал — шаблоны проектирования, интерфейсы, корпоративные стандарты документирования, UML и т.д. Планирование, увы, не всегда срабатывает, поскольку решения не всегда лежат на поверхности, а то бы Гугл еще до Цукенберга запланировал сделать мегасоцсеть. Боюсь, реально работающий рецепт один — приобретать опыт, учиться, пробовать и быть дисциплинированным в работе.
Вообще, проблема разработки чего-то сложного не нова. Я помню интервью одного нашего космонавта, который верно заметил, что успех космических программ имел в основе не столько технологии, сколько способность разработчиков взаимно увязывать компоненты системы. Одному агрегату нужно больше питания, значит, нужны батареи потяжелее, значит нужно нарастить мощность ракеты, а она ограничена, в итоге ищем альтернативный способ подзарядки и т.д. Архитектору программных систем приходится решать эту задачу оптимизации постоянно. Для решения есть полный арсенал — шаблоны проектирования, интерфейсы, корпоративные стандарты документирования, UML и т.д. Планирование, увы, не всегда срабатывает, поскольку решения не всегда лежат на поверхности, а то бы Гугл еще до Цукенберга запланировал сделать мегасоцсеть. Боюсь, реально работающий рецепт один — приобретать опыт, учиться, пробовать и быть дисциплинированным в работе.
Фишка DRY — как можно больше атомарной реализации. У вас всегда должна быть возможность внести некоторые изменения в алгоритмах, без страха, что вся система рухнет.
P.S. Википедия, первый абзац — очень четкая, понятная формулировка.
P.S. Википедия, первый абзац — очень четкая, понятная формулировка.
Грубо говоря — не копипастить код из одной системы/подсистемы/функции/участка функции в другую, даже используя в качестве буфера мозг. Основная причина, имхо — сложность поддержки двух и более одинаковых кусков кода (нашли баг в одном куске — нужно не забыть исправить в других местах, где этот же код используется или, например, два почти одинаковых куска кода и сложно заметить, а заметив понять, различие). Дополнительная — общее уменьшение количества кода и, как следствие, размеров бинарников. И термину 100 лет в обед.
Больше б подобных статей на хабре. Вечер удался :)
А DRY не противоречит ли KISS и, особенно, YAGNI?
Пускай есть код вроде
Встретился он один раз, вроде не противоречит ни одному из принципов. Встречается второй раз… По DRY его просто необходимо вынести в отдельную функцию/метод get_users (а по некоторым методикам даже если один раз встретился такой код, его нужно выносить в отдельный слой), а по YAGNI не нужно предусматривать, что может измениться имя таблицы, СУБД или вообще что хранилище может перейти на плоские файлы или в облако.
DRY является усложнением кода (вводятся новые сущности, новые связи между ними и т. д.) ради облегчения поддержки, а KISS и YAGNI постулируют обратный процесс «фиг с ней с поддержкой будущей, главное чтобы сейчас было как можно проще (и быстрее)». Или не противоречат?
Пускай есть код вроде
users = new Set();
result = mysql.query("SELECT * FROM users");
while (user = mysql.fetch(result)) {
users.add(user);
}
Встретился он один раз, вроде не противоречит ни одному из принципов. Встречается второй раз… По DRY его просто необходимо вынести в отдельную функцию/метод get_users (а по некоторым методикам даже если один раз встретился такой код, его нужно выносить в отдельный слой), а по YAGNI не нужно предусматривать, что может измениться имя таблицы, СУБД или вообще что хранилище может перейти на плоские файлы или в облако.
DRY является усложнением кода (вводятся новые сущности, новые связи между ними и т. д.) ради облегчения поддержки, а KISS и YAGNI постулируют обратный процесс «фиг с ней с поддержкой будущей, главное чтобы сейчас было как можно проще (и быстрее)». Или не противоречат?
Вы правы, и все зависит именно от контекста реализации. Если у вас в системе уже предусмотрены разные источники данных — стоит использовать DRY. Но если в требованиях этого нет — все делаем KISS/YAGNI.
При написании кода второй раз необходимо произвести рефакторинг и вынести общий код в отдельную функцию.
Рефакторинг — это не добавление и не изменение функционала. YAGNI распространяется на функционал, а не на рефакторинг. Если что-то повторяется — рефакторинг обязателен. Говорить про рефакторинг «нам это не понадобится» — нельзя. Поэтому не противоречит.
Вообще со статьей местами очень не согласен. YAGNI — это основополагающий принцип и не вижу проблем в сложных проектах его использовать
Вообще со статьей местами очень не согласен. YAGNI — это основополагающий принцип и не вижу проблем в сложных проектах его использовать
Не нравится мне такой перевод:
В оригинале:
Я бы перевел так: «Со временем, фундаментальные вещи берут верх».
В крайнем случае «Любовь приходит и уходит, а кушать хочется всегда».
впомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет.
В оригинале:
The fundamental things apply, as time goes by.
Я бы перевел так: «Со временем, фундаментальные вещи берут верх».
В крайнем случае «Любовь приходит и уходит, а кушать хочется всегда».
Я сам долго пытался найти естественный перевод, перепробовал разные варианты, но ни один из них не доносил смысла, который автор хотел передать. Бросив, просто нашел перевод песни, который, как мне кажется, действительно полноценен.
Я смысл статьи понял как:
Пишите код хорошо, и у вас будет хороший код.
Как-то так.
Пишите код хорошо, и у вас будет хороший код.
Как-то так.
Как бы парадоксально сие не было, но большинство разработчиков очень сильно сопротивляются написанию «хорошего кода». Они могут придумать сотню отмазок почему надо писать абы какой код, и почему нет времени на написание хорошего. Ежики и кактус…
Если код писать хорошо и проектировать приложение не торопясь — то проект запустится намного раньше и съест намного меньше денег.
Типичные будни сотфверных компаний:
Аврал! Красная кнопка. Люди орут бегают туда сюда, кто то принес огнетушитель. Грузовик с костылями уже въезжает во двор, главный архитектор раздает программерам их пачками и все несутся к рушащемуся зданию прибивать эти самые костыли со всех сторон.
П.С. Делать качественно всегда дешевле и быстрее, но людям очень сложно сломать этот стереотип
Если код писать хорошо и проектировать приложение не торопясь — то проект запустится намного раньше и съест намного меньше денег.
Типичные будни сотфверных компаний:
Аврал! Красная кнопка. Люди орут бегают туда сюда, кто то принес огнетушитель. Грузовик с костылями уже въезжает во двор, главный архитектор раздает программерам их пачками и все несутся к рушащемуся зданию прибивать эти самые костыли со всех сторон.
П.С. Делать качественно всегда дешевле и быстрее, но людям очень сложно сломать этот стереотип
Один из моих основных принципов при программировании (на самом деле и в остальных сферах жизни) — «Телепатов нет»
(это утверждение также подкрепляется такими высказываниями как, если что-то можно понять не правильно, то оно обязательно так и будет понято).
Данный принцип призывает как упрощать (привет KISS), так и комментировать сразу (а не потом, когда-нибудь после кода-ревью или пинка, направленного на улучшение документации).
Вообще, чем меньше вы оставите места для «додумывания» (да простит меня Русский язык), тем лучше.
(это утверждение также подкрепляется такими высказываниями как, если что-то можно понять не правильно, то оно обязательно так и будет понято).
Данный принцип призывает как упрощать (привет KISS), так и комментировать сразу (а не потом, когда-нибудь после кода-ревью или пинка, направленного на улучшение документации).
Вообще, чем меньше вы оставите места для «додумывания» (да простит меня Русский язык), тем лучше.
Плюсики, конечно, везде проставил. Но в рамках стариковского брюзжания скажу, что мне не нравятся такие статьи. Есть в них что-то от небезызвестной книги «Банды Четырех», которая, по мнению многих разработчиков, нанесла чудовищный удар индустрии программирования.
DRY, KISS и YAGNI — это великолепные принципы. Замечательные. Но это инструменты — и, как у любых инструментов, у них есть цена использования. Для чего предназначены эти принципы? В первую очередь — для борьбы со сложностью, с «complexity problem». А как показывает практика, сложность программного решения — это некая константаня величина, диктуемая его объемом. Ее нельзя просто взять и убрать. Ее можно спрятать во фреймворк — тогда на верхнем уровне будет несколько красивых строчек кода а под ними — айсберг. Ее можно спрятать в иерархию — тогда вместо копипасты будет вызов метода. Можно спрятать в абстракцию — тогда вместо ручного управления памятью будут умные указатели. Но ее, #$!#!#@, нельзя убрать из кода :(.
И все эти замечательные принципы убирают сложность в одном месте, добавляя ее в другом. Так же как упомянутые мной паттерные проектирования убирали архитектурную сложность в одном месте — добавляя ее в другом за счет введения дополнительного слоя абстракции (для большинства паттернов). И если, не зная этих лежащх в основе концепций, применять DRY, KISS и YAGNI — то можно легко получить ситуации, когда разработчик убирает три копипасты по две строчки, заменяя их классом на двадцать. Или, в соответствии с принципом KISS, не делает абстракции базы данных, потому что «ну кто же будет в LAMP базу данных менять»?
Только вот про основы, борьбудобра и зла программистов с проблеммой сложности кода, что именно дает DRY или YAGNI, зачем они нужны — не пишут. Пишут готовые кулинарные рецепты, бережно передаваемые из поколения в поколение — «об этом еще Дейкстра говорил!». Не уверен, что это есть хорошо.
DRY, KISS и YAGNI — это великолепные принципы. Замечательные. Но это инструменты — и, как у любых инструментов, у них есть цена использования. Для чего предназначены эти принципы? В первую очередь — для борьбы со сложностью, с «complexity problem». А как показывает практика, сложность программного решения — это некая константаня величина, диктуемая его объемом. Ее нельзя просто взять и убрать. Ее можно спрятать во фреймворк — тогда на верхнем уровне будет несколько красивых строчек кода а под ними — айсберг. Ее можно спрятать в иерархию — тогда вместо копипасты будет вызов метода. Можно спрятать в абстракцию — тогда вместо ручного управления памятью будут умные указатели. Но ее, #$!#!#@, нельзя убрать из кода :(.
И все эти замечательные принципы убирают сложность в одном месте, добавляя ее в другом. Так же как упомянутые мной паттерные проектирования убирали архитектурную сложность в одном месте — добавляя ее в другом за счет введения дополнительного слоя абстракции (для большинства паттернов). И если, не зная этих лежащх в основе концепций, применять DRY, KISS и YAGNI — то можно легко получить ситуации, когда разработчик убирает три копипасты по две строчки, заменяя их классом на двадцать. Или, в соответствии с принципом KISS, не делает абстракции базы данных, потому что «ну кто же будет в LAMP базу данных менять»?
Только вот про основы, борьбу
Задача этих принципов не ликвидировать сложность, это нереально. Эти принципы позволяют снизить сложность, раздробить ее на мелкие, управляемые части, или вообще не писать сложных вещей.
Сложность можно снизить, только если решение усложнено. Если решение не усложнено (а это, на вскидку, прмерно половина случаев) — то можно только понизить концентрацию сложности в одном конкретном месте куда путем переноса части сложности в другие места. Про это никто не пишет, что меня немного огорчает.
Наверное, это всем очевидно. Только почему тогда основная масса кода такого низкого качества? :)
Наверное, это всем очевидно. Только почему тогда основная масса кода такого низкого качества? :)
Нельзя быть немного беременным. Если решение сложное — его стоит упростить, а не прятать куда либо.
Мне кажется, вы путаете понятие сложности, с уровнем взгляда на общую архитектуру системы. Если смотреть на проблему с вершины айсберга — да, все довольно сложно. Но, в хорошем проекте, эта сложность собрана из хорошо написанных, качественных, небольшых частей, каждая из которых не такая уж и сложная. Если вдруг у вас не так, вам есть к чему стремиться, используя принципы, описанные в этой статье.
Мне кажется, вы путаете понятие сложности, с уровнем взгляда на общую архитектуру системы. Если смотреть на проблему с вершины айсберга — да, все довольно сложно. Но, в хорошем проекте, эта сложность собрана из хорошо написанных, качественных, небольшых частей, каждая из которых не такая уж и сложная. Если вдруг у вас не так, вам есть к чему стремиться, используя принципы, описанные в этой статье.
По моему вы путаете сложность с количеством информации. Которая только от задачи должна зависеть в идеале.
А вот сложность реализации может быть любая. Вот, пример. Когда-то меня «заставили» писать научную статью. Для галочки. У меня не было никаких идей и муза была в отпуске, а настороение не очень, поэтому я написал на первое выражение 0 = 0. Далее начал наращивать. В конце у меня получилась большая система сложных уравнений. И была она математически верной. Но суть осталась — ноль равен нулю. Я такое часто вижу в разработке ПО.
У нас один чудак написал проект для переливки таблицы из эксель в БД. Там тысячи классов. Понесло, что называется. Искусство ради искусства. Куча паттернов, куча совершенно не обоснованных решений. Погоня за гибкостью на самокате. )))
Один из примеров. В базе есть справочник, который он создал. У элементов справочника есть целочисленные идентификаторы. Но он решил, что в коде пользоваться идентификаторами — хардкод и опасно (он вообще странный). И поэтому дал имена элементам справочника вроде «Item_1», «Item_2» и т.д. Потом в коде парсит и находит цифру. Она уже как бы от идентификатора не зависит.
Почти все проблемы, которые я видел в «архитектуре», работая в разных компаниях — это излишняя сложность. Когда люди пытаются не отталкиваться от требований, а предвидеть и сделать более гибкое решение или более оптимальное (преждевременная оптимизация). В результате появляется код, оснований писать который не было никакого. Этот код требует поддержки и создается костыль за костылем, «чтобы уравнять уравнения».
А вот сложность реализации может быть любая. Вот, пример. Когда-то меня «заставили» писать научную статью. Для галочки. У меня не было никаких идей и муза была в отпуске, а настороение не очень, поэтому я написал на первое выражение 0 = 0. Далее начал наращивать. В конце у меня получилась большая система сложных уравнений. И была она математически верной. Но суть осталась — ноль равен нулю. Я такое часто вижу в разработке ПО.
У нас один чудак написал проект для переливки таблицы из эксель в БД. Там тысячи классов. Понесло, что называется. Искусство ради искусства. Куча паттернов, куча совершенно не обоснованных решений. Погоня за гибкостью на самокате. )))
Один из примеров. В базе есть справочник, который он создал. У элементов справочника есть целочисленные идентификаторы. Но он решил, что в коде пользоваться идентификаторами — хардкод и опасно (он вообще странный). И поэтому дал имена элементам справочника вроде «Item_1», «Item_2» и т.д. Потом в коде парсит и находит цифру. Она уже как бы от идентификатора не зависит.
Почти все проблемы, которые я видел в «архитектуре», работая в разных компаниях — это излишняя сложность. Когда люди пытаются не отталкиваться от требований, а предвидеть и сделать более гибкое решение или более оптимальное (преждевременная оптимизация). В результате появляется код, оснований писать который не было никакого. Этот код требует поддержки и создается костыль за костылем, «чтобы уравнять уравнения».
Это вы вообще про детский сад рассказываете, про усложненные решения. Подразумевается, что код, к котоому прменяются паттерны и подходы сам по себе адекватен и не усложнен. И вот тогда начинаются вопросы с ценой этих паттернов.
Я видимо ваш комментарий понял буквально.
Логика и наоборот действует — можно сложное упрощать. А если вопрос стоит в том, что уже достаточно упрощено, то я следую принципу максимального соотвествия кода задаче (не реализации). Прятать куда-то что-то за имена и вращать разными паттернами не нужно, потому что чаще всего есть одно-два понимания, как в коде правильно закодить требования, нечего выдумывать.
Сегодня была ситуация. Дали задание проанализировать как создать архитектуру для одной задачи. Вклиниться в уже созданную БД, это просто очередная задача.
Через полчаса получили развернутый ответ, всё время просто письмо заняло. И начали удивляться, что я мало времени потратил на «создание архитектуры».
Какая еще архитектура. Есть требования, они однозначно переводятся в сущности БД. Нечего выдумывать, анализ занимает время всего лишь, чтобы понять смысл задачи. Остальное автоматом.
Так и с любым кодом. Если люди начинают что-то прятать, высовывать — то это или рефакторинг, чтобы лучше код соответствовал задаче или не совсем понимают, зачем это нужно.
Логика и наоборот действует — можно сложное упрощать. А если вопрос стоит в том, что уже достаточно упрощено, то я следую принципу максимального соотвествия кода задаче (не реализации). Прятать куда-то что-то за имена и вращать разными паттернами не нужно, потому что чаще всего есть одно-два понимания, как в коде правильно закодить требования, нечего выдумывать.
Сегодня была ситуация. Дали задание проанализировать как создать архитектуру для одной задачи. Вклиниться в уже созданную БД, это просто очередная задача.
Через полчаса получили развернутый ответ, всё время просто письмо заняло. И начали удивляться, что я мало времени потратил на «создание архитектуры».
Какая еще архитектура. Есть требования, они однозначно переводятся в сущности БД. Нечего выдумывать, анализ занимает время всего лишь, чтобы понять смысл задачи. Остальное автоматом.
Так и с любым кодом. Если люди начинают что-то прятать, высовывать — то это или рефакторинг, чтобы лучше код соответствовал задаче или не совсем понимают, зачем это нужно.
Так и с любым кодом. Если люди начинают что-то прятать, высовывать — то это или рефакторинг, чтобы лучше код соответствовал задаче или не совсем понимают, зачем это нужно.
Все просто. Паттерны и подходы (тот же указанный в статье DRY) решают проблемы. Какие проблемы? Проблемы концентрации сложности в одном месте. Например, что делает DRY: если у нас один и те же строки кода повторяются в нескольких местах, то в тот момент когда нам нужно будет их поменять — нам придется менять во многих местах. И если мы все эти места не найдем — мы получим сложноотлавливаемую багу. Принцип DRY позволяет избавится от этой проблемы — повторяющуюся строчки меняются на одну, и общий код выносится в одно место — класс, функцию, декоратор — whatever.
О чем я брюзжу — это о том, что применение этой операции не уменьшает сложность — оно переносит ее из одного места (копипаста, размазанная по коду — сложность модификации) в другое (дополнительный уровень абстракции — сложность понимания кода). Тоесть сложность остается той же, но за счет применения данной техники мы ее убрали из того места где она нам не нравится в то место, где мы готовы ее терпеть. На мой взгляд, понимание этой концепции позволят оценивать когда мы хотим убрать копипасту — а когда не хотим. В случае, если убирание десятка строчек копипасты приведет к созданию класса в полсотни строк при уже навернутых уровнях абстракции в этой точке кода — мы явно не хотим добавлять еще один слой абстракции — цена, которую мы за это заплатим будет больше выгода.
Но никто почему-то про это не пишет. Большинство бегает и кричит — «А-а-а-а-а, применяйте DRY, он кле-е-е-е-евый, он копипасту убирает! Он превращает быдлокод в мегакод!». Но это не так, это ложь. Он не бесплатно убирает копипасту — он ее убирает ценой добавления еще одного уровня абстракции. Это цена, и в ряде случаев мы совсем не хотим ее платить. Но никто это не оценивает, а потом получается код, где количество слоев абстракции настолько высоко, что даже я его понять не могу :(.
Как уже говорилось, это в рамках старческого брюзжания, не обращайте внимания :). Все эти проблемы возникают когда все остальное более-менее. Когда же стоит вопрос, что написанное студентов решение в 10000 строк на самом деле можно написать в 100 просто другим способом — то тут проблемы применения паттернов отходят на второй план :).
да нет же! ))
Если сложный кусок повторяется несколько раз, то во столько же раз и сложность растет. Если условно сложность куска кода равна единице, то пять повторений — сумма — сложность 5. Сведение в одно место уменьшает сложность.
Другое дело, что это не единственный критерий оценки сложности. Вот, можно посмотреть, как майкрософт автоматически в вижуал студии оценивает сложность кода.
Сведение в одно место кода уменьшает сложность — цикломатическую сложность. Но повышает другие сложности — туда входит и количество строк. И глубина вложенности классов. Всё это вопрос балланса.
Например, возможно круто использовать виртуальные методы вместо ветвлений. Но очевидно, что для несложных операций если будет стоять if и метод от этого не слишком велик, то иф лучше — потому что код лежит в одном месте, доступен обзору глазами. То же наверное и с копипастом. Если то, что куски кода делают — ясное и в обзоре глазами воспринимается хорошо, то пусть будет. Но если этому куску можно дать ясное осмысленное имя и этот кусок встречается не два раза, а много раз — значит это некоторая операция, характеризующая программу, выносить надо однозначно.
Где-то так. Обилие методов (функций), которые содержат по три строчки, возможно кому-то нравится. Но разброс логики по разным файлам в разных функциях не делает код читаемее. Потом, за каждый вынос куска кода нужно платить — придумывать имя. А имя — это новая сущность, смысл которой нужно помнить. А новому программисту с ней разобраться и тоже запомнить.
Всё несет нагрузку. Просто надо в комплексе рассматривать. Для меня основной критерий — это отражение требований. Т.е. ясность кода с т.з. предметной области. Кое чем можно жертвовать, оценивать по разным параметром код, но этот критерий — главный.
Если сложный кусок повторяется несколько раз, то во столько же раз и сложность растет. Если условно сложность куска кода равна единице, то пять повторений — сумма — сложность 5. Сведение в одно место уменьшает сложность.
Другое дело, что это не единственный критерий оценки сложности. Вот, можно посмотреть, как майкрософт автоматически в вижуал студии оценивает сложность кода.
Сведение в одно место кода уменьшает сложность — цикломатическую сложность. Но повышает другие сложности — туда входит и количество строк. И глубина вложенности классов. Всё это вопрос балланса.
Например, возможно круто использовать виртуальные методы вместо ветвлений. Но очевидно, что для несложных операций если будет стоять if и метод от этого не слишком велик, то иф лучше — потому что код лежит в одном месте, доступен обзору глазами. То же наверное и с копипастом. Если то, что куски кода делают — ясное и в обзоре глазами воспринимается хорошо, то пусть будет. Но если этому куску можно дать ясное осмысленное имя и этот кусок встречается не два раза, а много раз — значит это некоторая операция, характеризующая программу, выносить надо однозначно.
Где-то так. Обилие методов (функций), которые содержат по три строчки, возможно кому-то нравится. Но разброс логики по разным файлам в разных функциях не делает код читаемее. Потом, за каждый вынос куска кода нужно платить — придумывать имя. А имя — это новая сущность, смысл которой нужно помнить. А новому программисту с ней разобраться и тоже запомнить.
Всё несет нагрузку. Просто надо в комплексе рассматривать. Для меня основной критерий — это отражение требований. Т.е. ясность кода с т.з. предметной области. Кое чем можно жертвовать, оценивать по разным параметром код, но этот критерий — главный.
Если сложный кусок повторяется несколько раз, то во столько же раз и сложность растет. Если условно сложность куска кода равна единице, то пять повторений — сумма — сложность 5. Сведение в одно место уменьшает сложность.
Это… очень смелое предположение :). «Сложность» — абстрактное понятие. Что именно вырастет в пять раз? Какие операции для разработчика станут в пять раз сложнее?
Вот этот фрагмент:
books = FindBooks( "flibusta.net" )
SaveBooks( books )
books = FindBooks( "fenzin.org" )
SaveBooks( books )
books = FindBooks( "bookz.ru" )
SaveBooks( books )
Неужели в три раза сложнее чем:
books = FindBooks( "flibusta.net" )
SaveBooks( books )
Не верю :)
да нет же! ))
Обилие методов (функций), которые содержат по три строчки, возможно кому-то нравится. Но разброс логики по разным файлам в разных функциях не делает код читаемее. Потом, за каждый вынос куска кода нужно платить — придумывать имя. А имя — это новая сущность, смысл которой нужно помнить. А новому программисту с ней разобраться и тоже запомнить.
Вы как-то странно со мной не соглашаетесь, полностью повторяя мои выкладки о цене применяемых методов O_O.
Сложность — не совсем абстрактное понятие. В него уже вкладывают смысл. Повторю: у майкрософта в студии встроен анализатор кода, который показывает индекс, насколько код хорош. Конечно, эта вещь не абсолютна, т.к. мерки снимает автоматические. Но стоит посмотреть на эти коэфициенты. Проводят исследования и как-то сложность превращают в вычислимую величину.
Там много критериев. Самый известный — цикломатическая сложность. Грубо говоря, это количество независимых маршрутов в графе кода. Т.е. в таком простом примере как привели вы — сложность одинакова — там только один путь. Но строк кода в три раза больше. Это другой коефициент. Да и очевидно, что первый фрагмент сложнее второго.
Но. Если бы там были ветвления, то в три раза и увеличилась бы сложность от трех повторений. Далее, эти маршруты меряются по теории в одном куске кода. Если будет два метода с одинаковым выполнением — цикломатическая сложность увеличится на два. Насколько я понял (не написано про отдельные методы), но проведя эксперимент, видно, что просто цикломатические сложности методов суммируются.
Глубина наследования — другой коэфициент. Тоже вынос в методы, вынос в базовые классы, хоть и уменьшает по DRY размер кода и повторения, но увеличивает этот коэфициент. Он негативно влияет на простоту кода.
«Вы как-то странно со мной не соглашаетесь, полностью повторяя мои выкладки о цене применяемых методов O_O.»
А я с вами и не несоглашаюсь. Только не соглашаюсь с отдельным моментом — что сведение сокращение повторений сложных кусков не уменьшает сложность.
Там много критериев. Самый известный — цикломатическая сложность. Грубо говоря, это количество независимых маршрутов в графе кода. Т.е. в таком простом примере как привели вы — сложность одинакова — там только один путь. Но строк кода в три раза больше. Это другой коефициент. Да и очевидно, что первый фрагмент сложнее второго.
Но. Если бы там были ветвления, то в три раза и увеличилась бы сложность от трех повторений. Далее, эти маршруты меряются по теории в одном куске кода. Если будет два метода с одинаковым выполнением — цикломатическая сложность увеличится на два. Насколько я понял (не написано про отдельные методы), но проведя эксперимент, видно, что просто цикломатические сложности методов суммируются.
Глубина наследования — другой коэфициент. Тоже вынос в методы, вынос в базовые классы, хоть и уменьшает по DRY размер кода и повторения, но увеличивает этот коэфициент. Он негативно влияет на простоту кода.
«Вы как-то странно со мной не соглашаетесь, полностью повторяя мои выкладки о цене применяемых методов O_O.»
А я с вами и не несоглашаюсь. Только не соглашаюсь с отдельным моментом — что сведение сокращение повторений сложных кусков не уменьшает сложность.
Повторю: у майкрософта в студии встроен анализатор кода, который показывает индекс, насколько код хорош. Конечно, эта вещь не абсолютна, т.к. мерки снимает автоматические. Но стоит посмотреть на эти коэфициенты. Проводят исследования и как-то сложность превращают в вычислимую величину.
Цикломатическая сложность — это как тест на IQ. Позволят отделить безнадежных даунов от всех остальных :). Как уже говорилось, коду, в котором зашкаливает цикломатическая сложность DRY не поможет — его изначально неправильно написали — другая проблема, другие решения.
Только не соглашаюсь с отдельным моментом — что сведение сокращение повторений сложных кусков не уменьшает сложность.
Соглашусь, что мое высказывание было не совсем корректным. Мы не можем адекватно и точно померить сложность, поэтому более корректно будет, что на мой взгляд «применение шаблона проектирования или техники написания кода не убирает сложность, а переносит ее в другое место. При этом сложность в целом может как повыситься, так и понизиться — но в общем случае у нас нет адекватных инструментов чтобы это оценить».
не стоит реализовывать абстракцию к драйверу БД. Старайтесь тщательнее оценивать все, что может добавить сложности вашей системе. Учтите, что зачастую многие абстракции реализовываются в сторонних продуктах и библиотеках. К примеру, смотря на каком языке вы пишите, Hibernate (Java), Doctrine (PHP) или Active Record (Ruby) – все идут с уровнем абстракции вокруг БД, и ORM.
По моему опыту «стандартные» ORM — почти всегда зло, особенно если недостаточно хорошо их знаешь.
Не-функциональные требования не описывают поведения системы, они описывают дополнительные свойства, по которым можно оценить качество продукта. Т.к. описание качества предполагает знание продукта, плохие концепты можно часто определить по отсутствию не-функциональных требований.
Это шедевральное высказывание, спасибо огромное!!!
Впредь буду пользоваться только этим определением качества продукта, любого продукта!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Три ключевых принципа ПО, которые вы должны понимать