6 «шкідливих» рад розробнику



/ фото Alexandre Dulaunoy CC

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

1. Eat, sleep, code, repeat!
Відомо, що цієї концепції дотримуються багато розробники – вона стала своєрідною мантрою, яку повторюють найбільш прихильні своїй справі трудяги. Проте в ній ховається небезпечний підтекст. Якщо задуматися, то ця фраза пропагує нездоровий спосіб життя, навіюючи думку, що програмування – це все. Нібито, щоб досягти успіху в цій області, необхідно цілком присвячувати себе розробці. Але на ділі все зовсім навпаки.

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

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



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

2. Митапы не потрібні
Серед розробників існує думка, що програми доставляються в термін лише в тому випадку, якщо програмісти пишуть код, а не просиджують на «розборах польотів». Але потрібно розуміти, щоб створити хороший продукт, приділяти час цих розмов необхідно, інакше компанія ризикує піти не в ту сторону.

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

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

Пітер Тіль (Peter Thiel), співзасновник компанії PayPal, як-то відзначив: «Як генеральний директор ви є центром організації, проте інший раз ви знаєте менше всіх в компанії». Тому навіть невеликі доповіді тривалістю 5-7 хвилин дозволять босові тримати руку на пульсі і не відчувати себе аутсайдером.

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

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

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

Ось тут він хотів відобразити якусь інформацію, бо створив це поле, зрозуміло, з наміром пізніше видалити його. Тут він вирішив, що непогано б додати ще пару параметрів – так з'явилися кілька нових кнопок і випадаючих списків. Так, а чому цей параметр ніде не виводиться? Непорядок. Додамо ще один повзунок. У результаті народжується щось подібне:



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

Тим, хто прагне навчитися розробляти хороші інтерфейси, варто почати з вивчення цієї теми Stack Overflow.

4. ...і тестувати всі самостійно
Розробник не може бути тестувальником (зрозуміло, виключення есть завжди). Це пов'язано з тим, що девелопер занадто добре знає всі тонкощі створеного ним програмного забезпечення, тому йому складно зробити якісь висновки про життєздатність коду – цей факт добре відомий тестувальникам.

Зрозуміло, розробники можуть приймати участь в процесі тестування, особливо у разі Agile, але необхідно пам'ятати про «сліпих плямах». Ось кілька з них:

1) Батьківська любов до написаного коду

Відомий факт: своє творіння складно оцінити об'єктивно. Розробники емоційно прив'язані до написаних ними операторів і функцій.



Наочний приклад – діти. Батьки вважають своїх дітей ідеальними (не помічають недоліків) і сердяться, якщо хтось лає їх чадо.

2) Позитивне мислення

Більшість зусиль розробника спрямовані на ефективну реалізацію функцій. У тестуванні необхідно шукати «неефективні» способи їх використання (що може піти не так?) – переключити свідомість за короткий період часу досить проблематично.

3) Спрощення складних сценаріїв

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

4) Слабкий «нюх»

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

Більшість розробників не мають чіткого уявлення про те, як користувачі будуть звертатися з ПО. Тестувальники ж розуміють, як саме користувачі добиваються поставлених цілей, і вміють «симулювати» їх роботу з додатком.

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

Розробник фокусує увагу на коді і архітектурі продукту. Замовник думає про бізнес-вимоги. Іноді ці дві людини не хочуть чути один одного.

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

6. «Стелс-режим» або «Alone In The Dark»
Код «пахне» – так кажуть, коли в лістингу з першого погляду видно потенційні проблеми і недоробки. Мартін Фаулер (Martin Fowler), автор ряду книг і статей по архітектурі, називає такий «запах» індикатором проблем, присутніх в системі. На сьогоднішній день написано сотні статей на тему визначення поганого коду (наприклад, ось, ось і ось). Найчастіше ця проблема пов'язана з надмірною складністю, заплутаністю, бездумним копіюванням і т. д.

Однак код, написаний однією людиною, також буде «видавати неприємний запах». Це не означає, що він поганий, просто, якщо показати його іншим експертам, зі 100% вірогідністю вони поліпшать його.



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

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

Можливо, це досить очевидна річ, але не кожен девелопер готовий віддати свою роботу на суд інших. Просити про фидбеке непросто – ніхто не любить чути, що він був неправий.



Ми в 1cloud вважаємо, що про розробках потрібно розповідати, ділитися досвідом зі знайомими та колегами. Хороший код і сервіси не народжуються з нізвідки, вони стають такими, закаляясь у вогні критики. Для цього відмінно підходить Хабр, а нам залишається тільки оперативно реагувати на будь-яку критику і давати максимум інформації про своє IaaS-провайдера.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.