Ну почему же сразу крайности? А что насчёт перестать себя корить, полюбить что есть здесь и сейчас и не особо сильно разрывать жопу, но стараться не ухудшать то что есть?
Вот вы пишите изменить можно многое, а теперь расскажите зачем вообще что то менять (с учётом неизменного пункта конечного назначения)?
Мне показалось или ваша точка зрения (не)много поменялась с нашей последней дискуссии о свободе воле? Там то как раз вы больше склонялись к тому что желания и усилий достаточно для преодоления (почти) любых сложностей.
В том то и беда, что дискуссии нет, есть только (эмоциональные) оценочные суждения. Вроде как всё логично, должна маска помогать, но насколько хорошо/целесообразно не ясно. В моей локации, маски обязательны только в ОТ, но дело в том что у нас ковида вне карантинных мест уже давно нет (пару раз прорывался, так его локдауном отлично загоняют назад), и как то не очень ясно зачем все это, или а как конкретно измениться ситуация если их вообще не носить.
Т.е. конгрессмены хотят запретить продажу новых лицензий (новый техпроцесс) или уже купленные лицензии имеют срок годности? Получается штаты также готовы нести убытки т.к. я подозреваю много тех самых совместных предприятий как раз родом из штатов?
А китайцам даже с наличием лицензии разве уже не запретили делать микросхемы? Не совсем понятно, как именно вот этот запрет на софт помешает китайцам с учётом уже существующих санкций?
Давайте предположим, что я как бы это все читаю в первый раз в жизни и для меня это откровение. Правда я как бы немного буду чуть более наблюдательным чем если бы это было на самом деле так. Один из вас пишет, что Раст собственно ничего и не гарантирует, а другой пишет что речь идёт об аппаратной атомарности. Вы знаете я чёто запутался в ваших показаниях. Если Раст ничего не гарантирует, то на кой лят этот инт128, а если он что то гарантирует, то что же именно? И все же, а что сломается если просто тупо взять и переписать инт128 таким же образом как сейчас придётся писать инт256?
Дополнительный вопрос со звёздочкой, а как по вашему с проблемой не атомарности записи в инт большего чем регистр размера справляется ядро? Ну ведь не может же такого быть чтобы такой задачи ещё не возникало или что ядреные разработчики расплакались и сказали что это невозможно?
Это и так понятно, эта проблема была всегда, сегодня для 128, вчера для 64, позавчера для 32 и так до ламповых компьютеров, ничего принципиально не поменялось. Си уже наверное пережил эту проблему начиная с 16 и так далее и на уровне языка это ничему не мешает, и тут вдруг для раста это стало проблемой. Вы так и не сказали что перестанет работать если Раст перестанет гарантировать атомарность для 128.
Вся необходимая память для обработки ошибок включая оом выделяется статически на старте очень заранее от собственно оом, что бы не попадать в ситуацию двойного отказа, ну и если у вас оом в момент инита ядра то тут уже все, ничего не поделать тут и ядро паникует.
А почему вы считаете, что все инты атомарны? Ещё каких то 15 лет назад даже самый обычный инт32 но с неправильным выравниванием ни на одной платформе не был атомарным, теперь почти везде атомарный. Я это к тому что тому же с/с++ эта (не)атомарность особо никогда не мешала. Это я к тому что ну будет инт128 не атомарным из коробки и чё? В чем собственно проблема?
А вы то сами читали его идеи? Я не читал и поэтому не осуждаю, что бы осуждать надо знать, но вы ж запрещаете знать, но требуете верить в то что его идеи гумус. Сегодня Геббельс, а завтра потребуете верить в то что вы помазаник божий и все должны перед вами склониться. Реальность моих опосений должна быть буквально очевидной жителям России.
Да, я тоже родился, учился(трту кстати), женился и сбежал из тагана через теже 23 года. С начало Ростов, потом Москва, потом Лимасол, а сейчас Окленд. И чем дальше от тагана тем счастливее я себя чувствую.
Никто почему-то не вспомнил из минусов мерзкую слякоть вместо снега зимой, которую невозможно избежать т.к. если дороги для машин ещё хоть как-то ремонтируются, то тратуары не фиксились НИ РАЗУ за всю мою сознательную жизнь и последующие заезды в гости к родителям. Последний раз правда я там бывал 7 лет назад, но сильно сомневаюсь что это как то улучшилось.
Летом жарища +40 (ночью без кондея лучше сразу сдохнуть) начиная с мая иногда даже с апреля до самого конца августа. Дождей может не быть 2 месяца подряд, полный штиль и воздух очень сухой 10-15% влажности и конечно же полчища комаров самых обычных кровопийц, нет не тех зелёных они относительно недавно завелись лет 10 назад.
Зимой снега нет, но есть гололёд — нехилый такой гололёд почти каждую зиму я падал не меньше раза. А да зима в тагане это непробиваемый депресняк
. В ноябре приходит свинцово серая туча на все небо из которой постоянно что то капает в течении 2 месяцев без намека на солнце 100% влажность, а потом приходит мороз и ветрище который выдувает все мозги насквозь, вы думаете в это время снег выпадает? нет снега в тагане нет, есть только слякоть и гололёд, да кстати тратуары и дороги от слякоти/гололёда ни кто не чистит. Готовьтесь пару недель в году будет -30 и одновременно ветер 30 м/с.
Вода из водопровода — эталон пиздеца, хуже только техническая вода для полива на дачах. Как то в один год случилось нежданное и пришел дождь посреди лета — выпала полугодичная норма за 4-6 часов естественно слив к такому небыл готов и все пошло очень не так. Я подробностей не знаю, но потом вся вода в городе натурально воняла стоками в течение 2 лет. В другой год часть улицы провалилась из за того что сточную канализации не ремонтировали вообще никогда.
Школы просто пипец, был когда уникальный ТМОЛ (я там учился), но его задушили.
Больнички, по разному, но ни за что и ни когда не попадайте в 5-ую больницу это филиал ада, я не шучу, попав туда выйти оттуда живым и хотя бы не в более худшем состоянии шансы 50 на 50.
А теперь плюсы, ОЧЕНЬ вкусная и дешевая еда, овощи фрукты, ягоды, речная/пресноводная рыба. Вкуснее Таганской малосольной селёдки нет нигде в мире. Был трту/юту, как там сейчас не знаю, но судя по этому посту этот вуз все ещё торт. Все, на этом плюсы заканчиваются.
И нет, залив в тагане не для купания он для слива индустриального говна чтобы купаться надо либо на речку ехать либо в деревни на море, проблема в том что оно очень мелкое и найти хороший пляж без ила не легко/близко.
Вобщем я не слышал чтобы кто то не будучи студентом, а осознано после опыта жизни в разных локациях добровольно переезжал в таган на ПМЖ, таган это разумный выбор отучиться в юту жениться получить первый опыт работы и переехать куда получше.
Как обычно боятся нужно не ии, а людей надельных властью/возможностью причинять добро. Ну будет ии и что? С чего вдруг у него вообще какая-то мотивация будет хоть что то делать, откуда(на каком основании) мотивация как то взаимодействовать с миром подразумевается присущей ии? Или по другому почему внутреннее целеполагание внезапно характеристика ии?
И снова, бояться надо тех кто способен причинить добро, а добро неведомо ии (на сколько мы знаем), но это тоже не точно.
Не знаю почему, но все как то восприняли это в строго черно белом ключе — либо все хорошо, либо все плохо, но ведь есть же еще и серая палитра. Давайте так я вам дам предустановку — менеджер адекватный, решения принимаются осознанно и что важно информированные (после обсуждения альтернатив плюсов и минусов). Тесты обязательное требование, CI/CD настроен, ТЗ есть, QA есть, ревью есть, и даже авто тесты есть, качество кода среднее, качество продукта среднее (было ниже среднего), у менеджеров есть мотивация повысить качество продукта (на тесты им как бы фиолетово). Команда в целом юнит тесты пишет из под палки и часто низкого качества, авто тесты довольно сложны в поддержке не стабильны и самое главное дороги в запуске на дев машинах, основные замечания на код ревью о форматировании и стиле(не функциональные замечания) реализации. Иногда, если повезет, можно получить функциональный фидбек на ревью, но такое редко.
Писать быстро-грязно и без тестов с какого-то момента (в среднем — через месяца 3-4) становится намного медленнее, чем с тестами (а с тестами уже быстро-грязно писать не получится).
Так я только в одно месте сказал что тесты не нужны — там где их явно попросили не писать.
По моим наблюдениям использование «чистой архитектуры» не стоит практически ничего, т.е. заметных накладных расходов на неё очень мало.
Не согласен, думать по определению дороже чем не думать. Но самая главная цена это бюрократия — нужно написать предложение / поревьюить дизайн, убедить что дизайн «оптимальный» Т.е. всегда идет торг один говорит что это не нужно и его решение проще/быстрее другой говорит что нужно ибо качество.
А взамен она даёт возможность намного проще писать юнит-тесты, что моментально окупает накладные расходы на саму архитектуру.
Ну не знаю, об этом все говорят, но доказать/обосновать пока никто не смог. Я вижу, что даже если люди пишут юнит тесты, это ничего не гарантирует. Если «архитектура» помогает писать юнит тесты (которые можно было бы и не писать из за их содержания/полезности) то как то не очень преимущество.
В моём понимании «только чтобы тикет смерджили» подразумевает отсутствие лишнего (не описанного в тикете) фукнционала. А «на минималках» включает обязательные юнит-тесты изменений в этом PR (с покрытием хотя бы порядка 70%), обязательный процесс ревью кода, обязательное использование линтеров и CI/CD.
Ну так все и есть — формально, а на практике тесты стараются не писать если есть хоть одна причина не писать их, без ревью и CI не смержится, но ревью часто обходит стороной функциональные вопросы.
В общем и целом бизнесу плевать, на архитектуру и тесты и… они нужны для нас с вами, а бизнесу в лучшем случае нужен качественный (достаточно хороший для ЦА) продукт. Самая большая причина которая заставляет усложнять что-то в целях удешевления это умение предугадать какие проблемы поднимут на ревью и заранее их решить, какие проблемы найдут QA и заранее их протестировать.
Внутренние процессы компании устанавливает планку на минимальную сложность кода и определяют минимальную цену решения. Нужно делать всегда как можно дешевле, но по всем правилам и чтобы все были в курсе / знали что происходит.
Ну, нет. То о чем вы говорите предписывает делать самое простое решение, а я говорю о самом дешёвом и это не тоже самое. Есть факторы которые будут заставлять вас усложнять код в целях его удешевления. Самый простой код не равно самый дешёвый. С другой стороны вы конечно правы и ягни самый близкий родственник.
А что насчёт такого принципа, пишите так что бы было ДЕШЕВЛЕ вот прям здесь и сейчас согласно ТЗ? А когда придет время, тогда будете усложнять/расширять в соответствии с принципами/здравым смыслом и опять же как можно дешевле здесь и сейчас.
Плюсы:
Высокая скорость разработки
Минимализм (невозможность упростить)
Мир и согласие с вашим менеджером
Не нужно строить из себя оракула и пытаться угадать будущее (все равно облажаетесь)
Недостатки:
Ваш код обязательно назовут говном
Расширить функционал на гипотетический (предложенный на ревью, а не из реального тикета) случай будет сложно (а реальное расширение никто пока и не знает)
Похвастаться знаниями принципов/паттернов будет получаться редко.
Тупо скучно, очень мало творчества, велосипедостроительства, будьте честны это вообще главный мотиватор. Все эти принципы нужны просто как аргументированная рационализация того почему работадатель должен платить за ваш художественный взгляд.
Тут без уточнений меня конечно поймут неправильно:
Если уровень качества кода в вашей компании низкий (такаво бизнес требование/модель монетизации) то писать юнит тесты это зло для бизнеса.
Если требуется качество на среднем уровне (большинство) то вышеописанное мне кажется идеальный вариант, сложность/функциональность/расширяемость/тестируемость кода должна быть на минималках только чтобы тикет смерджили
Если требуется высокое качество или цена изменений высока (по не связанным с разработкой причинам), то таки да следуйте принципам сразу это рационально — дешевле.
Ещё одно уточнение, если что то можно сделать лучше/проще/безопасней в текущих условиях задачи без усложнения или например можно что то упростить ещё больше, то лучше сделать/отрезать что то лишнее чем следовать каким то принципам (ну за исключением дешевле здесь и сейчас). Как то так.
И да я тоже художник, и тоже могу придумать 1000 и 1 причину почему мое решение лучше вашего. Я не стесняюсь требовать оплаты за велосипеды (которые иногда пишу) иначе мне станет скучно и я уйду, а это дороже для бизнеса. И/или заведомо делая/пропуская на код ревью код проще/хуже чем я могу написать/вижу иное решение — таково ОСОЗНАННОЕ требование бизнеса.
Принцип всего один — пиши как можно ДЕШЕВЛЕ, но полностью в соответствии с ожиданиями бизнеса.
Да можно и предусмотреть, я обычно не код ревью не требую писать точки которые не нужны вот прям в этом же МР, но если их реализовали то сразу иду смотреть есть ли тесты? Нет тестов сразу идёт требование либо написать тест на точку расширения либо удалить ее, и что вы думаете (какоя самое частое решение принимает автор)? Наверное уже догадались, в такой дихотомии выбор почти 100% удалить. Смотрите автор МР уже наигрался с кодом — показал что он молодец умеет делать велосипеды, желание творить удовлетворено, но также все понимают что рациональней просто напросто выкинуть эту часть кода — проще, быстрей, безопасней. Но ежели автор озаботился хорошими тестами, то нет причин удалять то что более менее работает, такое бывает редко.
Согласен, если бы еще багтрекер показывали, то мне однажды не пришлось бы менять работу через месяц, хотя я и без кода на собесе почувствовал, что место мне не зайдет, но в тот момент было нужно что-то срочно найти и было самым лучшим предложением.
Выбор в моих краях к сожалению не так чтобы большой — верхняя граница это — сойдет если не принюхиваться, но проблема не в коде, а в людях / процессах. Сойдет если не принюхиваться качество кода это такой баланс между кого организация может захантить за рыночную стоимость и минимально приемлемым качеством продукта. Так что из моей практики в целом код в любом многолетнем не маленьком коммерческом продукте всегда на грани фола — так дешевле. Поэтому я больше стараюсь выяснить про процессы чем смотреть на код.
форсировать базовые правила по написанию читаемого кода
да так, что бы в результате у вас конфликт не получился и исправление было реализовано. На моей практике, очень небольшое количество людей адекватно воспринимает критику и эти люди в наименьшей степени нуждаются в ней, большая часть уходит в глухую оборону при ЛЮБОМ способе донесения идей отличных от тех, что уже поселились в голове.
Ну так пример из статьи + бесконечное количество в любом месте где бы я не работал, да что уж ханжить я и сам по молодости такое писал.
ASSERT(attempts > 0);
if (attempts <= 0) throw NegativeAttempts();
Не вижу причин чтобы UB произошло снаружи.
Ну так нашу частичную функцию вызвали с невалидным аргументом не для забавы ради, есть всего два варианта почему так произошло:
1. не проверили ввод, и тогда наша функция первая в цепочке вызовов, баг есть но УБ пока еще не произошло.
2. какой то код который уже отработал содержит баг — из валидного входа производит не верный результат и передает его на вход нашей функции, это и есть состояние что вызывающий код уже в состоянии УБ.
Вот это техника «защитного» программирования нацелена на 1 причину, но при этом очень сильно портит жизнь когда настоящая причина срабатывания ассерта номер 2.
Вот я уже даже перестал понимать, с чем у нас разногласие, чем больше общаемся тем больше соглашаемся. Скажите, вы сами в своем коде после ассерта будете использовать «защитное» программирование? И если да, то в каких случаях, но лучше пример.
На основе без преумеличения десятков примеров из опыта, я лично убежден (пока не предъявили контрпример), что «защитное» программирование это анти бест практис везде и всегда.
Ну почему же сразу крайности? А что насчёт перестать себя корить, полюбить что есть здесь и сейчас и не особо сильно разрывать жопу, но стараться не ухудшать то что есть?
Вот вы пишите изменить можно многое, а теперь расскажите зачем вообще что то менять (с учётом неизменного пункта конечного назначения)?
Мне показалось или ваша точка зрения (не)много поменялась с нашей последней дискуссии о свободе воле? Там то как раз вы больше склонялись к тому что желания и усилий достаточно для преодоления (почти) любых сложностей.
В том то и беда, что дискуссии нет, есть только (эмоциональные) оценочные суждения. Вроде как всё логично, должна маска помогать, но насколько хорошо/целесообразно не ясно. В моей локации, маски обязательны только в ОТ, но дело в том что у нас ковида вне карантинных мест уже давно нет (пару раз прорывался, так его локдауном отлично загоняют назад), и как то не очень ясно зачем все это, или а как конкретно измениться ситуация если их вообще не носить.
Т.е. конгрессмены хотят запретить продажу новых лицензий (новый техпроцесс) или уже купленные лицензии имеют срок годности? Получается штаты также готовы нести убытки т.к. я подозреваю много тех самых совместных предприятий как раз родом из штатов?
А китайцам даже с наличием лицензии разве уже не запретили делать микросхемы? Не совсем понятно, как именно вот этот запрет на софт помешает китайцам с учётом уже существующих санкций?
Позвольте поинтересоваться на каком основании они это рекомендуют? По-другому, почему они верят в то что это хоть как-то лучше чем без масок?
Давайте предположим, что я как бы это все читаю в первый раз в жизни и для меня это откровение. Правда я как бы немного буду чуть более наблюдательным чем если бы это было на самом деле так. Один из вас пишет, что Раст собственно ничего и не гарантирует, а другой пишет что речь идёт об аппаратной атомарности. Вы знаете я чёто запутался в ваших показаниях. Если Раст ничего не гарантирует, то на кой лят этот инт128, а если он что то гарантирует, то что же именно? И все же, а что сломается если просто тупо взять и переписать инт128 таким же образом как сейчас придётся писать инт256?
Дополнительный вопрос со звёздочкой, а как по вашему с проблемой не атомарности записи в инт большего чем регистр размера справляется ядро? Ну ведь не может же такого быть чтобы такой задачи ещё не возникало или что ядреные разработчики расплакались и сказали что это невозможно?
Это и так понятно, эта проблема была всегда, сегодня для 128, вчера для 64, позавчера для 32 и так до ламповых компьютеров, ничего принципиально не поменялось. Си уже наверное пережил эту проблему начиная с 16 и так далее и на уровне языка это ничему не мешает, и тут вдруг для раста это стало проблемой. Вы так и не сказали что перестанет работать если Раст перестанет гарантировать атомарность для 128.
Вся необходимая память для обработки ошибок включая оом выделяется статически на старте очень заранее от собственно оом, что бы не попадать в ситуацию двойного отказа, ну и если у вас оом в момент инита ядра то тут уже все, ничего не поделать тут и ядро паникует.
А почему вы считаете, что все инты атомарны? Ещё каких то 15 лет назад даже самый обычный инт32 но с неправильным выравниванием ни на одной платформе не был атомарным, теперь почти везде атомарный. Я это к тому что тому же с/с++ эта (не)атомарность особо никогда не мешала. Это я к тому что ну будет инт128 не атомарным из коробки и чё? В чем собственно проблема?
А вы то сами читали его идеи? Я не читал и поэтому не осуждаю, что бы осуждать надо знать, но вы ж запрещаете знать, но требуете верить в то что его идеи гумус. Сегодня Геббельс, а завтра потребуете верить в то что вы помазаник божий и все должны перед вами склониться. Реальность моих опосений должна быть буквально очевидной жителям России.
Да, я тоже родился, учился(трту кстати), женился и сбежал из тагана через теже 23 года. С начало Ростов, потом Москва, потом Лимасол, а сейчас Окленд. И чем дальше от тагана тем счастливее я себя чувствую.
Никто почему-то не вспомнил из минусов мерзкую слякоть вместо снега зимой, которую невозможно избежать т.к. если дороги для машин ещё хоть как-то ремонтируются, то тратуары не фиксились НИ РАЗУ за всю мою сознательную жизнь и последующие заезды в гости к родителям. Последний раз правда я там бывал 7 лет назад, но сильно сомневаюсь что это как то улучшилось.
Летом жарища +40 (ночью без кондея лучше сразу сдохнуть) начиная с мая иногда даже с апреля до самого конца августа. Дождей может не быть 2 месяца подряд, полный штиль и воздух очень сухой 10-15% влажности и конечно же полчища комаров самых обычных кровопийц, нет не тех зелёных они относительно недавно завелись лет 10 назад.
Зимой снега нет, но есть гололёд — нехилый такой гололёд почти каждую зиму я падал не меньше раза. А да зима в тагане это непробиваемый депресняк
. В ноябре приходит свинцово серая туча на все небо из которой постоянно что то капает в течении 2 месяцев без намека на солнце 100% влажность, а потом приходит мороз и ветрище который выдувает все мозги насквозь, вы думаете в это время снег выпадает? нет снега в тагане нет, есть только слякоть и гололёд, да кстати тратуары и дороги от слякоти/гололёда ни кто не чистит. Готовьтесь пару недель в году будет -30 и одновременно ветер 30 м/с.
Вода из водопровода — эталон пиздеца, хуже только техническая вода для полива на дачах. Как то в один год случилось нежданное и пришел дождь посреди лета — выпала полугодичная норма за 4-6 часов естественно слив к такому небыл готов и все пошло очень не так. Я подробностей не знаю, но потом вся вода в городе натурально воняла стоками в течение 2 лет. В другой год часть улицы провалилась из за того что сточную канализации не ремонтировали вообще никогда.
Школы просто пипец, был когда уникальный ТМОЛ (я там учился), но его задушили.
Больнички, по разному, но ни за что и ни когда не попадайте в 5-ую больницу это филиал ада, я не шучу, попав туда выйти оттуда живым и хотя бы не в более худшем состоянии шансы 50 на 50.
А теперь плюсы, ОЧЕНЬ вкусная и дешевая еда, овощи фрукты, ягоды, речная/пресноводная рыба. Вкуснее Таганской малосольной селёдки нет нигде в мире. Был трту/юту, как там сейчас не знаю, но судя по этому посту этот вуз все ещё торт. Все, на этом плюсы заканчиваются.
И нет, залив в тагане не для купания он для слива индустриального говна чтобы купаться надо либо на речку ехать либо в деревни на море, проблема в том что оно очень мелкое и найти хороший пляж без ила не легко/близко.
Вобщем я не слышал чтобы кто то не будучи студентом, а осознано после опыта жизни в разных локациях добровольно переезжал в таган на ПМЖ, таган это разумный выбор отучиться в юту жениться получить первый опыт работы и переехать куда получше.
Как обычно боятся нужно не ии, а людей надельных властью/возможностью причинять добро. Ну будет ии и что? С чего вдруг у него вообще какая-то мотивация будет хоть что то делать, откуда(на каком основании) мотивация как то взаимодействовать с миром подразумевается присущей ии? Или по другому почему внутреннее целеполагание внезапно характеристика ии?
И снова, бояться надо тех кто способен причинить добро, а добро неведомо ии (на сколько мы знаем), но это тоже не точно.
Так я только в одно месте сказал что тесты не нужны — там где их явно попросили не писать.
Не согласен, думать по определению дороже чем не думать. Но самая главная цена это бюрократия — нужно написать предложение / поревьюить дизайн, убедить что дизайн «оптимальный» Т.е. всегда идет торг один говорит что это не нужно и его решение проще/быстрее другой говорит что нужно ибо качество.
Ну не знаю, об этом все говорят, но доказать/обосновать пока никто не смог. Я вижу, что даже если люди пишут юнит тесты, это ничего не гарантирует. Если «архитектура» помогает писать юнит тесты (которые можно было бы и не писать из за их содержания/полезности) то как то не очень преимущество.
Ну так все и есть — формально, а на практике тесты стараются не писать если есть хоть одна причина не писать их, без ревью и CI не смержится, но ревью часто обходит стороной функциональные вопросы.
В общем и целом бизнесу плевать, на архитектуру и тесты и… они нужны для нас с вами, а бизнесу в лучшем случае нужен качественный (достаточно хороший для ЦА) продукт. Самая большая причина которая заставляет усложнять что-то в целях удешевления это умение предугадать какие проблемы поднимут на ревью и заранее их решить, какие проблемы найдут QA и заранее их протестировать.
Внутренние процессы компании устанавливает планку на минимальную сложность кода и определяют минимальную цену решения. Нужно делать всегда как можно дешевле, но по всем правилам и чтобы все были в курсе / знали что происходит.
Ну, нет. То о чем вы говорите предписывает делать самое простое решение, а я говорю о самом дешёвом и это не тоже самое. Есть факторы которые будут заставлять вас усложнять код в целях его удешевления. Самый простой код не равно самый дешёвый. С другой стороны вы конечно правы и ягни самый близкий родственник.
А что насчёт такого принципа, пишите так что бы было ДЕШЕВЛЕ вот прям здесь и сейчас согласно ТЗ? А когда придет время, тогда будете усложнять/расширять в соответствии с принципами/здравым смыслом и опять же как можно дешевле здесь и сейчас.
Плюсы:
Высокая скорость разработки
Минимализм (невозможность упростить)
Мир и согласие с вашим менеджером
Не нужно строить из себя оракула и пытаться угадать будущее (все равно облажаетесь)
Недостатки:
Ваш код обязательно назовут говном
Расширить функционал на гипотетический (предложенный на ревью, а не из реального тикета) случай будет сложно (а реальное расширение никто пока и не знает)
Похвастаться знаниями принципов/паттернов будет получаться редко.
Тупо скучно, очень мало творчества, велосипедостроительства, будьте честны это вообще главный мотиватор. Все эти принципы нужны просто как аргументированная рационализация того почему работадатель должен платить за ваш художественный взгляд.
Тут без уточнений меня конечно поймут неправильно:
Если уровень качества кода в вашей компании низкий (такаво бизнес требование/модель монетизации) то писать юнит тесты это зло для бизнеса.
Если требуется качество на среднем уровне (большинство) то вышеописанное мне кажется идеальный вариант, сложность/функциональность/расширяемость/тестируемость кода должна быть на минималках только чтобы тикет смерджили
Если требуется высокое качество или цена изменений высока (по не связанным с разработкой причинам), то таки да следуйте принципам сразу это рационально — дешевле.
Ещё одно уточнение, если что то можно сделать лучше/проще/безопасней в текущих условиях задачи без усложнения или например можно что то упростить ещё больше, то лучше сделать/отрезать что то лишнее чем следовать каким то принципам (ну за исключением дешевле здесь и сейчас). Как то так.
И да я тоже художник, и тоже могу придумать 1000 и 1 причину почему мое решение лучше вашего. Я не стесняюсь требовать оплаты за велосипеды (которые иногда пишу) иначе мне станет скучно и я уйду, а это дороже для бизнеса. И/или заведомо делая/пропуская на код ревью код проще/хуже чем я могу написать/вижу иное решение — таково ОСОЗНАННОЕ требование бизнеса.
Принцип всего один — пиши как можно ДЕШЕВЛЕ, но полностью в соответствии с ожиданиями бизнеса.
Да можно и предусмотреть, я обычно не код ревью не требую писать точки которые не нужны вот прям в этом же МР, но если их реализовали то сразу иду смотреть есть ли тесты? Нет тестов сразу идёт требование либо написать тест на точку расширения либо удалить ее, и что вы думаете (какоя самое частое решение принимает автор)? Наверное уже догадались, в такой дихотомии выбор почти 100% удалить. Смотрите автор МР уже наигрался с кодом — показал что он молодец умеет делать велосипеды, желание творить удовлетворено, но также все понимают что рациональней просто напросто выкинуть эту часть кода — проще, быстрей, безопасней. Но ежели автор озаботился хорошими тестами, то нет причин удалять то что более менее работает, такое бывает редко.
Выбор в моих краях к сожалению не так чтобы большой — верхняя граница это — сойдет если не принюхиваться, но проблема не в коде, а в людях / процессах. Сойдет если не принюхиваться качество кода это такой баланс между кого организация может захантить за рыночную стоимость и минимально приемлемым качеством продукта. Так что из моей практики в целом код в любом многолетнем не маленьком коммерческом продукте всегда на грани фола — так дешевле. Поэтому я больше стараюсь выяснить про процессы чем смотреть на код.
Ну так пример из статьи + бесконечное количество в любом месте где бы я не работал, да что уж ханжить я и сам по молодости такое писал.
Ну так нашу частичную функцию вызвали с невалидным аргументом не для забавы ради, есть всего два варианта почему так произошло:
1. не проверили ввод, и тогда наша функция первая в цепочке вызовов, баг есть но УБ пока еще не произошло.
2. какой то код который уже отработал содержит баг — из валидного входа производит не верный результат и передает его на вход нашей функции, это и есть состояние что вызывающий код уже в состоянии УБ.
Вот это техника «защитного» программирования нацелена на 1 причину, но при этом очень сильно портит жизнь когда настоящая причина срабатывания ассерта номер 2.
Вот я уже даже перестал понимать, с чем у нас разногласие, чем больше общаемся тем больше соглашаемся. Скажите, вы сами в своем коде после ассерта будете использовать «защитное» программирование? И если да, то в каких случаях, но лучше пример.
На основе без преумеличения десятков примеров из опыта, я лично убежден (пока не предъявили контрпример), что «защитное» программирование это анти бест практис везде и всегда.