Хто такий Software Engineer? Програмна інженерія VS "просто" програмування

Пропонуємо до вашої уваги адаптацію статті Саміра Буна (Samer Buna) про відмінності між програмною інженерією та програмуванням, або чим розробка концепції програмного забезпечення відрізняється від «просто кодингу». Всі програмні інженери можуть кодувати, але не всі програмісти можуть розробляти концепції програмного забезпечення. Деякі люди не люблять визначення «Програмний інженер» (він же інженер-програміст, він же Software Engineer) через те, що найчастіше слово «інженер» ми використовуємо, говорячи про щось фізичніше — будівництво, наприклад. Наша стаття, зрозуміло, не про термін. Якщо він раптом викликає у вас відторгнення, його легко можна замінити щось пов'язане з креативністю. «Творець ПЗ», «автор ПЗ» … та хоч «Творець ПЗ»! Вміння програмувати автоматично не робить із людини програмного інженера. Навчитися кодити може будь-хто, і це набагато простіше, ніж здається. Кожен може створити просту програму для власного використання, але це не дає гарантій, що ця програма підійде іншим. Мій улюблений приклад такий: багато хто з нас співає в душі, але, на жаль, далеко не завжди це виконання гідно професійної сцени. Зрозуміло, за високими музичними враженнями ви, швидше за все, звернетеся до профі. Вам потрібні приклади?

• Всі ми вчимо математику та лист у школі, але це не робить нас математиками та письменниками.
• Більшість із нас здатні приготувати стерпну, а часом і дуже смачну страву, але не кожен ризикне приготувати стіл на 100 персон для званої вечері в посольстві. У цьому випадку ми наймаємо кухаря.
• Чи готові ви прямо зараз повністю довірити будівництво нового будинку сусідській дитині, яка створює вражаючі шедеври з Lego?

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

Інженерний склад розуму - пошук прикладних рішень

Програмні інженери не вважають своєю головною метою написання програм як такої. Вони думають у масштабах забезпечення потреб та вирішення проблем . Це важливо, оскільки не кожна проблема вимагає створення програмного рішення. З деякими з них можна розібратися за допомогою вже існуючих програм. Виникнення деяких проблем іноді можна передбачити заздалегідь, а за допомогою грамотного проектування програм – уникнути у майбутньому. Складні проблеми часто вимагають написання багатьох програм. Існують завдання, яким потрібні паралельно працюючі програми, інші потребують послідовного виконання кількох програм. Ряд проблем можна вирішити, просто навчивши користувачів. Перед тим, як розпочати створення програми, інженер ПЗ задає собі низку питань:

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

Якість програми та якість коду

Хороші програми зрозумілі та читальні. Їх легко розширювати, вони відмінно працюють з іншими програмами, і робота з ними не стане вашим нічним кошмаром. Якість коду не є предметом переговорів. Воно має бути високим, і все тут. При його розгляді неприпустимі відмовки на кшталт поганого настрою кодера або надто стислих термінів виконання (ох вже ці дедлайни!). Один із найважливіших моментів розробки ПЗ — проектування програми таким чином, щоб надалі її було легко підтримувати та модифікувати (привіт, ОВП!). Сьогодні практично все програмне забезпечення модифікується, часто цей процес відбувається навіть без участі користувача або не вимагає від нього нічого, крім «прийшло оновлення вашої програми, натисніть ОК або Відкласти». Зрозуміло, Сам собою шматок коду навряд чи можна назвати корисним. Корисні функції ПЗ починаються там, де розрізнені шматки додатків взаємодіють між собою, обмінюються даними та працюють спільно, виконуючи завдання представлення даних та інтерфейсів користувачам. Програми потрібно проектувати з урахуванням цих моментів! Які повідомлення вони беруть? Які події моніторять? Як відбувається автентифікація та авторизація? Інша не менш важлива ознака хорошої програми — зрозумілість коду, а не кількість тестів, що пройшли додатком, або навіть не хороше покриття тестами. Здавалося б, прості питання: «Чи може хтось, окрім мене, розібратися з моїм кодом?», «Чи я зможу, написавши сьогодні цей код, зрозуміти його за кілька тижнів?». Популярна цитата про дві найскладніші речі в програмуванні говорить: Читання коду набагато важливіше, ніж прийнято вважати. На жаль, неможливо визначити точні показники або параметри ясності коду. Почасти допоможуть запам'ятовування загальноприйнятих мовних норм, хороших моделей та методів розробки. Але зазвичай цього замало. У справжніх професіоналів з часом і досвідом розвивається, якщо можна так сказати, «почуття ясності», щось схоже на інтуїцію. Тут добре підійде метафора з листом: знання великої кількості слів, що не допоможе вам написати короткий і ясний за змістом. Можливість легко та швидко виправляти баги – ключова ознака гарного програмного забезпечення. Помилки в програмі повинні надсилати чіткі повідомлення та централізовано реєструватися для відстеження. Коли надходить повідомлення про нову помилку, той, хто її усуватиме, повинен мати можливість для налагодження. Йому потрібно легко підключатися до системи, отримувати доступ до інформації про виконання у будь-який час, а також мати можливість легкої перевірки працездатності будь-якої частини системи.

Оточення та тестування

Коли інженери-програмісти розробляють програми, вони роблять все від себе залежне, щоб ті працювали на комп'ютерах різної архітектури та з різними ОС. Важливо, щоб програмне забезпечення працювало при різних дозволах і орієнтаціях екрана, а ще щоб воно не «їло» більше пам'яті і процесорних потужностей, ніж потрібно. Якщо мова йде про веб-застосунки, то вони повинні працювати у всіх основних браузерах. Створюючи декстопну програму, потрібно переконатися, що вона запускається і коректно працює і на Mac, і на Windows, і на Linux. Ну а програма, залежить від даних, то програма має працювати навіть у разі повільного з'єднання з даними або його відсутності. Щоб написати частину програми, інженери продумують різні варіанти сценарію, а також планують їх тестування. Все починається з вибору ідеального варіанта, коли все працює без помилок. Потім вони документують всілякі можливі проблеми та заносять їх у план тестування. Деякі інженери починають з написання коду, який вони називають тестовим прикладом та в якому імітуються сценарії всіх можливих проблем та помилок. А потім уже пишеться програма, яка зможе працювати за будь-якого з розглянутих варіантів. Унікальною здатністю талановитого інженера ПЗ є не знання, як написати код, а розуміння того, що саме додаток має робити на виході і як цього досягти. Інженеру необхідно за неповних, а, можливо, і неоднозначних вимог замовника до ПЗ правильно їх оцінити і «зрозуміти».

Вартість та ефективність

Програмний інженер здебільшого може швидко вирішити проблему. Якщо ви думаєте, що при наймі на роботу «дорогого» досвідченого програміста ви збільшите витрати, подумайте вкотре. Чим досвідченішим виявиться найнятий програміст, тим швидше він зможе надати просте, акуратне, надійне та легке в експлуатації рішення. У довгостроковій перспективі це однозначно зменшить витрати на розробку програмного забезпечення. Також необхідно враховувати витрати на виконання програми. Будь-яка програма використовує обчислювальні ресурси, а вони не безкоштовні. Наприклад, кешування даних, що часто використовуються, — одна з можливих стратегій, що застосовуються для отримання бажаного результату. Але це — лише один із, напевно, сотень інструментів та рішень, які можуть зробити програму швидше та ефективнішою. Початківець програміст може надати вам дешеве рішення, але використання такого рішення, зрештою, буде коштувати вам і вашим клієнтам набагато дорожче, ніж у випадку, якщо б ви працювали з досвідченим розробником, який створив насамперед ефективне рішення.

Орієнтація на зручність користувача

Хороший програміст веде розробку з думкою про Досвід Користувача (User Experience (UX)). Взаємодія "людина-машина" - тема з нескінченною кількістю досліджень та рішень. Чим більше рішень застосовується, тим краще вийде програма. Ось кілька прикладів, просто для того, щоб ви відчули, що це за напрямок такий:

• Коли ведеться розробка форм для введення даних, таких як e-mail, хороша програма повинна ігнорувати регістр літер для адресаи електронної пошти. Вона не повинна видавати помилку, якщо натиснуто клавішу CAPSLOCK, оскільки адресаа електронної пошти унікальна в нижньому регістрі. Якщо програма приймає на введення нову електронну адресау, перевіряйте її на ранніх етапах введення, щоб попередити користувача про те, що він використовує неправильний формат адресаи. Таке рішення включає як очевидні перевірки на кшталт пропущений знак «@», а також не настільки очевидні, як, наприклад, перевірка на неправильний порядок символів на кшталт «gmail.ocm»

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

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




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

  Виявилося, що для того, щоб відредагувати інформацію про поїздку, мені потрібно було прокрутити близько двадцяти рядків форми, ввести номер картки лояльності та номер телефону, без якого форму не можна надіслати на перевірку. Це приклад програми, яка розроблялася без думки про те, наскільки користувачеві буде з нею зручно.

Надійність, захищеність та безпека

На мою думку, найважливіша відмінність професійного розробника програмного забезпечення від аматора — облік таких параметрів, як надійність, захищеність та безпека програми під час його створення. Частини програми повинні бути стійкими до некоректного введення, некоректних станів та неправильної взаємодії. Це дійсно дуже важко забезпечити і це основна причина, через яку ми чуємо історії про те, що люди гинуть через помилки в програмному забезпеченні. Користувачі вводабо, вводять і вводитимуть некоректні дані в програму. Це потрібно прийняти як факт. Причому деякі робитимуть це спеціально, з метою зламати додаток і дістатися ресурсів, доступних йому. Ось приклад із реального життя: особа, нібито відповідальна за недавній витік даних Equifax, звинувачується у невиконанні своїх службових обов'язків, які полягали у розробці рішень, стійких до поганого та зловмисного введення у всіх програмних продуктах, які надходять до загального доступу. Випадки, що стосуються інформаційної безпеки, пов'язані не тільки з неправильним і шкідливим введенням, але також і з даними, що правильно вводяться. Якщо користувач забув пароль, скільки разів він може спробувати його ввести? Чи заблокуєте ви його після цього? А що, якщо хтось інший намагається заблокувати його обліковий запис? Чи може користувач надсилати свої облікові дані через незашифрований канал передачі даних? Що, якщо запит на вхід надійшов із незвичайного місця? Що ви будете робити, якщо спроба входу нагадує автоматичну? Що ви зробабо для того, щоб захистити ваших користувачів від міжсайтового скриптингу та міжсайтової підробки запитів та банального фішингу? Чи є у вас резервна стратегія на випадок DDoS-атаки ваших серверів? Ці питання вказують лише деякі проблеми, які необхідно враховувати. Захищена програма не зберігає важливу інформацію у текстовому вигляді. Вона захищає її з допомогою складного одностороннього шифру (такого, з допомогою якого легко зашифрувати, але неможливо розшифрувати без ключа). Це резервні заходи на випадок, якщо програму таки зламають. Хакери виявлять зашифровані дані, які марні для них. Несподівані проблеми виникають навіть у найкращих програмах. Програміста, який готовий до їх виникненню, навряд можна назвати професіоналом. Поки він не чекає на несподівану поведінку, він не інженер. Він — автор небезпечних програм. Помилки у програмах не завжди очевидні. Наші інтелектуальні можливості передбачати та запобігати відомим помилкам обмежені. Ось чому програмні інженери розуміють важливість хороших інструментів, що дозволяють їм писати правильне та безпечне програмне забезпечення.

Необхідні інструменти

Немає сумнівів, нам потрібні різні та хороші інструменти розробки. Їх роль часто недооцінюють, але насправді вони неабияк економлять час і сабо, спрощуючи деякі завдання на порядок. Уявіть, якби вам досі доводилося заливати файли FTP для розгортання, так би мовити, по-старому. Уявіть налагодження проблем мережі та продуктивності без Chrome DevTools! А як неефективно в наші дні було б писати код на JavaScript без ESlit та Prettier! Будь-який інструмент, що скорочує час зворотного зв'язку, коли ви пишите код, має бути прийнято з радістю. Коли я знаходжу незнайомий мені раніше, але справді корисний та дієвий інструмент, я можу шкодувати лише про те, що я не використав до цього щасливого моменту.

Еволюція програмної інженерії

Ніхто не може вивчити програмну інженерію за два місяці, за півроку і навіть за рік. Вас не навчать бути програмним інженером на курсах, в університеті чи навчальному таборі. Я навчаюсь останніх двадцять із лишком років і продовжую вчитися зараз. Я зміг спокійно називати себе досвідченим програмістом лише після десятиліття навчання та розробки, створення та підтримки додатків, якими користуються тисячі користувачів. Програмна інженерія — не всім, але кожен має вчиться вирішувати свої завдання з допомогою комп'ютера. Якщо ви можете навчитися писати прості програми вам варто це зробити. Якщо ви можете навчитися використовувати загальнодоступне програмне забезпечення, це варто зробити. Якщо ви можете навчитися використовувати програми з відкритим вихідним кодом та доопрацьовувати їх для себе, ви отримаєте суперсилу! Щодня приносить розробникам нові завдання, нові проблеми, тому потрібна програмна інженерія. Головне завдання цієї професії — створювати ПЗ так, щоб звичайній людині не довелося розбиратися з нею багато років. Щоб для взаємодії з програмами не було потреби довгого навчання. І ще програмні інженери весь час думають над створенням більш досконалих інструментів, здатних вирішувати складніші відомі проблеми, і робити все можливе, щоб нові проблеми з'являлися якомога рідше.