Відвантажити або померти (з якістю чи без?)
Однією з ідей, які мене інтригують, є менталітет «відправляй або помри». Щодо того, як це називається, існують його варіації, але ідея цієї фрази проста:
Якщо у вас є ідея, якомога швидше переведіть її від концепції до продукту.
Звичайно, ідею переходу від концепції до продукту також можна назвати «концепцією до готівки», але ніколи немає гарантії, що ви збираєтеся отримати гроші, чи не так? Але є гарантія, що ви можете перетворити це в матеріальний продукт.
І в колах розробників програмного забезпечення завжди є багато аргументів за або проти цієї ідеї. У мене на голові одразу спадають на думку два плюси та мінуси:
- Pro. Швидке виконання роботи, яка [потенційно] приносить дохід.
- Con. Слабка архітектура, обслуговування, масштабованість, тестування тощо.
Коротше кажучи, може бути компроміс між тим, як швидко ви можете відправити щось на ринок, і архітектурою, що стоїть за проектом. Іноді є, іноді – ні. Загалом, однак, я думаю, що можна безпечно припустити перше.
Крім того, хтось може вважати перше легким виходом, хтось може розглядати останнє як вправу в YAGNI або, навіть простіше кажучи, що проблему можна вирішити, коли вона виникає.
Але яке відношення це має до чогось на даний момент?
Відправити або померти?
Вся причина, чому я витрачаю час на те, щоб писати про це, полягає в тому, що я, і я підозрюю, що інші в нашій сфері, думають про це принаймні трохи. Все це добре і добре, якщо говорити про це в абстрактному сенсі, але дозвольте мені спробувати прив’язати це до чогось більш реалістичного.
Одного разу…
Кілька років тому розробка інтерфейсу полягала в упаковці вмісту у вбудовані або блочні елементи рівня та стилізації їх за допомогою базового CSS?
У нас були розширені інструменти для роботи з нашим серверним кодом, але інтерфейс був відносно простим, окрім, можливо, стандартів кодування, яких дотримувалася компанія чи команда, з якою ми працювали.
Але з іншого боку…
Наші пристрої просунулися (що, до речі, я вважаю добре і навіть природно в техніці). Разом із зазначеним удосконаленням ми тепер маємо інструменти створення спеціально для інтерфейсної розробки, які є такими ж просунутими в деяких аспектах, як ті, які ми використовуємо для серверного програмного забезпечення.
Звичайно, у нас є «розробники повного стеку», але я радий визнати, що мені набагато комфортніше працювати на стороні сервера, ніж на інтерфейсі. Якщо я працюю на передній частині, я, як правило, дотримуюся інструментів, з якими я знайомий, і намагаюся залишатися в межах огорожі, визначеної смугою, на якій я працюю.
Це допомагає підтримувати зосередженість розробки, швидкість і послідовність проектів.
Гаразд, у чому сенс?
Сам по собі цей розділ може бути довгим дописом, але я не хочу заходити так далеко. Замість цього я візьму один фрагмент того, як працює зовнішня розробка прямо зараз, і подивлюся, чи не зможу я використати це, щоб зрозуміти свою думку.
Отримання Sassy
Візьмемо, наприклад, те, на що перетворився CSS. У нас є мови поверх мов (наприклад, Sass, який стоїть поверх або доповнює базовий CSS).
І у нас є процесори, які компілюють, мінімізують, лінзують і не дозволяють нам бачити нашу роботу до того, як певні помилки та попередження будуть виправлені заради якості. (Я не вважаю це поганою річчю, але це свідчить про зростаючий рівень складності – або, можливо, зрілості – нашого зовнішнього інструментарію).
Фронтальна розробка надто проста, давайте зробимо її складнішою, щоб ми могли почуватися розумнішими серед тих наших колег, які, очевидно, мають справу з більш «критичними» аспектами бізнесу. Пам’ятайте, що це змагання.
Ця стаття має гумористичний погляд на все це.
Розумний рівень якості
Щоб було зрозуміло, я не кажу, що це погано, але я кажу, що речі, які колись були віднесені до сторони сервера або компільованих мов, тепер поширюються на весь стек розробки веб-додатку.
Щоб бути максимально чітким: я за якість. Пересилання речей без будь-якої міри може розглядатися як вправа безвідповідальності.
Але я також вважаю, що потрібно знайти баланс між написанням найбільш оптимального, функціонального та продуктивного коду, можливого за обмеженнями часу та бюджету.
Я не вірю, як би ми не намагалися це собі нав’язати, що ми живемо в утопії розробників, де ми можемо оптимізувати, проектувати та впроваджувати незаймані системи в кожному окремому проекті.
Але здається, що ми доклали всіх зусиль, щоб його створити, чи не так?
Але в якийсь момент хіба не варто запитати, чи всі інструменти, які ми створюємо, і всі речі, які ми додаємо до наших проектів, усувають те саме, що привело нас у галузь у першу чергу? Звичайно, для деяких із нас це, ймовірно, інакше. Чи справедливо стверджувати, що наявність ідеї, написання коду для її втілення в життя та спостереження за вирішенням проблеми – це те, що привело нас у коло?
Однак на даний момент ми представили стільки інструментів, що створення та запуск середовища розробки для веб-програми, що працює від бази даних до браузера, є страшним завданням.
Так багато речей має відбутися, перш ніж ми будемо готові почати писати код, що це може стати втомливим і навіть трохи виснажливим, якщо зробити це лише на перших кроках.
Особиста остаточна думка
Я прагну до застосування сильних об’єктно-орієнтованих практик і інструментів у багатьох проектах, над якими я працюю зі своєю командою та які постачаю іншим, тому що з досвіду знаю, що час, долари та дані можуть бути втрачені через щось t зверталися з усіх боків.
Це не означає, що швидке відправлення щось заперечує це. Але процес і організація коду, що стоїть за проектом, — це те, що мені дуже важко ігнорувати настільки, що я відчуваю себе паралізуючим відправляти щось, що не було протестовано та перевірено в найвищому ступені (і навіть тоді, є проблеми).
З іншого боку, є частина мене, яка хоче поекспериментувати з однією чи двома ідеями, що лежать в основі менталітету «відправити це або померти», просто подивіться, як швидко щось можна створити, відправити та отримати будь-який дохід незалежно від того, наскільки незайманим він був база коду є.
І, можливо, я спробую це з деякими майбутніми проектами.