Один знакомый называл классы "а", "b", "c"...
так это плохо или хорошо?
Чтобы эффективно применять знания на практике, имеет смысл не делить на черное и белое, а задавать вопросы "зачем, с какой целью?".
Можно наваять один большой скрипт и монопроцедуру, которая вроде как решает задачу, работает, использует кучу разных непонятных переменных, но если ты это написал за одну ночь, запустил, выполнил задачу и теперь тебе этот код никогда больше не понадобится (например, тебе нужно было один раз быстро проанализировать/переупорядочить какие-то данные, с которыми больше ничего такого делать не придется). Цель - сделать быстро, а не красиво. Пожалуйста, воруй@убивай, если это тебе сэкономит время, ибо зачем тратить лишний день на красоту?
С другой стороны, есть энтерпрайз. Это:
* много кода,
* много этапов обработки данных,
* много разработчиков,
* требования к надежности,
* требования к возможности поддержки кода.
Все полезные практики перечислять долго, поэтому затрону те, которые имеют отношение к поднятому вопросу.
Добрая часть рекомендаций по хорошему стилю сводится к тому, чтобы
1. дробить большие куски кода (будь то классы, методы, процедуры и т.п.) на как можно более логически атомарные,
2. переиспользовать код, где это возможно,
3. позволять статическому анализатору находить ошибки еще до сборки.
Это позволяет легче понимать (объектное мышление интуитивно для человека) и дорабатывать код коллегам (или завтрашнему себе), делать меньше ошибок (будь то шибки копипаста, опечатки в аргументах), позволяет делать код более масштабируемым, т.е. при изменении логики отдельных частей не придется переписывать сразу много кода.
Таким образом, подробная декомпозиция - штука в большинстве случаев хорошая.
Как относиться к мему, я до конца не решил.
* Это либо быдлокодеры обсуждают работу нормального разработчика с опытом разработки, не понимая, зачем он закладывает в код масштабируемость, отчего проводимая им декомпозиция кажется им бессмысленной и чрезмерной.
* Либо действительно обсуждается разработчик, который не имеет опыта практического проектирования, что пытается компенсировать старательным абьюзом фишками объектно-ориентированного программирования. Что любопытно, если он не совсем шизофреник, то у него выше шансы вырасти в приличного разработчика, чем у джуна, который пишет монолитами.
Можно наваять один большой скрипт и монопроцедуру, которая вроде как решает задачу, работает, использует кучу разных непонятных переменных, но если ты это написал за одну ночь, запустил, выполнил задачу и теперь тебе этот код никогда больше не понадобится (например, тебе нужно было один раз быстро проанализировать/переупорядочить какие-то данные, с которыми больше ничего такого делать не придется). Цель - сделать быстро, а не красиво. Пожалуйста, воруй@убивай, если это тебе сэкономит время, ибо зачем тратить лишний день на красоту?
С другой стороны, есть энтерпрайз. Это:
* много кода,
* много этапов обработки данных,
* много разработчиков,
* требования к надежности,
* требования к возможности поддержки кода.
Все полезные практики перечислять долго, поэтому затрону те, которые имеют отношение к поднятому вопросу.
Добрая часть рекомендаций по хорошему стилю сводится к тому, чтобы
1. дробить большие куски кода (будь то классы, методы, процедуры и т.п.) на как можно более логически атомарные,
2. переиспользовать код, где это возможно,
3. позволять статическому анализатору находить ошибки еще до сборки.
Это позволяет легче понимать (объектное мышление интуитивно для человека) и дорабатывать код коллегам (или завтрашнему себе), делать меньше ошибок (будь то шибки копипаста, опечатки в аргументах), позволяет делать код более масштабируемым, т.е. при изменении логики отдельных частей не придется переписывать сразу много кода.
Таким образом, подробная декомпозиция - штука в большинстве случаев хорошая.
Как относиться к мему, я до конца не решил.
* Это либо быдлокодеры обсуждают работу нормального разработчика с опытом разработки, не понимая, зачем он закладывает в код масштабируемость, отчего проводимая им декомпозиция кажется им бессмысленной и чрезмерной.
* Либо действительно обсуждается разработчик, который не имеет опыта практического проектирования, что пытается компенсировать старательным абьюзом фишками объектно-ориентированного программирования. Что любопытно, если он не совсем шизофреник, то у него выше шансы вырасти в приличного разработчика, чем у джуна, который пишет монолитами.
И да, если я неправильно понял, и вопрос был не про мем в посте, а про test1 в комментарии, то здесь ситуация однозначная: все имена должны быть понятными, а то в отдельных случаях и достаточно подробными. Чем больше можно понять из самого кода, тем меньше комментариев придется писать.
Алсо, я бы всем начинающим разработчикам после прочтения учебников сразу рекомендовал бы познакомиться вживую с кодом какого-нибудь приличного проекта на практике: доработать, написать плагин, да хотя бы почитать его и подебажить. Дает хорошее представление, как делать надо. А в процессе написания своего кода изучать антипаттерны программирования (много где приведены, легко нагуглить) и бить себя за них по рукам.
Алсо, я бы всем начинающим разработчикам после прочтения учебников сразу рекомендовал бы познакомиться вживую с кодом какого-нибудь приличного проекта на практике: доработать, написать плагин, да хотя бы почитать его и подебажить. Дает хорошее представление, как делать надо. А в процессе написания своего кода изучать антипаттерны программирования (много где приведены, легко нагуглить) и бить себя за них по рукам.
Всегда интересовало, а насколько подробными они должны быть? Читал где-то, что в каком-то ЯПе названия функций пускай и полные, но состоят чуть ли не из десятка слов. Как не-программист не вижу в этом ничего плохого, но люди вроде как плюются
Звучит какая-то жесть. Ибо имена методов обычно представляют собой глаголы или глагольные словосочетания: postPayment, deletePage, save и т. д. Методы чтения/записи и предикаты образуются из значения и префикса get, set и is согласно стандарту javabean. Откуда взяться жести с названиями функций на десятки слов?
ну когда я пишу дополнения для сайтов, беру встроенные имена классов и дополняю их уже конкретикой функционала, 3-4 слова получается в имени
Только что погуглил, на стаке лежит вопрос на эту же тему с названием метода "getNumberOfSkinCareEligibleItemsWithinTransaction"
По ситуации.
1. Есть стиль, принятый в конкретном проекте. О нем следует договориться, и его следует придерживаться. Опять же, в зависимости от языка также могут быть свои рекомендации.
2. Здравый смысл. Не надо пытаться уместить в наименование документацию, но поставь себя на место человека, который ищет в проекте нужный класс или метод, и ему нужно выбрать из нескольких похожих. Если пара лишних слов в названии переменной позволит избежать написания комментариев без ущерба понятности - вперёд. Но если таких переменных будет много, то глазам будет сложнее зацепиться, так что с часто используемыми классами, методами, переменными следует быть осторожным, чтобы не превратить код в стену текста.
3. Скептикам можно также напомнить, что любая IDE поддерживает автодополнение, так что удобство набора не является валидным аргументом против длинных наименований.
4. Умение правильно пользоваться жаргоном поспособствует лаконичности.
1. Есть стиль, принятый в конкретном проекте. О нем следует договориться, и его следует придерживаться. Опять же, в зависимости от языка также могут быть свои рекомендации.
2. Здравый смысл. Не надо пытаться уместить в наименование документацию, но поставь себя на место человека, который ищет в проекте нужный класс или метод, и ему нужно выбрать из нескольких похожих. Если пара лишних слов в названии переменной позволит избежать написания комментариев без ущерба понятности - вперёд. Но если таких переменных будет много, то глазам будет сложнее зацепиться, так что с часто используемыми классами, методами, переменными следует быть осторожным, чтобы не превратить код в стену текста.
3. Скептикам можно также напомнить, что любая IDE поддерживает автодополнение, так что удобство набора не является валидным аргументом против длинных наименований.
4. Умение правильно пользоваться жаргоном поспособствует лаконичности.
Немчинского слушаю иногда, говорит за test1 можно увольнять
ошибка выжившего и бомбардировщики
про декомпозицию согласен и рефакторинг туда же, но есть "Но" - вся эта красота разбивается об тупоголовых заказчиков-бизнесменов нижнего порядка, как например в моем случае.
Соболезную. Проще перечислить, что НЕ ломается о плохо выстроенные отношения заказчик-исполнитель. И ничего тут не сделаешь ни как разработчик, ни как РП, если политика компании – стелиться под каждый чих заказчика. Но есть и плюсы: можно провести себе стресс-тест (если переживешь, а не уволиться или получишь нервный срыв), научиться делать быстро минимальные вещи.
С другой стороны, зато в крупных ответственных компаниях все бюрократизировано от "а" до "я". Это, конечно, обеспечивает должный порядок, но местами и вставляет палки в колеса.
C'est la vie.
С другой стороны, зато в крупных ответственных компаниях все бюрократизировано от "а" до "я". Это, конечно, обеспечивает должный порядок, но местами и вставляет палки в колеса.
C'est la vie.
"Если вам понадобится банан, то придётся сначала накодить джунгли с обезьянами" (c)
Та это же вроде хорошо или я чёт не понял?
Это называется оверинжениринг, когда мы излишне усложняем систему без видимой на то причины даже в далёкой перспективе.
Причём, мой 20-летний опыт программирования говорит мне, что в 99% случаев все эти "заделы на будущее" остаются мертвым кодом и геморроем в жопе тех, кто в этой лапше бесполезной хуеты будет разбираться через 5 лет, после таких горе-проектировщиков.
Любят эту хуйню джуно-миды, которые находятся на пике эффекта Даннинга-Крюгера, когда им кажется, что они охуенны и всё понимают.
Но на самом деле, бизнесу чаше всего нужно бывает совсем не то, что они там себе нагородили в своих фантазиях.
Да, гибкость это хорошо, но нужно понимать, где она нужна, а где нахуй не всралась.
И да, в большинстве мест любого проекта гибкость именно что нахуй не всралась, и лучше убрать её, сделав максимально просто.
Любят эту хуйню джуно-миды, которые находятся на пике эффекта Даннинга-Крюгера, когда им кажется, что они охуенны и всё понимают.
Но на самом деле, бизнесу чаше всего нужно бывает совсем не то, что они там себе нагородили в своих фантазиях.
Да, гибкость это хорошо, но нужно понимать, где она нужна, а где нахуй не всралась.
И да, в большинстве мест любого проекта гибкость именно что нахуй не всралась, и лучше убрать её, сделав максимально просто.
>>Но на самом деле, бизнесу чаше всего нужно бывает совсем не то, что они там себе нагородили в своих фантазиях.
ага, как говорил один заказчик "Мне нужны были жигули, а вы начали мерседес строить"
В том плане, что дохрена усложнили систему, в изначальных требованиях выглядевшей в стиле "нажал на кнопку - выстрелил в тыкву"
ага, как говорил один заказчик "Мне нужны были жигули, а вы начали мерседес строить"
В том плане, что дохрена усложнили систему, в изначальных требованиях выглядевшей в стиле "нажал на кнопку - выстрелил в тыкву"
Смолвил как боженька. Чем меньше кода написано для решения задачи - тем лучше, Дийкстра еще об этом говорил. YAGNI и все такое. Но нет, в простом проекте прорастают эти абстракции абстракций и базовые классы моделей. Тесты ради тестов, каждый чих готовы пркрыть тестами. А через год - код идет на свалку, хотя писался как на 30 лет поддержки.
Что ещё хуже, любое совершенно мизерное изменение также требует переделки кучи тестов.
А так как в проекте чаще всего допиливаются существующие вещи, а не пишутся новые, львиная доля времени уходит не на реализацию логики, а на поддержку "ахуенной архитектуры" и тестов.
Баги при этом, естественно, никуда не деваются. Потому что тесты тестируют код, а не логику.
А так как в проекте чаще всего допиливаются существующие вещи, а не пишутся новые, львиная доля времени уходит не на реализацию логики, а на поддержку "ахуенной архитектуры" и тестов.
Баги при этом, естественно, никуда не деваются. Потому что тесты тестируют код, а не логику.
>Что ещё хуже, любое совершенно мизерное изменение также требует переделки кучи тестов.
>А так как в проекте чаще всего допиливаются существующие вещи, а не пишутся новые, львиная доля времени уходит не на реализацию логики, а на поддержку "ахуенной архитектуры" и тестов.
Так суть всей этой архитектуры и тестов именно в том, чтобы такого не происходило. Они НУЖНЫ для того, чтобы писались новые вещи, а не допиливались старые, чтобы на поддержку уходило меньше времени, а не больше. Для того, чтобы не тесты правились под изменения, а чтобы изменения проходили тесты.
>А так как в проекте чаще всего допиливаются существующие вещи, а не пишутся новые, львиная доля времени уходит не на реализацию логики, а на поддержку "ахуенной архитектуры" и тестов.
Так суть всей этой архитектуры и тестов именно в том, чтобы такого не происходило. Они НУЖНЫ для того, чтобы писались новые вещи, а не допиливались старые, чтобы на поддержку уходило меньше времени, а не больше. Для того, чтобы не тесты правились под изменения, а чтобы изменения проходили тесты.
Вот сейчас грустно стало за профессию.
Тут прям наоборот я бы сказал. Надо смотреть на проект. Может и правда оверинжиниринг, хотя он не то что бы часто ухудшает код, побег за байтами давно кончился, а зато качество кода у таких людей обычно ан высоте и структур хоть и много но все понятно.
Как раз описанный в посте программист хорош, о он даже не по з.п. дорог, а по времени. И проебавшийся по всем пунктам ПМ у которого завтра презентация а потом сразу в продакшн предпочитает нанять долбоеба, который вообще не использует наследование, или у которого все наследуемое в композиции. Да, он быстро наколупает инвалида с двумя костылями и отправит его ковылять в продакшн, а потом проект захочется изменить и на уровне с Классом "Пользователь" добавить класс "Бухгалтерша - функционал не открывать", а окажется что для этого надо ломать вс е вплоть до класса "мультивселенная", а не подредактировать капсулированные "люди".
Как раз описанный в посте программист хорош, о он даже не по з.п. дорог, а по времени. И проебавшийся по всем пунктам ПМ у которого завтра презентация а потом сразу в продакшн предпочитает нанять долбоеба, который вообще не использует наследование, или у которого все наследуемое в композиции. Да, он быстро наколупает инвалида с двумя костылями и отправит его ковылять в продакшн, а потом проект захочется изменить и на уровне с Классом "Пользователь" добавить класс "Бухгалтерша - функционал не открывать", а окажется что для этого надо ломать вс е вплоть до класса "мультивселенная", а не подредактировать капсулированные "люди".
Вопросы к архитектору. Спринтики и прыганье по задачам для пидоров, галер и веба. Нормальные продукты закладывают потенциал для расширения и кастомизации, а древовидная струкура с четкой вложенностью объектов приятна для масштабирования. Пусть продакшн будет на 5-10% позже а часть функций и правда ЮАГНИ, но продукт все равно лучше и полнее. Мое имхо и ниипет, я пм, что хочу то ворочу.
Пма как раз ебать это и не должно. It-ownerа ещё может быть, но не пма. Лишние абстракции не принесут никакой пользы и будут лишь лишним грузом, который надо поддерживать с вероятностью в 90%. Создание чего-то на опережение допустимо только при том, что в течении эпика эта хуйня будет использоваться. Спринтики - оптимальная хуйня для развивающегося ПО, водопадик оставь воякам, игроделам и пидорам, которые будут потом пиздеть что-то типа "а ещё нам надо это" когда паровоз уже ушел.
Что блядь значит "поддерживать" неиспользуемые модули. Висят себе как в релизной версии и пусть висят.
И как раз пидоры, которым "надо это", а паравозик не то что ушел - уже пришел на конечную - как раз спринтиками прыгают. Есть продукт, концепция и архитектура, в которую нужно заложить и "мультивселенная" и "формы жизни" и еще желательно что бы из утки можно было вытянуть клюв и приклеить к бобру без проблем создав утконоса, а не допиливая Австралию. А спринтики пусть будут в финале для кома0нд которые делают "пользователь 846" и им прилетает задача добавить ему третью руку.
И ПМа это еще как ебет, когда клиент очередной попросит утконоса, а архитектор думал что ЮАГНИ.
Вот недавно было, правда я там был не ПМом а заказчиком для системы в которую внедрялся мой продукт, что система состоит из трех БД - приняла состояние - отработала логику - отдала на ЮИ, которые вот вообще не связаны, а когда появилась задача знать состояние третьей БД которая к подвязана и не имеет логики ЮИ при отработке логики второй БД, что бы динамически менять статус события которое уже висит окошком, а не плодить десяток однотипных событий по сработке датчика, то их тимлид обосрался и дооолго со мной спорил с позиции "а может это вам не надо", так как это всей команде работы на три недели, а фича блядь очевиднейшая, вообще не ебу как они продукт продавали без нее.
И как раз пидоры, которым "надо это", а паравозик не то что ушел - уже пришел на конечную - как раз спринтиками прыгают. Есть продукт, концепция и архитектура, в которую нужно заложить и "мультивселенная" и "формы жизни" и еще желательно что бы из утки можно было вытянуть клюв и приклеить к бобру без проблем создав утконоса, а не допиливая Австралию. А спринтики пусть будут в финале для кома0нд которые делают "пользователь 846" и им прилетает задача добавить ему третью руку.
И ПМа это еще как ебет, когда клиент очередной попросит утконоса, а архитектор думал что ЮАГНИ.
Вот недавно было, правда я там был не ПМом а заказчиком для системы в которую внедрялся мой продукт, что система состоит из трех БД - приняла состояние - отработала логику - отдала на ЮИ, которые вот вообще не связаны, а когда появилась задача знать состояние третьей БД которая к подвязана и не имеет логики ЮИ при отработке логики второй БД, что бы динамически менять статус события которое уже висит окошком, а не плодить десяток однотипных событий по сработке датчика, то их тимлид обосрался и дооолго со мной спорил с позиции "а может это вам не надо", так как это всей команде работы на три недели, а фича блядь очевиднейшая, вообще не ебу как они продукт продавали без нее.
Я, как человек, специализирующийся на доработке всякого легаси говна, могу сказать, что самое худшее, что может случиться с проектом - это превращение его в мешанину говноклассов, которые нахуй не нужны, и ничего не делают. Которые были созданы "ради гибкости", так никогда и не пригодились, и превратили проект в кучу вонючего навоза, в котором нихуя невозможно понять из-за тонн бессмысленных сущностей и абстракций.
Я за 20 лет видел многое. И код, написанный математиками, с функциями на тысячи строк, и переменными типа a, ab, cc. И адскую многопоточную лапшу с кучей разделяемых объектов без намека на синхронизации. И ебанистическую мешанину из языков и технологий, перемешанных причудливым образом.
Но ничего нет хуже, чем оверинжинирнутый код, в котором фантазии говноархитектора воплощены в гору навоза под названием "гибкие заделы на будущее". Я, как человек, часто бывающий в этом самом будущем таких проектов, очень хорошо знаю, что эти фантазии, если они не основаны на реальных требованиях, так навсегда и остаются вонючим говном. Из-за которого приходится за немалые деньги нанимать людей типа меня.
Я за 20 лет видел многое. И код, написанный математиками, с функциями на тысячи строк, и переменными типа a, ab, cc. И адскую многопоточную лапшу с кучей разделяемых объектов без намека на синхронизации. И ебанистическую мешанину из языков и технологий, перемешанных причудливым образом.
Но ничего нет хуже, чем оверинжинирнутый код, в котором фантазии говноархитектора воплощены в гору навоза под названием "гибкие заделы на будущее". Я, как человек, часто бывающий в этом самом будущем таких проектов, очень хорошо знаю, что эти фантазии, если они не основаны на реальных требованиях, так навсегда и остаются вонючим говном. Из-за которого приходится за немалые деньги нанимать людей типа меня.
Расширение и кастомизация это для монолитных систем с перспективой внедрения и поддержки в течении десяти лет и более. Нонешний тренд микросервисов как раз предполагает быстро говнять, выпихивать, все равно через год перепишут или бизнес функция изменится и сервис в утиль пойдет. Нет смысла городить абстракции.
Именно. Ты вот прям все точно описал, мне нечего добавить по сути.
Только блядь я ебу как вы все жопой комментарии читаете когда я говорю, что как раз монолитные внедряемые системы мы и пилим, причем учитывая промышленный уклон - 10 лет далеко не предел жизни продукта.
Но нет, пришло десять долбоебов умеющих только в веб и микросервисы и пихают свое очень важное мнение. Насмотрелся я на большие проекты прогорающие из-за аджайла, модных "ничего лишнего" и следование трендам, когда 3-5 команд сидит в переговорке с пустыми взглядами и четвертый час тасует разноцветные бумажки и придумывает активность, вроде голосования чашками, что бы не сдохнуть от тоски.
По моему половина вообще не понимает что такое архитектура системы, создание продукта и лепит на ходу. Ну да, тут скрам самое оно, начинаешь делать гоночный автомобиль, через год получаешь реактивный суперджет с гаражом вместо салона, после правок клиента кладешь в гараж ладу и сдаешь проект.
Только блядь я ебу как вы все жопой комментарии читаете когда я говорю, что как раз монолитные внедряемые системы мы и пилим, причем учитывая промышленный уклон - 10 лет далеко не предел жизни продукта.
Но нет, пришло десять долбоебов умеющих только в веб и микросервисы и пихают свое очень важное мнение. Насмотрелся я на большие проекты прогорающие из-за аджайла, модных "ничего лишнего" и следование трендам, когда 3-5 команд сидит в переговорке с пустыми взглядами и четвертый час тасует разноцветные бумажки и придумывает активность, вроде голосования чашками, что бы не сдохнуть от тоски.
По моему половина вообще не понимает что такое архитектура системы, создание продукта и лепит на ходу. Ну да, тут скрам самое оно, начинаешь делать гоночный автомобиль, через год получаешь реактивный суперджет с гаражом вместо салона, после правок клиента кладешь в гараж ладу и сдаешь проект.
>Пусть продакшн будет на 5-10% позже
Но это не 5-10%, это 500-1000%.
Но это не 5-10%, это 500-1000%.
Нет. Вообще мимо. Тут охуенно ломаются принципы KISS и YAGNI. Этот программист - говно.
Васяны-прогеры дороже хороших программистов в разы, ибо не могут создать легкоподдерживаемую систему, а хуячат говнокод, из-за которого каждая маленькая задача превращается в пятидневный мозгоеб.
Васяны-прогеры дороже хороших программистов в разы, ибо не могут создать легкоподдерживаемую систему, а хуячат говнокод, из-за которого каждая маленькая задача превращается в пятидневный мозгоеб.
А КИСС это вообще не про то, блядь. "Проще" это не меньше кода и быстрые костыли. На счет васянов я согласен но и "быстрые хорошие прогеры" только для галер, где сдал проект и забыл.Клиент хочет поддержку и доп.фичи? Плоти много деняк и дай нам пол года перебрать треть проекта с нуля.
А как раз описанное в посте упростит, как я писал выше и масштабируемость, и возможности кастомизации, и передачу кода от команды к команде, и собственно работу командами. И не только для кода но и для железа. Пусть лишние выводы и структуры висят на плате и в прошивке соответственно. Есть не просят. А попросили тебя фичу прикрутить - не надо плату переразводить или АРХИТЕКТУРУ приложения менять. Не раз с этим сталкивался.
А как раз описанное в посте упростит, как я писал выше и масштабируемость, и возможности кастомизации, и передачу кода от команды к команде, и собственно работу командами. И не только для кода но и для железа. Пусть лишние выводы и структуры висят на плате и в прошивке соответственно. Есть не просят. А попросили тебя фичу прикрутить - не надо плату переразводить или АРХИТЕКТУРУ приложения менять. Не раз с этим сталкивался.
Чем тебе лишние абстракции не увеличение количества кода?
>Клиент хочет поддержку и доп.фичи? Плоти много деняк и дай нам пол года перебрать треть проекта с нуля.
Водопадопроблемы.
Лишний код - это просто лишний код. Понадобиться добавить абстракции, добавим, но задел на будущее оправдывает себя раз в 500 проектов.
>Клиент хочет поддержку и доп.фичи? Плоти много деняк и дай нам пол года перебрать треть проекта с нуля.
Водопадопроблемы.
Лишний код - это просто лишний код. Понадобиться добавить абстракции, добавим, но задел на будущее оправдывает себя раз в 500 проектов.
Галероподходы а не водопадопроблемы. Им это выгоднее, чем когда фича делается за час после запроса младшим джуном.
Лишний код это байтик на ПЗУ, не более, это вот вообще не узкое горлышко что десктопов, что серверов. Да даже сраные микрики обмазываются флешью.
Лишний код это байтик на ПЗУ, не более, это вот вообще не узкое горлышко что десктопов, что серверов. Да даже сраные микрики обмазываются флешью.
С долгоживущей системой программисты чаще читатели, чем писатели. И если лишние слои кода превращают Хоббита во Властелин_Колец, выполняя только ту же фичу "сходить туда и обратно", при этом будучи никогда не используемыми и расширяемыми - это плохой код, как бы идеально он не был написан.
вообще всё зависит от ТЗ (которое обычно ужасного качества, потому что заказчик нихуя не может сформулировать свои хотелки)
О, а вот и цитаты с баша в обертке твитов.
жизнь на основе кремния это теория
Баян 10-летней давности. https://bash.im/quote/412145
Я бы начинал с класса "вселеная".
а потом все оставшееся время будет искать объект который унаследовал сетевые терминальные гены.
Чтобы написать коммент, необходимо залогиниться
- Да, но...
- А твой "правильный" код работает?
- Ну, бывает...
- Назовёшь ещё раз переменную / класс "test1" и станешь безработной формой жизни.