Full-stack team lead в Universe
  • Оверінжиніринг — невидимий ворог компанії. Або що занадто, то недобре

    Вже є — framer.com (figma але для веб-сайтів)

  • Оверінжиніринг — невидимий ворог компанії. Або що занадто, то недобре

    Дуже філософське питання 🤔

    Моя улюблена книга «Джерело». Авторка Айн Ренд сповідує філософію здорового егоїзму. Тобто роби, що хочешь до тих пір доки це не приносить шкоди іншим. І ось в книзі є головний герой Говард Рорк, який символізує цю ідею. Він архітектор і робити будинки — це сенс його життя. Так ось він робить будинки не для того, щоб вони були найкрутіщі і не для того, щоб заробити грошей. А для того, щоб будинки вирішували проблему мешканців. Ідеально їм підходили, доповнювали їх. Мені здається, що це і є ідеальний баланс улюбленної справи/грошей. Гроші можно заробляти роблячі гарні речі, не завжди треба робити жертву одному чи іншому.

    Ще є така фраза «у самурая немає цілі, є тільки шлях», але як я це бачу, кожен для себе вибирає, в чому вимірюється «шлях». Особисто мені приносить задоволення не писати код, а бачити як він збирається до купи. Коли окремі модулі починають коммунікувати між собою і программа отримує видимі контури. Шлях для мене, в такому підході, вимірюється не тим, що ти зараз робиш, а більшими часовимі відрізками (проектами).

    Підтримали: Yevheniia Moskalchuk, Beaver Green
  • Оверінжиніринг — невидимий ворог компанії. Або що занадто, то недобре

    Так-так, вже усвідомив, що стаття націлена лише на веб додатки. Інші світи (направлення) залишилися за межами мого досвіду 😅

    Підтримав: Denys Poltorak
  • Оверінжиніринг — невидимий ворог компанії. Або що занадто, то недобре

    Перечитав багато статтей Джоеля, але цю не бачив. Дуже крута, дякую!

    Дійсно, різні цілі для кожного направлення. Моя стаття відносится тільки до веб додатків. Наступного разу буду уточнювати.

    Підтримав: Denys Poltorak
  • Оверінжиніринг — невидимий ворог компанії. Або що занадто, то недобре

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

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

    Підтримали: Denys Poltorak, Kateryna Prohnimak
  • Кешування наперед, або Сповідь адепта WorkBox

    en.wikipedia.org
    basecamp.com
    www.sketch.com

    Мне кажется, что статическая страница + cdn + cache-control в хедере отлично решает проблему ещё со времен http/1.1.

    Хороший абзац, про ddos своего апи. Зачем же тогда пушить в пользователей свои данные и создавать дополнительную нагрузку и гонять данные туда-сюда? Отдавать контент по-запросу выглядит более разумно.

    Да и если очень хочется кэшировать данные, почему не сделать один запрос на весь json со всеми данными соседних страниц? 1 запрос на html, второй запрос уже из JS для получения данных. Зачем рекурсивно ходить за каждой страничкой на сервер?)

    Підтримав: Vlad N
  • Создаем модульную архитектуру для большого React-приложения

    Я думал, что тема уже ушла :)
    А что интересует увидеть в репозитории дополнительно? Так будет проще дополнить.

  • Создаем модульную архитектуру для большого React-приложения

    3. Один тест в мене таки впав )))

    Писав уночі ¯\_(ツ)_/¯
    Репозиторій ще буду доробляти, хочу зробити гарний приклад.

    Кинулося в око використання MobX.subscription в useEffect

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

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

    Дякую велике за відгук і за те, що прочитали статтю 🙌
    Обговорення важлива частина розвитку. А критика допомагає виявити проблеми.

    ---

    Як додатковий висновок за останні 2 місяці, коли стаття готувалася до поблікації, такі собі плюси і мінуси даного підходу з точки зору команди.

    Плюси:
    1. Ми можем вчотирьох працювати над проектом і додавати функції незалежно один від одного. В нас ще не було конфліктів у коді;
    2. Джуніорам можна давати працювати над версткою, і щоб над логікою працював мідл/сеньор. Це трапляється із-за того, що в нас розділена візуальна і логічна частина додатку;
    3. Весь додаток покритий юніт-тестами, що спрощує тестування перед релізом;
    4. Коли треба зробити А/Б тест з новою логікою/флоу, то ми просто додаємо новий модуль, не змінючи вже існуючі. А потім заміняємо модуль на потрібний для кожного окремого тесту.

    Мінуси:
    1. Онбордінг нової людини (джуніора) займає 2 місяці. Сеньор почав працювати вже через тиждень;
    2. Архітектура не схожа на популярні рішення для реакту, тому виникає новий барьер для нових людей, кто не готовий вчитися. Але це як додатковий етап при наймі 😅

  • Создаем модульную архитектуру для большого React-приложения

    Додав посилання на репозиторій, дублюю тут: github.com/...​ych/modular-react-example

  • Создаем модульную архитектуру для большого React-приложения

    Ну вот как раз текущий сетап и сделан на nextjs :)

    Підтримав: gitmitos
  • Создаем модульную архитектуру для большого React-приложения

    Смотрели, но он вышел уже после того, как мы начали делать на nextjs. Поэтому на нём и остановились.

    Підтримав: gitmitos
  • Создаем модульную архитектуру для большого React-приложения

    Дякую за відгук і запит. Я думаю зможу підготувати гарний приклад і викласти його до кінця цього тижня 🙌

    Місцями дійсно це оверкіл, зокрема для маленьких проектів. Це дуже схоже з графіком часу/складності проекту у DDD (domain-driven design): khalilstemmler.com/...​img/wiki/anemic/chart.svg (зелене — проект на модульній архітектурі, червоне — проект на контекстах)