Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы
Прежде чем начинать разговор об архитектуре, и поиска истины между «правильная архитектура, но медленно или тяп-ляп, но быстро?». Нужно разобраться, о каких проектах идет речь.
Хотелось бы поинтересоваться у автора, какое количество моделей было в ваших проектах? Конечно, количество моделей не отражает на прямую сложность логики, но, практика показывает, что проект с 20-30 моделями это одно, а с 200-300 — совсем другое.
Если вы что-то не умеете готовить не значит, что это плохо.
Так говорят только те программисты, которые не готовы отвечать за проект в целом. Которые не думают о том, как с этим проектом будут работать другие люди, через 3-5-10 лет.
Если кто-то «умеет готовить» Perl — это не значит, что новый большой проект в 2020 году нужно писать на нем
сложность с поиском людей которые умеют и готовы этим заниматься.
Представляете, но это реально сложность. Есть проекты которые переписывали с нуля, не смотря на то, что они отлично работали, только потому, что найти программистов, которые бы их поддерживали было невозможно.
Мир хай-лоада и высоких нагрузок это все же отдельный мир. Там, вполне оправдано писать свои велосипеды, отказываться от ООП, и вообще переписывать на другой язык (например с php на go)
Применять правила хай-лоад разработки для всей разработки в целом — некорректно.
Полностью согласен с автором — на больших проектах, написанных на PHP/MySQL/Postgres (без хай-лоад нагрузки на базу), разбиение логики на бэк и базу производит к взрыву мозга программистов. Потому что все привыкли (на других языках, и на других бд возможно по-другому), что вся логика только в коде. Постоянно думать о том, что «а в базе вот то-то и то-то делается, в таких-то и таких ситуациях» — не только сильно усложняет процесс разработки, но и банально об этом постоянно забывают.
А если проект еще и не покрыт авто-тестами… добро пожаловать в мир бесконечных, самых чудесных и непонятных багов.
Проект, на котором наблюдал такую ситуацию (и тим-лид которого, любил процедурки) в итоге переписывали с нуля, конечно, не только из-за обилия процедур в базе, но и их в том числе.
Да вот как раз-таки ни фига непонятно. Бесят люди, которые задают вопрос про X, получают ответ, а потом недовольны, что ты ответил именно на то, что они спросили.
Не соглашусь. Так на любую ошибку можно сказать «причина ошибки находится между монитором и креслом» — и это правда, но она никак не помогает исправить ошибку.
И есть люди, которые вот так постоянно умничают — говорят очевидные вещи, но которые никак не помогают в решении проблем/задач.
Кстати, вспомнил подобный случай из практики. Сидит программист, к нему приходит какой-то менеджер и спрашивает «почему у нас авторизация с мобильников занимает 7 секунд?» (лично я, даже без знания деталей ответил бы так — потому что авторизация написана через одно место, надо переписывать), а программист начинает рассказывать технические делали — для авторизации делается то, потом вот то, потом там такой косяк, и он решается таким-то образом, который занимает много времени и так далее. Очевидно же, что менеджера не интересуют все эти технические подробности, его интересует вопрос «какого хрена у нас такая отвратительная авторизация?». И ответ на него должен быть соответствующий, например «я готов разобраться в проблеме и предложить решения (и решить), но мне нужно, чтобы тим-лид поставил мне такую задачу, и выставил ей высочайший приоритет»
А вот тим лид — это ступенька, там и зряплата больше
Не факт.
В нашей компании была ситуация, когда срочно нужен был опытный Ruby-программист. В итоге у найденного (пусть он много и не проработал — а только вытащил проект из ж*пы) ставка в час была раза в 3-4 выше, чем у тим-лида (он с Ruby вообще не работал, по-этому конкретно в той проблеме ничем компании помочь не мог)
Когда ты разработчик, каждый день у тебя есть скомпилированный билд, выполненная задача, новая фича на проде, — и в этом есть определенное удовольствие. Некий дзен: я сделал дело, можно вечером со спокойной душой идти отдыхать.
А что делать программистам, которые мыслят не уровнем своих локальных задач, а уровнем всего проекта? И в какую сторону проект развивается? А что делать программисту, который переживает за качество продукта?
Не все так просто.
Для этого ты должен выстроить доверительные отношения с заказчиком
Ключевой момент. Если для заказчика авторитетное мнение — знакомый тим-лид из другой компании — можно прямо сразу увольняться. Потому что на каждый второй ваш довод вы будете слышать «А вот мой знакомый тим-лид Вася сказал, что можно и по другому». Классическая разводка ответственности, когда говорит как делать Вася, а отвечает за результат Петя.
Ещё один способ увеличить анонимность — намеренная дезинформация.
Забавно, но размышляя об анонимности пришел к аналогичному выводу — что информацию лучше не скрывать, а наоборот генерировать информационный мусор по нужным параметрам персоны. Возможно уже кто-то и сделал такой сервис — указываешь там, например, свои ФИО — и сервис генерирует фейковые аккаунты в социальных сетях, фотки, сообщения, аккаунты на форумах, и прочее и прочее (и делает это в тарифе ~100$ за год — можно хоть на 20 лет оплатить вперед). Пойди потом разберись, где в этом мусоре реальные данные по нужному человеку.
Гораздо безопаснее было бы рандомизировать время смерти, личность жертвы и обстоятельства смерти.
Только хотел написать, что убивать преступников, как бы это не показалось благородно на первый взгляд — ни разу не гуманно. Очень быстро люди у власти поймут, что это хороший способ убирать неугодных людей — фабрикуется ложное обвинение (или вообще фейк о том, что такой-то человек преступник) и готово — «добродетель» убьет невинного человека.
Мораль, мне кажется, весьма очевидна — не стоит играть со злом, ожидая, что это закончится чем-то хорошим.
В общем, через месяца 3 уже все поймут, кого наняли.
Все проще и банальней.
Кто стоит между рядовыми программистами, которые пишут код, и владельцами бизнеса, которые ничего не понимают в разработке? Чаще всего — тот самый сеньер/тим-лид.
И, внезапно может оказаться, что главная задача такого тим-лида — не писать божественный код, а объединять программистов и владельцев бизнеса. Быть промежуточным слоем, адаптером, который абстрактные и оторванные от реальности хотелки «бизнеса» приводит во что-то похожее на ТЗ для программистов.
В моей компании именно так. Тим-лид не является для меня образцом для подражания в техническом плане, но он выполняет свою роль, и если его не станет (и мне предложат занять его место) — я сразу уволюсь, потому что ну нахрен общаться с этими далекими от разработки людьми с деньгами. Проходили, нервы дороже.
Согласен. Код должен быть одинаково понятен хоть новичку, хоть опытному программисту.
Код, который может прочитать только опытный программист — плохой код.
Как вы думаете если предложить сделать такую же систему, с таким же функционалом, но на правильном на сегодня стеке за кучу денег, бизнес это купит?
Был как-то на собеседовании, у компании большой проект на Perl'е. И компания собирала новую команду, которая перепишет проект на PHP.
Потому что работать на старых/редких яп это такое себе. Вот конкретно тот проект поддерживал один программист. Где гарантии, что если этот один человек уйдет — они быстро найдут нового? А где гарантии, что этот новый разберется?
Эта похожа на «если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага». :)
Я бы сказал, что это простое следствие нормально организованных процессов в компании. Знакомый работал там, отлично отзывался, ушел только из-за зарплаты. А потом из яндекса сбежал через два месяца — постоянная спешка, нервы, и все что из этого следует.
Скажем так, работая в нормальной компании разработчик спустя время обретает уверенность в себе. Работая в плохих — только испорченные нервы.
И вот для этого успешного донесения этой мысли и нужны либо метрики, либо умение убеждать
Не все так плохо. Когда в проекте куча багов, новые фичи пилятся долго, а программисты постоянно жалуются на код — до руководства все же доходит, что надо что-то делать.
По этому, когда руководство созрело — достаточно просто фразы «так дальше работать нельзя, надо переписывать с нуля». И лично наблюдал ситуацию, когда такая фраза от тимлида сработала. Наняли новых людей + часть людей из старой команды начали параллельно со старым проектом писать новый. Правда, не успел посмотреть, чем в итоге все закончилось — уволился раньше.
Далее возникает вопрос: какими метриками на этом этапе Вы будете подкреплять аргументацию
Это не подкрепляется никакими метриками.
Как уже говорил — любой опытный менеджер должен через это пройти. Тот, кто не прошел — действительно, будет считать все разговоры программистов о техническом долге, о костылях, о легаси который нужно переписать — какой-то фигней, не стоящей внимания.
В такой ситуации можно или сразу увольняться, или расслабиться (в смысле перестать переживать за будущее проекта) и наблюдать за деградацией (ну и набираться опыта — чтобы впредь не оказаться в подобных компаниях).
Всем нам иногда нужен негативный опыт, чтобы до сознания дошел факт о том, что мы делаем что-то неправильно. Менеджеры здесь не исключение. А так как их сфера ответственности намного больше, чем у рядового программиста — то и негативный опыт у них совсем другого масштаба.
Отвечать нужно так:
1. В проекте есть плохой код. Пока он никак не выражается для обычного пользователя, но только пока.
2. Новый функционал пишется поверх старого. Соответственно старые костыли приходится покрывать сверху новыми. Количество плохого кода нарастает.
3. Количество плохого кода рано или поздно приводит к увеличению количества багов.
4. Багов становится все больше, появляются самые неприятные баги — редкие, плавающие, которые сложно воспроизвести, чтобы починить. Старые программисты уходят, новые, банально не могут разобраться во всем этом клубке багов и костылей
5. Самый замечательный этап, который обязательно наступает — это «внезапные» падения проекта. Просто взял, и упал на ровном месте. Проект поднимают — а там ошибка. В итоге банальный запуск проекта выливается в часы нервотрепки, и для программистов и для бизнеса.
6. К этому моменту атмосфера в бизнесе давно испорчена. Бардак, скандалы, поиски крайних. Программистов считают «криворукими», потому что создали такой плохой продукт.
Если команда маленькая, то проект может закончиться просто тем, что пару последних программистов разом уволится, и к очередному падению проекта его просто некому будет поднимать. Ну или новый программист просто не поймет как это сделать.
Либо, если команда большая, то проект переходит в стадию «команда 80% времени чинит бесконечные баги, новый функционал делается со скоростью 1 фича в пол года».
Не смотря на всю печальность ситуации — я считаю, что каждый менеджер проекта, каждый владелец бизнеса должен через такое пройти. Чтобы не было иллюзий, что «чистый код» это какая-то прихоть программистов. Ну и чтобы понимать, что скупой (на сроки в том числе) в итоге платит дважды, трижды и т.д.
Первое, что нужно понять и запомнить — нельзя создать качественный продукт, если компании (владельцам бизнеса) это не нужно.
«Что делать?»
1. Не работать в компаниях с плохим кодом
2. Если уж занесло — не переживать, делать то, что хочет руководство, напоминая, что все это закончится плохо (не работая над тех.долгом), и просто наблюдать, как все в итоге умрет.
Владельцы бизнеса тоже должны получать опыт. Так что пусть получают. Вы их предупредили, ну а то, что они вам ответили «работает и ладно, зачем переписывать» — это уже их проблемы.
Мне не особо нравилось писать юнит-тесты из-за всех связанных с этим церемоний с абстракциями и созданием заглушек, но таким был рекомендованным подход, а кто я такой, чтобы с ним спорить?
Есть такой типаж программистов, которым «западло» писать тесты. В таких компаниях обычно пишут только приемочные тесты, и пишут их тестировщики.
Лично я, когда только попробовал юнит-тесты, осознал, что все что писал до этого — было «тяп-ляп и в продакшен». И очень рад, что начал писать тесты. Юнит, приемочные, интеграционные, в будущем планирую еще мутационное тестирование попробовать.
Прежде чем начинать разговор об архитектуре, и поиска истины между «правильная архитектура, но медленно или тяп-ляп, но быстро?». Нужно разобраться, о каких проектах идет речь.
Хотелось бы поинтересоваться у автора, какое количество моделей было в ваших проектах? Конечно, количество моделей не отражает на прямую сложность логики, но, практика показывает, что проект с 20-30 моделями это одно, а с 200-300 — совсем другое.
Найти хороших специалистов сложно, да. Но, есть области, где их найти еще раз в десять сложнее.
Так говорят только те программисты, которые не готовы отвечать за проект в целом. Которые не думают о том, как с этим проектом будут работать другие люди, через 3-5-10 лет.
Если кто-то «умеет готовить» Perl — это не значит, что новый большой проект в 2020 году нужно писать на нем
Представляете, но это реально сложность. Есть проекты которые переписывали с нуля, не смотря на то, что они отлично работали, только потому, что найти программистов, которые бы их поддерживали было невозможно.
Применять правила хай-лоад разработки для всей разработки в целом — некорректно.
А если проект еще и не покрыт авто-тестами… добро пожаловать в мир бесконечных, самых чудесных и непонятных багов.
Проект, на котором наблюдал такую ситуацию (и тим-лид которого, любил процедурки) в итоге переписывали с нуля, конечно, не только из-за обилия процедур в базе, но и их в том числе.
Не соглашусь. Так на любую ошибку можно сказать «причина ошибки находится между монитором и креслом» — и это правда, но она никак не помогает исправить ошибку.
И есть люди, которые вот так постоянно умничают — говорят очевидные вещи, но которые никак не помогают в решении проблем/задач.
Кстати, вспомнил подобный случай из практики. Сидит программист, к нему приходит какой-то менеджер и спрашивает «почему у нас авторизация с мобильников занимает 7 секунд?» (лично я, даже без знания деталей ответил бы так — потому что авторизация написана через одно место, надо переписывать), а программист начинает рассказывать технические делали — для авторизации делается то, потом вот то, потом там такой косяк, и он решается таким-то образом, который занимает много времени и так далее. Очевидно же, что менеджера не интересуют все эти технические подробности, его интересует вопрос «какого хрена у нас такая отвратительная авторизация?». И ответ на него должен быть соответствующий, например «я готов разобраться в проблеме и предложить решения (и решить), но мне нужно, чтобы тим-лид поставил мне такую задачу, и выставил ей высочайший приоритет»
Не факт.
В нашей компании была ситуация, когда срочно нужен был опытный Ruby-программист. В итоге у найденного (пусть он много и не проработал — а только вытащил проект из ж*пы) ставка в час была раза в 3-4 выше, чем у тим-лида (он с Ruby вообще не работал, по-этому конкретно в той проблеме ничем компании помочь не мог)
Хуже нет, чем предвзятые HR. «Он блондин, а все блондины, которых мы брали на работу, оказывались подлецами, по этому ему сразу откажем»
А что делать программистам, которые мыслят не уровнем своих локальных задач, а уровнем всего проекта? И в какую сторону проект развивается? А что делать программисту, который переживает за качество продукта?
Не все так просто.
Ключевой момент. Если для заказчика авторитетное мнение — знакомый тим-лид из другой компании — можно прямо сразу увольняться. Потому что на каждый второй ваш довод вы будете слышать «А вот мой знакомый тим-лид Вася сказал, что можно и по другому». Классическая разводка ответственности, когда говорит как делать Вася, а отвечает за результат Петя.
Забавно, но размышляя об анонимности пришел к аналогичному выводу — что информацию лучше не скрывать, а наоборот генерировать информационный мусор по нужным параметрам персоны. Возможно уже кто-то и сделал такой сервис — указываешь там, например, свои ФИО — и сервис генерирует фейковые аккаунты в социальных сетях, фотки, сообщения, аккаунты на форумах, и прочее и прочее (и делает это в тарифе ~100$ за год — можно хоть на 20 лет оплатить вперед). Пойди потом разберись, где в этом мусоре реальные данные по нужному человеку.
Только хотел написать, что убивать преступников, как бы это не показалось благородно на первый взгляд — ни разу не гуманно. Очень быстро люди у власти поймут, что это хороший способ убирать неугодных людей — фабрикуется ложное обвинение (или вообще фейк о том, что такой-то человек преступник) и готово — «добродетель» убьет невинного человека.
Мораль, мне кажется, весьма очевидна — не стоит играть со злом, ожидая, что это закончится чем-то хорошим.
Все проще и банальней.
Кто стоит между рядовыми программистами, которые пишут код, и владельцами бизнеса, которые ничего не понимают в разработке? Чаще всего — тот самый сеньер/тим-лид.
И, внезапно может оказаться, что главная задача такого тим-лида — не писать божественный код, а объединять программистов и владельцев бизнеса. Быть промежуточным слоем, адаптером, который абстрактные и оторванные от реальности хотелки «бизнеса» приводит во что-то похожее на ТЗ для программистов.
В моей компании именно так. Тим-лид не является для меня образцом для подражания в техническом плане, но он выполняет свою роль, и если его не станет (и мне предложат занять его место) — я сразу уволюсь, потому что ну нахрен общаться с этими далекими от разработки людьми с деньгами. Проходили, нервы дороже.
Код, который может прочитать только опытный программист — плохой код.
Был как-то на собеседовании, у компании большой проект на Perl'е. И компания собирала новую команду, которая перепишет проект на PHP.
Потому что работать на старых/редких яп это такое себе. Вот конкретно тот проект поддерживал один программист. Где гарантии, что если этот один человек уйдет — они быстро найдут нового? А где гарантии, что этот новый разберется?
Я бы сказал, что это простое следствие нормально организованных процессов в компании. Знакомый работал там, отлично отзывался, ушел только из-за зарплаты. А потом из яндекса сбежал через два месяца — постоянная спешка, нервы, и все что из этого следует.
Скажем так, работая в нормальной компании разработчик спустя время обретает уверенность в себе. Работая в плохих — только испорченные нервы.
Не все так плохо. Когда в проекте куча багов, новые фичи пилятся долго, а программисты постоянно жалуются на код — до руководства все же доходит, что надо что-то делать.
По этому, когда руководство созрело — достаточно просто фразы «так дальше работать нельзя, надо переписывать с нуля». И лично наблюдал ситуацию, когда такая фраза от тимлида сработала. Наняли новых людей + часть людей из старой команды начали параллельно со старым проектом писать новый. Правда, не успел посмотреть, чем в итоге все закончилось — уволился раньше.
Это не подкрепляется никакими метриками.
Как уже говорил — любой опытный менеджер должен через это пройти. Тот, кто не прошел — действительно, будет считать все разговоры программистов о техническом долге, о костылях, о легаси который нужно переписать — какой-то фигней, не стоящей внимания.
В такой ситуации можно или сразу увольняться, или расслабиться (в смысле перестать переживать за будущее проекта) и наблюдать за деградацией (ну и набираться опыта — чтобы впредь не оказаться в подобных компаниях).
Всем нам иногда нужен негативный опыт, чтобы до сознания дошел факт о том, что мы делаем что-то неправильно. Менеджеры здесь не исключение. А так как их сфера ответственности намного больше, чем у рядового программиста — то и негативный опыт у них совсем другого масштаба.
Отвечать нужно так:
1. В проекте есть плохой код. Пока он никак не выражается для обычного пользователя, но только пока.
2. Новый функционал пишется поверх старого. Соответственно старые костыли приходится покрывать сверху новыми. Количество плохого кода нарастает.
3. Количество плохого кода рано или поздно приводит к увеличению количества багов.
4. Багов становится все больше, появляются самые неприятные баги — редкие, плавающие, которые сложно воспроизвести, чтобы починить. Старые программисты уходят, новые, банально не могут разобраться во всем этом клубке багов и костылей
5. Самый замечательный этап, который обязательно наступает — это «внезапные» падения проекта. Просто взял, и упал на ровном месте. Проект поднимают — а там ошибка. В итоге банальный запуск проекта выливается в часы нервотрепки, и для программистов и для бизнеса.
6. К этому моменту атмосфера в бизнесе давно испорчена. Бардак, скандалы, поиски крайних. Программистов считают «криворукими», потому что создали такой плохой продукт.
Если команда маленькая, то проект может закончиться просто тем, что пару последних программистов разом уволится, и к очередному падению проекта его просто некому будет поднимать. Ну или новый программист просто не поймет как это сделать.
Либо, если команда большая, то проект переходит в стадию «команда 80% времени чинит бесконечные баги, новый функционал делается со скоростью 1 фича в пол года».
Не смотря на всю печальность ситуации — я считаю, что каждый менеджер проекта, каждый владелец бизнеса должен через такое пройти. Чтобы не было иллюзий, что «чистый код» это какая-то прихоть программистов. Ну и чтобы понимать, что скупой (на сроки в том числе) в итоге платит дважды, трижды и т.д.
Если часть команды переписывает старый код — значит над тех.долгом уже работают, значит все уже не так уж плохо.
Есть ситуации, о которых, как понимаю и говорит автор, когда тех.долгом вообще не занимаются — «работает и ладно»
1. Не работать в компаниях с плохим кодом
2. Если уж занесло — не переживать, делать то, что хочет руководство, напоминая, что все это закончится плохо (не работая над тех.долгом), и просто наблюдать, как все в итоге умрет.
Владельцы бизнеса тоже должны получать опыт. Так что пусть получают. Вы их предупредили, ну а то, что они вам ответили «работает и ладно, зачем переписывать» — это уже их проблемы.
Есть такой типаж программистов, которым «западло» писать тесты. В таких компаниях обычно пишут только приемочные тесты, и пишут их тестировщики.
Лично я, когда только попробовал юнит-тесты, осознал, что все что писал до этого — было «тяп-ляп и в продакшен». И очень рад, что начал писать тесты. Юнит, приемочные, интеграционные, в будущем планирую еще мутационное тестирование попробовать.