Должен ли я уволиться с работы, если я беру на себя плохую кодовую базу с не очень хорошей поддержкой от первоначальных создателей?

Много устаревшего кода отстой. Даже если код был разработан с использованием лучших практик того времени, лучшие практики десятилетней давности очень часто сильно отличаются от лучших практик сегодня. Но более того, поскольку разработчики приходят и уходят, не все разработчики будут придерживаться первоначального видения, которое было у первоначального разработчика. Например, даже если они смогут понять это видение, они могут просто не заботиться о его дальнейшем продвижении. Некоторых разработчиков это может волновать, но другие разработчики могут просто реализовать быстрые уродливые хаки, чтобы выполнить свою работу. Через несколько лет у вас может быть действительно уродливая кодовая база.

Мой совет будет просто попытаться придерживаться его. Если вы убегаете с работы каждый раз, когда сталкиваетесь с дерьмовым кодом, вы будете работать с любой работы на свете. Ну, может быть, за исключением стартапов с нуля. Если вы привыкнете работать с дерьмовым кодом сейчас, то ваш опыт может стать историями, которыми вы поделитесь в интервью позже!

Существует несколько видов профессий программиста. Это один из них.

«Поддержка устаревшего кода» — это большая часть отрасли с разной степенью безобразия. Если вы решите, что вас не устраивает работа в этой области, тогда да, вы можете уйти и искать другую работу, но вы должны понимать, что вы урезаете большую часть возможного карьерного пространства. Если вы в целом хорошо относитесь к унаследованному коду, но считаете, что этот конкретный унаследованный код однозначно уродлив, и не хотите заниматься этим конкретно? Что ж, возможно , вы правы. Хотя я бы не стал на это ставить.

Похоже, вам придется работать над рефакторингом по ходу дела. Ваш начальник вряд ли предложит вам провести какой-либо серьезный рефакторинг в ближайшее время, но он не собирается мешать вам улучшать код, к которому вы прикасаетесь. Как только вы поймете, что делает фрагмент кода, прокомментируйте его. Если вы касаетесь части кода и видите эти обертки «проглотить все ошибки», подумайте, где вы можете позволить себе сделать их более информативными. Даже если вы заставите их работать с журналами, вы можете сбросить туда всю трассировку стека, после чего получить необходимую информацию в любом случае будет относительно просто. По мере того, как вы будете лучше понимать вещи, работайте над улучшением того, что вы можете.

Что касается «выполнения дела вовремя», это только ваше восприятие, или вы получаете какую-то обратную связь от начальства, что они считают вашу работу неприемлемой? Это правда, что унаследованный код с большим количеством долгового кода требует больше времени для работы, особенно когда вы только начинаете. Возможно, они принимают это во внимание, а вы нет. Это, вероятно, станет лучше, когда вы получите более глубокое понимание того, как работает система (и вам удастся провести рефакторинг некоторых ее элементов). Насколько "влияет на ваш рост"? Ну... да, но не так, как ты думаешь. Это не повлияет на ваш рост или на его рост. Это повлияет на то, как вы будете расти. Как я уже сказал, управление унаследованным кодом — огромная часть отрасли. Изучение того, как делать это хорошо, не является бесполезным ростом.

Устаревший код составляет большую часть разработки на рынке. Вам редко удается разрабатывать новые проекты с нуля, используя самые современные инструменты и методы.

Устаревший код сам по себе неплох, но это достаточно распространенное явление, и вам нужно научиться работать в такой среде.

Я не говорю, что вам нужно смириться с этим и придерживаться этого, но что вам нужно оставить шанс своему рабочему месту. Вам нужно научиться справляться с унаследованным кодом (например, вы можете прочитать «Эффективная работа с унаследованным кодом»), и вам нужно рассказать своему коллеге и руководителю о цене плохого кода.

Если вы сможете научить людей лучшим методам работы и внедрить передовые методы и инструменты на своем рабочем месте, вы приобретете ценные профессиональные навыки и доверие. Однако если ситуация не улучшается и вы страдаете от этого, то обязательно найдите другое место работы.

Я бы продолжил работу. Делайте все возможное с кодовой базой в ее нынешнем виде, и вскоре вы поймете, как она сочетается.

Когда вы работаете над элементами, очищайте код как можно лучше в тех областях, в которых вы работаете. Через некоторое время вы сможете высвободить время для более широкой работы.

Но пока наращивайте и корректируйте по мере необходимости. Относитесь к этому как к опыту обучения.

Кроме того, если вы уволились и нашли другую работу, вероятность того, что вы окажетесь в команде, использующей великолепно организованную кодовую базу, минимальна. Идеальный код — это идеал, но всегда будет компромисс между совершенством и «сделать это». В большинстве случаев побеждает принцип «сделай это».

Как уже говорили другие, существует множество дерьмового кода, и многие из нас в конечном итоге будут его поддерживать.

(Справедливо также сказать, что мы создаем его под давлением, или в начале нашей карьеры, или потому, что мы не знаем ничего лучше. Не принимайте на свой счет, когда другие навязывают вам такой код! )

Тем не менее, ваш выбор в начале вашей карьеры имеет значение. Много . Если вы потратите свои первые несколько рабочих мест на обслуживание некоторых приложений, написанных на спагетти-коде, вам будет сложно развить свои более тонкие инженерные навыки. Научиться хорошему дизайну будет сложно. И распознать плохой дизайн — это не то же самое, что знать, как создать хороший.

По моему опыту, позже это сведет на нет ваши карьерные возможности. Я беру интервью у многих инженеров-программистов и отказываюсь от оценок именно по этой причине. Они приятные, дружелюбные и знают основы программирования, но после многих лет работы в плохой среде они, кажется, не видят ничего кроме этого. Они не умеют хорошо решать проблемы. После того, как им много раз говорили, что вещи не могут измениться (или меняться, но медленно), они потеряли свою искру. Их инженерные решения будут окрашены их (плохим) опытом.

Когда свежему выпускнику не хватает более тонких навыков, менеджер по найму ищет возможность учиться. Когда кому-то с 5 или 10-летним опытом не хватает этих навыков, это огромный красный флаг. Почему они еще не научились? Будут ли они когда-нибудь? Поддаются ли они обучению?

Если вы будете разборчивы в выборе работы в начале своей карьеры, это ограничит ваш выбор. Отсутствие разборчивости также ограничит ваш выбор (и вашу зарплату) позже.

Что касается того, что искать в этой или другой работе. Важна не столько техника, сколько наставники. Найдите место, где есть кто-то, у кого вы действительно можете чему-то научиться, а затем приклейтесь к нему или к ней. Узнайте как можно больше, прежде чем перейти к следующей возможности.

Вы написали:

Поговорил с моим менеджером, он ответил, что я могу переписать эту кодовую базу через какое-то время, но я доставлю то, что ожидается, прежде чем начать переписывание, что снова доходит до сути, я не могу понять этот спагетти-код, если бы я мог, я бы даже не надо переписывать

Это звучит как идеальный случай для постепенного «рефакторинга» кодовой базы.

Выполняя повседневные задачи, воспользуйтесь возможностью «рефакторить» (улучшить) кодовую базу. Начните, например, с улучшения обработки исключений. Затем добавьте комментарии. Затем улучшите обработку запросов. Затем улучшить что-то еще, и так далее.

Поговорите со своим руководителем, расскажите ему о своем стремлении сделать это и совместите работу по «рефакторингу» со своими повседневными задачами. Убедите их, что рефакторинг принесет дивиденды в среднесрочной и долгосрочной перспективе, учитывая, что с лучшей кодовой базой будет легче работать как вам, так и следующему программисту (кем бы он ни был).

Со временем кодовая база будет улучшаться, и однажды она станет логически организованной и понятной.

Нам, программистам, время от времени приходится иметь дело с плохим кодом. Не пугайтесь и не разочаровывайтесь — примите это как вызов и учебную деятельность!

Итак, добро пожаловать в настоящий мир разработки программного обеспечения, а не в тот мир, каким вам хотелось бы его видеть. В мире, как мне бы хотелось, весь код был бы сильно прокомментирован, имел бы надлежащие тест-планы, дизайны, спецификации требований и многое другое.

Я занимаюсь этим уже 42 года из-за денег, но до сих пор не получаю того, чего хочу.

Это больше соответствует ситуации, в которой вы находитесь.

Пока у вас не будет достаточного опыта, а это будет гораздо ближе к 10 годам, чем у вас сейчас, у вас не будет профессиональной репутации, позволяющей изменить организацию. Что вы можете сделать прямо сейчас, в начале своей карьеры, так это начать развивать эту репутацию. Это значит:

1. Оставьте код лучше, чем вы его нашли.
2. Кодируйте идиоматически на любом языке. Не делайте это своим личным стилем, но делайте это ясным и читаемым, и в идиомах для этого языка.
3. Будьте очень осторожны, читая лекции более опытным разработчикам. Мы все знаем, что нас заставляют делать то, чего мы не хотим, менеджеры, которые должны прекратить это делать.

Проблемы, которые вы описываете, решаются годами. Во-первых, есть много устаревшего кода, который сгнил за эти годы. Во-вторых, вы должны вовлечь своих коллег в идею.

Но чего вы не можете сделать, если хотите иметь хороший код для работы, так это бросить работу. Потому что так же плохо, более или менее, в следующем месте.

Сначала самое главное: нет, это не нормальное явление. Я проработал более 15 лет разработчиком программного обеспечения в стартапе (в Великобритании), правительственном ведомстве (в Новой Зеландии), большом исследовательском институте, телекоммуникационной и многомиллиардной инвестиционной организации (все в Швейцарии). Ни у кого из них не было и близко такого плохого кода. Конечно, я сталкивался со всеми этими проблемами (не с частью «90%», а со всеми по отдельности) не раз, и неидиоматический код, в частности, довольно распространен, но кодовая база, замусоренная всеми этими проблемами, — это смертельная ловушка.

Достойный менеджер знает, что переписывание очень рискованно и довольно дорого, даже если оно проходит очень хорошо. В стартапе было бы наивно ожидать, что переписывание находится где-то в пределах финансового горизонта компании.

Что же касается того, следует ли вам остаться, то существует куча вакансий, на которых вы получаете соответствующую подготовку, где люди действительно заботятся о таких вещах, как качество и безопасность, где менеджеры реалистично и честно относятся к переписыванию, где вы можете обратиться к людям, хорошо знающим технологию. существующая система в помощь, и, если хоть немного повезет, все вышеперечисленное.

Необходимость работать со старой кодовой базой сама по себе не является проблемой. Кто-то должен это сделать. Так же, как кто-то должен собирать мусор людей раз в неделю или раз в две недели. Конечно, если вам это не нравится, вы должны найти другую работу.

Проблема, связанная с рабочим местом, может заключаться в том, что ваша работа не ценится. Это только производит затраты для компании, никакой новой прибыли. И, как вы сказали, вы добиваетесь меньшего результата в неделю, чем могли бы на какой-то другой должности. Но вашему руководителю и менеджменту в целом должно быть ясно, что вам нужно платить за проделанную работу, а не за прибыль, которую она приносит компании. (И если бы это производило только затраты, а не новый доход, я думаю, это нанесло бы огромный ущерб, если бы эта работа не была сделана, или они вообще не наняли бы вас. Получение прибыли и предотвращение убытков — это одно и то же. Или мы должны избавиться от пожарных в городах повсюду, так как они никогда не производят ничего ценного. Обычно, когда они выполняют свою работу, возникают огромные потери. Если они не делают свою работу, потери будут гораздо более масштабными

Поэтому объясните своему начальнику, что (а) кодовая база запутана, что она недокументирована, и что любая работа в ней требует больше времени, чем можно было бы ожидать, и (б) ваша оплата должна быть такой же или выше, чем у вас. что из людей, выполняющих модную работу.

В зависимости от того, как долго этот продукт будет поддерживаться, договоритесь со своим руководителем о том, что улучшение и документирование кодовой базы является частью вашей работы.

Часть этого на вас. При собеседовании на работу, особенно в области программирования или инженерии, вы должны задать себе следующие вопросы:

• Какая технология используется? Насколько велика и стара кодовая база?
• Это разработка с нуля?
• Написано ли достаточное количество тестов?
• Какая автоматизация используется (CI/CD)?
• Каков процесс регистрации и слияния, что вы используете для контроля версий?
• Какие инструменты вы используете для помощи в разработке/тестировании/отладке?

И т. д.

Обязательно задавайте эти вопросы во время собеседования. Ни одна компания не идеальна, но есть много компаний/кодовых баз, которые истощают вашу душу.

Если вы несчастливы, просто продержитесь от 6 месяцев до года. Никому не нравится слышать, что я уволился с прошлой работы из-за ужасной кодовой базы. Вы все еще можете узнать кое-что о том, чего НЕЛЬЗЯ делать, и, возможно, вы сможете внести небольшие улучшения во время своего пребывания в должности, о чем спросит ваш будущий сотрудник.

Ключевой вопрос:

Ваше руководство понимает, признает и признает проблему, и управляет ли оно своими собственными ожиданиями в отношении эффективности и качества работы на основе этой кодовой базы?

Если да: рассматривайте это как шанс.

Если нет: Беги :)

Я часто обнаруживал, что лучший подход при доведении этих вопросов до сведения руководства состоит не в том, чтобы жаловаться на сложность кода или на сложность разработки, а в том, чтобы дать четкое описание проблемы, вызванной эта структура.

В вашем случае, когда проглатывается большое количество исключений, придумайте легко объяснимую и воспроизводимую проблему, например:

1. Логи клиента добавляют foo в корзину
2. Клиент оформляет заказ, но код подтверждения не работает при приеме платежа.
3. Мы отправляем товар покупателю в любом случае

И это, вероятно, привлечет их внимание гораздо быстрее. Это вопрос оформления:

«У меня проблема с кодовой базой, из-за которой очень сложно писать и поддерживать этот код без внесения ошибок. Могу ли я изменить его, пожалуйста?»

это твоя проблема

«У меня проблема с кодовой базой — я обнаружил [вставьте здесь ужасную бизнес-проблему] , которая, по-видимому, в значительной степени связана со структурой, использованной при написании этой статьи. Могу ли я найти время, чтобы изменить ее, пожалуйста?»

Это то же самое, но теперь это проблема для вашего босса, и, таким образом, вам легче выделить время для работы над этим.

Код, который так же сложно писать и поддерживать, как вы описываете, с гораздо большей вероятностью будет иметь такие ужасные проблемы. Все, что регулярно перехватывает и съедает исключения, может привести к возникновению всевозможных странностей.