Помогает ли работа с унаследованным кодом стать программистом? [закрыто]

Я Java-разработчик с чуть более чем годовым опытом, который ставит меня где-то выше младшего, но пока не относится к числу разработчиков среднего уровня. Недавно мне предложили долгосрочный проект, который заключается в изучении существующего кода банковского приложения в течение 4 месяцев и внесении изменений при необходимости. Как неопытный программист, я ищу способы развития и думаю, что может дать такой проект.

Считаете ли вы, что работа с большими и, возможно, не очень хорошо написанными приложениями - хорошая практика для начинающих?

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

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

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

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

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

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

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

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

Это абсолютно поможет вам, но вы должны быть осторожны.

Вы должны убедиться, что вы учитесь на унаследованном коде. Откуда ты знаешь, что хорошо, а что плохо? Может быть, вы можете узнать плюсы и минусы различных шаблонов / методов, но если вы были начинающим разработчиком, только начинающим, вы не сможете.

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

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

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

Предупреждение о спортивной аналогии: Как вы думаете, покровитель в НФЛ учится больше и становится более ценным, играя в команде с худшим результатом или лучшим? Мой ответ: они не только более ценны, играя за лучшие команды, но, вероятно, они подобрали лучшие практики и знания и избежали выбора методов и подходов, заканчивающих карьеру.

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

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

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

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

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

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

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

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

Это очень сильно зависит от того, как вы определяете «наследие» в этом контексте. Позвольте мне привести пример из C и C ++. Многие программисты на C ++ называют плохой практикой использование строк C в приложениях C ++, другие не требуют смешивания, в то время как другие, в свою очередь, утверждают, что использовать биты кода C просто потому, что они старые, т. Е. " Наследственный "код. Некоторые идут дальше и избегают использования pre-C ++ X (замените 'X' соответствующим числом) стандартные идиомы, стиль - это синтаксис, потому что это "устаревший" стиль.

Оставляя в стороне проблемы производительности потоков и строк C ++ и некоторые особенности STL, это хорошая практика, чтобы взглянуть на то, что находится внутри вашей столь любимой директивы препроцессора #include <string.h>. Если вы пойдете по пути к реализации и окажетесь на машине unix / linux по адресу /usr/include/string.h(и получите источники реализации libc, например, из gnu.org ) и прочитаете strcmp.cили strlen.cили strtok.c, держу пари, вы услышите «Какой прекрасный мир "постепенно.

Однако в этой прозе есть предостережение, а именно устаревшие классы и методы. В Java довольно много устаревших вещей все еще доступно из недавней среды, но, если я правильно помню, не все. В секторе IB, из моего собственного опыта, ну, не все программное обеспечение написано хорошими программистами. Многие выпускники практически не знакомы с программированием в реальном мире, прежде чем они начали работать в должности аналитика / разработчика. Но не обобщайте это утверждение. Я знаю многих людей, которые используют Java и C # в ядре высокопроизводительных сред с низкой задержкой. Я не согласен с ними, но, к счастью, это их дело. Если бы они пошли настоящими HFT, их бы оттолкнули далеко в очереди. Но опять же из этого предложения легко понять предположение (и во многих случаях тот факт), что код Java является высокооптимизируемым. И если вы сможете преуспеть в оптимизации, если потребуется, а не только в исправлении того или иного, вы станете бесценным разработчиком. Очень приятно осознавать, сколько вы внесли. Я бы пошел на это.