Як ви виходите з ролі підтримуючого коду? [зачинено]

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

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

Написання нового коду та підтримка існуючого коду - це два абсолютно різних завдання. Це як порівняння інженера з авіації та механіки літаків.

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

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

Мені здається, що на це запитання насправді немає простої відповіді, але хтось міг дати мені деяку інформацію? Ви коли-небудь бували на першому поверсі нового проекту? Що потрібно було, щоб потрапити туди?

Технічне обслуговування означає різні речі для різних людей і виникає з різних причин.

• Найгірший випадок, коли початкова система була співана в поспіху, початкова команда взяла на себе кредит за всю справу. Вони дотримувались правила 80/20, тому, хоча може бути мінімально життєздатний продукт, який можна продати, багатьом клієнтам потрібно багато виправлень та невеликих вдосконалень. Залишається багато проблем, але слави залишається не багато. У вас найважча робота, і її невдячна. Я сподіваюся, що це не ваша ситуація.
• У кращому випадку, ви показали, що ви обережні зі своєю роботою і можете довіряти внесення змін до польового продукту, не порушуючи його. Проблеми, які залишаються, надто важкі для людей, які разом забили оригінальну систему. Можливо, вони не змогли побудувати систему до останнього, і ви там, можливо, як їх заміна, щоб налаштувати все і врятувати клієнтів, проект та прибуток.
• Дуже ймовірно, 60% витрат на проекти припадають на технічне обслуговування. Можливо, це час, можливо, ваша організація розмежовує між новою розробкою та технічним обслуговуванням, але ви знаходитесь у 3/5-й більшості, тому що багато хто з нас робить технічне обслуговування.

Ось декілька речей, які можна спробувати:

• Робити чудову роботу, чудово ставитись, бути лідером ідеї.
• Наскільки це можливо, працюйте в командах, а не поодинці.
• Вивчіть новіші мови.
• Дізнайтеся новіші платформи.
• Запросити працювати на менших програмах, можливо, навіть звернутися до менших компаній.
• Будьте кваліфіковані та займіться документацією. Коли проекти починаються, навіть в епоху після водоспаду, їм потрібно багато письмової координації для планування, документування, оцінки та уточнення вимог.
• Проекти небезпечно стартувати в руках людей, які не цінують управління вимогами, оцінку та оцінку ризиків, тому вивчайте та практикуйте ці навички, наскільки це можливо.
• Отримайте більш офіційне навчання або сертифікати. Це може підвищити ваш статус і зробити вам більш привабливим вибір, коли формуються команди для нових проектів розвитку.
• Створіть компанію або якийсь консультаційний бік. Це дає вам творчу розетку для орієнтації на ваш улюблений вид роботи, і ви краще розумієте, що саме починати, не маючи коду чи документації.
• Наблизиться до свого начальника та до людей, які планують нові проекти.
• І навпаки, якщо ви дуже близькі до тестерів і QA, їх вихід часто є вкладом у технічне обслуговування, тож здогадайтесь, з ким ваш начальник думає, що ви дуже добре працюєте?
• Зробіть якомога більше друзів і завоюйте повагу якомога більше розробників Greenfield.
• Нові розробники - це люди, які можуть робити, тому будьте обережні щодо будь-яких натяків на критику чи негатив. Дайте їм свої ідеї вільно, без вини чи судження. Ваші ідеї не потребують вступу, просто скажіть їх. Ніколи не кажіть, що ми робили це так, або це не працює, спробуйте це. Ніколи не кажіть, я не знаю, але це може спрацювати. Просто скажіть ідею. Або краще, покажіть це.
• Знайдіть і скористайтеся будь-якою можливістю створити доказову концепцію, яка може перетворитися на ваш новий проект.
• Слідкуйте за тим, хто призначає вам роботу. Зазвичай це повинен бути хтось у вашій командній ланцюзі. Якщо це ваші однолітки, відсуньте частину часу назад. Якщо це хтось, ким ви керуєте, потрібно бути вагомою причиною того, що контроль перевертається. Якщо це QA або тест, переконайтеся, що він має значення для вашої командної ланцюга, і не планується таким чином, щоб затримати роботу, яку ви обіцяли раніше.
• Остерігайтеся досконалості. Нова розробка часто зарезервована для швидких людей, навіть якщо вони перехрещують очі і не розставляють точки.
• Приділіть час навчанню та практикуйте навички раннього проекту, відповідні вашій лінії розвитку. Сюди можна віднести: створення сховищ джерел, визначення середовища побудови, налаштування сервера постійної інтеграції, тісна робота з апаратною командою для створення нових плат з пакетами підтримки плати або письмом на самостійних тестах. Це може навіть допомогти знати, як працювати з покупкою, щоб придбати нові засоби розробки, навчання та обладнання COTS.
• Переконайтеся, що ви продовжуєте роботу до завершення проекту технічного обслуговування, можливо, купуючи свої навички всередині команд, а може бути, менеджерів, або зовні.
• Вільно володійте кожною технологією, яку ви знаєте, і знайте безліч технологій.

Роль технічного обслуговування можна перетворити на вашу користь декількома способами.

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

Сказавши все це, я є контр-прикладом, а не прикладом для наслідування. Значна частина цієї точки зору виходить із досвіду та спостережень.

Є багато нових програм, які ще потрібно написати.
Будьте готові, і незабаром ви будете працювати над одним.

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

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

До цього часу ви можете спробувати вивчити рефакторинг застарілих програм для очищення модулів.

Гарне прочитання - " Робота зі застарілими програмами " та " Повторне відновлення до шаблонів ". Якщо ви не прочитали оригінал Refactoring (Fowler), будь ласка, зробіть це. І навчитися тестово керованої розробки (TDD) завжди допомагає.

Якщо ви працюєте з PHP, я написав практичну статтю, цей код все ще працює ...

Веселіться!

Найпростіший шлях до втечі - це повністю змінити стиль програмування, а також додати нові навички за той же час. Наприклад, ви можете спробувати бути дослідником. Це може бути не престижною роботою перший рік, і, звичайно, це не настільки високооплачувана, як звичайна робота з програмування (на першому курсі, якщо ви науковий співробітник / науковий співробітник в команді університету - звичайно, як старший науковий співробітник досить гарний багато в чому відповідає решті галузей), але це обов'язково поставить ваші навички роботи над найважчими проблемами, які ви можете знайти сьогодні. Після такої роботи ви могли б легко перестрибнути на кращу позицію, за умови, що у вас є кілька цікавих проектів, щоб показати своєму наступному начальнику.