Боротьба з технічним боргом як "найнижчий розробник"?

Скажімо, ви працюєте в компанії, і ви робите це розробка програмного забезпечення для них. Ви не маєте уявлення про велику картину чи, можливо, незначну. У вас є завдання, призначені вам через систему відстеження випусків. Вам даються завдання, ви змушуєте їх працювати так, як їх описує завдання, ви повертаєте їх назад. Як додавання 2 цілих чисел:

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

Але згодом, коли проект рухається вперед, ви помічаєте, що, addстаючи складнішим, ви розумієте, що він повинен був потребувати певної форми архітектури, більше, ніж просто функція, яка додає параметри і повертає значення. Однак ви цього не знали. По-перше, все, що їм було потрібно, було таким простим add. Ви не очікували, що додавання стане таким складним.

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

Як ви справляєтесь із цими ситуаціями? Як ти борешся з технічним боргом як "найнижчий розробник"?

Пояснення:

• Ви "реалізатор", найнижчий в ієрархії.

• Ви бачите проблему, але не маєте з цим питання.

• Я не оцінюю технічну заборгованість чи шукаю інструменти.

• Щодо третього "дубліката"

  • Refactoring & Rewrite - ви заблоковані у своїх завданнях. Вам не платять, щоб робити додатково.
  • Огляд архітектури - Ви знаєте загальну систему, але не маєте уявлення про архітектуру.
  • Замороження коду - не ваш дзвінок. Ви не керуєте.
  • Модуляризація - Поняття про архітектуру. Модулі змінюються по мірі зміни вимог.
  • Автоматизовані тести - не існує.

Щоразу, коли ви помічаєте щось подібне, введіть новий квиток у систему відстеження випусків.

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

Скористайтеся правильним інструментом для роботи. Я роблю це завжди і настійно рекомендую зробити те саме.

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

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

Резюме: спростити дизайн із залученням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функція, яка зазнала повного повзучості функції, візьміть кілька хвилин і складіть контур того, що її покращить. Надішліть це тому, кому вам знадобиться схвалення для його впровадження, і продовжуйте рухатися далі.

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

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

Візьміть на себе цю відповідальність. Не кажіть додавання функцій, якщо ви не можете підтримувати базу. Проконсультуйте замовника зі своїм досвідом Наступіть на гальма зараз, перш ніж пізно і вам доведеться викинути весь проект, тому що це вже не буде ремонтом.