— Привіт, Аміго!
— Привіт, Білаабо!
— Сьогодні я розповім тобі про те, як зазвичай розробляються програми.
У 20 столітті, коли сучасне ІТ тільки зароджувалося, всім здавалося, що програмування чимось схоже на будівництво чи виробництво.
Зазвичай справа була приблизно така:
Замовник розповідав, яка програма йому потрібна, що і як вона повинна робити.
Бізнес-аналітики b> вислуховували його і, на основі його історій, складали повний список вимог до програми.
Потім менеджери проекту розбивали ці вимоги на завдання (таски), а також визначали, який програміст робитиме якусь тяганину і в якому порядку.
Потім програмісти приступали до роботи. Іноді це могло зайняти кілька років(!).
Коли роботу було зроблено, програму віддавали тестувальникам.
Тестувальники проходили по кожному пункту вимог до програми та перевіряли , що він реалізований і програма працює як треба.
Якщо щось було не так, тестувальники писали баги та відправляли їх програмістам.
Тому програмісти фіксували (виправляли) ці баги і знову відправляли виправлену програму тестувальникам. І так по колу.
Коли основні баги були виправлені, програма віддавалася замовнику.
— Що так прям все і відбувалося?
— Ну, тут, звичайно, багато спрощено, але справа майже так і була.
І що проект реально міг писатися півтора-два роки?
— Іноді коли розробка проекту була дуже тривалою, її розбивали на окремі релізи. Кожні 3-6 місяців розробники зобов'язані були зробити певну частину функціоналу програми, протестувати її, виправити всі баги та показати замовнику.
Щоб він міг внести свої зауваження і, що важливіше, продовжував платити гроші за розробку програми.
— Продовжував платити?
— Тоді розробка часто розтягувалася в 2-3 разу. А т.к. оплата праці програмістів часто була погодинною, то й вартість програми зростала в 2-3 рази. А ось користь від неї при цьому падала. Адже те, що потрібно сьогодні і за $100,000, зовсім не обов'язково буде потрібно через 3 роки, та ще за втричі більшу ціну.
8212; Тобто. замовники часто відмовлялися платити?
— Ага. Потім вони вигадали додавати до договорів штрафні санкції, але це ситуацію не покращило. Розробка програм затягувалася і затягувалася, і ніхто не міг з цим нічого вдіяти, навіть якщо хотів.
— А чому так?
— Ну, по-перше, на етапі планування дуже багато не відомо. Найчастіше проблеми, з якими стикалися програмісти, на самому початку не міг передбачити ніхто. Але досвідчені програмісти мали б самі все передбачити, хіба ні?
— Чи бачиш, програмування – це унікальна професія.
Звичайний фахівець дуже часто виконує ту саму роботу. Годинник робить годинник, кухар – готує, вчитель – вчить, лікар – лікує, тощо. Фактично кожен із них щодня займається тим самим, що й учора. І тому починає робити свою роботу все краще та краще.
У програмуванні інший підхід. Як тільки у програміста щодня виникає те саме завдання, він пише для неї функцію/модуль/програму і більше до неї не повертається.
Кожне своє завдання програміст зазвичай вирішує один раз у житті.
>Чимось схоже на вченого або інженера-конструктора, який щось винаходить.
— Ага. А яка роль у проекті найважливіша?
— Ну що тобі сказати. Легко сказати, яка найважливіша, складно сказати – яка найважливіша.
Основне завдання тестувальників (Quality Assurance,QA) – стежити за станом роботи програми та вчасно рапортувати про знайдені помилки. Чим більше і раніше тестувальник знайде помилок, тим більше їх буде виправлено. Хороший тестувальник впливає на якість продукту більше, ніж хороший програміст.
— А чому програміст не може сам тестувати свою програму? Адже він краще знає, що в ній працює, а що ні?
— Хороший програміст просто не може бути добрим тестувальником. Програміст добре знає, як влаштовано програму, тому користується їй завжди специфічним чином. На відміну від користувача, який користується програмою, як бог на душу покладе.
Крім того, тестувальник не тестує те, що ще не працює. Тестувальник тестує ту функціональність, ті частини програми, які на думку програміста вже працює і працюють чи не ідеально.
І ось коли тестувальник знаходить там гори помилок, а програміст їх виправляє, продукт справді стає ближчим до ідеалу.
Основне завдання програміста (Software Developer Engineer, Developer, SDE) – реалізовувати нову функціональність. Або, якщо бути простіше, виконувати призначені на нього завдання. Призначили завдання із новими фічами – робить їх. Призначили баги – фіксує баги.
— Щось у тебе одні англіцизми у розмові. Кожне друге слово.
— Це не так англіцизми, як професійний сленг. Звикай.
Але іноді бувають завдання і складніші, наприклад, придумати архітектуру програми чи її частини. Чим краще буде запропонована архітектура, тим легше виконуватиме подальшу роботу.
Проблема в тому, що архітектуру треба вибрати на самому початку, а вдалу ти вибрав архітектуру чи ні, стає зрозуміло не раніше середини розробки.
>Більш того, якщо архітектура була вдалою і програма вийшла чудовою, то, швидше за все, на її базі замовник захоче випустити нову версію програми.
Це я до чого.
Яку б версію архітектури програми ти не вибрав, завжди знайдеться купа змін, доповнень, нових фіч, які цією архітектурою не враховуються.
Ось тобі хороший приклад.
Замовив клієнт збудувати будинок на 5 поверхів, ти придумав архітектуру, і будинок збудували.
Затем замовник каже, а давайте добудуємо ще один поверх, а потім ще один і т.д. А стіни перших поверхів на таке навантаження не розраховані, фундамент теж, от і доводиться все переробляти. А якщо замовник після будинку в 5 поверхів захоче будинок відразу о 50-й?
— Тоді легше знести те, що було і збудувати все наново…
— Але щодо архітектури, у мене для тебе є одна порада.
Архітектура програми в першу чергу повинна бути гнучкою і мати на увазі, що при вирішенні переробити половину програми не доведеться повністю переробляти другу половину. Таку архітектуру зазвичай називають гнучкою і модульною. Основне завдання менеджера - це приймати рішення. Менеджер – це людина, яка бачить всю картину і приймає рішення, виходячи з цього.
Припустимо, у процесі розробки з'ясувалося, що деяке завдання не вийде в такому вигляді, в якому її хочуть бачити. І тут менеджер може:
а) спробувати домовитися із замовником, щоб це завдання змінили;
б) виділити більше часу на це завдання;
в) залучити більш досвідчених програмістів з інших проектів.
Тут ще багато варіантів.
Справа в тому , що в кожному з них доведеться чимось жертвувати, а завдання менеджера - звести сумарні збитки від таких жертв до мінімуму.
Або, наприклад, провідного програміста перекуповують конкуренти, запропонувавши вдвічі більше грошей.
Менеджер може:
а) нічого не робити. Програміст йде, проект, ймовірно, затягнеться і потрапить на штрафні санкції.
б) підняти йому зарплатню вдвічі. Тоді решта людей у команді теж захочуть собі підвищення ЗП. Якщо всім їм дати грошей, витрати на проект зростуть, і він може стати збитковим.
в) свій варіант.
— Ясно.
— Зазвичай, коли поганий менеджер, проект може витягнути хороша команда, але не завжди.
Хороший менеджер і команда середніх програмістів майже завжди зроблять проект швидше, ніж поганий менеджер та команда відмінних програмістів.
— Ясно.
— Ось як виглядають ці професії одними очима:
— Ха-ха, смішно.
— Гаразд, давай зробимо невелику перерву, а потім продовжимо.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ