Кава-брейк #13: Що повинен знати кожен новачок у програмуванні; 4 способи включити дизайнерське мислення у процес розробки

Про що має знати кожен новачок у програмуванні

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

1. Код має бути послідовним, інформативним, добре документованим.
2. Код має використовувати стабільні сучасні функції.
3. Код не повинен бути надмірно складним чи непрацездатним.

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

Читати чужий код складно

Справді, співвідношення часу, витраченого читання і написання коду, становить понад десять до 1. Але читання чужого коду не обійтися. Вам доведеться читати чужий код. І чим раніше ви покращите свої навички, тим краще. Спробуйте вивчати чужий код за відкритими репозиторіями GitHub. Можна практикуватися в будь-який час: просто знайдіть відповідний вам проект і вникайте в кожен рядок. Ще один спосіб, який допоможе покращити читання чужого коду, полягає в тому, щоб ви почали копіювати стиль. Коли ви пишете код у чужому стилі, це не тільки покращує навички читання, але й робите код звичнішим для вас. Спробуйте.

Ви ніколи не писатимете «ідеальний» код

Я чотири роки був розробником-одинаком, перш ніж почав працювати у команді. Більшість цього часу я вважав, що будь-який досвідчений програміст пише ідеальний код. На мою думку, навчитися писати ідеальний код — це лише питання часу та зусиль. Але коли я приєднався до команди, зрозуміли, що ніхто не пише «ідеальний» код. Щоправда, код, який зрештою включався до системи, майже завжди був «ідеальним». Чому так виходило? Вся справа в аналізі коду. Я працюю з командою справді блискучих інженерів. Це одні з компетентних, впевнених у собі програмістів, яких можна найняти за гроші. Але у кожного з них (включаючи мене) почалася б справжня панічна атака, якби хтось колись запропонував включити додаток неперевірений код. Навіть якщо ви думаєте, що ви наступний Білл Гейтс, ви робитимете помилки. Я навіть не говорю про логічні помилки, я говорю про помилки, пропущені символи. Речі, які ваш мозок іноді просто не вловлює. Речі, які можна побачити лише свіжим поглядом. Прагніть працювати з тими, хто уважний до деталей та готовий критикувати вашу роботу. Спочатку буде важко сприймати критику, але це єдиний надійний спосіб покращити якість коду. Робіть все можливе, щоб не захищатися під час перевірки коду і ніколи не сприймайте критику особисто. Ви це не ваш код.

Ви не повинні писати код 8 годин на день

Ніхто вам точно не скаже, скільки часу на день він витрачає на написання коду. Але насправді мало хто пише код понад 4 години на день. Люди, які не згодні з цим, є або винятком із правил, або працюють у компаніях, які погано ставляться до свого персоналу. Програмування - напружена, психічно виснажує робота. Цілком неправильно думати, що хтось писатиме код по 8 годин на день, 5 днів на тиждень. Будуть рідкісні випадки, коли вам потрібно вкластися в дедлайн, але коли я говорю «рідко», я маю на увазі майже ніколи. Не допускайте, щоб робота обтяжувала вас і змушувала працювати понаднормово. Я не пропоную вам працювати лише чотири години на день. Інші чотири години зазвичай найкраще витрачати на такі речі, як:

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

Я також рекомендую робити регулярні перерви протягом дня і робити фізичні вправи (хоча б трохи). Позитивний вплив вправ давно доведено.

4 способи включити дизайнерське мислення у процес розробки

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

1. Включайтесь у процес із самого початку

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

2. Вивчіть процес UX

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

• дослідження мети проекту;
• створення каркаса – простого дизайну, що дозволяє визначити основні характеристики продукту;
• внесення в дизайн проекту більш тонких деталей, таких як інтерфейс користувача;
• випробування дизайну користувачами. Мабуть це найважливіший етап UX-розробки. Це дає цінну інформацію про продукт, перш ніж ви витратите час на розробку;
• ітерація: використовуючи аналіз результатів тестування, ітеруйте проект, щоб покращити взаємодію з користувачем.

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

3. Слідкуйте за розробкою дизайну

Дуже погано, коли дизайнери створюють проект, не радячись із розробниками. Це контрпродуктивно. Для DevOps важливо встановити правила, щоб розробники мали доступ до ескізів проекту в легкодоступних форматах, таких як PNG або PDF. Ефективна співпраця між розробниками та дизайнерами має вирішальне значення для успішної реалізації програми. Будь-якою ціною уникайте сліпої передачі готового дизайну. Помилки краще виправити на початковому етапі, а не наприкінці.

4. Погодьте, на якому етапі вам покажуть проект

Коли розробників просять створити мінімально життєздатну версію продукту (MVP), вони від початку мають знати вимоги до остаточної версії. Це необхідно, щоб уникнути проблем з невиправданими очікуваннями. Дизайнери повинні показати розробнику обидві версії дизайну: як MVP, так остаточного варіанта. Це допоможе реалізувати MVP з урахуванням того, що замовник очікує побачити у фінальній версії. Працюючи разом, дизайнери та розробники отримують безліч переваг. Кожен з них має знання, які можна застосувати до досвіду іншого. Розробники можуть надати цінну інформацію про те, які функції неможливо реалізувати у дизайні. З іншого боку, співпраця з програмістом позбавить дизайнера необхідності переробки проекту, що, відповідно, заощадить час всій команді.