Как стать автором
Обновить

Комментарии 56

>>> Если вы работаете над сайтом, который размещается на LAMP стеке – какова вероятность того, что клиент сменит БД

Был какраз этот случай. С мускуля на постгрес через несколько лет разработки с plain sql запросами в коде. Внезапно понадобилось переходить. Шанс обысно мизерный, но если такое случится, сложно представить сколько человеко-часов придется затратить. В таком случае лучше использовать сразу какой-нибудь Zend_Query, заодно у вас будет единая точка для запросов куда можно воткнуть профилирование, кеширование и прочая. Менджмент рисков никто не отменял.
Никто ведь не говорит, что нужно писать запросы в DB прямо в бизнес-логике. Можно ввести DAO — это тоже абстракция, но абстракция, покрывающая именно ваши проблемы. При смене DB вам потребуется лишь реализовать новые DAO классы, причём public contract и сигнатура методов сохранятся, равно как и юнит тесты. Кстати, даже используя Zend_Db, при смене DB вам также придётся переписывать запросы.
По поводу кеширования, профилирования и прочее — то при чём здесь Zend_Db? Вы серьёзно считаете, что без использования Zend_Db этого не достичь?
Если не секрет, какие были причины смены SQL сервера? Я человек в базах не сильно сведущий, Postgre даёт значительный прирост производительности или что-то ещё?
У PostgreSQL намного лучше планировщик запросов, что очень сильно влияет на сложных запросах с кучей подзапросов/джойнов. MySQL в таких случаях норовит сделать full table scan, а PostrgeSQL обходится выборкой по индексу.
Компоненты-компоненты… Эх, а вы видели, что сейчас происходит в Google Play? Хочу я к примеру найти плеер для интернет-радио: огромный выбор чего только можно, каждое приложение лезет в телефонную книгу, в вайфай, в автозапуск и всем обязательно нужен доступ к GPS, ну или как минимум к данным сети. Без всего этого проиграть интернет-радио невозможно. После скачивания приложения что нужно сделать? Не, не читать Readme, даже не лазить в настройки, нужно обязательно авторизоваться через твиттер, фейсбук или что-то подобное. Мне интересно, там вообще есть приложения без социальных сетей? Каждое второе приложение в собственном стиле, изобретает свои UI-виджеты. Обязательно, в каждом плеере должен быть будильник, магазин треков и возможность отобразить обложку играющего трека.

И вот через все это прорываешься к строчке ввода адреса, откуда собственно играть радио, а этого самого адреса и нету. Потом идешь в FAQ на официальном сайте, находишь вопрос про добавление своего URL — а там сказано. что такое не поддерживается. Тихо материмся и удаляем приложение. Я это сделал множество раз, а радио-плеера так и не нашел.

А вы говорите про 80% затрат на 20% функционала. Где он, этот функционал? Нужный мне функционал на j2me был реализован в пределах 100 строк, включая UI. Видимо, придется не только заниматься своей версией Icecast, но и создавать плеер.
Более того, такого легковесного simple-плеера с трудом найдешь и под винду :) Винамп 2.97 только молодец в этом плане…
AIMP.
foobar
Не зря мною написано было «легковесный». Винамп кушает до 20мб оперативки, в то время как аимп и фубар стремятся к 40-50+
Давно уже не смотрю, сколько памяти отбирает проигрыватель — на фоне современных приложений он у меня даже не в первой десятке.
foobar у меня занимает 13МБ при проигрывании. У вас что-то не так :)
AIMP занимает 15 МБ.
50Мб, вот уж трагедия, у меня вкладка этой страницы в хроме больше памяти сжирает.
Может, дело в бюджете? Например, приложение без социалок, магазина треков и ещё тысячи свистелок не монетизируется и, следовательно, может быть написано «для себя», но не в маркет.
Судя по комменту iFrolov он бы рад и купить такое приложение, но нет.
Возможно, прибыль от покупки сотней энтузиастов не котируется по сравнению с доходами от тысячи «условно-бесплатно» закабаленных.
Эта статья как раз и призвана научить программистов писать код грамотно, не тратя времени на «нужные» (читай ненужные) фичи.

По поводу 80/20, в плане фич, есть старая, но очень хорошая статья.
Читал оригинал, статья замечательная.
Вероятно, стоило перевести статью более литературно, а не так дословно. Всё-таки такие понятия как информация, знания и данные различаются по смыслу. Так же различаются понятия класса и объекта.
Например, сразу бросилось в глаза:
Принцип DRY требует, чтобы такие части информации встречались в вашем коде один, и только один раз.

The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.

После прочтения оригинала, мне показалось, что под термином «piece of knowledge», автор статьи понимает как формализацию знаний о том, как что-то сделать, в виде алгоритма, выраженного на ЯП, так и некоторую информацию, представленную в виде данных, к которым можно обращаться, используя некоторую переменную. Таким образом, смысл цитаты можно свести к тому, что не надо повторять одинаковые фрагменты кода и дублировать данные без необходимости.
Это ещё нормально. Вы бы видели как переводят книги по Computer Sience на русский — коллега заказал как-то Фаулера, так смысл некоторых фраз мы искали в моём англоязычном варианте.
Не могу не согласиться. Но мне кажется, если переводить эту цитату, вырвав из контекста — ваш вариант более понятен. Но если ее читать в рамках статьи — суть остается той же. Ну и вообще — довольно непросто философствовать о принципах ПО на литературном языке.
НЛО прилетело и опубликовало эту надпись здесь
Статья, если честно, неглубока. Я не знаю, кем должен быть читатель на Хабре, чтобы никогда не слышать о принципе Парето («20 % усилий дают 80% результата, а остальные 80 % усилий — лишь 20% результата») и о бритве Оккама («не плоди сущностей без надобности»). Ладно, это мелочи. Но про Эйнштейна, конечно, лихо. Если верить автору, Эйнштейн просто выкинул эфир и суждение что «время не является константой» и тут же изобрел ОТО. Между прочим, до подтвержения Хабблом факта расширения Вселенной Эйншейн на 12 лет включил в свою теорию космологическую постоянную, потому что придерживался теории статической Вселенной, а потом сокрушался своей ошибке. Тут у него kiss-принцип, видимо, не сработал.

Вообще, проблема разработки чего-то сложного не нова. Я помню интервью одного нашего космонавта, который верно заметил, что успех космических программ имел в основе не столько технологии, сколько способность разработчиков взаимно увязывать компоненты системы. Одному агрегату нужно больше питания, значит, нужны батареи потяжелее, значит нужно нарастить мощность ракеты, а она ограничена, в итоге ищем альтернативный способ подзарядки и т.д. Архитектору программных систем приходится решать эту задачу оптимизации постоянно. Для решения есть полный арсенал — шаблоны проектирования, интерфейсы, корпоративные стандарты документирования, UML и т.д. Планирование, увы, не всегда срабатывает, поскольку решения не всегда лежат на поверхности, а то бы Гугл еще до Цукенберга запланировал сделать мегасоцсеть. Боюсь, реально работающий рецепт один — приобретать опыт, учиться, пробовать и быть дисциплинированным в работе.
Вы немного отвлеклись от смысла статьи. Ваши комментарии относятся к деталям, которые приводятся для сравнения, или же имеют некую аналогию с идеями, которые хочет донести автор. Цель статьи — научить/рассказать/напомнить программистам о трех постулатах разработки.
Кто-нибудь может мне объснить в чем конкретно заключается принцип DRY? По описанию вроде бы похоже на модульный подход, но зачем какой-то новый термин? И почему нельзя повторять именно себя?
Фишка DRY — как можно больше атомарной реализации. У вас всегда должна быть возможность внести некоторые изменения в алгоритмах, без страха, что вся система рухнет.

P.S. Википедия, первый абзац — очень четкая, понятная формулировка.
Грубо говоря — не копипастить код из одной системы/подсистемы/функции/участка функции в другую, даже используя в качестве буфера мозг. Основная причина, имхо — сложность поддержки двух и более одинаковых кусков кода (нашли баг в одном куске — нужно не забыть исправить в других местах, где этот же код используется или, например, два почти одинаковых куска кода и сложно заметить, а заметив понять, различие). Дополнительная — общее уменьшение количества кода и, как следствие, размеров бинарников. И термину 100 лет в обед.
Больше б подобных статей на хабре. Вечер удался :)
А 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.
Вроде не противоречат. Согласно KISS мы не должны применять принцип DRY преждевременно.
При написании кода второй раз необходимо произвести рефакторинг и вынести общий код в отдельную функцию.
Рефакторинг — это не добавление и не изменение функционала. YAGNI распространяется на функционал, а не на рефакторинг. Если что-то повторяется — рефакторинг обязателен. Говорить про рефакторинг «нам это не понадобится» — нельзя. Поэтому не противоречит.

Вообще со статьей местами очень не согласен. YAGNI — это основополагающий принцип и не вижу проблем в сложных проектах его использовать
Даже не совсем так. YAGNI не только на функционал, но и на хитрые реализации, паттерны распространяется. Но не на рефакторинг. Рефакторинг — механическая вещь, ведущая к KISS. И он делается просто на каждом шаге по ТДД. Это неотъемлемая часть процесса разработки.
Не нравится мне такой перевод:
впомнив фразу из моего любимого фильма «Касабланка» — в любви законов новых нет — так создан свет
.
В оригинале:
The fundamental things apply, as time goes by.

Я бы перевел так: «Со временем, фундаментальные вещи берут верх».
В крайнем случае «Любовь приходит и уходит, а кушать хочется всегда».
Я сам долго пытался найти естественный перевод, перепробовал разные варианты, но ни один из них не доносил смысла, который автор хотел передать. Бросив, просто нашел перевод песни, который, как мне кажется, действительно полноценен.
Я смысл статьи понял как:

Пишите код хорошо, и у вас будет хороший код.

Как-то так.
Как бы парадоксально сие не было, но большинство разработчиков очень сильно сопротивляются написанию «хорошего кода». Они могут придумать сотню отмазок почему надо писать абы какой код, и почему нет времени на написание хорошего. Ежики и кактус…
Если код писать хорошо и проектировать приложение не торопясь — то проект запустится намного раньше и съест намного меньше денег.
Типичные будни сотфверных компаний:
Аврал! Красная кнопка. Люди орут бегают туда сюда, кто то принес огнетушитель. Грузовик с костылями уже въезжает во двор, главный архитектор раздает программерам их пачками и все несутся к рушащемуся зданию прибивать эти самые костыли со всех сторон.
П.С. Делать качественно всегда дешевле и быстрее, но людям очень сложно сломать этот стереотип
Под разработчиками вы имеете в виду только программистов или всю команду, включая менеджмент?
Под разработчиками я имел ввиду программистов. тим лидов и архитекторов. Тех кто отвечает за разработку и проектирование системы.
Один из моих основных принципов при программировании (на самом деле и в остальных сферах жизни) — «Телепатов нет»

(это утверждение также подкрепляется такими высказываниями как, если что-то можно понять не правильно, то оно обязательно так и будет понято).

Данный принцип призывает как упрощать (привет KISS), так и комментировать сразу (а не потом, когда-нибудь после кода-ревью или пинка, направленного на улучшение документации).

Вообще, чем меньше вы оставите места для «додумывания» (да простит меня Русский язык), тем лучше.
Плюсики, конечно, везде проставил. Но в рамках стариковского брюзжания скажу, что мне не нравятся такие статьи. Есть в них что-то от небезызвестной книги «Банды Четырех», которая, по мнению многих разработчиков, нанесла чудовищный удар индустрии программирования.

DRY, KISS и YAGNI — это великолепные принципы. Замечательные. Но это инструменты — и, как у любых инструментов, у них есть цена использования. Для чего предназначены эти принципы? В первую очередь — для борьбы со сложностью, с «complexity problem». А как показывает практика, сложность программного решения — это некая константаня величина, диктуемая его объемом. Ее нельзя просто взять и убрать. Ее можно спрятать во фреймворк — тогда на верхнем уровне будет несколько красивых строчек кода а под ними — айсберг. Ее можно спрятать в иерархию — тогда вместо копипасты будет вызов метода. Можно спрятать в абстракцию — тогда вместо ручного управления памятью будут умные указатели. Но ее, #$!#!#@, нельзя убрать из кода :(.

И все эти замечательные принципы убирают сложность в одном месте, добавляя ее в другом. Так же как упомянутые мной паттерные проектирования убирали архитектурную сложность в одном месте — добавляя ее в другом за счет введения дополнительного слоя абстракции (для большинства паттернов). И если, не зная этих лежащх в основе концепций, применять DRY, KISS и YAGNI — то можно легко получить ситуации, когда разработчик убирает три копипасты по две строчки, заменяя их классом на двадцать. Или, в соответствии с принципом KISS, не делает абстракции базы данных, потому что «ну кто же будет в LAMP базу данных менять»?

Только вот про основы, борьбу добра и зла программистов с проблеммой сложности кода, что именно дает DRY или YAGNI, зачем они нужны — не пишут. Пишут готовые кулинарные рецепты, бережно передаваемые из поколения в поколение — «об этом еще Дейкстра говорил!». Не уверен, что это есть хорошо.
Задача этих принципов не ликвидировать сложность, это нереально. Эти принципы позволяют снизить сложность, раздробить ее на мелкие, управляемые части, или вообще не писать сложных вещей.
Сложность можно снизить, только если решение усложнено. Если решение не усложнено (а это, на вскидку, прмерно половина случаев) — то можно только понизить концентрацию сложности в одном конкретном месте куда путем переноса части сложности в другие места. Про это никто не пишет, что меня немного огорчает.

Наверное, это всем очевидно. Только почему тогда основная масса кода такого низкого качества? :)
Нельзя быть немного беременным. Если решение сложное — его стоит упростить, а не прятать куда либо.

Мне кажется, вы путаете понятие сложности, с уровнем взгляда на общую архитектуру системы. Если смотреть на проблему с вершины айсберга — да, все довольно сложно. Но, в хорошем проекте, эта сложность собрана из хорошо написанных, качественных, небольшых частей, каждая из которых не такая уж и сложная. Если вдруг у вас не так, вам есть к чему стремиться, используя принципы, описанные в этой статье.
По моему вы путаете сложность с количеством информации. Которая только от задачи должна зависеть в идеале.

А вот сложность реализации может быть любая. Вот, пример. Когда-то меня «заставили» писать научную статью. Для галочки. У меня не было никаких идей и муза была в отпуске, а настороение не очень, поэтому я написал на первое выражение 0 = 0. Далее начал наращивать. В конце у меня получилась большая система сложных уравнений. И была она математически верной. Но суть осталась — ноль равен нулю. Я такое часто вижу в разработке ПО.

У нас один чудак написал проект для переливки таблицы из эксель в БД. Там тысячи классов. Понесло, что называется. Искусство ради искусства. Куча паттернов, куча совершенно не обоснованных решений. Погоня за гибкостью на самокате. )))
Один из примеров. В базе есть справочник, который он создал. У элементов справочника есть целочисленные идентификаторы. Но он решил, что в коде пользоваться идентификаторами — хардкод и опасно (он вообще странный). И поэтому дал имена элементам справочника вроде «Item_1», «Item_2» и т.д. Потом в коде парсит и находит цифру. Она уже как бы от идентификатора не зависит.

Почти все проблемы, которые я видел в «архитектуре», работая в разных компаниях — это излишняя сложность. Когда люди пытаются не отталкиваться от требований, а предвидеть и сделать более гибкое решение или более оптимальное (преждевременная оптимизация). В результате появляется код, оснований писать который не было никакого. Этот код требует поддержки и создается костыль за костылем, «чтобы уравнять уравнения».
Это вы вообще про детский сад рассказываете, про усложненные решения. Подразумевается, что код, к котоому прменяются паттерны и подходы сам по себе адекватен и не усложнен. И вот тогда начинаются вопросы с ценой этих паттернов.
Я видимо ваш комментарий понял буквально.

Логика и наоборот действует — можно сложное упрощать. А если вопрос стоит в том, что уже достаточно упрощено, то я следую принципу максимального соотвествия кода задаче (не реализации). Прятать куда-то что-то за имена и вращать разными паттернами не нужно, потому что чаще всего есть одно-два понимания, как в коде правильно закодить требования, нечего выдумывать.

Сегодня была ситуация. Дали задание проанализировать как создать архитектуру для одной задачи. Вклиниться в уже созданную БД, это просто очередная задача.
Через полчаса получили развернутый ответ, всё время просто письмо заняло. И начали удивляться, что я мало времени потратил на «создание архитектуры».

Какая еще архитектура. Есть требования, они однозначно переводятся в сущности БД. Нечего выдумывать, анализ занимает время всего лишь, чтобы понять смысл задачи. Остальное автоматом.

Так и с любым кодом. Если люди начинают что-то прятать, высовывать — то это или рефакторинг, чтобы лучше код соответствовал задаче или не совсем понимают, зачем это нужно.
Так и с любым кодом. Если люди начинают что-то прятать, высовывать — то это или рефакторинг, чтобы лучше код соответствовал задаче или не совсем понимают, зачем это нужно.


Все просто. Паттерны и подходы (тот же указанный в статье DRY) решают проблемы. Какие проблемы? Проблемы концентрации сложности в одном месте. Например, что делает DRY: если у нас один и те же строки кода повторяются в нескольких местах, то в тот момент когда нам нужно будет их поменять — нам придется менять во многих местах. И если мы все эти места не найдем — мы получим сложноотлавливаемую багу. Принцип DRY позволяет избавится от этой проблемы — повторяющуюся строчки меняются на одну, и общий код выносится в одно место — класс, функцию, декоратор — whatever.

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

Но никто почему-то про это не пишет. Большинство бегает и кричит — «А-а-а-а-а, применяйте DRY, он кле-е-е-е-евый, он копипасту убирает! Он превращает быдлокод в мегакод!». Но это не так, это ложь. Он не бесплатно убирает копипасту — он ее убирает ценой добавления еще одного уровня абстракции. Это цена, и в ряде случаев мы совсем не хотим ее платить. Но никто это не оценивает, а потом получается код, где количество слоев абстракции настолько высоко, что даже я его понять не могу :(.

Как уже говорилось, это в рамках старческого брюзжания, не обращайте внимания :). Все эти проблемы возникают когда все остальное более-менее. Когда же стоит вопрос, что написанное студентов решение в 10000 строк на самом деле можно написать в 100 просто другим способом — то тут проблемы применения паттернов отходят на второй план :).
да нет же! ))
Если сложный кусок повторяется несколько раз, то во столько же раз и сложность растет. Если условно сложность куска кода равна единице, то пять повторений — сумма — сложность 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.»

А я с вами и не несоглашаюсь. Только не соглашаюсь с отдельным моментом — что сведение сокращение повторений сложных кусков не уменьшает сложность.
Повторю: у майкрософта в студии встроен анализатор кода, который показывает индекс, насколько код хорош. Конечно, эта вещь не абсолютна, т.к. мерки снимает автоматические. Но стоит посмотреть на эти коэфициенты. Проводят исследования и как-то сложность превращают в вычислимую величину.


Цикломатическая сложность — это как тест на IQ. Позволят отделить безнадежных даунов от всех остальных :). Как уже говорилось, коду, в котором зашкаливает цикломатическая сложность DRY не поможет — его изначально неправильно написали — другая проблема, другие решения.

Только не соглашаюсь с отдельным моментом — что сведение сокращение повторений сложных кусков не уменьшает сложность.


Соглашусь, что мое высказывание было не совсем корректным. Мы не можем адекватно и точно померить сложность, поэтому более корректно будет, что на мой взгляд «применение шаблона проектирования или техники написания кода не убирает сложность, а переносит ее в другое место. При этом сложность в целом может как повыситься, так и понизиться — но в общем случае у нас нет адекватных инструментов чтобы это оценить».
не стоит реализовывать абстракцию к драйверу БД. Старайтесь тщательнее оценивать все, что может добавить сложности вашей системе. Учтите, что зачастую многие абстракции реализовываются в сторонних продуктах и библиотеках. К примеру, смотря на каком языке вы пишите, Hibernate (Java), Doctrine (PHP) или Active Record (Ruby) – все идут с уровнем абстракции вокруг БД, и ORM.

По моему опыту «стандартные» ORM — почти всегда зло, особенно если недостаточно хорошо их знаешь.
Не-функциональные требования не описывают поведения системы, они описывают дополнительные свойства, по которым можно оценить качество продукта. Т.к. описание качества предполагает знание продукта, плохие концепты можно часто определить по отсутствию не-функциональных требований.


Это шедевральное высказывание, спасибо огромное!!!

Впредь буду пользоваться только этим определением качества продукта, любого продукта!!!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории