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

20

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

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

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

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

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

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

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

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

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

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

    • Рефакторинг и перезапись - вы заблокированы для ваших задач. Вам не платят, чтобы сделать дополнительно.
    • Обзор архитектуры - Вы знаете общую систему, но понятия не имеете об архитектуре.
    • Замораживание кода - не ваш звонок. Ты не менеджер.
    • Модуляризация - без понятия архитектуры. Модули меняются при изменении требований.
    • Автоматизированные тесты - ни один не существует.
Джозеф
источник
3
@gnat, я думаю, что вопросы связаны (особенно последний), но не дубликаты. Я вижу этот вопрос как «Учитывая, что разработчик системы не является разработчиком, а разработчикам не предоставляется общее представление о системе, как можно быть уверенным, что реализации достаточно гибкие или масштабируемые?»
MetaFight
1
Вы спрашиваете, как бороться с техническим долгом в целом, или вы спрашиваете, как бороться с техническим долгом, когда вы играете роль кодировщика, на которого не возложена ответственность за улучшение архитектуры?
Док Браун
2
@JosephtheDreamer Да, есть много вещей, которые можно сделать, чтобы улучшить исходный код, но вы заявили в своем вопросе, что проблема заключается в отсутствии полномочий для принятия каких-либо изменений. Я мог бы рассказать вам все лучшие практики, но если вам не позволено тратить огромное количество времени на их реализацию, то какой в ​​этом смысл? ;)
Reactgular
2
« Но задания исходят от высших людей » - что мешает вам дать себе какие-то задания, кроме « Мне не платят за это » сегодня? Если вы будете действовать как получающая команду пчела, вас будут рассматривать как единое целое.
JensG

Ответы:

22

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

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

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

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

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

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

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

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

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

<a piece of code like one behind the right door here:>
http://i.stack.imgur.com/ARBSs.jpg


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

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

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

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

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

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

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

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

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

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

комар
источник
7
+1 Хороший совет, но отслеживание проблем в среде, которая не охватывает процесс, просто становится черной дырой. Что хорошего в отслеживании проблем одного человека. В лучшем случае фантастический список дел.
Reactgular
@MathewFoscarini перед публикацией я разъяснил это с помощью OP в комментариях (в моем ответе это связано с «вашей системой отслеживания проблем») - «Да, отсюда и« задачи »(проблемы, заявки, как бы вы их ни называли) ...» Я также не был бы настолько пессимистичен в отношении случаев «черной дыры», в долгосрочной перспективе ситуация имеет тенденцию меняться, особенно если разработчики «самого низкого уровня» проявляют инициативу и вкладывают усилия в поддержание трекера и продвижение его использования самостоятельно (если бы там было сделано, что )
комнат
И, кроме того, я видел людей, обвиняемых в загрязнении системы билетов (= открытие «слишком много» билетов). Если культура не подходит, никакая система билетов не поможет. К сожалению, технически люди склонны искать технический инструмент, а не решение, и другие технические специалисты считают его хорошим советом, потому что он соответствует их процессу мышления.
JensG
1
@JensG «люди обвиняются в загрязнении системы билетов» - это известное явление, возможно, заслуживающее отдельного вопроса (или, возможно, его уже задавали и отвечали, я не искал). Если культура не подходит, потребуются дополнительные конкретные усилия, чтобы система тикетов стала полезной (как я уже писал в предыдущем комментарии, я уже проходил через это ранее).
комнат
8

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

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

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

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

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

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

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

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

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

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

JensG
источник
8

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

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

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

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

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

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

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

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

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

DougM
источник
2
«Технический долг редко приводит к краху предприятия из-за занятости». Я не был бы так уверен. Причиной неудачи многих программных проектов является технический долг.
Эйфорическая
2
Проект не предприятие, @Euphoric. Mozilla не перестал существовать только потому, что Sunbird никогда не взлетал. Если ваш проект провалился, вы переходите к новому проекту с тем же работодателем. Если ваше предприятие терпит неудачу, вам нужно найти новую работу.
DougM
Этот ответ очень неправильный. Я видел технический долг, разрушающий продукт предприятия. А что касается «технически долга - это буквально не ваша проблема», чья это ответственность, если не разработчики программного обеспечения?
Брэндон
2

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

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

winkbrace
источник
4
это только ваше мнение или вы можете как-то это подтвердить? На уровне OP («низший») «нажимать на педали тормоза, говорить« нет »», по моему опыту, редко получалось нормально. Ни для проекта, ни для карьеры. Оглядываясь назад, я могу ясно вспомнить случаи, когда я пропускал одну или две вещи, когда «отказывался» от видения старших коллег / ведущего / менеджера
комнат
С точки зрения человеческих ресурсов, размещение людей за рабочими билетами без надлежащего решения их трудовых проблем может привести к катастрофе. Счастливые работники работают больше за меньшие деньги, этому есть экономические доказательства. Наступить на тормоза - это возможность обучения как для младшего, так и для руководства. Тормозить - это то, как стартапы могут быть настолько компетентными за такое короткое время, у нас нет чертовых билетов. Это может привести к конфликту, но конфликт является частью чертовой жизни. Забота о качестве должна быть выслушана и обеспечена, так что я на шаге на стороне тормозов.
Артур Гавличек
2
Я рекомендую это чтение, в котором говорится
Артур Гавличек,