Що робити, коли перед вами стоїть завдання програмування, якого ви ніколи не робили?

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

Я дуже рада, що нарешті змогла почати кодування. Команда, до якої я приєднався, поки що невелика, тому що починала новий проект, що чудово, тому що я маю бути причетним до всього життєвого циклу проекту. Це веб-проект SPA з підтримкою, що використовує ASP.NET MVC / ASP.NET Web API та в рамках програми Durandal та відповідних бібліотек.

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

Я ніколи не робив жодного зі створених завдань і не знаю, як мені діяти.

Наприклад, одним із створених завдань є створення загального механізму обробки помилок для всієї програми.

Як звичайно діяти людина, стикаючись із завданнями, яких він ніколи не робив?

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

• Подумайте про проблему і намалюйте кілька діаграм. Переконайтеся, що ви знаєте, у чому полягає проблема, яку ви намагаєтеся вирішити.
• Робіть дослідження того, що ви намагаєтеся зробити. Інтернет є цінним джерелом інформації. Я не кажу, щоб запитати Stack Overflow - я кажу, що слід вивчити, як інші люди вже вирішили таку проблему, як ваша, або підійшли до неї. Це те, що google придумав: "Поводження з винятками як системна проблема" . Особисто я завжди намагаюся вчитися у інших.
• Нарешті, і це може бути найважливішим, поговоріть з іншими людьми у вашій команді, щоб отримати більше роз’яснень та напрямків щодо того, що робити. Мені завжди хочеться, щоб нові інженери прийшли просити настанови щодо проектів.

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

Ось чому я інженер; Я люблю вигадувати нові речі.

Ніколи не припиняйте вчитися новому. Навчання - це те, що робить тебе кращим.

Не існує ідеального рішення, але деякі речі, які можуть допомогти:

• Розбийте завдання на найменші можливі одиниці - розбивайте їх до тих пір, поки не будете робити речі.

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

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

• Зверніться за допомогою у виборі правильного завдання та підходу до початку роботи.

• Шукайте наставника, який може надати тиждень-два постійні (в ідеалі щоденні) відгуки.

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

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

• Не бійтеся задавати найосновніші запитання. Припущення інших може бути важким викликом, але якщо ви не можете продовжувати те, що вам дано, доведеться запитати знову.

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

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

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

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

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

=================

PS Є деякі програмісти, які думають, що спосіб запустити будь-який проект - це написання «платформи» для надання всіх загальних послуг, які знадобляться модулям додатків. Зазвичай це перетворюється на місяці тривіальної роботи, що вигадує речі, які вже зараз доступні безкоштовно. Поки ви не досягнете меж продуктивності доступних рішень, немає підстав писати послуги «платформи». Також немає жодних причин писати обгортки навколо існуючих API. Якщо ви рефакторируєте постійно, точна оболонка, необхідна вашій програмі, магічно з'явиться.

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

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

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

Прототип - Змініть свою точку зору на завдання від виробництва до прототипу. Просто попросіть щось працювати і будувати звідти. Коли ви доберетеся до того, що зможете використати, тоді почніть мислити про це як про виробництво. Тепер ви не побачите завдання як те, що навіть не знаєте, з чого почати.

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

Це старий жарт про лікарів, які все ще «практикують» ліки; вони також не мають всіх відповідей.

Радійте тому, що ви не робите те, що робили сто разів раніше. Ви знайшли радість від розробки програмного забезпечення (для мене, як би там не було, YMMV) - навчитися керувати автомобілем, коли ви їдете по автостраді з надзвичайною швидкістю. Це та річ, якою живе великий розробник і має перевагу.

Мій особистий процес є приблизно таким:

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

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