Мастер сельского афоризму
0,4
рейтинг
19 сентября 2012 в 21:09

Разработка → Иллюзия эффективной разработки: проектирование

    Этот пост является продолжением: Иллюзия эффективной разработки: управление

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



Церковь имени Совершенного кода

    Проблема стара как мир — использование идеи без понимания ее смысла. В нашем случае все начинается тогда, когда с передовыми методиками проектирования знакомится человек, не имеющий достаточного опыта, чтобы понять зачем они нужны, или же не имеющий достаточно знаний, чтобы сформулировать связь между типовыми задачами отрасли и подходами, излагаемыми в книге. Результат один — предлагаемые идеи принимаются на веру. А ввиду непонимания области применения, идет применение этих идей там, где они неприменимы.
    Мир IT хорош тем, что те, кто не учится, тот не задерживается в нем надолго. И постепенное понимание того, зачем на самом деле нужно ООП, паттерны и т.д. таки приходит к таким программистам. Тех же, кто так ничего и не понял, очень легко определить по безапелляционности суждений в пользу какого-либо подхода и готовности признать людьми второго сорта всех тех, кто такого подхода не придерживается. И если это тимлид во главе индусского полка, то такое поведение еще можно как-то объяснить, а в остальном, я считаю, что таким тимлидам стоит многому научиться у киногероя бессмертного творения Светланы Басковой, призывающего всех быть людьми.
    Не переставайте каждый раз задавать себе вопрос, почему тот подход, который вы используете стоит применить в конкретном случае. Отдавайте себе отчет в том, какие проблемы такой подход решает. Убедитесь, что эти проблемы существуют в вашем проекте. Если в результате этой простой процедуры вы пришли к конечным обоснованиям вида «это хорошая практика», а то и «моя вера сильна», то, возможно, это косвенный признак того, что выбранный подход в данном случае не подходит.


От бумажного самолетика к шаттлу

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


Велосипед для езды по стенам

    Сегодня мы имеем множество замечательных проектов вида github.com, sourceforge.net и т.п., не говоря уже репозитариях кода для конкретных языков. И именно их наличие сыграло немалую роль в плане насаждения убеждения о том, что велосипеды это плохо, и что всегда есть готовое решение. Безусловно, если вы решите писать свой gui-тулкит для windows или же шаблонизатор для php, то я бы бросил все незаконченные дела, встал, застегнул штаны и пошел бы прочь с вашего поля, выражая при этом мнение большинства.
    Но как только мы возьмемся за что-нибудь чуть более нетипичное, чем указанные выше вещи, как перед нами в полный рост встанет проблема качества тех библиотек, которые кажутся такими доступными. Под качеством я подразумеваю 3 вещи:
  • функциональность — необходимо самолично прочувствовать тот момент, когда обнаруживается, что в выбранной библиотеке отсутствует 10% функционанала, на котором будет держаться 90% вашего проекта. Разработчики — такие же люди как и вы, и обычно в эти очень нужные 10% входят самая грязная работа за которую никто не хочет браться.
  • документация — плохая документация просто бич всех молодых проектов, а без нее добро пожаловать в код
  • качество кода — определяет возможность расширения и или даже изучения API в случае плохой и отсутствующей документации

    Если смотреть на качество библиотек трезво, то можно все-таки допустить вариант когда вам придется писать аналог самому. Просто потому что так будет проще. Так будет быстрее и эффективней. Так будет неправильно. А еще ваш велосипед правда может быть особенным — в том плане, что даже при мнимом изобилии решений ни одно из них не подойдет вам в полной мере. Хотя вы можете получить индульгенцию за это святотатство, выложив свой вариант на github. Чтобы другие погорели на нем или написали свой. А еще время развертывания приложения прямо пропорциональна количеству библиотек, которые необходимо развернуть вместе с ним.
    Отдельно выступает проблема выбора между новым проектом или развитием уже существующего решения. Наиболее это выбор тяготеет над web-программистами — львиная доля проектов в web довольно типовые, для которых существуют движки cms, web-магазинов, соцсетей и пр. На первый взгляд всегда кажется, что логично доделать уже существующее решение до требований ТЗ, чем писать свой велосипед с нуля. Особенно логичным это кажется после того, как на одном и том же движке подряд выполняется несколько проектов, причем быстро и изящно. Однако же можно и погореть, упершись в ограничения архитектуры или в причудливую верстку, или даже в скорость, с которой все будет работать после того как работа будет закончена. Для себя я вывел эмпирическое правило — если проект занимает по моим прикидкам более месяца, то лучше писать с нуля или на фреймворке общего назначения. Ну как лучше — мне лучше, а вам придется выводить свои правила в зависимости от того, с чем вы работаете.
    Просто помните, что бывают случаи, когда парсинг xml регулярными выражениями будет предпочтительнее, чем использование байндинга к libxml, а написание простенького на первый взгляд интерент-магазина будет более простым на Yii, чем на основе PrestaShop. Все, безусловно, уже придумано до нас, но не все это воплощено в коде в том виде, чтобы этим можно было удобно пользоваться.


На передовом рубеже технологий

    Одним из самых простых способов заработать авторитет в мире ИТ является следование трендам. Чем скорее вольетесь в тренд, тем лучше. Будете думать и проверять насколько тренд эффективен в действительности — не успеете в первые ряды, и почетного звания senior-bleeding-edge-developer вам не видать. Я вовсе не говорю, что новое — это плохо, я даже верю в то, что применение новых технологий может как-то помочь вам обойти конкурентов(но я все-таки считаю, что хороший менеджер продаж или отличный юзабилити дадут вам на порядок больше шансов завоевать первенство, чем грамотная архитектура). Я лишь хочу заметить, что перед тем как выбрать для своего проекта новомодный фреймворк неплохо быть уверенным в том, что:
  • в этом фреймворке присутствует хотя бы часть реально необходимого для вашего проекта функционала
  • этот функционал правда можно будет применить — ну т.е. взять и использовать, я не плясать с бубном, чтобы это хоть как-то заработало
  • вы настолько уверены в себе и своих подчиненных, что знаете, что если наткнетесь ошибку, из-за которой вся разработка может встать, то вы сможете путем дебага и копания во внутренностях фреймворка устранить ее
  • у вас есть время на реализацию предыдущего пункта

    Опять-таки, отдавайте себе отчет в том, для чего вы выбрали новую технологию Y, при наличии технологии X, которая уже хорошо оттестирована, имеет коммьюнити и вообще используется повсюду.


Теория и практика

    Я долго думал, что написать тут, но как-то получалось, что слишком объемно или слишком конкретно, из-за чего многие бы подумали, что я являюсь идейным противником каких-то технологий и подходов. Поэтому я ограничусь пятью пунктами:
  • Не принимайте за истину выкладки теоретиков(этой статье, например) или чужой опыт, если не уверены, что он получен на основании создания решения очень близкого к вашему.
  • Насколько бы убедительны не были примеры в документации, помните, что они зачастую синтетические
  • Вообще любая концепция придумывается для решения какой-то задачи или класса схожих задач, нет никакой гарантии, что ваша задача гармонично вписывается этот класс
  • Сложные на первый взгляд концепции применительно к вашей задаче могут обернуться выкладкой в пару строчек, понятных большинству сельских учителей информатики
  • Очень осторожно относитесь к концепциям «не для всех» или «опередившим свое время», которые годами остаются уделом небольшой группы людей — они могут оказаться чрезмерно сложными в применении, но зачастую просто практически бесполезными

    Вот и понимайте их как хотите. И помните о разнице между олимпиадным и промышленным программировании.


Только бы не ошибиться

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


Тимлид — наш царь, отец и бог

    Признаться вся эта статья была навеяна тем фактом, что мне приходилось работать в командах с разными тимлидами, у каждого из которых были свои представления о том, как нужно писать код правильно. Все они были в деталях правы, но беда в том, что эти детали у каждого из них весьма сильно расходились. Более того, я рискну предположить, что если всех их свести за одним столом в питейном заведении, а после перевести беседу в русло сравнения императивного и функционального программирования или же об отличиях Dependency Injection от старой доброй Factory, то без вмешательства охраны не обойдется.
    Все тимлиды тоже люди, все они имеют свои убеждения и знания, полученные на основе выполнения каких-то своих проектов. Иногда такие убеждения соответствуют реальности, иногда — нет. Иногда последнее может вам казаться из-за того, что вы еще не сталкивались с задачами, которые бы привели вас к пониманию того, почему делать нужно именно так. В любом случае, воспринимайте все, что скажет тимлид как его требования, а не как реально хорошие вещи. Если его советы пройдут проверку практикой — замечательно, а если нет, то переубеждать человека в такого рода ошибках обычно бесполезно.


Заключение

Не существует универсальных правил хорошего тона в разработке. Существуют правила, которые могут принести пользу в какой-то ситуации. Даже если таких ситуаций много, это не значит, что вы не столкнетесь с другой, когда правила, когда-то помогавшие, окажутся бесполезными. И не забывайте задавать себе вопрос, почему вы выбрали именно это решение проблемы, а не другое.
@PerlPower
карма
168,0
рейтинг 0,4
Мастер сельского афоризму
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (50)

  • +2
    Я бы сформулировал более кратко:
    1. Учись и эксперементируй.
    2. Не бойся совершать ошибки
    3. Не верь наслово
    Как-то так))) А вообще надо статью скинуть нашему тимлиду =))
    • 0
      К третьему я бы еще добавил: развивай интуицию и прислушивайся к ней (=
    • +6
      и пункт 0. Найди работодателя, который все эти твои метания оплатит:)
      • +7
        Вот тебе и чайник — дает правильные, практичные советы :-)
    • 0
      Хорошая статья, я думаю, он с удовольствием почитает;-)
      • 0
        Ахаха, и тут ты меня нашёл)) ни куда не спрятаться
  • +3
    Статья об абсолютно жизненных вещах.
    У меня был случай на хакатоне — выбрали слишком большой Java EE проект для двадцати четырех часового события, по-этому я вообще забросил стандартные вещи, писал больше «говнокодом»(ну, к примеру, связывал бины не на уровне интерфейсов), а мой друг утверждал что всё это ужас, нужно выдумать пару паттернов, сделать всё красиво и правильно… и при этом не мог аргументировать почему мы должны тратить на это время. Когда событие закончилось, я всего за 1 вечер сделал код красивым.
    А ещё, бывает за собой замечаю муки совести что нужно сделать именно так, потому что так все делают, но мне никогдане понадобится то, ради чего все так делают…

    Спасибо! Ваша статья мне понравилась, буду рекомендовать всем.
  • +9
    Статья аккуратная и нейтральная, но между строк почудилось мне это:
    1. Задолбали вы со своим SOLID и MVC!
    2. Следующему, кто спросит «Зачем изобретать велосипед?» — сломаю шею.

    P. S. С автором согласен на все 100%.
    • 0
      Никто меня не задолбал и у меня в мыслях не было кому-то что-то ломать, я просто указал на трудности с которыми придется столкнуться при неграмотном использовании «хороших» практик. Давайте таки не будем читать между строк, это же не Библия, чтобы ее нужно было толковать.
      • +2
        Почему вы решили написать статью на эту тему?

        P. S. Мне почудилось, я не говорил это от вашего имени…
        • +1
          Потому что вижу в публикациях только то, что нужно использовать правильные методы. Можно сказать такими публикациями все заполнено. Обратная сторона вопроса представлена только публикациями на тему паттернов головного мозга. Мне кажется, что проблема шире и потому я решил ее осветить в этой статье.

          P.S. Я понимаю что ваше мнение по поводу прочитанного, но вы сформулировали это так, что немалая часть читателей может подумать что я правда так написал, как в вашем первом комментарии, потому и ответил вам.
          • +1
            Одобряю.

            P. S. Прошу прощения.
            • +1
              Блин, написал так, будто мое одобрение чего-то стоит, бес попутал.
    • +1
      С MVC прикол в том, что он в первоначальном виде в вебе просто неприменим, применяется, на самом деле, его модификация MVA.

      А так, SOLID и MVC (и дизайн-паттерны 1994 года выпуска) — это солидные раскрученные бренды, хорошая тема для разговора и повод для демонстрации провинутости и лояльности ведущим трендам;-) Как раз чтоб поспрашивать на собеседовании.
      • 0
        Правильно, валун им в огород, если бы MVC было бы хоть сколько ни будь внятной концепцией, не получилось бы так, что каждый разработчик продукта и каркаса (пусть даже очень-очень-очень опытный разработчик/архитектор) понимает его абсолютно по разному. И SOLID туда же, приблизительно по буковку L, концом вперед.
  • 0
    Будете думать и проверять насколько тренд эффективен в действительности — не успеете в первые ряды, и почетного звания senior-bleeding-age-developer вам не видать.
    — По мне так это все не нужные звания, различные сеньеры-помидоры… С автором согласен, смысл гоняться за трендами, ровно такой же, как и гоняться за последними тенденциями в моде и посещать каждую гламурную тусовку — время зря прожжигать
  • +3
    И не забывайте задавать себе вопрос, почему вы выбрали именно это решение проблемы, а не другое.

    А если на каждую проблему задавать вопрос и отвечать на него, то тоже далеко не уедешь и увязнешь. Так ведь?

    Мне свой подход удалось сформулировать 2 словами — просто и очевидно. Если не просто и/или не очевидно — значит нужно переделать.
    • 0
      При всей актуальности описанной вами проблемы, она относится к психологии, а не к методологии проектирования ПО. Да и вопросов в каждом проекте придется себе задавать не так много.
      • 0
        Вам не за что извиняться — вы же написали «почудилось».
  • 0
    Если исходить из Ваших мыслей, то у программирования очень много общего с боевыми искусствами: споры о методологиях аналогичны утверждениям «мое кунг-фу лучше твоего», в реальной схватке все решит опыт и немножко удачи, ну и все дерутся не постановочно, а так, как могут, иначе есть риск получить в глаз :) И только истинные мастера, достигшие вершин, разят врагов в соответствии с идеями своей школы. Но в принципе, это выглядит немного странно и мало кому нужно, а большинству достаточно простой рукопашки.
    • 0
      Лучше неправильные представления тимлида о правильности кода, чем никаких. Это как на войне — лучше плохой план, чем никакого.

      Насчё боязни ошибиться — ну, известно, что за ошибки наказывают, и для избежания наказания надо заранее перевести на что-то стрелки.
      • 0
        сорри, не туда написал, хотел к самой статье оставить комментарий
      • 0
        А ещё лучше — если этот человек не будет тимлидом
      • 0
        Никаких нету. Бывают у каждого свои, и тогда получается говнокод.
  • 0
    Спасибо, очень толково написано. Действительно, успех продукта решают люди, а не паттерны. Но всегда нужно выделять время на рефакторинг.
  • +1
    Improveзируйте, господа!
  • +4
    Нельзя спроектировать систему с первого раза. Можно умудриться задать такие рамки, внутри которых можно будет «дописывать», но это не всегда самый эффективный путь, т.к. рамки начинают в какой-то момент диктовать «куда можно развиваться, а куда нет».

    По моим наблюдениям штатным является переписывание хотя бы два раза. Больше 4 — признак незамеченной проблемы.

    А highload начинается в тот момент, когда его не ждут. Когда его ждут — он никогда не highload.
    • 0
      Да, все как у Брукса — первая система на выброс.
  • 0
    Хорошая статья, но с одним не соглашусь, что нужно перед тимлидом молчать если с ним не согласен. Тимлид тоже человек, ему свойственно ошибаться, и как раз такое прямое выражение своих мыслей очень способствует наставлению на путь истинный. Но, разумеется, тут нужно знать меру и не начинать спорить и давать выход эмоциям, т.к. это приведет к конфликту.
    Если люди в команде будут молчать, то качество системы не превысит уровня лида, а если будут влиять на разработку, то превысит.
    Это все из личного опыта, граблей и шишек.
    • +1
      Поэтому я считаю, что лучше самому тимлиду при необходимости спрашивать, есть ли какие-то замечания у сотрудника, даже незазорно и советоваться. Сотрудник в таком случае может нормально высказать мнение, зная, что оно будет рассмотрено.
      Тимлиду это может дать дополнительную информацию о проекте, о сотруднике.
      Если решение программиста ошибочное — указать почему в данном случае так делать не стоит. Программист не будет питать иллюзий «а вот надо было так делать, было бы лучше».
      Если решение хорошее, то применить, поблагодарить. Это очень мотивирует программиста.
      Ну и вообще может быть родится третье решение в результате беседы.
      Естественно, вся ответственность по принятии только на тимлиде. Если даже оказалось что программиста решение было не очень, то уж никаких сваливаний вины — сам думать должен.
  • 0
    Не знаю, случайность или нет, но последние 5 лет у нас успех проекта зависит от характера разработчика, но никак не от кода. Если человек — гнус, никакие паттереы не помогают, все загибается.
  • 0
    Аж чуть не прослезился) Сам всегда утверждал, что нужно исходить и конкретной задачи. Нужен конкретный сервис — пиши сервис, нужна универсальная платформа — будь добр учесть все нюансы масштабирования
  • 0
    Такое наверное полезно почитать после многолетней практики следования за «модными» веяниями, с богатым опытом разработки.
    А поскольку я молодой программер, то не понимаю, почему нужно задавать себе какие-то вопрос «почему именно так, а не эдак».
    Всё просто: надо пробовать сперва, а потом сравнивать и задавать себе вопросы, если останется время.
  • 0
    Иногда (часто) тренды, бренды — всего лишь маркетинг. Ничего плохого не хочу говорить о майкрософт, но эти любят сделать какую-нибудь очевидную простую вещь, а раскручивать так, что кажется, в истории такого рывка вперед не было.

    Я против велосипедов, но иногда надо и смотреть на профит. Пример, ORM. Кучу раньше времени тратил по прикручиванию. То хранимые процедуры не получается прикрутить, то ленивость, то еще что-то. Потом сделал свой генератор классов и код, связывающийся с бд, компилируется в рантайме. Кода на несколько страниц. Без напряжения делается за день. Вот и вопрос — велосипед ли я изобретал? Стоило мне тратить время на эти все фреймворки, которые тяжелые, много функционала, а тот, который нужен — либо его нет, либо дописывать костыли надо, которые соизмеримы со своим кодом.
  • 0
    Один из главных вопросов перед использованием «сложного велосипеда»: насколько этот «велосипед» надежен, функционален и расширяем в своей функциональности? И если функциональность проверить можно, то с надежностью сложнее — либо тесты, либо сложившаяся практика использования, которую надо изучать.
  • 0
    На самом деле слово «программирование» куда уже, чем упомянутый в начале «мир IT», а статью можно распространить на весь это мир (да и не только на ИТ).

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

    Спасибо за статью! Главное теперь — не забывать, что работа должна быть интересной (на которой есть куда расти и развиваться не только пивным животом, но мозгами), а работодатель — хорошим (т.е. поддерживающим упомянутые про работу ожидания не только при приеме на работу, но и в процессе, как морально, так и материально)! :))
  • 0
    Статья очень понравилась, добавил в избранное.
  • 0
    Каждый из нас лично для себя формирует технологию на основе опыта, получаемого через пробы и ошибки, через эксперименты и последующие выводы. В какой-то момент времени я стал больше анализировать сам процесс разработки и проектирования, выделять какие-то общие принципы в совершенно разных задачах. Одним из выводов, которые я сделал была попытка формализации общих принципов в технологию разработки, которая помогала мне решать задачи:

    0. Идея

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

    1. Технология и инструментарий

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

    Иначе говоря, мы можем использовать самые сложные и самые универсальные инструменты и технологии для того, чтобы прибить дома полочку к стене, даже не смотря на то, что в контексте идеи реализация задуманного требует обычного молотка и пары гвоздей.

    2. Прототипирование, разработка

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

    Есть разные бокалы и емкости для различных напитков, но даже самой обычной чашки будет достаточно для всех возможных их видов, какими бы изысканными они ни были. Вопрос этики.

    3. Готовый продукт, релиз

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

    Велосипеды? Нет, лишь вариации на тему.
  • –1
    Извините, но я сомневаюсь, что кто-то кроме вас понял что вы имели ввиду. Во всяком случае после первого прочтения.
  • 0
    «Ползи, улитка,
    по склону Фудзи
    вверх до самых высот»

    Спасибо за хорошую статью.
  • 0
    Не понимаю почему скорость разработки и качество всякий раз ставятся по разные стороны баррикад. Чтобы придерживается простых принципов и партнеров вроде SOLID и DI, не нужно больше времени, чем на написание спагетти кода. По моему личному опыту — даже меньше.

    Так почему же написанию плохого когда постоянно ищут оправдания?
    • 0
      image
      • 0
        Из картинки следует, что делая быстро и халтурно, разработчик становится дешевым.
        А мне думается, что каждый разработчик хочет стать дорогим. В таком случае он должен делать быстро и качественно. Это если верить картинке. А на самом деле халтура, в конечном счете, обходится дороже.
        • 0
          Вы неисправимый идеалист :)
    • 0
      Все правильно. Но для того, чтобы писать качественный код нужно иметь либо опыт, либо время на тупление (выбор варианта как лучше, а что в какой ситуации делать, а можно ли вот так и так...). Начинающим программистам время на тупление не выделяют обычно, вот и получается плохой код. SOLID и DI — не панацея, лучше чем ничего конечно, но и их внедрение не является моментальным.
      • 0
        Эти штуки просто применить. Это можно делать почти механически, проходя по чек-листам. Семи пядей во лбу быть не обязательно.
        SOLID и DI делают код легко изменяемым и расширяемым. Даже если вы промахнулись с глобальной архитектурой, изменить ее будет удивительно просто.
        • 0
          Да что вы такое говорите?

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

          > SOLID и DI делают код легко изменяемым и расширяемым.
          Нет, не делают. Они регламентируют только часть методик построения хорошего кода, в другой части можно так накосячить, что и через пару дней автор не сможет понять что он там написал.

          > Даже если вы промахнулись с глобальной архитектурой, изменить ее будет удивительно просто.
          Да не в одной сказке. SOLID не регламентируют макро-архитектуру, и если запутаны между собой макро подсистемы, что возможно даже при SRP, изменения будут крайне тяжкими. Даже при эталоне совершенности кода, изменять что-то в архитектуре, обычно, чрезвычайно сложно.
          • 0
            Спорить не буду, но я имею опыт, опровергающий ваши слова.
            • 0
              Ну так и у меня есть опыт и соображения подтверждающие мои слова, но ведь это все эмпирическое…
  • 0
    Мне кажется, Вам удалось сделать почти невозможное — написать лучшую статью из всех, которые я читал про проектирование.

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

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