Як пройти шлях від добра до великого

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

«Група людей, що замислюється над ноутбуком та аркушами паперу» Штефана Штефанчика на Unsplash

Створення чудового продукту часто не є самостійним починанням. Найбільш продумані установки включатимуть багато команд творчості, маркетингу, продуктів та технологій. Навіть якщо ви одна компанія, вам потрібно буде взаємодіяти зі своїми користувачами, щоб зібрати їх відгуки про те, що для них працює. Ця ітеративна структура процесу циклічного проектування для покращення якості та функціонування зазвичай називається Agile Iteration Workflow.

Чим швидше ви зможете повторити, тим кращим став ваш продукт.

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

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

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

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

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

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

Рівні тестування програмного забезпечення

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

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

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

Це чудовий погляд на те, як ми плануємо зробити ефективніші процеси нашої команди більш ефективними. Ми детальніше розберемося про впровадження в наступних публікаціях про розробку на StashAway. Будьте в курсі!

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