Асинхронне світосприйняття

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

Визначення середовища та цілей

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

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

Приклади з практики:

• Мені потрібно поступово виходити на інші ринки. Однією з підцілей, яку я виявив під час реалізації, може бути машинний переклад Інтернету.
• Мені потрібно забрати 6 відправлень в різних місцях навколо Праги і я не знаю найкоротшого маршруту. Я не хочу з'ясовувати це складним шляхом, тому просто прямую до найвіддаленішої точки і по дорозі змінюю свій план на інші маршрути. Наприклад, коли я пересідаю на Anděl, я вирішую сісти на трамвай, який прибуває першим, що динамічно впливає на наступний план маршруту.
• Мені потрібно написати цей пост, але я не маю години часу поспіль. Тому я можу писати її частинами, їдучи в метро, окремими розділами. Потім я зроблю остаточне злиття в цю форму в майбутньому.
• Я не знаю, як працює алгоритм розрахунку викупу товару для мого клієнта, який мені потрібно перепрограмувати. Тому я буду ставити питання кільком людям одночасно і вирішувати щось інше, поки буду це робити. Асинхронно протягом 2 днів надійде декілька різних відповідей, на основі яких я лише згодом прийму рішення.
• Мені потрібно надовго позбутися PHP на сервері, тому поступово переписую по одній сторінці на React. Поступово переношу сайти в хмару і будую їх на статично згенерованому Nect.

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

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

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

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

Я з цим дуже багато борюся скрізь.

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

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

У мене досі є одне виробниче середовище, яке завжди працює. З нього під кожне завдання створюється нова гілка для вирішення конкретної функції. Оскільки я використовую Vercel (дуже хороший хмарний провайдер) для розміщення інтерфейсу, я можу мати власну URL-адресу для кожної гілки розробки.

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

Багато в чому це пов'язано з ідеєю, яку мені донесли в LMC - "Функція, яку ви надаєте клієнту завтра, навіть якщо вона в недосконалому стані, має для нього набагато більшу цінність, ніж функція, яка ідеально відлагоджена, але буде доступна лише через рік". Але це може спрацювати лише в тому випадку, якщо у вас є спосіб швидкого розповсюдження новин - як правило, це веб-розробка.

Що мені дуже подобається у фреймворку Next.js (побудованому на Recto) та Vercel - це принцип, за яким ви підключаєте свій репозиторій GitHub безпосередньо до Vercel, і з кожним коммітом відбувається автоматична збірка, тести, а потім розгортання у виробництво, коли все в порядку. Таким чином, розробнику не потрібно ні про що турбуватися, і додаток розгортається щогодини з нульовими зусиллями. Дуже важливо формалізувати рутинні речі, а потім їх автоматизувати.

Публікація контенту

Я розбив вище десятки тем і постів зі мною в Apple Notes. По кожній темі я постійно придумую нові ідеї, які записую і сортую за тегами. Коли на тему створюється кілька заміток, я перетворюю їх на розділи, а потім перетворюю групу розділів на статті та пости у ФБ.

Особливості цього принципу:

• Я не знаю наперед, скільки статей я коли-небудь опублікую,
• Але знову ж таки, я знаю, що їх може бути багато,
• Я можу гарантувати, що кожна публікація наповнена інформацією, думками та ідеями, які визрівали протягом тривалого часу (ця публікація визрівала приблизно 3 місяці),
• Це стабільно, і мені це сподобається, тому що мені не доведеться писати тонни тексту в один момент і ризикувати, що я щось забуду.

А потім видавничий процес.

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

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

Знання, освіта, тестування

Мені подобається гратися з технологіями, де з самого початку не зрозуміло, чим це буде корисно колись.

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

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

Чи працює такий підхід для реалізації нестандартних проектів?

Здебільшого ні.

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

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

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

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