Никаких особых медицинских диагнозов мне не ставили, но мои умственные способности крайне ограниченны. Даже те задачи на Leetcode, которые попроще, вызывают у меня затруднения. Когда я читаю о самом обычном алгоритме консенсуса, у меня кипит мозг. У меня плохо получается отслеживать сложные зависимости в кодовой базе. Я не способен освоить модные языки вроде Rust (пытался, но по правде сказать, для меня это чересчур). Я терпеть не могу микросервисы и современный фронтенд: там слишком много движущихся частей, и уследить за всеми я не в состоянии.
Как же я выхожу из положения?
Я использую наиболее легкий мейнстрим-язык программирования из всех доступных (Go), а также самые базовые возможности Python. Пишу простой (хотя иногда весьма тяжеловесный) код, который несложно осмыслять и поддерживать. Избегаю глубоких абстракций и всегда предпочту композицию наследованию или примесям. К дженерикам прибегаю только при крайней необходимости. По возможности отдаю предпочтение плоским структурам данных.
Внешние зависимости я ввожу по минимуму (в идеале вообще обхожусь без них). Проектирую модули с понятными API (и не употребляю слово «понятный» в том значении, которое ему придает Роберт Мартин), но почти никогда не перевожу их в микросервисы. Пользуюсь JSON-over-HTTP и ни в коем случае не GraphQL. Я не пожалел времени на то, чтобы изучить SQL, и активно его использую. Для устойчивости применяю самые базовые паттерны: таймауты, автоматические выключатели и обратное давление.
Стараюсь сводить количество компонентов ПО к минимуму. В идеале только само приложение, SQLite или PostgreSQL для хранения данных, а также Docker, приправленный shell, для развертывания. Nginx/HAProxy – по мере необходимости. Никаких API-шлюзов, никакого сегментирования, никаких распределенных кэшей, никаких очередей сообщений, никаких NoSQL/NewSQL/Graph/всевозможных баз данных, никакого обнаружения сервисов, никакой федерации, никакой ориентации на облако, никаких лучших практик уровня FAANG.
Чтобы разобраться в legacy-коде, я рисую графики зависимостей и диаграммы последовательности. Оставляю комментарии, чтобы напомнить себе в будущем, почему та или иная функция делает то, что делает, или зачем нужна определенная if-ветвь. Составляю документацию, стараясь сделать ее лаконичной и простой для чтения. Пишу примеры – очень много примеров. Некоторые из них даже интерактивные.
Программы, которые я создаю, вроде бы работают нормально. На программиста из Google они большого впечатления, конечно, не произведут, но своим пользователям и бизнесу служат исправно. Так что в каком-то смысле я научился управляться со своей глупостью.
Комментарии (278)
vitslepukhin
24.04.2024 08:53+55Просто эталон программистского благочестия. Сам себя не похвалишь - никто не похвалит.
DenSigma
24.04.2024 08:53+1О! Интересно. А как к принципам "Чистого кода" Мартина относишься? Для меня наоборот, это сильно упрощает понимание и работу с кодом (если пишу свой, конечно). Наследование имхо слишком сложно.
bear11
24.04.2024 08:53+5Вот к этому самому "Чистому коду" надо на самом деле относиться с опаской. Бездумное применение его практик может приводить к внушительным потерям в производительности программ - именно из-за следования советам этой книги.
Подробнее в статье на английском: https://www.computerenhance.com/p/clean-code-horrible-performance
UranusExplorer
24.04.2024 08:53+6Эту "статью на английском" тут уже не раз переводили и разбирали в комментариях, она чуть более чем наполовину состоит из откровенного натягивания совы на глобус и выдачи желаемого за действительное.
isadora-6th
24.04.2024 08:53+1"Чистого кода" Мартина слегка устарел, т.к. был написан под Java 5 и за пределами этой самой Java выглядит многословно.
Ну и ряд тейков в книге у него было откровенно вредительских - типа функции которые в идеале не принимают аргументов и многопоточка не дает прироста по перфу. Самое смешное, это там где он привел листинг кода на 7 страниц книги с ремаркой внизу, что ~"реализовал тоже самое на питоне в 5 раз короче, а все потому-что Java многословный язык"
Из прикольного, читал про Domain Driven Development, который выглядит адекватно и на самом деле это адекватный чисто-код с понятными плюсами и минусами.
А "Чистокодить" за пределами Java, например в плюсах, это моветон
Batalmv
24.04.2024 08:53+4Все зависит от нефункциональных требований к приложению
Если вам хватает (а почему бы и нет) - от ок. Но с какого-то уровня может не хватить
CitizenOfDreams
24.04.2024 08:53+12И с течением лет пришел к осознанию, что я не очень умный.
Не наговаривайте на себя. "Не очень умный" - это, например, программист, который в системе бронирования авиабилетов не может различить двух пассажиров с одинаковыми именами (см. соседнюю новость на Хабре).
Newbilius
24.04.2024 08:53+18У меня есть сомнения, что именно разработчик лично решил сравнивать пассажиров именно так. Возможно программист таки рвался сделать всё правильно, но ТЗ есть ТЗ, и порой переубедить заказчика, что фигня получится - не так уж просто...)
newintellimouse
24.04.2024 08:53+28Из личной практики:
— Вы хотите написать систему управления многоквартирным домом и хотите запретить регистрироваться в нём пользователю, если человек с таким же ФИО уже зарегистрировался в системе. Но вот смотрите, в моём доме живёт три человека с совпадающим ФИО...
— Ну какая вероятность, что такое произойдёт вообще? Меньше одного процента? Мы пренебрежём этой возможностью совпадения.
Полгода переговоров параллельно с разработкой ТЗ ни к чему не привели, требование ушло в работу :)
tuxi
24.04.2024 08:53+26— Ну какая вероятность, что такое произойдёт вообще? Меньше одного процента? Мы пренебрежём этой возможностью совпадения.
О да! Классический шаг в бездну потенциального секса с проектом через полгода год. И каждый раз одна и та же картинка. Как только произносятся ключевые слова про "вероятностью в 1% надо пренебречь" можно смело планировать время на глубокий рефакторинг спустя полгода. И про "1% пронебречь" уже никто не вспомнит, а зачем нужен рефакторинг придется обосновывать.
VYudachev
24.04.2024 08:53+4Немножко подушню, а чем тут поможет глубокий рефакторинг, если это по определению "процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения" (с), а тут клюнул жареный процент и внешнее поведение не устраивает? Можно смело планировать время на переписывание проекта.
tuxi
24.04.2024 08:53+2глубокий рефакторинг != рефакторинг ... ну как то так)
Если говорить серьезно, бизнесу же не важно, что там внутри. Может там совсем новая версия будет. Или старая, но теперь она (как в примере выше) умеет рассылать письма менеджерам с уведомлениями, что "вау! редкое событие таки наступило, чините парни руками прямо в бэдэшечке".
SquareRootOfZero
24.04.2024 08:53+4В программировании 1% - это ведь буквально овердохрена. Это значит, что столкнёшься с этим явлением а) обязательно; б) скоро; в) неоднократно. Если, допустим, запрограммировать Псалтырь, чтобы, в результате бага, произвольное слово с вероятностью 1% подменялось матерным ругательством - матерных ругательств там будет в среднем по одному-два на страницу, а не "спустя полгода пренебречь". Чтобы хоть в каком-то приближении можно было "пренебречь" (читай: "спихнуть, пока не заметили") - это какие-то сотые-тысячные доли процента должны быть, а не единицы.
DvoiNic
24.04.2024 08:53+33Лет пятнадцать назад читал одну историю (к сожалению, сейчас найти не могу). Смысл такой: программист бодался с менеджером (или постановщиком, или ключевым пользователем) по поводу ТЗ (какое-то деловое ПО ), и в алгоритме одна из ветвей "вела в никуда". Менеджер доказывал, что "такое сочетание событий не то, чтоб крайне маловероятно, но вообще никогда не может быть". Ну, договорились, что в этом случае будет приходить письмо на электронную почту этого менеджера. В общем, за неделю там накопилось несколько сотен писем...
Поэтому я если слышу слова "никогда" или "маловероятно" - я знаю, что это наверняка случится. И чем меньше заявляют вероятность, тем скорее это произойдет...
perfect_genius
24.04.2024 08:53+3Похоже на закон Мёрфи.
DvoiNic
24.04.2024 08:53+1Может, и Закон Мерфи. Но скорее всего, эта ситуация была регулярна, как-то обрабатывалась исполнителями (линейными сотрудниками), а менеджер был "не в курсе". поэтому я частенько контактирую не только с постановщиками, но и с исполнителями... "чтоб сто раз не переделывать".
franzose
24.04.2024 08:53+12Ну, договорились, что в этом случае будет приходить письмо на электронную почту этого менеджера. В общем, за неделю там накопилось несколько сотен писем...
А ведь это гениальная идея)
StriganovSergey
24.04.2024 08:53+1Хорошая, до тех пор, пока за ночь не придет 800 тысяч писем, и к утру почтовый сервер ляжет.
И это не образное выражение, а реальный кейс из жизни - про отправку писем на "маловероятное событие".
bat
24.04.2024 08:53+1конец нулевых, самописаный сервис деск на пыхе, ловим странное исключение в логе... нахожу его в коде, а там после обработки пачки кейсов, которые по задумке покрывают все случаи, стоит выброс исключения с комментарием - этого никогда не должно случится
Ndochp
24.04.2024 08:53Отличная практика разбрасывать такие исключения в ветке "else" четко падает, вместо того чтобы тихо выполняться. (ну если конечно у вас не спутниковый софт)
Emulyator
24.04.2024 08:53А какая альтернатива решающая проблему была предложена заказчику и почему он отказался?
newintellimouse
24.04.2024 08:53Не вводить это ограничение, как избыточное :) И относящееся к проблеме, которой нет. Полные тёзки в этой системе никаких проблем друг другу не создавали.
Emulyator
24.04.2024 08:53Но тогда получается, что можно одному человеку 100 раз регистрироваться, разве это нормально?
VladimirFarshatov
24.04.2024 08:53+3Вводятся дополнительные критерии - огграничители, к примеру "номер телефона", "год рождения", ИМЕИ и пр. данные конфигурации железки - источника запроса. Это просто "навскидку", там много можно чем дополнять ФИО.
Emulyator
24.04.2024 08:53Так вот и непонятно, были ли такие критерии в этом случае, или одних фио достаточно для регистрации.
DaneSoul
24.04.2024 08:53+7Но тогда получается, что можно одному человеку 100 раз регистрироваться, разве это нормально?
Конечно нормально. Что мешает одному человеку выкупить несколько квартир в одном доме для сдачи внаем / инвестирования ?
Emulyator
24.04.2024 08:53А что мешает, имея одну квартиру, зарегистрироваться 100 раз?
releyshic
24.04.2024 08:53+2мешает тот, кто одобряет заявки или тот, кто потом администрирует эти учётки
Emulyator
24.04.2024 08:53+2Я кажется понял на своем примере как работают такие системы: задаешь вопрос человеку по мотивом его воспоминаний о конкретном случае из личной практики, и получаешь уверенные ответы с 4 разных аккаунтов. )
dsv180
24.04.2024 08:53А почему нельзя несколькими квартирами под одной учеткой управлять?
ИМХО вообще людей на полезных сервисах надо через ЕСИА авторизовать...
Evengard
24.04.2024 08:53+1Если речь про регистрацию, которая "прописка", то кажется что номер паспорта неплохое ограничение. Не идеальное, но неплохое.
papalesik
24.04.2024 08:53Увы - плохое. регистрация вообще в другом месте может быть. Владелец он такой - может быть зарегистрирован где угодно )). А номер паспорта - не слишком ли круто? эти данные еще и защищать придется. а паспорта еще и меняют..
lamerok
24.04.2024 08:53Тут странности со стороны менеджера. Обычно наоборот бывает, В данном случае, добавление такого условия, это очевидное добавление ефортов, так как надо отдельно обрабатывать ситуацию с одинаковыми именами.
Т. е для заказчика это доп. траты. Заказчик обычно не тупой, и такие вещи спецом добавляет, типа вы такой ему, да зачем это делать, заказчик соглашается, убирается пункт из ТЗ и уменьшается стоимость. Ну вам же меньше делать.
Наоборот такие вещи надо делать без обсуждения, а уже потом за отдельную плату удалять.
newintellimouse
24.04.2024 08:53Финальная оценка уже после подготовки ТЗ была.
И за эту штуку он заплатил в итоге, и она была реализована.
VladimirFarshatov
24.04.2024 08:53Год назад, работая в сфере ЖКУ я уже слышал такое. Ушел раньше начала написания по ТЗ .. нахер. Не одно ли это место, случаем? ;)
NikRag
24.04.2024 08:53Это ТЗ не значит ведь, что вы будете хранить пользователей в базе по уникальному ФИО? Ведь не значит?
[падме.жпг]
gxcreator
24.04.2024 08:53+4
Забавно, хабр выдал это по вашей ссылке на новость.
tuxi
24.04.2024 08:53+4Буквально вчера видел this.messages is null вместо ленты статей )))
exTvr
24.04.2024 08:53+2Да что-т глючит Хабр в последнее время, навигация по "F" через раз работает, ошибки сыплет и помечает все комменты прочитанными. @Boomburum что-то неладное творится, уровень счастья пользователей Хабра падает.
Boomburum
24.04.2024 08:53+4F вроде штатно работает ) ну или подробности в личку бы (с окружением итд).
Насчёт остального мы в курсе, в процессе исправления — это следствие большого подкапотного обновления.
seregamorph
24.04.2024 08:53У меня была другая история. Вылетал из Схипхол (Амстердам), было два рейса одновременно на Прагу. Мало того, что кто-то додумался их поставить в одно и то же время, так они были в разных гейтах и на табло был отображен только один. Попался на этот косяк не только я - в итоге еле успел. Теперь всегда помимо времени вылета проверяю на табло еще и номер рейса.
engine9
24.04.2024 08:53+12В каком-то смысле это и есть вершина эволюции отдельного человека — познать ограничения и адаптироваться к ним. И да, если вам хватило возможностей разума работать с кодом, то вы умнее 95% людей. Многим не по силам даже в арифметику и прогнозирование собственных действий на 2 шага вперёд.
vrytov
24.04.2024 08:53+50И да, если вам хватило возможностей разума работать с кодом, то вы умнее 95% людей.
Нет.
coresky
24.04.2024 08:53+1Потенциально существует интеллект, для которого самые умные программисты - просто муравьи барахтающиеся в банке. Все люди разные. Самое главное: не переставать учиться и развиваться. Статья и ее резонанс не о чем.
developer7
24.04.2024 08:53+44Гениально! Я смотрю тут многие не поняли про что написано и давай хейт разводить. А смысл прост - писать просто настолько насколько можно. Выкинуть всё ненужное настолько - что бы программа выполняла только то что от неё требуют.
До этой мысли приходишь только спустя годы или даже десятилетия программирования.
А всё от того что написав свой код, спустя месяц ты на него смотришь, и что бы понять что там происходит тратишь день, а не 10 минут. Я не говорю про чужой код.
В 99% случаях сложная иерархия классов на старте никому в последствии ненужна. А только будет доставлять неимоверный гимор в разработке. Опять же если проект растёт - то гораздо проще переписать уже устоявшуюся архитектуру с нуля, чем писать очередной костыль который будет бороться с изначально неправильной архитектурой.
И такой подход имеет свою особенность. Код становится выглядеть "примитивным". Отсутствуют наследования, инъекции, полиморфизм - да вообще всё. Любой новичок посмотрев на такой код сразу понимает как он работает.
Но как написали в статье: в "Гуглах" будут воротить нос.
markoni
24.04.2024 08:53+3Вполне нормальный подход. Недавно где-то глаз зацепился: после jquery пошел бурный рост и развитие разных framewors: react, node, angular, vue, svelte - а все равно 77% сайтов на настоящий момент используют jquery :) Не близко к тексту - но посыл был примерно такой.
developer7
24.04.2024 08:53+9Кстати добавлю как у меня получается писать "просто".
Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать ))) Извините за каламбур.
Короче я это делаю в 2 или в 3 подхода. Сначала пишешь как есть. Когда код работает - даёшь ему отлежатся. Плюс со временем в него добавляются новые фичи.
Потом когда код перестаёт интенсивно расти - возвращаешься к нему и выкидываешь, склеиваешь функции по максимуму, упрощаешь логику.
И да я описал банальный рефакторинг. Который в современном бизнесе совсем не ценится.
3 итерация это возвращение к коду спустя продолжительное время - когда поменялась архитектура. И причёсываешь код под новую архитектуру. при этом не забывая выкидывать и упрощать.
Может показаться что это бесконечный процесс - но как показала практика, такое выкидывание и упрощение всегда приближается к какому то максимуму и останавливается. Это похоже на ёмкость заполненную разными фигурами. Сначала все они лежат в разнобок. Но со временем все фигуры укладываются упорядоченно одна за другой. Что то типа тетриса. В результате все фигуры претёрты друг к другу.
Положительный момент - отлавливаются много упущенных багов.
Отрицательный - бизнесу такое нафиг не нужно.
P.S. И забыл добавить. Итерация 2 и 3 не привязаны ко времени. Они привязаны к ситуации. Т.е. происходят тогда когда они нужны. Тогда при рефакторинге ты находишься максимально в мейнстриме. И рефакторинг происходит максимально безболезненно. Имеется виду безболезненно для психики программиста. Никто же не хочет разгребать этот поганый легаси )))
DvoiNic
24.04.2024 08:53+5"усложнять - просто. Упрощать - сложно!"©Законы Мэрфи
movl
24.04.2024 08:53+1Многие наверно подумаю что это же "просто"! А вот нифига. Написать "просто" - сложнее чем просто написать
Еще у Паскаля было: "Письмо это вышло более длинным только потому, что у меня не было времени написать короче". В общем, это просто проблема оптимизации, которая обычно не решается за 2-3 итерации. За это время можно даже не успеть понять, что конкретно следует оптимизировать и в ущерб чему.
VasiliyLiGHT
24.04.2024 08:53+2У меня попроще - второй этап как третий, спустя полгода :D
Вот сейчас как раз занимаюсь переписыванием того, что было реализовано год назад - половина кода стёрта окончательно (а не закомментирована, как до этого обычно делали), большая часть конструкций упростилась, entity framework пошёл лесом - SqlConnection хватает за глаза. Спасибо M$ за Minimal API - громоздкие контроллеры
заменены несколькими строками
Через какое-то время может быть ещё где-то можно будет упростить, но пока что мне кажется, что проще не сделать. Опыта всего ничего)
YemSalat
24.04.2024 08:53+1Через какое-то время может быть ещё где-то можно будет упростить
Уберите префикс "Map.." из всех этих MapGroup, MapGet и тд
VasiliyLiGHT
24.04.2024 08:53Не убрать, это стандартная реализация https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis
nronnie
24.04.2024 08:53+3Удачи вам в ваших упрощениях. Уверен, придет время и вам придется все возвращать назад. Не зря ведь говорят, что простота она часто хуже воровства :) Все эти "minimal bla-bla-bla" они обычно только для примеров масштаба "Hello world" хороши.
Apv__013
О, наконец то нормальный программист, а не выращенная маркетологами макака на стероидах. Спасибо!
DenSigma
"Макака, позиционирующая себя крутым программистом". Освоила стримы и реактивку, но еще не умеет их НЕ применять.
bokhanych
Я всегда пишу огромные мануалы по проделанной работе, указывая все мелочи, вплоть до версий пакетов, если эту работу предстоит делать в будущем, снова, потомкам. И, как правило, я и есть этот потомок ;) А так-же оставляю в коде ссылки на свой git\linkedin для вопросов тех, кто будет продолжать работу.
Автор не тупой, а заботливый.