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

Теперь вы знаете эту программу лучше, чем кто-либо.

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

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

Очевидно, взгляните на то, что вы демонстрируете, и узнайте, что работает, а что нет. Также посмотрите любую документацию/поговорите с людьми и поймите, что должно работать и как. Демонстрация знаний и демонстрация уверенности в системе вызовут доверие к вам и тому, что вы говорите. Это поможет вам вернуть все на рельсы.

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

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

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

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

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

Подобные ситуации не так редки, как вы думаете. Конечно, это может ощущаться как надвигающаяся гибель.

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

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

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

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

Маловероятно (хотя и не невозможно), что вы настроены на неудачу. Более вероятно, что бизнес пытается сделать что-то из того, что в настоящее время является безвозвратным убытком.

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

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

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

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

Такого рода кодовая база встречается на удивление часто, и многие из нас работали над подобными. (Было замечено, что кодовая база является отражением организационной структуры, создавшей ее, или даже движущейся хроникой организации). Вот прагматичный подход, который я изучил:

• Менеджмент не знает кодовой базы (на самом деле это и сила, и слабость), совершенно не заботятся об ошибках и только заинтересованы в добавлении новых функций. Так что гораздо проще продать их, если вы работаете над последним (приносящим доход), а не над первым (поглотителем затрат); им проще продать это как внутри компании, так и заказчику.
• Поэтому, когда проект начинается, очень быстро проведите сортировку самых серьезных ошибок и либо добавьте неудачные тестовые случаи или обвязки, либо, как минимум, задокументируйте сценарии в системе отслеживания ошибок ( «Когда я делаю X на Y, это не работает». с результатом/ошибкой Z" ). Пересматривайте это время от времени, когда позволяет время, или когда очевидное наличие или серьезность ошибок в отношении разрабатываемых функций существенно меняется. Очень сложно быстро сортировать вещи, которые должны быть исправлены, но время не позволяет. Но пишите отчеты об ошибках и планируйте исправления с расчетом на то, что какое-то неизвестное время и бюджет могут появиться волшебным образом.
• Затем, когда вы расширяете область добавления функций, любой связанный рефакторинг и исправления ошибок становятся зависимостью функции, включаются в работу, оценки времени, тестовые сценарии. Как вы определяете и сообщаете об этой работе, зависит от вас. Только ты знаешь, как их обойти. Пока в резюме говорится «Реализация функции X», им все равно.
• Подойдите к демонстрациям, проведя внутренние репетиции за несколько недель до этого, как возможность показать им: «Мы реализовали код для X, но в нем есть ошибки A, B, C, которые необходимо исправить». На самом деле, запланируйте внутреннюю демонстрацию для своего руководства, независимо от того, просит ли ее клиент. Постепенно приучите их учитывать в своих оценках x% времени на исправление ошибок и тестирование или, наоборот, делать первые демо за несколько недель до того, как вы ожидаете работающий код.
• «Работайте в их мире, а не в вашем»

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

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

Прошли месяцы и скоро пора показывать программу

Шаг 2: убедитесь, что у вас есть регулярные демонстрации/предварительные просмотры с клиентом, как для того, чтобы установить ожидания, так и для того, чтобы убедиться, что вы делаете правильные вещи/приоритеты.

Поскольку рефакторинг есть и никогда не был вариантом из-за нехватки времени и пожеланий менеджера

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

так как мне пришлось делать некоторые странные вещи, чтобы обойти ошибки

Никогда не скрывайте ошибки, поднимайте их, добавляйте в систему отслеживания ошибок и получайте суждение об их исправлении (см. выше)

Как я могу избежать наказания за унаследованный мной проект, в котором уже были ошибки, в то время как мне сказали работать над дополнительными функциями, а не исправлять ошибки?

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

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

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

Это не означает, что вы не можете проводить рефакторинг по ходу дела.

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

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

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

Рискуя показаться легкомысленным, мир жаждет программистов. Некоторые организации разоряются, если, возможно, это так, то ищите новую работу .

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

Берегите себя в этой ситуации.

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

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

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

Если это произойдет в будущем, то, что вы делаете, это: -

• Быстро оцените то, что вы унаследовали.
• Сообщите об этом своему руководителю по электронной почте и порекомендуйте подходящие действия по исправлению вместо исправления ошибок в течение нескольких недель, прежде чем продолжить.
• Отложите (распечатайте и храните в файле на работе И дома) любой отказ/настойчивость в отношении новых функций, чтобы прикрыть себя позже.
• Мягко отклоняйте любой запрос на новые функции, говоря, что вы боитесь, что можете дестабилизировать хрупкую кодовую базу. Отправьте окончательное решение от вашего менеджера, как указано выше.
• Напишите модульные тесты для всего , что вы добавляете.
• Подкрепляйте каждую оценку, которую вы даете для новой функции , кроме добавления модульных тестов (Как кто-то может противоречить вашей оценке, если он не знает кода?).
  Затем, используя свое «лишнее» время:
• Добавьте больше модульных тестов для областей с наибольшим количеством ошибок (как предлагали другие люди).
• Исправьте ломающие тесты.
• Рефакторинг старого кода.

Ваша ситуация будет улучшаться с каждой новой функцией.

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

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

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

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

Было сказано многое, с чем я согласен, но я думаю, что есть еще одна вещь, которую следует упомянуть: это потрясающая возможность для вас.

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

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

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

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

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

По моему опыту, в подобных ситуациях менеджер часто так же счастлив, как и разработчик, обвиняя парня, который покинул компанию!

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

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

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

Заставьте своего босса поддержать вас. Убедитесь, что ваш начальник убежден в наличии серьезных проблем, чтобы он мог получить время и согласие от высшего руководства. Затем наймите лучшего архитектора в компании, чтобы он помог вам изменить дизайн, провести рефакторинг или переписать проект. Работайте со своим менеджером и архитектором над созданием явно лучшей программы. Это случилось со мной в последние 6 месяцев.