Комментарии 27
Очень хорошо в качестве концентрированного обзора для расширения изначально узкого кругозора, но каждая отдельная тема требует отдельной статьи. Иначе остаются за кадром основания и мотивировки для появления каждой проблемы, да и неясными оказываются последствия. В отдельных статьях можно было бы привести по нескольку конкретных примеров, чтобы хорошо почувствовать, что происходит, если использовать определённые принципы и подходы, и что происходит, если не использовать.
При этом последователи догм очень агрессивны.
когда начинаешь копать, то выясняется, что все хорошо знают определение, но довольно слабо понимают, где это можно и нужно использовать, почему это надо и какие проблемы решает.
Мне было бы крайне интересно узнать, что такое параметрический полиморфизм и полиморфизм ad-hoc.
С чисто обывательской точки зрения, полиморфизм — это возможность писать определённый обобщённый код таким образом, чтобы его конкретное исполнение зависело от объекта, который поступает в обработку. Или, точнее, от его класса или типа. (Это и есть полиморфизм подтипов?)
В книгах и статьях нередко приводят, как мне кажется, довольно искусственные примеры применения полиморфизма. Наверное, самый важный вопрос — это вопрос о том, в каких ситуациях полиморфизм действительно нужен. Например, можно было бы написать библиотеку, аналогичную по своим функциям STL, но без применения шаблонов (как это и делалось в стародавние времена). Совершенно очевидно, что, в такой ситуации, полиморфизм будет важнейшим способом реализации всевозможных контейнеров.
И ещё. Я подозреваю, что у полиморфизма есть неприятная оборотная сторона. Если, вдруг, кому-то понадобится соорудить новый подтип, то, может оказаться, что этот подтип плохо вписывается в общую схему.
Если, вдруг, кому-то понадобится соорудить новый подтип, то, может оказаться, что этот подтип плохо вписывается в общую схему.
Дык принцип подстановки Лисков как раз про то чтоб подтипы вписывались, нет разве?
Параметрический полиморфизм - это дженерики (параметры типов)
Ad-hoc полиморфизм - перегрузка функций и операторов (выбор варианта во время компиляции).
Ну и по идее должен быть какой-то полиморфизм для прототипных языков, в которых нет подтипов, но есть полиморфизм
Не все знают, что недавно в мире редакторов произошла революция. Раньше было четкое разделение на IDE (которые дают рефакторинг, autocomplete, подсказки, документацию и запуск кода) и обычные редакторы, которые дают подсветку и небольшой набор базовых возможностей, типа перехода по файлам. Но какое-то время назад всё изменилось.
А, что изменилось в мире IDE и сторонних редакторов?
Разве они стали больше, например, поддерживать языки мало присутствующие в ротации?
Как раз ниже рассказывается про LSP.
Грубо говоря - хочешь автокоплит, рефакторинг, разные крутые штуки - покупай или качай IDE.
Хочешь скорости, простоты, комп не тянет IDE? Бери редактор (vim, notepad++, sublime и тд)
И как еще было - под каждый стек\язык своя IDE. Щас можно просто взять редактор и всунуть в него то, что самому хочется.
Изменилось то, что разработчик языка может создать language server, и поддержать сразу много ide
хотя сейчас уже надо говорить main
рождение нового ритуала...
Делать неблокирующее ревью через маленькие изменения позволяет подход Trunk-based Development.
Делать неблокирующее ревью позволяет отдельная ветка для разработки фичи, которая для этой фичи является мастером, пока фича не будет полностью сделана и протестирована. Долгая фича делится на подзадачи, каждая подзадача проходит ревью и мержится в ветку фичи. Мастер периодически мержится в ветку фичи для поддержания актуальности кода.
Как технику тяжело читать при таком количестве грубых англицизмов. Неужели так трудно соблюдать строгость терминологии и при переводе применять полный нативный термин, как это принято во всей академической литературе.
Недумаю, чтобы вместо "давления" использовали прежуре от pressure, вместо температура темпреча от temperature, вместо колесо вилл от whell.
Такой же незаметной и довольно пагубной практикой является безумное стремление многих российских компаний к разработке в один присест, одновременно сосуществующая с другой крайностью в виде бесконечной разработки в виде вечного бета-теста, что мы наблюдаем во всех текстах посвещенных менеджменту в IT, и одновременно написанным людьми, которые реальный менеджмент ни разу не видели, ни нюхали.
Некоторые программисты этого не замечают, потому что сами не придают этому значения. А многие и не скажут прямо, посчитав темой табуированной. Но стоит им хоть раз увидеть картину здоровую, как например в студиях разработки видеоигр в начале нулевых, то каждый скажет - "Вот, вот оно! Мы так хотим".
Да ладно, какие нулевые? Давайте уже сразу вернёмся к двоичному коду) И к методологии "ну будем, короче, делать так". Относительно претензий в адрес не нюхавших менеджмента: если их аргументация ценна и работает, то совершенно не имеет значение нюхали они менеджмент или пили. У вас argumentum ad hominem получается с этой претензией.
Как технику тяжело читать при таком количестве грубых англицизмов. Неужели так трудно соблюдать строгость терминологии и при переводе применять полный нативный термин, как это принято во всей академической литературе.
Какая ирония
При таком подходе даже если вы что-то напишете не так, то быстро и легко сможете это поправить. Есть еще дополнительный бонус от такого подхода. Когда программист что-то долго пишет и где-то в начале уходит не туда, он может идти не туда целую неделю и даже больше. В результате накопленный негативный эффект будет слишком большой. Но если бы он вливал в main очень маленькими кусочками, то вы бы намного раньше увидели, что он пошел не в ту сторону, и поправили это.
Вот тут не могу согласиться. Одно дело, когда разработчик неделю писал в своей ветке что-то не то - да, он потратил время, но ущерб проекту на этом заканчивается. И совсем другое дело, когда он за эту неделю сделал 50 мелких коммитов в trunk (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.
Барбара Лисков - это вообще-то она. Самая известная ее работа - язык CLU, который стал пионером абстрактных типов данных и одним из первых, куда ввели исключения. Но помнят ее почему-то только за какой-то дурацкий принцип.
Да и я бы не сказал, что принцип дурацкий; при написании кода мы практически всегда стараемся в той или иной мере ему следовать, пуусть и неосознанно. Например (в C#), переопределяя метод ToString, обычно никто не будет выбрасывать исключений, а спроси почему это плохая идея - ответят, что вызывающий код может не знать, что объект такого типа требует особого обращения, и вызвать ToString, и неожиданно упасть. Или, к примеру, реализуя метод Equals, технически мы можем делать всё что угодно, хоть картинки котиков показывать, но обычно мы туда помещаем логику сравнения объектов, потому что это именно то, что ожидает потребитель интерфейса.
Так это же и есть проявления принципа Лисков, к которым мы привыкли и воспринимаем как данность. Ну так и многие "принципы", "паттерны", "законы" лишь формализуют то, что давно известно и применяется. Так вот живешь и не знаешь, что всю жизнь говорил прозой.
Если вы про это место
Про Лисков. В своей статье про SOLID он сказал:
, то я тоже раз пять перечитал, и тоже возмутился, но потом посмотрел, что "он" - это дядя Боб. :)
Очень люблю эти фразы про то, что любую задачу можно разделить и лить супер маленькими мр-ами. Только все почему то сразу забывают - что смотрящий мр теперь не видит ни картины того, что делает разработчик, ни вообще что происходит т.к. видит маааленький кусок логики оторванный от задачи, и ему потребуется стянуть себе ветку (что конечно никто делать не будет), чтобы посмотреть все зависимости влитые до этого. Что на декомпозицию задачи уйдёт дополнительный день разработки, а самое главное, что когда все в итоге не заработает в конце - то исправляющие мры/рефакторинг скорее всего затронут насквозь кучу предыдущих изменений и мр-ов станет больше, а значит еще дольше смотреть.
Серьёзно, работал на проекте одного банка где было ограничение на мр по количеству строк - так я убедился что просто разделив код можно протащить в кодовую базу вообще что угодно, главное делить фичу так, чтобы каждый компонент выглядел максимально нейтрально сам по себе. 1 коммит на 5 интерфесов, второй на 5 xml с разметкой, и вот уже смотрящий не увидит что класс управляющий разметкой творит какое-то говно, потому что и разметку уже не видно, и вроде интерфейс уже из кодовой базы.
Trunk-based разработка это такой же карго-культ. Который в принципе разбивается об SLA на уровне 2-4 девяток. Пример с букингом плохой: 100000 для них пыль, а вот для компаний поменьше это повод для разбора полетов на уровне СЕО и прочих боссов. И автор не сообщает, что же делать, если фича-флагов становится много и как управлять этим зоопарком.
Короче, уменьшать бюрократию надо так, чтобы она не возникала в других местах. И своп карго-культов, генерализация удачных практик одной компании на всё и вся - не выход. Кому то транк будет помогать, если потеря транзакций из за багов не катастрофична, но легко представить сценарии, где он будет опасен (например торговые системы, которые не должны терять деньги, и прочий критичный софт - те же транспортные системы).
Что делать? Прежде всего - думать в лббой непонятной ситуации.
Мифология и реальные методы прагматичного программирования