Борьба с техническим долгом как «самым низким разработчиком»?

Допустим, вы работаете в компании и разрабатываете программное обеспечение для них. Вы не представляете себе общую картину или, может быть, небольшую. У вас есть задачи, назначенные вам через систему отслеживания проблем. Вам дают задания, вы заставляете их работать так, как их описывает задача, вы отправляете их обратно. Как добавление 2 целых чисел:

function add(a,b){return a + b;}

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

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

Как вы справляетесь с этими ситуациями? Как вы боретесь с техническим долгом как «самый низкий разработчик»?

Разъяснение:

• Ты - "исполнитель", самый низкий в иерархии.

• Вы видите проблему, но не имеете права говорить с этим вопросом.

• Я не определяю технические долги и не ищу инструменты.

• По поводу третьего «дубликата»

  • Рефакторинг и перезапись - вы заблокированы для ваших задач. Вам не платят, чтобы сделать дополнительно.
  • Обзор архитектуры - Вы знаете общую систему, но понятия не имеете об архитектуре.
  • Замораживание кода - не ваш звонок. Ты не менеджер.
  • Модуляризация - без понятия архитектуры. Модули меняются при изменении требований.
  • Автоматизированные тесты - ни один не существует.

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

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

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

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

(Названия функций, тикетов и код, используемые в реальном трекере, скрыты, но текст копируется как есть).

Резюме: упростить дизайн с участиемParticularPieceOfCode

Описание:
в ходе реализации согласно TICKET-12345 код, связанный с использованием, ParticularPieceOfCodeнакапливал некоторые сложности и стал довольно трудным для чтения, понимания и обслуживания (см. Пример фрагмента кода ниже).

Найдите способ упростить это.

Пример кода, который желательно изменить, можно найти в ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW мой совет применяется независимо от того, какой вы "уровень".

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

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

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

• ^{Вы можете подумать, что ваше мнение написано (например, по электронной почте) было бы лучше, но если вы думаете об этом, это действительно не так. Если ваш проект имеет значительную почтовую активность, то, что было написано, будет потеряно и через месяц будет забыто.}

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

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

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

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

Даже если вы предпочитаете греметь в эфире , высказывание «Я бы хотел обсудить TICKET-54321 ...» делает более прочную отправную точку, чем «Послушайте, я бы хотел поговорить о некотором фрагменте кода, с которым я имел дело некоторое время назад». ... »И вы можете безопасно передавать ссылки на тикет по почте: даже если почта будет потеряна, проблема все равно останется в трекере со всеми подробностями, о которых вы хотели рассказать.

Что меня расстраивает из-за вашего сценария, так это то, что вы написали в заголовке и несколько раз в тексте вопроса:

Вы самый низкий разработчик в цепочке

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

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

Возьми! Не ждите, пока кто-то не сделает вас ответственным.

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

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

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

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

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

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

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

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

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

1. Если исправление тривиально, независимо от того, связано оно или нет, исправьте его.
2. Если исправление является нетривиальным и ненужным, сделайте официальную рекомендацию, используя любой формальный механизм связи / отслеживания проблем, который вы согласовали.
3. Если может быть доказано, что исправление необходимо для выполнения основной задачи, но оно неожиданно увеличит стоимость, сообщите об изменении области действия.
4. Если выявленная проблема представляет серьезную угрозу для успеха проекта, проясните это. Формально. Если существуют этические проблемы, связанные с разрешением проблемы, не решенной (например, в системах здравоохранения, чрезвычайных ситуациях или транспортных системах), настаивайте на решении проблемы до отгрузки продукта (уведомите СМИ или органы власти, если этически необходимо).

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

1. Будь хорошим примером. Насколько вы можете, производить чистый и разумный код. Когда вам предоставляется выбор, выберите тот, который соответствует вашим требованиям с меньшими недостатками. (Имейте в виду, что технический долг - это не что иное, как долговые обязательства - просто иметь его не обязательно плохо.)
2. Сообщите свои проблемы . У вас должен быть кто-то, либо руководитель группы, либо заказчик, либо архитектор, который на самом деле несет ответственность за управление техническим долгом и распределение ресурсов вашего предприятия. Когда вы видите что-то, что считаете плохим, сообщите им о своих проблемах. Поместите это в письменном виде (например, в электронное письмо), если вы не уверены, что они поймут, ответят и оценят ваш вклад.
3. Не стресс Технический долг редко приводит к прекращению занятости предприятия. Пока вы сообщаете о своих проблемах и выполняете свою работу, проблемы с архитектурой, такие как технический долг, в буквальном смысле не являются вашей проблемой. Да, они могут повлиять на вас, но они не больше беспокоит вас, чем переизбрание шерифа - это беспокойство младшего офицера полиции.

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

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

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

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