Comments 59
кратко: делайте всё по ситуации
Я бы добавил: делай как умеешь сейчас. Через несколько месяцев всё равно полностью перепишешь.
Спойлер - не перепишешь
Если оно нужно только мне, то и хрен с ним. Если оно понадобилось кому-то ещё, то пусть они и переписывают 😎
Не соглашусь. Почти полгода назад разрабатывал прием и отгрузку маркированного товара. С несколькими ошибками в PRODе механизм заработал стабильно через пару недель (нет тестировщиков, обновление строго 2 раза в неделю в 2-х часовом окне). Прошло несколько месяцев - понадобилось сделать прием более гибким и в результате переписал и модуль приема, и модуль отгрузки. Так что если реально нужно кому-то ещё, то перепишешь)
Вывод котоырй я сделал из статьи - автор ужасный программист и ему лучше в руки никакой архитектурный код не давать, испортит любую концепцию, что стейт, что универсальные компоненты.
А ещё абсолютно идиотские предпосылки: "В один момент я решил, что Redux — это решение вообще для всего" "Прочитал статью о том, как классно использовать одну популярную библиотеку для анимации, и решил внедрить её в проект" - ну кто так откровенно набрасывает?
Я так могу все что угодно доказать.
"В один момент я решил, что Вода — это решение вообще для всего. Выпил 30 литров и умер."
"В один момент я решил, что ChatGPT — это решение вообще для всего. Написал уже 9 статей-списков, но рейтинга не набрал."
Вот про воду я Вам не верю. Можете доказать?
Тут лучше не верить, а знать наверняка. Так как у человека смертельная доза воды: 6–7 литров воды за короткий промежуток времени. Человек умирает из-за гипонатриемии и отказа почек. Автор комментария даже преувеличил упомянутыми 30-ю литрами.
Реальные факты, которые я навскидку нашел:
Соревнование на радио в США (2007 г.): Женщина выпила около 7,5 литров воды за несколько часов в конкурсе «Hold Your Wee for a Wii» и умерла от водной интоксикации, вызванной гипонатриемией
Студенческая инициация (2005 г.): Молодой человек был вынужден пить большое количество воды в рамках ритуала инициации, что привело к его смерти
Эндуро-спортсмены: Спортсмены, участвующие в марафонах или военных тренировках, иногда умирают от переувлажнения, особенно если они пьют воду без восполнения электролитов
я загуглил "можно ли умереть, выпив много воды" - оказывается, можно. Должно хватить 15 литров.
Банально почки могут отказать. Было не так давно в новостях - один китаец на спор выпил 5 литров воды, его не спасли. Ну и 30 литров за раз человек не осилит.
Сказано грубо, но по делу. Я, кстати, так и не понял из статьи, что такое быть "слишком правильным". Слишком правильным быть нельзя, так как "правильно" - очень размытое понятие и у каждого разработчика свои правильности, как и у организаций. Вот в организациях "правильно" определяется соглашениями, принятыми разработчиками и при несоблюдении их человек становится "сильно неправильным", так как соглашения принимаются на вооружение исходя из целесообразности и здравого смысла и при соблюдении их просто нельзя быть слишком правильным. При соблюдении их программист становится слишком неуволенным.
Под "слишком правильным" я имел в виду попытку писать так, как говорят бородатые дяди у себя на каналах, без размышлений о том, нужно ли это мне именно здесь. Разработчики время от времени пытаются быть максимально "трушными", тыкая отрывками из умных книг или best practices, где надо и где не надо. Счастье в простоте
Под "слишком правильным" я имел в виду попытку писать так, как говорят бородатые дяди у себя на каналах
А с чего вы взяли что эти самые дядьки говорят правильные вещи? С умным видом можно задвигать что земля плоская и т.д. и т.п. и что теперь, верить на слово каждому такому дядьке что ли?
Умный человек отличается тем, что у него прежде всего критическое мышление, т.е. он не опирается на "авторитеты", а прежде всего сам думает своей головой, сам проверяет те или иные вещи. Если дядька говорит делать вот так, это хорошо, а ты понимаешь что че-то он несет какую то чушь, то с вероятностью >99% он и правда несет чушь. Даже если эту чушь будут поддерживать многие люди, не обладающие критическим мышлением разумеется.
Опять же, далеко за реальными примерами ходить не надо - плоскоземельщики, антиваксеры и т.д. и т.п.
Разработчики время от времени пытаются быть максимально "трушными", тыкая отрывками из умных книг или best practices, где надо и где не надо
Как показывает практика, примерно 99.9% из этих "разработчиков" пишут в итоге жесточайший, неподдерживаемый write-only говнокод.
Счастье в простоте
Именно. Причем это настолько очевидно, что даже странно, откуда у некоторых(слава яйцам не у всех) людей берется тягота превращать простые вещи в очень сложные. Это же настолько нелепо, что порой просто смешно.
KISS и YAGNI во главе всего - единственный путь к реально хорошему коду и реально хорошей архитектуре. Где ты не будешь бороться с тем, что ты наплодил, а просто будешь решать конкретные задачи.
Да я то понял. Отвечу более конкретно. Я не знаю каких конкретно бородатых дядь вы смотрите. Их много и многие говорят разное. Программирование многообразно и нужно выбирать именно то, что будет правильным в вашем проекте. Бородатый дядя не станет работать вместо вас. Поэтому перед тем как бросаться использовать чьи-то успешные практики стоит делать PoC. Я не зря упомянул про соглашения в организации - они как раз и создаются из анализа успешных практик, которые были проверены PoC как работающие в совокупности. Но подозреваю, что вы один разработчик своего профиля в организации. В таком случае советую вам выбирать набор успешных практик самому для вас самих. Повторюсь, в мире программирования нельзя быть слишком правильным - это неформализуемое понятие. Вот если вы скажете, что вы используете какие-то инструменты или подходы вопреки здравому смыслу, то и тут будет вопрос к вашему здравому смыслу, а не к тому, что кто-то где-то что-то назвал правильным, но у вас это не сработало. Статья имела бы смысл, если бы провели аналитику подходов разработки и сказали, что конкретная связка инструментов конфликтует с конкретными подходами разработки или конфликтует между собой.
А то, что нельзя доводить до абсурда соблюдение правил из теории программирования - это и так достаточно известный факт. Для примера один из авторов и основной апологет SOLID сам не вывез дискуссию, где его мокнули в то, что прямое следование SOLID приводит к вреду. Почитайте Дэн Норта и Кевлин Хенни. Однако никто не может упрекнуть в неправильности тех, кто развивает теорию программирования и определяет границы применения тех или иных принципов или подхода к разработке. Так, например, SRP приобрел новые трактовки, например: "единственная причина для изменения" или "единственный актор, который может инициировать изменение". SOLID абсолютно применим к фронту, если вам это интересно. Он вообще применим ко многим сферам деятельности, даже к организации гос аппарата.
я имел в виду попытку писать так, как говорят бородатые дяди у себя на каналах, без размышлений о том, нужно ли это мне именно здесь
Ну детство вроде бы давно прошло с его "мама всегда права".
Вывод который я сделал из статьи - автор ужасный программист и ему лучше в руки никакой архитектурный код не давать, испортит любую концепцию, что стейт, что универсальные компоненты.
Сильное заявление. Благо мой работодатель думает иначе :) Да и ежемесячные транзакции на карту говорят об обратном. Спорить с вами не буду, каждое мнение имеет право на существование, даже такое.
"В один момент я решил, что ChatGPT — это решение вообще для всего. Написал уже 9 статей-списков, но рейтинга не набрал."
Хочу вас огорчить. Ваша попытка уличить меня в использовании чатаГПТ потерпит фиаско... Я не отрицаю, что активно использую ИИ для написания своих статей. Если у меня есть возможность прибегнуть к помощи ИИ как своего личного редактора, почему нет? Идея, тезисы, подготовка каркаса, ревью текста — всё это по-прежнему стоит за мной. А вот набор текста, красивый слог, форматирование текста, примеры (да, местами очень слабые, но несущие иллюстративный характер), — увы, это рутинная работа, и нет интереса выполнять её самостоятельно.
Моя цель появления на Хабре — не набрать рейтинг, а высказать свои мысли и идеи. Да, возможно, автор из меня никудышный, да и красиво говорить у меня не всегда получается, но желание говорить и делится мыслями любым доступным способом, у меня не отнять.
9 статей-списков
P.S Люблю списки)))
Благо мой работодатель думает иначе :)
Как вы обманываете своего работодателя не мое дело.
Но вы несете бред публично на хабр, да ещё и под видом советов для программистов.
А мне и моим коллегам потом разбирать ваш накопипасченный безархитектурный самовелосипедный код, когда ваш работодатель осознает что у него неподдерживаемый кусок того что вы пишете.
Я не отрицаю, что активно использую ИИ для написания своих статей.
Всё понятно, спасибо что признались сразу. Обычно когда несут нейросетевой мусор, пытаются это скрыть, если что.
Но вы несете бред публично на хабр...
В каком хоть месте статьи бред?
Я прочитал её, написано вполне логично.
Есть даже весьма похожая позиция - overengineering.
Вот на хабре есть: https://habr.com/ru/articles/99889/
И в этой статье и в статье про overengineering основная мысль вполне схожа: не переусложняйте.
В каком хоть месте статьи бред?
Примеры бредовые. Сам автор признался что их нейросеть писала, вам это норм вообще читать?
И в этой статье и в статье про overengineering основная мысль вполне схожа: не переусложняйте.
Верная глобальная мысль не делает саму статью полезной. А сама статья не несет нагрузки, автор не учит как именно надо упрощать, его аргументы против - "ну у меня не получилось". Напомню, его выдуманные аргументы.
Так вот даже если бы они были реальные, всё равно - в сложном искусстве программирования автор уповает на эмоции людей. "Не гонитесь за «крутыми» решениями, просто делайте свою работу!" - это дешевый лозунг. Да ещё и вредный.
"не переусложняйте", "не переупрощайте", "пишите тесты", "думайте когда программируете" - это всё статьи одного пошиба и для меня чуть ли не инфоцыганство.
===
Я вот смотрю на плюсы автору, минусы себе в карму и понимаю что с такой аудиторией я пожалуй тоже пойду напишу ещё 2 статьи, они вам понравятся 100%:
"пишите хороший код"
"не пишите плохой код"
Попрошу сгенерировать примеров вида: "Однажды я быстро написал плохой код и у меня потом полезли ошибки. Я переписал на хороший код и ошибки ушли" - как вам идея, хорошая?
Как говорил классик: Мудрость приходит с годами, но к некоторым годы приходят одни.
Иначе говоря, некоторые вещи становятся доступными для понимания только через призму опыта.
Я вот смотрю на плюсы автору, минусы себе в карму и понимаю что с такой аудиторией
Пожалуйста, пересмотрите "Жванецкого", про "Консерватория, золото, суд, Сибирь", особенно про сделанный там вывод. Может, поможет в жизни. Удачи.
Примеры бредовые. Сам автор признался что их нейросеть писала, вам это норм вообще читать?
Автор написал буквально следующее: "Если у меня есть возможность прибегнуть к помощи ИИ как своего личного редактора, почему нет? Идея, тезисы, подготовка каркаса, ревью текста — всё это по-прежнему стоит за мной."
То есть, нейросеть была нужна только для редактирования. Про выдуманность аргументов тут ничего нет.
Я вот смотрю на плюсы автору, минусы себе в карму и понимаю что с такой аудиторией я пожалуй тоже пойду напишу ещё 2 статьи, они вам понравятся 100%:"пишите хороший код""не пишите плохой код"
Тут такое дело... Я недавно наткнулся в википедии на статью под названием "Лысенковщина". Суть в том, что Лысенко ничего не понимал в генетике, зато очень громко кричал, что генетика - это плохо. Однако, генетики кричали недостаточно громко, в результате наука генетика на 20 лет оказалась в опале.
Причём тут статья? Есть вполне себе годные книжки про архитектуру. И есть ахапка статей вида "Чистая архитектура хорошо, Роберт Мартин молодец". То есть, люди "с той стороны" громко кричат.
И есть буквально несколько статей вида "Чистая архитектура - это не всегда хорошо" (пример: https://habr.com/ru/companies/sportmaster_lab/articles/728880/) Но про эти статьи как-то не особо кричат (имхо, может просто стесняются спорить про крутых авторов).
Что имеем в результате: программисты видят (слышат?) много криков, что чистая архитектура - это прекрасно, пытаются её усиленно использовать, получают приложения с невысокой производительностью. Итог: всё это слегка напоминает Лысенковщину, когда результат определяется исключительно громкостью крика. Имхо, в результате программирование может лет на 20 залипнуть в состоянии "красиво, но медленно".
То есть, если вы напишите статью "пишите хороший код", то это будет хорошо, потому что скомпенсирует крики "с той стороны", и вынудит людей смотреть на проблему со всех сторон. Имхо, это прекрасно. (Ну, в крайнем случае окажется, что красота лучше производительности.... но это хотя бы будет осознанный выбор).
А вот набор текста, красивый слог, форматирование текста, примеры (да, местами очень слабые, но несущие иллюстративный характер) - увы, это рутинная работа, и нет интереса выполнять её самостоятельно.
Итак, кто придумал примеры для статьи?
Я кажется понял. Для вас в целом важна идея и тезисы из статьи, для меня они - бред
Для меня такие идеи (не переусложняйте код) и такие тезисы (Библиотеки: не всегда «всё решают») сами по себе не стоят и выеденного яйца. Это просто общие слова на которые мне жалко потраченного времени.
То есть, если вы напишите статью "пишите хороший код", то это будет хорошо, потому что скомпенсирует крики "с той стороны", и вынудит людей смотреть на проблему со всех сторон.
Я напишу такую статью только чтобы доказать что хабр превратился в сообщество г**ноедов, которые плюсуют такой мусор и ещё готовы его защищать. Если бы хабр ещё котировался на собесах, то я так бы и сделал.
Любые такие крики - это плохо. Не важно с какой стороны. Лысенковщина была возможна только благодаря плановой экономике и этому самому Лысенко у власти.
===
Вы устроили какую-то политику, эта сторона, та сторона, эти кричат много, те мало и начинаете вариться в каком-то собственном соевом соусе где каждый хочет перекричать другую сторону адептов чего-то.
Бросьте это.
В моем мире программирования этого всего нет. Там тишина, спокойствие, аргументированные идеи, конкретные хорошие примеры, полезные техники и нет этого бесконечного крика о том что лучше. Нет никаких адептов ничего, для каждой задачи есть пара подходящих и пара не очень инструментов, но если и они решают задачу, то в целом почему бы и нет. 100% соответствия каким-то там идеалам не требуется.
Присоединяйтесь, никогда не поздно.
Как заметил классик: Надо простым кодом создавать гениальные программы, а не гениальным кодом создавать простые программы.
Один из преподавателей по программированию любил повторять "Программа пишется людьми и для людей, а компьютер только её исполняет. Потому, пишите так, что бы другой человек мог понять ваш код."
От себя добавил бы пункт: Делайте код слабосвязанным. Лучше, пусть код будет повторяться.
А что насчет "A little copying is better than a little dependency."?
Один из преподавателей по программированию любил повторять "Программа пишется людьми и для людей, а компьютер только её исполняет. Потому, пишите так, что бы другой человек мог понять ваш код."
== "Чтобы ваш преподаватель мог понять ваш код".
Keep It Simple. Программирование это борьба со сложностью. Не стоит переусложнять без необходимости.
Keep It Simple.
Keep It Simple Stupid - так звучит этот принцип полностью.
переусложнять без необходимости
Звучит как оксюморон. Переусложнение уже само по себе означает усложнение сверх необходимости.
Я в целом согласен с вашим комментарием. Просто настроение душное.
Ну вы, батенька, и душнила :D
К слову, оксюморон - сочетание противоположных понятий. А повторение близких по смыслу слов называется тавтологией.
У меня тоже настроение душное
Увеличим градус душности:
Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама / Хабр
Да, вы правы - тавтология. С другой стороны ChatGPT говорит, что это и не тавтология и не оксюморон, а уточнение контекста действия с усилением его отрицательной окраски. Тут явно нужна комиссия когнитивных лингвистов.
KISS, DRY и т.д. :)
заморочился ...чтобы кэшировать всё...
...кэш перестал ... отловил баги, выяснилось, что ...Не был учтён ...из-за ошибок... я только усложнил всё.
Вывод: Кэширование — это хорошо, но не всегда это необходимо.
Звездец, а не вывод. Типа: "Х это хорошо, но если Х делать неправильно, то ... не всгда это необходимо".
А можете навскидку предложить идею как должен обновляться кэш справочника некоторого набора атрибутов чтобы всегда выдавать актуальную информацию в РИБ масштаба страны чтобы в ту же секунду как произойдут изменения в наборе атрибутов об этом узнали все филиалы с единственной целью - не обращаться к БД при прокрутке списка при условии что обмен с филиалами не чаще 1 раза в 5 минут? От себя подтверждаю, что кэш - это не всегда необходимо
жуткие дебри этих абстракций
Тут проблема не в масштабе проекта, а в подходе к созданию абстракций. Любой слой абстракции должен упрощать взаимодействие компонентов программы. Условно говоря, надо думать о том, что если другой разработчик захочет воспользоваться твоим компонентом, то после введения дополнительного слоя абстракции ему должно быть легче это сделать. Если же абстракция только усложняет использование кода, то это плохая абстракция. К сожалению, на практике слои абстракции вводят только для того, чтобы применить новый сеньорский паттерн, а не для того, чтобы что-то упростить.
О сколько нам открытий чудных готовит просвещенья дух ….
Автор не пробовал для начала книжки почитать?
Рекомендую Фредрик Брукс «Мифический человеко-месяц».
Как говорится «красть ничего не надо, все уже украдено до вас»
Мы тщательно оптимизировали код, внедряли реактивщину и т.п., затратив на это кучу времени, усилий и нервов, потому что заказчик планировал расширить клиентскую базу с 15 клиентов до 100 тысяч и приложение должно было выдерживать высокие нагрузки.
Вот уже три года прошло, у него 50 клиентов и больше в обозримом будущем не предвидится. Приложение работает на 1 процент от своих возможностей.
Ну хоть опыта набрались в новомодных технологиях...
О, мы для заказчика програграммный комплекс полгода для работы под Wine адаптировали!
В итоге, на Linux у заказчика только сервер, на котором софт и так чисто линуксовый.
Всё это напоминает "не спешите исполнять приказ, его могут отменить".
Классика же : https://youtu.be/23fBoqQxSgQ
Не совсем понял правда название статьи относительно её содержания)) Причём здесь правильность? Правильность я считаю, тем более в данном случае, понятие относительное. Единственное на что бы я ориентировался бы, это на то, что усложняет или упрощает использование в дальнейшем этого кода в использовании твоего компонента. А так по сути, я сам, по истечении какого-либо времени смотрю на то, что и как я делал вчера и понимаю что сегодня у меня другое мнение и подход ко многим вещам.
Делайте всё просто. Усложнить всегда успеете.
Сильно-связанное простое легче менять чем слабо-связанное сложное.
Простой код легко читать (понимать). Если код легко читать, то его легко и менять.
Список дел, перед тем как уволиться в Яндекс.
Лайфках, чтобы душа была чиста:
1) Пишешь рабочий, но такой себе в плане "правильности", код;
2) Подписываешь его как `TODO: исправить`;
3) git add + git commit + git push;
4) Радуешься, что хотя бы немного оправдался перед коллегами :)
Краткое содержание некоторых глав "Совершенный код" Макконнелла.
Ошибки, которые я совершил, пытаясь быть «слишком правильным» в разработке