×Закрыть

Как качать скилл архитектора?

Я Front-End Разоработчки с чуток опыта. Довольно хорошо знаю базу — JS, HTML, CSS — куда ж без этого. С лёгкостью могу выучить и на практике применить почти любой инструмент — Angular, React, Redux, TypeScrtipt, Observable, Lodash и много чего другого. Без проблем решаю алгоритмические задачи на том же codewars.

Ноо...! Чем дальше я работаю и чем сложнее мне тим лид ставит таски тем сильнее я понимаю что моё мышление какое-то ограниченное. Мне сложно выстроить архитектуру всего приложения на уровне самого приложения, хотя повторюсь — на уровне компонента, одной функции без проблем решаю поставленные задачи. Дайте совет как прокачать скилл архитектора...И нужно ли это вообще джуну...мидлу?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

джун или мидл не могуть архитекторами. просто по определению

Архитектура — это управление сложностью.
Изучите архитектуры 100 больших проектов и поймете как с этой сложностью борятся.

как же ты можешь написать хоть одну функцию правильно если не понимаешь как приложение будет устроено целиком?

Як жеж ви можете користуватися машиною, якщо не розумієте її побудови? ;)

«написать хоть одну функцию» не равно «користуватися машиною» вообще не та аналогия прямо показывающая что не та.

Чтобы машину таки чинить и тем более строить уже таки надо бы б «розумиты йийи побудовы» (к) (тм)

і скільки працівників, які збирають машину на автоконвейєрі чи ремонтують її на СТО, зможуть її спроектувати ? :)

да кто угодно. ведь есть же удобные фреймворки для проектирования. фабрики, куябрики:
auto car = CarFabric::build(color: red);

А если это чистая функция ?

Не знаю хто такий «скилл», але завжди сприймав «архітектурні» здібності як звичайні професійний досвід та знання. В чому відмінність у проектуванні системи і проектуванні функції? У тому що в першому випадку треба розуміти як працюють кафки, БД, диски та інші підсистеми? Так і при проектуванні функції що працює з ІО теж треба розуміти як працює нижчий рівень. Треба просто більше всього розуміти, знати і вміти. Мати свій смак і стиль. Все це приходить з досвідом. Звісно, якщо цікавитися, а не просто гребсти на ЄЖБ по дві години в день.
Коротше, це звичайний розвиток професійного рівню людини. Не думаю що якийсь там Шевченко чи Мессі задавався питанням про те, що такого особливого вивчити щоб стати капітаном.

Я Front-End Разоработчки с чуток опыта.
Дайте совет как прокачать скилл архитектора...И нужно ли это вообще джуну...мидлу?

Я думаю ты имел ввиду скил «проектирование грамотной архитектуры». Для этого есть разные книги, например можно начать с «Чистый код» от Роберта Мартина, затем взять черную серию книг от Фаулера для начала. Сюда же «Совершенный код» Мак Коннела. ИМХО любая даже самая красивая архитектура развалится, если внутри будет говнокод, поэтому я и добавил книги по чистоте кода.

Не путай «проектирование архитектуры» и «архитектора».

Решил написать свое мнение по скиллбилду. короче раскидываешь поинты примерно так
— однозначно вкладывать максимум в стелс(Удар в спину, Приглушенное движение, Клинок Ассассина, Смертельное прицеливание, Тишина)
— лайт армор(тут вообще без разницы, что брать)
— алхимия(Змеиная кровь, Яды, Концентрированные Яды, Физик)
— луки(все возможные перки)
— взлом(Охотник за сокровищами, Золотое касание)
это, как говорится, мастхэв. остальное по желанию.

Такі якраз у 35 по Дніпру йдуть. Танкувати треба вміти та хілятись! І скілл більше потрібен для такого насправді, кожен нуб у дпс йде.

Решил написать свое мнение по поводу архитектуры и архитектора, а то много кто не совсем понимает что я пытаюсь сказать там ниже в ответах на комментарии.
Архитектор — это не тот кто умеет разбить какое-то приложение на классы с использованием паттернов (это должен умень обычный дев), не тот кто может выбрать какой-то фремворк или библиотеку, а тот, кто может полностью понять требования ко всей системе, и построить архитектуру и выбрать решения, которые позволят все эти требования удовлетворить. Очень редко бывают системы, где нужен только юай (я даже не могу ни одного примера представить), по этому станно звучит «юай архитект».

Приведу пример архитектурной задачи (над которой я работал). Задача звучала так:
— у нас есть система, которая должна мочь отправлять данные внешним системам по типу salesforce. Данные должны отправлятся на каждое изменение в БД нашей основной системы. Систем несколько с разными api (rest, webservices, msmq, jms и тп) и форматом данных (json, xml, binary и тп), весь список неизвестен и может расширяться. Внешние системы тоже будут нам присылать данные с помощью разных механизмов и в разных форматах и с разной структурой. Структура данных для некоторых систем требует больших трансформаций, агрегаций и калькуляции полей на основании группы данных.

Дальше пошло выяснение требований и оказалось что:

Мы не можем гарантировать что на стороне внешних систем есть дедупликация данных, хотя точно знаем что некоторые системы это умеют, по этому мы хотим чтоб для каких-то систем мы могли включить гарантированную доставку 1 и только 1 раз, для других можем положиться на внешнюю дедупликацию и гарантировать доставку просто не меньше 1 раза.

Мы не хотим изменять код основной системы и мы не знаем какая будет нагрузка на систему сообщений, по этому она должна горизонтально масштабироваться (и без участия программистов).

Мы не хотим менять код для добавления новой системы, которая будет получать или отправлять сообщения. Мы не хотим менять код, если нам нужно изменить формат отправляемого сообщения или переименовать, например, поле. Мы не хотим менять код даже если нам нужно поменять калькулируемые или агрегированные поля. Хорошо бы это делать через UI

Система должна детектить race condition и решать проблемы вида «изменения проводятся одним и тем же пользователем одновременно в нашей системе и, например, в salesforce», система должна быть eventually consistent.

и тп

Для начала нужно было выяснить все требования, влияющие на архитектуру, рассмотреть все возможные решения с точки зрения удобства, скорости разработки и цены для компании (это был стартап) и подумать как все это дело тестировать. Были рассмотрены и внешние решения (например от mulesoft) и, в итоге, спроектирована внутренняя система, работающая на AWS.

Как видите, тут были и bd, и UI и сервер и интеграция и выяснение требований и тп и тд. Вот такого рода задачи можно назвать архитектурными задачами, а не разбиение на классы в UI (что должен уметь делать обычный дев)

Так ты и ТС говорите про разные вещи. Ты описываешь типичного Solution/System Architect, а парниша спрашивает про умение проектировать архитектору приложения (web application, mobile application, server etc.) — то бишь, одного компонента всей системы/решения. И с чего это ты решил, что не может быть отдельного архитектора на каждом компоненте системы? Пусть даже эту роль будет выполнять один из инженеров в команде или тимлид. Возможно, для маленькой системы, которую ты описал — это оверкил. Но на средних и огромных проектах — вовсе нет. Возьми условную MMORPG игру в стиле WoW, где клиент («юай» в твоей терминологии) и сервер может каждый легко содержать по миллиону строк кода. Без команды архитекторов, во главе с Solution Architect или CTO, которые коллективно проектируют систему, такой проект далеко не уедет.

Без команды архитекторов, во главе с Solution Architect или CTO, которые коллективно проектируют систему

в этом и дело. Они будут коллективно проектировать систему — то есть работать вместе над всеми аспектами. То есть будет команда. В проектах поменьше — просто один человек. Но тот, кто работает над архитектурой клиента, не будет рассписывать как разбить клиент на классы, а будет работать на более высоком уровне, в т.ч. ходя и на сторону сервера, чтоб вместе с серверными архитекторами работать над моделью данных, протоколами взаимодействия и тп и тд.
Ладно, все пошло в холивар по поводу терминологии уже. Основной мой посыл, что я хотел донести, что архитектор это больше, чем разбиение кода на классы. Чаще всего архитектор как раз этим и не занимается. А занимаются девы

Основной мой посыл, что я хотел донести, что архитектор это больше, чем разбиение кода на классы.

Классы — это особенности реализации. Hа них архитекты точно ничего не разбивают. :)

Но на подсистемы систему разбивают и интерфейсы между подсистемами (на самом верхнем уровне) — оговаривают в самом начале. Дальше, в каждой подсистеме работает свой архитект, который уже лепит интерфейсы для частей подсистемы. А остальное (включая, ОО-декомпозицию), это уже за командами.

будет работать на более высоком уровне, в т.ч. ходя и на сторону сервера, чтоб вместе с серверными архитекторами работать над моделью данных, протоколами взаимодействия и тп и тд.

Согласен, но опять таки, возникает ощущение, что у тебя все рассуждения происходят в контексте какого-то веб-приложения в виде тонкого клиента, построенного на 3 классах, в котором нечем заниматься «юай-архитектору», но с навороченным бекендом, где и вершит судьбы Java God Architect.
А что если речь идет о таких приложениях, как Photoshop, After Effects, iMovie, Adobe Audition etc. У них и бека как такового может не быть, кроме примитивного облочного хранилища для синхронизации файлов, типа iCloud. Зато будет пару миллионов строк кода на каждой платформе, включая десктопы, мобилки и браузер. И будут они иметь локальные базы данных, модульную архитектуру для отдельных фич (наверняка подключаемые по premium схеме), типа истории, навигатора, инструментов. Возможно даже построенные в виде микросервисов. Будут подключаемые плагины. Опять таки, юайка, только очень сильно конфигурабельная. Чтобы спроектировать такой корабыль, мало синьору скрутить пару классов по паттернами из банды четырех. Вот тебе и работка для фронтенд-архитектора, iOS-архитектора, android-архитектора и тд. Хотя наверняка у них всех будут примерно одинаковые подходы, совместно согласованные.

дык внимательно тему почитай. Тут как раз о вебе и всяких

JS, HTML, CSS

Конечно же в таких проектах как

Photoshop, After Effects, iMovie, Adobe Audition etc

есть архитекторы. Но назвать их веб UI архитектор как-то язык не повернется

Почему язык не поворачивается? Чем перечисленые приложения отличаются от веб фронтенда? Сегодняшний веб фронтенд включает в себя достаточный спектр технологий (включая такие языки как C/C++/Rust). Если не работал со сложным фронтендом то зачем комментировать если явно не в теме.

Ну если из твоей работы выкинуть сбор требований, что в нормальной жизни делает бизнес аналитик, то это сделает и дев. Если вернутся к твоему сбору требований, то опять таки это сделает и дев :)

то это сделает и дев.

дев-супер-фуллстек (к) (тм)

бекенд, фронтенд, фуллстек.... как люди только не пытаются избежать быть программистами

аркитект ))

чувак, в такую рань спать надо ))

А можно по подробнее о

включить гарантированную доставку 1 и только 1 раз

а то слабо представляю что вы делаете для гарантии в случае если внешняя система приняла сообщение и упала до отправления вам Acknowledge. И при этом у вас

  • нет возможности перезапросить состояние внешней системы или
  • вы не знаете каким образом сообщение влияет на состояние системы чтоб понять по состоянию, доставлено оно иои нет
Действительно интересно.

Это исключительный случай, была только одна система (принимающая сообщения по msmq) с таким условием (нельзя опросить позже, приняты ли данные или нет). Тут делать нечего, кроме как оставить лок на сообщении и начать слать имейлы чтоб разбирались вручную (т.к. были финансовые данные и делать догадки опасно). Но нам здорово помогло то, что msmq это локальный windows-сервис и у нас был маленький windows-сервер в системе, на котором было простейшее C# приложение, которое только читало из kafka и слала в msmq (локая сообщение перед этим). Т.к. приложение было очень простое (один класс, делающий только это) и общалось оно с локальным сервисом для отправки данных, падения не было ни разу и вручную ни разу не пришлось разруливать проблемы. Позже уже внешний вендор согласился прикрутить дедупликацию данных на их стороне

Да, наверное ничего лучше чем слать имейл (rise-ить manual handling) не придумать.

поставить лок...
Гениально) Архитектор от бога

Чем не решение, если это единственный вариант справиться с ситуацией?
И да, архитектор должен и уметь принимать такие вот решения, даже если хочется ввернуть что-то другое.

да он просто потрындеть пришел

а ну ка давай, расскажи мне, как бы ты справился с такой ситуацией. Я жду. Если проигноришь или отписку напишешь — ты м"дазвон и чмо, договорились?

Вспомнилось:

«concurrent programming isn’t so much about threads or locks, any more than civil engineering is about rivets and I-beams»

Думаю, что на уровне двутавров архитекторы-строители при расчетах вполне работают. Так что если следовать строительной метафоре, то тут с этим все должно быть Ок.

Очень редко бывают системы, где нужен только юай (я даже не могу ни одного примера представить), по этому станно звучит «юай архитект»

Ворд, иксель, фотошоп, итд итп ?

Ворд

Выбор формата внешнего и внутреннего хранения данных (одна только дилемма — форматирование встроенное в поток, как сейчас в html, или внешними метками — способна добавить седых волос любому архитектору).
То же самое, с учётом алгоритмов обработки и отображения.
Логика своевременного отображения (включая проблемы типа «текст скроллится вверх, надо суметь быстро перепарсить кусок такого размера, чтобы точно соответствовал предшествующей области).
Методы представления данных документа для адекватного байндинга скриптами.
Можно долго продолжать...
И всё это с учётом мощностей уровня 286-го (когда там Word первый появился?)

иксель

Оптимальная логика пересчёта данных с учётом возможных рекурсий и т.п.
Язык формул, грамматика, семантика, стандартная библиотека функций.
Модули визуализации (построители диаграмм и т.п.)
Взаимодействие с внешним миром (типичный корпоративный вариант — кнопочка в экселине меняет данные на складе, делает проводку, выписывает счёт-фактуру и т.п. — всё это надо удобно прицепить)...

фотошоп

Оптимальное представление изображений в памяти — для всех видов редактирования с учётом того, что может в память не влезать (у фотошопа фактически своя подсистема виртуальной памяти), слоёв изображения...
API плагинов.

итд итп

Да, итд, итп. От «просто UI» до этих программ целая пропасть.

Вот влияет ли это на возможность сущестования понятия «UI architect», я не берусь решать, хотя тоже склонен думать, что UI в них далеко не основная часть.

Как видите, тут были и bd, и UI и сервер и интеграция и выяснение требований и тп и тд.

У вас просто типичный бакэенд. Тут в задаче уи вторичен, если не третичен.
Подумайте про чтото типа ворда.
-Миллион различных диалогов и форм.
-Куча событий от нажатий различных кнопок в формах и хоткиев.
-Куча стейта об учете того где что когда нажато, и какие их комбинации.

Вдруг выясняется, что написать синглтон котрый порешает все вопросы — будет не достаточно.

дык тут же в теме про JS c CSS-ом, десктоп приложения это не то, никто десктоп приложения UI-ем не называет

Как это не называет? Гугл докс это тот же css и html

Скорей всего Василий имеет в виду большенства мелко-средних сайтеков (нде с большущей долей вероятности ТС и работает). Там «архитектура» нынче преподноситься на блюдичке в виде готового к использованию фреимворку. Типа тогоже ангуляру где большую часть уи архитектурных вопросов решено.

да я понимаю, это больше попытка указать на то, что у человека только свои стереотипы, и что если он чего-то не видел, то не значит что этого нет. но он конечно далеко не один такой

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

ох лол — открою тебе секрет в работу архитектора даже входит обсуждение того будет ли идти трейлинг слеш в названии класса (если мы говорим про пехепе например)

Архітектура — це методології в першу чергу. А методології — це спосіб вирішення проблеми.

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

Як побудувати систему, яка не потребує тестування?

А можно подробнее? Я что-то упускаю.
А то как-то слишком много таких самодуров архитекторов встречаю последнее время, которые строят системы, которые не требуют тестирования... в их голове

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

Повернемося до основного запитання. Яка система не потребує тестування? Зазвичай таких систем є три основні типи:

  1. Яка не існує
  2. Яка має внутрішній health-check, вбудований в саму систему
  3. Яка побудована по принципу fail-safe
З першим варіантом все зрозуміло. А ось другий та третій — найбільш цікаві. Якщо система сама слідкує за своїм станом, то її тестування буде проводитися по всіх трьох напрямках, при чому постійно. Але третій варіант найбільш цікавий. Важливо не просто знайти помилку та «вмерти», а ще й спробувати відновити функціональність. Типовий приклад такого підходу — парсер HTML. Він може з’їсти багато чого, виправити найдебільніші помилки, та в решті решт показати контент. Його архітектура спирається не на тезісі, що на вхід приходять ідеальні структури, а на тезісі, що на вхід приходить цифрове лайно. Ви скажете, що його все одне треба тестувати. Так, треба, але що саме ви будете тестувати? Варіативність вхідних даних наближається до нескінченності. Простіше не тестувати сам парсер, простіше вже навчитися контролювати його «здоров’я».
А то как-то слишком много таких самодуров архитекторов встречаю последнее время

Може у вас проблема із сприйняттям інформації? Може саме ви не розумієте, що задачу можна вирішувати не в один єдиний спосіб? ;)

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

В этом проблема. Если в системе баг, то она, следя за своим состоянием, не сможет его увидеть. Для аналогии, представьте себе мозг, который галюционирует. Ему кажется, что он идет по поляне с бабочками радугами, а на самом деле он на краю обрыва и следующий шаг — падение в пропасть.

Для мозку в цей час все реальне. Хоча в дійсності він живе виключно в віртуальному світі.

Поэтому и делают отдельный уровень, который контролирует, чтоб внешнее поведение системы не выходило за допустимые ранки. По аналогии — если человек галюцинирует и пытается прыгнуть с балкона — на него одевают смирительную рубашку,закрывают в комнате с мягкими стенами и начинают колоть голоперидол

Поэтому без тестирования вы нормальную систему не запилите.

я подсознательно хочу верить, что вы понимаете, о чем говорите. просто у вас слово «тестирование» с чем-то другим ассоциируется.
и пытались на личности переходить не потому, что аргументы у вас жидкие и пованивают, а просто у вас такая манера общения.

но если открыть исходники той же мозилы и посмотреть, что и как они там тестируют, то
там немного иначе все происходит.

я подсознательно хочу верить, что вы понимаете, о чем говорите. просто у вас слово «тестирование» с чем-то другим ассоциируется.

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

и пытались на личности переходить не потому, что аргументы у вас жидкие и пованивают, а просто у вас такая манера общения.

Не зрозумів нічого, ну то таке...

но если открыть исходники той же мозилы и посмотреть, что и как они там тестируют, то там немного иначе все происходит.

Ми про архітектуру спілкуємося, чи про реалізацію та процеси тестування? Я вам надав приклад парсера для того, щоб ви прив’язалися до реального світу, бо з абстрактним мисленням тут у людей просто сум-біда. Не намагайтеся довести мені, що без тестування нікуди. Спробуйте довести зворотнє. Це вельми цікава задача для архітектора, який апріорі мусить мати креативне мислення та вирішувати непрості задачі.

ну совсем без тестов, в широком смысле слова, у вас никогда не получится сделать приложение. если говорит об автоматах/юнит тестах, то основная причина их написанися — это возможность облегчить будущею поддержку без регресионых ошибок. поэтому, наиболее типичная система которая таких тестов не требует — это законченная и условно маленькая система.

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

Виходьте вже із зони комфорту. Чим більше ви будете наближатися то умовної точки із нулем тестування, тим більш стабільною та якісною буде ваша система. Такий от парадокс! Але наближатися треба архітектурно, а не просто ігноруючи тести.

По описанию видно, что такая методология не будет работать на более менее серьезных проектах. Если у вас есть какая-то идея, вы не можете ее понятно объяснитьб. Попробуйте написать статью с вашей методологией, может так понятнее будет

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

То есть вы мсье теоретик и вам нечего сказать здесь присутствующим кроме того чтоб набросить. Увы, предсказуемо.

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

От человека, который проповедует какие-то методологию, ожидается, что он ее использовал и получил обнадеживающие результаты. В противном случае вес его словам равен нулю, с таким же успехом мы можем обсуждать методологию обучения белых длиннохвостых крыс основам программироавния.

Да що ви так вчіпилися в мої методології? Хочете стати архітектором? Починайте самостійно думати про запитання, що я задав.

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

Fail-safe будували, там нічого складного немає. Хоча я б більше назвав би це fault-tolerant. Один з прикладів нижче десь в коментарях.

у меня нет самоцели избавится от тестов, ибо это глупо.

правильный подход — отказатся от подхода — «так все делают значит и нам надо», и если в текущей ситуации автотесты не нужны то они не пишутся.

Не глупо. Ефективно. Час та ресурси, які компанії витрачають на тестування, в більшості випадків прямо пропорціональні проблемам архітектури. Бо спрацьовує проста логіка: чим менше я розумію проект, тим більше бажання писати тести. Замість наближення до KISS, іде поступова деградація проекту.

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

так и я говорю о эффективности. есть случаи где тесты таки помогут избежать ошибок, но это скорее редко встречаемые задачи, аля есть алгоритм который творит «магию», для таких вещей юнит тесты очень сильно помогают, конечно когда вы херачите тесты на простой крад, то кхм.. ценность снижается. когда есть «стремнная» бизнес логика, опять таки тесты привносят ценность.

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

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

— Мыши, станьте ежиками
... (а как?) ...
— Мое дело — стратегия!
P.S.
Можете продемонструвати реальну систему ?

Парсер HTML браузера — один з прикладів

Відкривайте код Firefox або Webkit, та вивчайте.

HTML браузера

сферичного браузера в вакуумі ? Про який саме ми говоримо — Chromium, Firefox?

Яка різниця? Ви зараз хочете що саме довести? Що код цих двох парсерів різний? Ви на сутність дивіться, що вони роблять, а не на те, як саме написаний їх код.

Але третій варіант найбільш цікавий. Важливо не просто знайти помилку та «вмерти», а ще й спробувати відновити функціональність. Типовий приклад такого підходу — парсер HTML. Він може з’їсти багато чого, виправити найдебільніші помилки, та в решті решт показати контент.

Парсер обробляє помилки відповідно до специфікації, описаної в HTML-стандарті:
html.spec.whatwg.org/...​parsing.html#parse-errors
в якій перелічено перелік помилок.
Немає ніякої магії — всі відомі помилки обробляються згідно алгоритму, якщо виникла невідома помилка, парсер може просто припинити парсінг.
Що саме вам браузер покаже в результаті парсунгу коду з помилками — це ще питання.
P.S.
І то не факт, що помилка буде виявлена — в коді парсера Chromium є кучка // FIXME: parse error ( не хочете допомогти покращити парсер ? :)

Парсер обробляє помилки відповідно до специфікації, описаної в HTML-стандарті:

Тої спеки занадто мало. Вона нічого не каже, наприклад, про випадки типу «нема <html>», «нема <body>»; «незакритий тег», що не можна вкладати; закриття зовнішнього тегу без закриття внутрішнього...
Стандарти і W3C наполягають на виконанні норм, але практично всі браузери якось виправляють ці ситуації. Наприклад:

<p>Q<sub>1</p>

і хто з них відмовиться відображати це? Щось не бачив таких...

І то не факт, що помилка буде виявлена — в коді парсера Chromium є кучка // FIXME: parse error

Що саме в них і до чого виявляти помилку? Звичайно для цього є окремі лінтери.

Парсери так працювали задовго до специфікації. Це вже потім їх поведінку описали в специфікації.

І то не факт, що помилка буде виявлена

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

Это лол. Вот про это и шла речь...
Реальность она другая. На это поведение парсеров есть даже тесты, что бы вы там себе не придумывали бы. Я специально вчера посмотрел, как именно тестируется парсер в мозиле, хромиуме...

Возможно концептуально вы в чем-то правы. Но нужен пример. А так пирамиду тестирования и стоимость ошибок на различных этапах никто вроде не отменял

Ви читаєте те, що написане, чи власну вигадану реальність? Я вам давав приклад не того, що парсер НЕ ТЕСТУЄТЬСЯ, а приклад того, ЯК ПОВОДИТЬСЯ парсер із потоком свідомості від авторів. Скільки разів ще повторити, щоб ви зрозуміли цей простий приклад?

А так пирамиду тестирования и стоимость ошибок на различных этапах никто вроде не отменял

Я не казав, що її треба відміняти обов’язково. Чому всі вважають, що напрямок «від тестування» означає обов’язково деградацію?

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

то фактически контр пример вашему

Контр приклад чому саме?

насколько геморно поддерживать систему, которая (типа) может восстановиться

Наскільки геморно вам підтримувати ваш власний організм?

вот только на днях на хабре статья была про инъекцию через ошибку в html парсере

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

Парсер HTML браузера — один з прикладів

Ерунда. Откройте реальный парсер. Я же вам выше написал, что реальность не совпадает с вашим представлением.

Я понимаю, к чему вы пытаетесь клонить.
Просто ваши формулировки очень смахивают на то, что вы не сильно понимаете процесс поставки продукта. А абстрактное борождение просторов космоса может приводить к тому, что в итоге требования архитектора абсурдны и ими можно принебречь

Просто ваши формулировки очень смахивают на то, что вы не сильно понимаете процесс поставки продукта.

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

А абстрактное борождение просторов космоса может приводить к тому, что в итоге требования архитектора абсурдны и ими можно принебречь

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

лол. прочитайте первый комментарий, который вы мне написали. и что я вам на это ответил =) мы ходим по кругу.
спойлер: вы начали с оценочного суждения, перехода на личности и додумывания за собеседника..

текстовый редактор хороший пример

спойлер: вы начали с оценочного суждения, перехода на личности и додумывания за собеседника..

Де я переходив на особистості? о_О

так пример у вас есть?
с таким кол-вом постов можно было уже 100 раз объяснить мотивацию, обстоятельства и хоть несколько примеров из реальной жизни.

так пример у вас есть?

Валом прикладів. Один з останніх. Ми використовуємо структурно-подійне програмування для побудови логіки UI. Якщо дуже коротко, то це набір базових хендлерів, які викликаються при розповсюдженні події в певній структурі. Потік виконання ситуативний, залежить від структури, а не описаний імперативно в коді. Хендлери «тупі», виконують гарно лише одну функцію. Система слабкопов’язана та стійка до змін. Наявність або відсутність структури не впливає на загальний процес виконання. Внесення модифікацій не впливає на систему цілком та локалізовано в певній структурі.
Резюме: система fault-tolerant.

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

Ніхрена не зрозумів. Кусок коду покажіть.

тоді вже лінк на фреймворк давайте
github.com/s0rr0w/z
Отже, ще один JS фреймворк.
Приклади зроблені красиво, але чим він кращий за інші, не розкрито.

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

але чим він кращий за інші

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

спасибо за пример. хотелось бы немного разобраться.
1. как этот подход упрощает тестирование? там же нельзя разделить логику от вида?
2. циклические подписки by design — это норм?
3. не всматривался, но как обстоят дела с подпиской и отпиской на динамические элементы?
4. как со скоростью?
5. пару примеров чем это лучше redux?

1. как этот подход упрощает тестирование? там же нельзя разделить логику от вида?

Задача не спростити тестування. Задача мінімізувати важливість тестування. Це абсолютно різні речі. В першому варіанті ви пишете тести, та хочете спростити їх написання/виконання/контроль. В другому — наявність тестів чи їх відсутність не впливає на загальний процес та кількість багів. Тому що процес розробки не множить баги системи. Логіка виконання коду проста, більше схожу на бінарну, або працює, або ні. Сайд-ефектів майже немає (вони в основному з’являються через переускладнення або перевантаження певної «функції»). Тому після того, як ти написав щось та запустив, одразу стає зрозумілим, чи працює це, чи ні. Після написання якогось умовного компонента, його код потім ніколи не змінюється. А значить, повторно тестувати не треба. В решті решт, наявність чи відсутність тестів не впливає на кількість багів системи. Що підтверджується роками використання цього підходу.

Логіку від представлення ви не зможете від’єднати, бо цієї логіки не існує. Логіка компонента створюється під час запуску події (ситуативний потік виконання), та залежить від структури, де саме розповсюджується подія. Того звичного світу, до якого всі звикли, немає. Тому немає і його проблем. Окрім того, процеси виконання певної «функції», є графом, та інші функції можуть частково використовувати ці графи для своїх потреб. Наприклад, якщо у вас є процес зміни стану, наслідком якого є перебудова статистики, наслідком якого є реініціалізація UI, то це три різних процеси, які можна використовувати як частки сторонніх процесів. Достатньо їх запустити. Це не імперативний підхід, тут немає прямого контролю дій, які мусить виконати функція/метод, щоб досягти результату.

2. циклические подписки by design — это норм?

Що вас бентежить? Ви можете створити нескінченну функцію, яка визиває сама себе. Браузер все одне зупинить її виконання, але можливість зробити постріл собі в ногу є. Хоча процес підписання тут статичний, тільки під час темплейтування, але ви можете темплейтити самого себе.

3. не всматривался, но как обстоят дела с подпиской и отпиской на динамические элементы?

Відписуватися не треба by design. Такої сутності як «динамічні елементи» там не існує як класу. Вони всі динамічно створюються, хоча потім є статичною структурою.

4. как со скоростью?

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

5. пару примеров чем это лучше redux?

А чим redux краще за jQuery? Запитання приблизно з одного рядка.
Це не конкуренти взагалі та їх порівняння в лоб не можливе. Хоча деякі моменти я вже описував: ситуативний процес виконання коду, кожен елемент структури може мати власну реакцію на зміну стану, не треба писати JS код. Цього вже достатньо для того, щоб окреслити основні відмінності.

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

вот я не уверен (сказал бы, что крайне скептически отношусь) в том, что предложенная архитектура отражает написанное вами выше. самый простой пример — наличие (возможность, которой обязательно воспользуются) циклических обработчиков. можно всю жизнь потом дебажить, кто и что поменял, и как оно повлияло на другие компоненты. это одна из причин, почему интересно стало сравнение с популярным дизайном redux.

Логіка виконання коду проста, більше схожу на бінарну, або працює, або ні

ваша логика логичнее моей логики

Сайд-ефектів майже немає (вони в основному з’являються через переускладнення або перевантаження певної «функції»).

вот это одно из тех мест, где мы сильно расходимся в понимании. как по мне это «почти» — нифига себе огромная дыра в дизайне

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

это зависит от размера проекта. частенько ничего не понятно. не каждый компонент позволяет за 10 секунд проверить все состояния. да и наверняка кол-во компонентов * поклацать каждый = дорого. вот здесь и нужны тесты, которые покрывают поведение компонента.

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

зависит от проекта и требований. для мелких проектов и фреймворк не нужен. и вообще можно взять Wordpress с плагинами.
но когда нужно разрабатывать сервис, который будет развиваться, то это заложенная бомба.
а что если вы обновите версию фреймворка своего? а что «если»?
как раз смысл протестировать именно на этапе написания компонента в том, чтобы убедиться, что его «контракт» будет соблюдатьяс вне зависимости от изменений. как он работает — консьюмеро все равно, лишь бы контракт выполнялся. потому что дальше это кто-то ручками, либо каким-нибудь selenium будет педалить много ненужных сценариев.

Того звичного світу, до якого всі звикли, немає

я просто пропущу этот абзац, потому что я вижу концепцию фреймворка чуть ближе к тому миру, которого больше нет.

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

вы там выше писали про дизайн, который упрощает тестирование (делает его менее важным). и теперь пишете, что by design вы можете стрелять себе в ногу. все равно браузер остановит вас.. когда-нибудь... как бэ..

Відписуватися не треба by design

лень было всматриваться. но если хендлеры глобальные нигде не регистрируются и рефернсы не устаревают, тогда наверное.

Краще запитувати, які можливості є по тюнінгу. Можна зробити швидше за React.

это можно кому-то другому писать (весь абзац).
«ускорили в 10 раз» — по сравнению с чем?
как вы оценили эту самую возможность тюнинга? грид на 100.000 элементов с подписками сделаете? сравните двойной буферизацией DOM и redux?

А чим redux краще за jQuery?

зависит от требований. но как раз react redux лучше, в принципе, во всем (если не говорить о простых сайтах, которые никогда-никогда не будут ничего особо динамически выводить). скорость, управляемость, ментейнабилити, прозрачность. все это там лучше.

Це не конкуренти взагалі та їх порівняння в лоб не можливе

подразумевается react + redux. какой процесс обработки событий, поток данных, генерирование вьюх

можно всю жизнь потом дебажить, кто и что поменял, и как оно повлияло на другие компоненты.

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

нифига себе огромная дыра в дизайне

Немає ідеальних дизайнів. В одному одне погане, в іншому — інше. ;)

не каждый компонент позволяет за 10 секунд проверить все состояния

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

а что если вы обновите версию фреймворка своего?

В цьому немає необхідності. Простіше написати фреймворк над фреймворком. Його базової функціональності вистачить на десятки років наперед. Плюс, використана абстракція дозволить переписати код ядра на чому завгодно без втрати функціональності компонентів. ;)

потому что я вижу концепцию фреймворка чуть ближе к тому миру, которого больше нет.

Ви ж не розібралися, але вже зробили висновки...

лень было всматриваться. но если хендлеры глобальные нигде не регистрируются и рефернсы не устаревают, тогда наверное.

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

«ускорили в 10 раз» — по сравнению с чем?

В порівннянні із власним кодом, звісно ж.

грид на 100.000 элементов с подписками сделаете?

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

но как раз react redux лучше, в принципе, во всем

Якщо в мене є лендінг, а на ньому мені треба галерею, я оберу jQuery, а не реакт + редакс. ;)

подразумевается react + redux

Системи, які побудовані на принципі «JS first», в яких HTML є результатом роботи, а не основою, прирекають розробників на біль та страждання. На кожний чих/пук приходиться писати JS-код. А я не пишу його вже роки два, використовую написане. Інколи, раз на місяць, вношу мінорні зміни, в основному в обробники, а не в код ядра, та й ті в пару строчок коду. А компоненти та функціональність проектів при цьому тільки збільшується. Ось основний виграш.

какой процесс обработки событий, поток данных, генерирование вьюх

Оце все для світу z — пусті слова. ;)

Щось не схоже, что такий парсер не потребує тестування.
Або я (і не тільки я) зовсім не розумію, про що мова.

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

Так это шпак, у него год назад был основной посыл — аналитики не нужны, теперь вот эволюционировал в тестировщики не нужны, человек оркестр, нужны только девы

В его защиту он не имел в виду, что тестировщики не нужно. Но строить архитектуру, которая более стойкая к изменениям и требует меньше усилий для тестирования

Такой подход требует большой степени абстрактности и в половине проектов не просто не нужен а еще и усложнит проект

Не обязательно, ну а сложность очень относительное понятие, можно и упрощением добиться кода, который устойчив к изменениям и требует меньших усилий для верификации, главное знать чего хочешь и не хотеть противоположного. Сложность с усилиями для проверки чаще прямо пропорциональны, чем наоборот

Звучит как набор пустых слов, как ты упрощением без увеличения абстракции сущностей добьешся более устойчивого к изменению решения?

Як приклад можу привести скрипти *nix’а. Так званий *nix way. Купа примітивних утиліт, які гарно роблять одну функцію, за допомогою скриптів, які описують доволі просту логіку, можуть в цілому складатися в високорівневу функціональність.

Что за каша у вас в голове, скрипты юникса это тулзы, если вы про изменоустойчивость юникс операционки, то она должна измеряется тем как система гибка при изменении железа и внешних интерфейсов, система не модет быть определена гибкой только потому что у нее есть богатый функционал для конечного пользователя, скрипты юникса не меняют его ядро (Что и определяет архитектуру юникса), это всего лишь утилитки.

Что за каша у вас в голове, скрипты юникса это тулзы

Скрипти юнікса це скрипти юнікса, текстові файли, написані на bash, sh, perl, python etc. Словом tools називають маленькі утилітарні бінарні файли (ls, rm, dd, grep, find, ln, mount, etc.)

если вы про изменоустойчивость юникс операционки

Ні.

о она должна измеряется тем как система гибка при изменении железа и внешних интерфейсов, система не модет быть определна гибкой только потому что у нее есть багатый функционал для конечного пользователя

Нічого не второпав.

Окей, тоесть вы не про архитектуру юникс операционки. Про архитектуру какой системы вы тогда говорите как пример изменоустойчивой?

А можна трошки офтопіку, а що ви маєте на увазі під словами «архітектура юнікс операціонки»? Цікаво, бо я трохи розгубився, може в нас не однакове розуміння даного виразу...

У каждой системы есть архитектура — набор сущностей и их связей, правил, флоу которое определяет ее структуру и поведение. Если вы приводите архитектуру юникса — то это на 95% его ядро которое состоит из подсистем и их взаимодействия между собой. И соответственно изменоустойчивость юникса будет определяться тем как гибко система будет адаптироваться к новому железу (так как это назначение операционки одно из) и новым внешним интерфейсам и задачам без изменения ядра системы

И соответственно изменоустойчивость юникса будет определяться тем как гибко система будет адаптироваться к новому железу

Основні принципи архітектури Unix були розроблені ще десь в 70-х роках. С тих пір вони успішно пережили десятки архітектур процесорів, заліза, пристроїв, протоколів тощо. Систмі не треба адаптуватися до заліза, бо залізо для неї це файли. Процеси теж файли, сокети — файли, все — файли (ладно, не все, але це гіпербола).

и новым внешним интерфейсам и задачам без изменения ядра системы

Ядро Neutrino QNX було випущене в 2001 році. Чи потребує це ядро постійного дописування та змін? Думаю що ні.

в двух словах не объясню, но есть инфа 100% что абстракция упрощает, а не усложняет

а я что сказал?!

как ты упрощением без увеличения абстракции сущностей добьешся более устойчивого к изменению решения?

Упрощение с помощью абстракции ухудшает перформанс и мейнтенабилити

ухудшает перформанс

ну это уже на уровне изобретателя днипробд, который пишет все одним файлом «ради перформанса», такое никогда не становится узким горлышком

и мейнтенабилити

это не так, иначе, как минимум, ооп бы не применяли

ооп не равно абстракция, при чем тут оно
по поводу перформанса — очень даже, чем больше уровень абстракции — тем больше схлопнуты обьеты, тем хуже перформанс так как все свалено в одну кучу из-за абстракции

с таким подходом лучше на ассемблере писать, если ты не готов пожертвовать вообще ничем, обычно не абстракции ухудшают перформанс, они и 1% обычно не весят

сли ты не готов пожертвовать вообще ничем

ты вообще читал мои посты?! я как раз и говорю, что прийдется чем то пожертвовать, и потому для 50% проектов изменоустойчивость не так важна что бы ради нее жертвовать более важными параметрами

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

Правильно, везде лепи оверкомпликейтед решения, что бы потом на форуме писать какой ты модный)))

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

Возразить нечего, хороший подход. Но это же антоним слова изменоустойчивость, когда вы сами постоянно меняете архитектуру так как прошлая версия была хуже

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

Какое это имеет значение к изменоустойчивости?
Вы прыгаете от одной пустой фразы к другой, еще раз повторюсь — изменоустойчивость не всегда нужна, что бы проектировать систему с упором на это качество — нужны обоснования для этого

что бы проектировать систему с упором на это качество — нужны обоснования для этого

Дайте приклад системи (саме системи, а не якоїсь примітивної утиліти), яка принципово вимагає нестійкості до змін.

С чего вы взяли что неприоритетность изменоустойчивости == требование к системе быть нестойкой к изменениям?
Конечно же, было бы круто что бы все системы можно было бы наворотить сразу измено-отказо- устойчивыми, с максимальной производительностью, наилегчайшим мейнтененсом, офигенной скалабилити и не ресурсоемкой.
Но это был бы прорыв, такое коробочное решение сразу бы стали юзать все.
Ты всегда чем то жертвуешь, тебе надо изменоустойчивость — ты жертвуешь другими параметрами. И для каждой системы ты решаешь что для тебя важнее

Нарешті ви розгорнули думку та стало зрозуміло про які саме речі ви розповідаєте. Так, повністю згоден.

Але, якщо повернутися до нашого контексту, то ми розмовляли про розвиток людини до рівня архітектора. Та, як однією із задач, яку можна було б спробувати вирішити, була задача побудови системи, в якій тестування займало мінімум часу. Це не значить, що такі вимоги висуваються до всіх систем. Тому в нас виникло непорозуміння. ;)

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

Если все покрыть тестами, то тестирование вообще не занимает времени. Нажал кнопку, через несколько минут/часов есть результат, без каких-либо действий со стороны разработчика.

Если все покрыть тестами, то тестирование вообще не занимает времени.

Якщо ваша система ніколи в житті не буде змінюватися, то так.

Смотря, как будет меняться. Поэтому, в том числе, я и топлю здесь за black box и избирательное юнит-тестирование — чем уровень выше, тем меньше вероятность того, что система изменится, а при лаконичном подходе эти изменения покроются автоматом. Если же всё покрывать юнит-тестами, ненужный нижний уровень, если что, улетит в корзину вместе с ними.

В случае же серьёзных изменений, сколько % времени займёт написание тестов? Минимум. Стоит это уверенности в том, что система работает, как задумано? Конечно, стоит.

Абсолютно вірно! Дякую за розуміння.

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

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

В описываемой Вами ситуации тесты в любом случае нужны, потому что без них перелопатить всё вслепую нереально. Кстати, есть косвенный показатель хорошего кода — если структуры грамотные и лаконичные, black box тесты должны давать достаточное покрытие, чтобы юнит-тестирование практически не требовалось (в теории — не требовалось вообще). Но, если всё действительно очень плохо, то вполне возможно, что стоит поднажать на тесты, если их не хватает, а затем уже переходить к разгребанию.

Но, если всё действительно очень плохо, то вполне возможно, что стоит поднажать на тесты, если их не хватает, а затем уже переходить к разгребанию.

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

Ви вирішили замінити цей шматок коду на інший, який використовує взагалі сторонній сервіс для прийняття рішення. Сенс в покритті тестами вмираючого рішення?

все очень сильно зависит от обстоятельств.
«нет ничего более постоянного, чем временное». если замена будет «завтра», а в продакшн вы это все заливаете «сегодня», то неплохо бы быть уверенным, что оно работает. как исключение что-то старое (легаси), что уже 100 лет работает и «можно не трогать».
но здесь тоже есть нюанс — когда вы начнете это все «заменять» (т.е. рефакторить), как вы убедитесь, что новое решение заработало корректно? и вот здесь неплохо бы какие-то тесты иметь под рукой, чтобы убедиться, что поведение системы осталось неизменным

Ви вирішили замінити цей шматок коду на інший, який використовує взагалі сторонній сервіс для прийняття рішення. Сенс в покритті тестами вмираючого рішення?

Очевидно, что сторонние решения не предполагаются в этом примере (таким будет большинство реальных кейсов).

Кстати, есть косвенный показатель хорошего кода — если структуры грамотные и лаконичные, black box тесты должны давать достаточное покрытие, чтобы юнит-тестирование практически не требовалось (в теории — не требовалось вообще)

ШТА? это у кого такое?
обычно это показатель того, что у вас такое го№нище понаписано и такая связанность кода, что вы просто не можете юнит тесты написать так, чтобы они ненароком не стали интеграционными+.
каждая написанная строка кода содержит баг ©
поэтому выше и была фраза от Александра, что ~"не нужно тестировать тот код, который не написан«.
В итоге вы можете лишь повышать уровень абстракции ваших тулов (язык, библиотеки — полагаться на то, что вы используете уже протестированные кем-то средства разработки), чтобы уменьшить кол-во кода, уменьшить связанность (хрупкость) вашего кода. а все оставшееся тестируете по тест пирамиде. потому что «black box» тесты обычно самые дорогие и медленные.

связанность кода

Что такое «связанность»? Если какой-то код нереально вызвать с верхних уровней, то дело не в связанности, а в том, что такого кода в общем случае должно быть чем меньше, тем лучше. Если невозможно без сверхусилий написать black box тесты так, чтобы они покрыли большую часть всей логики, то там не «связанность», а нижние уровни кода просто оторваны от задач, и «отвязанность» в этом случае выглядит так, что либо: 1) кто-то потратил время на написание ненужного функционала, чтобы в уме всё выглядело красиво, но в реальности оно нафиг не нужно 2) с банальной инкапсуляцией большие проблемы.
Почему, если из верхних уровней нормально вызывается нижний, это «связанность»? Вы так пишете, вроде бы каждый юнит публичный и переиспользуемый в других системах, но это же не так.

обычно это показатель того, что у вас такое го№нище понаписано и такая связанность кода, что вы просто не можете юнит тесты написать так, чтобы они ненароком не стали интеграционными+.

ОК, задача — написать кастомный непубличный калькулятор, который будет что-то считать на нижних уровнях исполнения. Способ для калькулятора «юнит тесты написать так, чтобы они ненароком не стали интеграционными+» в студию.

потому что «black box» тесты обычно самые дорогие и медленные.

Если прикинуть, сколько времени пришлось бы потратить, чтобы покрыть то же самое юнит-тестами, по сути, повторно (при том, что black box писать всё равно нужно, т.к. именно они тестируют фактический функционал), издержки не кажутся такими весомыми. Т.е., если, к примеру, 30% — юнит-тесты (для кейсов, которые нецелесообразно покрывать black box тестами), а black box тесты покрывают 70%, то есть ли смысл покрывать юнит-тестами всё?

открываешь любую библиотеку, фреймворк или тулзу (желательно старую и от серьезных контор), и начинаешь задавать себе вопрос — почему этот класс-функция-модуль сделаны именно так ? какие есть альтернативные варианты ? насколько легко будет переделать под новые фичи и таде

Ноо...! Чем дальше я работаю и чем сложнее мне тим лид ставит таски тем сильнее я понимаю что моё мышление какое-то ограниченное. Мне сложно выстроить архитектуру всего приложения на уровне самого приложения, хотя повторюсь — на уровне компонента, одной функции без проблем решаю поставленные задачи.

Да это не уровень архитектора. Надо сомостоятельно брать лопату и копать приложение — что откуда береться, куда деваеться и от чего зависит. Просто тупо смотри изучай код. Для пущего эфекту возьми каконить не элементарный баг — попробуй зафиксить без малейшей подсказки тим лида. Потом на кодь ревью пусть ччательно поревьювит, и внимательно порасказывает что ты сделал не так и почему (на уровне компонентов). После пары таких багов жизнь наладиться.

Для того, чтобы «прокачать», нужно было начать с раскрашивания скролбаров. Теперь уже поздно. Остается только прочитать и выучить (где — не знаю, потому что приложения все разные, решения — тоже).
Если не учить, то прийдет с ростом числа приложений, над которыми Вы работали. Если опыта «чуток», тимлид не может ставить задачи, требующие знаний для решения архитектурных вопросов. Что-то на фирме не так происходит.
Переходите в нормальную, где будете учиться у коллег.
PS Прокачайте навык «сделать просто, быстро, остальное — скажут, что не хватает». Не старайтесь навернуть там кучерявые декорации. Оно не оплатится.

архітєктить!

всьо нормально, ростеш до межі своєї компетенціі.

Можете почитать про патеррны и прочие вещи. Это не помешает, но учитывайте, они устаревают и меняются почти так же быстро, как и javascript фреймворки.

Если интересуетесь более фундаментальными вещами, могу посоветовать эту книгу. Но предупреждаю, читать ее довольно сложно. www.amazon.com/...​Engineering/dp/0321815734

Когда вам дают задание, вместо того, чтоб бросаться его решать, сделайте шаг назад, посмотрите на то, что происходит вокруг. Например, может быть вам поставили задачу маскировать проблему, а вместо этого ее нужно решать, и это делается совсем в другом месте.

Избегайте ловушек, не привязывайтесь к своим идеям, какими бы хорошими они не были. Рассматривайте множество альтернатив, и честно анализируйте каждую из них. Документируйте все свои решения. Представьте, что прийдется обосновать свое решение перед тремя начальниками, которые готовы поставить под сомнение или даже уничтожить каждый ваш аргумент.

Если есть трудности, начните с того, что обсуждайте с более опытными людьми почему они приняли то или иное решение в проекте. Ставьте под сомнение их решения, ищите подводные камни и так далее.

Если в команде нет сильных специалистов, с которыми это можно обсудить, меняйте команду.

Я бы советовал уходить из фронтенда, чтоб работать с качественно другим классом задач.

и как же быстро меняются паттерны?)

Так быстро что никто не успевает реально уследить и только спрашивать но не применять.

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

То, о чем вы говорите это не архитектура, а дизайн приложения. Советую почитать Clean Code и другие работы автора Robert C. Martin.
Автора по имени Martin Fowler тоже можете почитать, особенно его книгу про рефакторинг, но другие работы я бы не советовал, слишком уж этот дядька «летает в облаках».

И конкретно по фронтенду — addyosmani.com/...​ialjsdesignpatterns/book, отличная книга в отрыве от конкретных технологий.

Ну и вы никогда не научитесь «водить», без практики, поэтому попробуйте спроектировать, например фронтенд для Twitter, а потом сравнить как собственно они и сделали в Twitter.

Как качать скилл архитектора?

1. Смотреть «изнутри» крупные проекты (код).
2. Медитировать.

Если прикрутить градус ненависти — ну вот попробуй читать что нибуть такое
dataintensive.net
полезно для расширения кругозора и вообще способ отвлечся от фронтенда

да никакой ненависти. Просто хотелось намекнуть тс-у что знать как построить юай и соединить в нем библотечки — это еще не архитект. И до архитекта расти и расти много лет, работая со всеми слоями кучи разных приложений, а не «прокачать скил», надо.

я опа вообще ***ми покрыл, потом только передумал for the greater good

ты че в прошлой теме про нз не отписался?
ЗЫ
забыл, что там же нельзя анонимам. как вариант можно всобачить туда post с смс, думаю прокатит.

Там не рады анонимам...

мне кажется, что можно таки. инпут поле просто не показывается юзеру, а через пост можно добавить.

серьезно? надо посмотреть

угу, ну я когда копался, то для поста все было в хтмлке.

это не такая тема, тут анонимам можно )

да там тупо нельзя писать анонимам. так что многие дешево отделались — срачь не состоялся

а, то ты у себя градус прикручивал... А я думал градус ненависти в теме... )

да у себя. Я сходу всякого плохого наговорил а потом решил быть более позитивным

во чего толерантное общество творит с человеком.

А че бывают фронтэнд архитекты?

и че они делают? )

Не знаю, в разделе обязанностей указано такое:

You’ll be given responsibility for the whole process of a key technology platform. You will facilitate the platform as it supplies source, build, and test services. We expect for you to utilize your extensive experience to continually improve and redefine the developed software. You will consistently ensure quality and productivity by implementing automation wherever possible

-------------------

• Design architecture.
• Code.
• Mentoring.

-------------------

• Participation in proposals preparation with all different parties, stakeholders and workflows
• Estimation and scope decomposition
• Risk assessment, defining dependencies and assumptions
• Technical specifications and architecture vision document creation
• Technology assessments and comparisons
• Participation in discovery phases and workshops covering all technical aspects of the deal
• Prototypes and proof-of-concept creation with their further delivery and presentation to the stakeholders
• Participation in the implementation phase defining and creating the core of that or another system, transferring the knowledge to development team

-------------------

In this role you will be a main figure in the Ukrainian R&D center, providing your expertise on different stages of development of a high-distributed innovative product as well as making crucial business and technological decisions in the product perspective.

а разве не задача архитектуры увязать 5-10 полноценных фремворков в один клубок сложного юайя, выбрав оптимальный вариант взаимодействия между ними и конкретные оптимальные решения из каждого фреймворка?
перформанс, паттерны интерфейсы — как у любого архитектора

я б сказав, його завдання — спочатку визначитись з загальною архітектурою проекту (як це банально не звучить) і вже наступним етапом підібрати під цю архітуктури конкретні сервіси, СУБД, фреймворки і т.д. Очевидно, він повинен знати про варіанти конкретної реалізації того чи іншого елементу архітектури (щоб не намагатись потім «впіхнуть невпіхуємоє»), але на етапі реалізації вибирати «конкретные оптимальные решения из каждого фреймворка» цілком може звичайний сеньйор.

ты упустил тот факт что мы абсуждаем фронт-енд архитектора, ты же написал о фулл стак архитекторе, когда он делает рахитектуру для всех 3 слоев

мы абсуждаем фронт-енд архитектора

ах от воно що: фронтенд-архітектори... архітектори фасадів будинків...
тоді я пас :)

уже приводил пример сложных задач по юаю —

Пример сложной архитектуры юайя — портал, в который могут интегрироваться другие апликухи в единую систему.

ну они то не только в юай интегрируются, правильно? То есть надо несколько «архитекторов»?

только)
это такой интересный вид проектов когда юай — это и есть ВСЕ приложение.
Конечно, есть немного конфигов но даже для полноценной базы их не наберется, как такового бекенда нету для таких типов апликух, потому что вся логика касается только юая.
Естетсвенно у каждой апликухи которые владельцы хотят интегрировать — есть бекенд, но то совсем отдельные независимые апликухи.
С огромнейшей натяжкой можно взять какую то часть логики таких проектов и сказать — мол вот наш бекенд, но на самом деле это искусственное разделение потому что бизнес назначения бекенда в таких апликухах нету.
Правда, не могу придумать другие примеры

ладно, пусть будет юай архитект для таких проектов )

а синьйор тогда чем занимается?

если проект большой — там будет достаточно много синьйоров, им что всем архитектуру на себя тянуть?) представляю такое, та ну нафиг, архитектор должен быть один)

я о том что «архитект» это немного сложнее, чем юай

Тогда это не архитект (возвращаемся опять к тому-же)

По канону данный чел дожен называться «тех лид», никак не «архитект».

Senior може мати вузьку спеціалізацію і не вміти вибирати архітектуру.

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

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

Помойму большенство проектов такие. Неспроста опытные архитекторы, который понимают что они делают и зачем — на вес золота.

Senior може ... не вміти вибирати архітектуру.

эээ... А мидл тогда кто?

уже не іюнь, але ще не сейнор

На відміну від Senior, він, наприклад, може не вміти правильно виконувати деякі нетривіальні завдання.

Senior, який пару десятків років писав низькорівневий код на asm/C/C++ для різного обладнання і знає багато підводних каменів у цій області, не зобов’язаний вміти спроектувати архітектуру системи, у якій його компанія використовує цей низькорівневий код, щоб називатися Senior.

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

И для решения такой задачи нужен архитектор?

То есть архитектор это тот, кто юай на фреймворке запиливает?

Пример сложной архитектуры юайя — портал, в который могут интегрироваться другие апликухи в единую систему.

вордпресс? #trollface

Та думаю любой ентерпрайз юай.

Хз как сейчас с джаваскриптами, а десять лет назад пару млн строк свинг кода задвигали так, что сейчас биг дата цветочками кажеться.

ну здравствуй, северный олень ;)

Ну вообще-то на дворе 21-ый век и уже во всю создаются SPA. Если расшифровать эту аббривиатуру, то получится Single Page Application... Ключевое слово Application для тех кто не в теме. А если есть Application, то есть и архитектура... Make sens ?
И кстати, в начале нулевых, когда ещё SPA были только в зародыше, ибо XmlHttpRequest только начинал своё шествие — всё равно были достаточно сложные фронт енды, со множеством активных эллементов. И как-то это всё добро нужно было структурировать для избежания каши как в коде, так и в голове девелопера... Поэтому архитектура есть везде, где есть приложение размер которого больше нескольких классов. Иначе это будет плохострукурированная каша, которую будет всё сложенее и сложнее саппортить с ростом code base. В общем, ИМХО необходимо продумывать архитектуру, после апрува прототипа (а иногда и прототип стоит вначале тщетельно архитектить, если он достаточно сложный) в не зависимости от того Front End это или Back End.

HelloWorld.exe — це також application. Чи значить це, що там є архітектура ?
P.S.
Так, тепер роблять такі SPA, що це вже не собача будка, а цілий здоровенний ларьок. Ок, будемо вважати МАФами. :)

HelloWorld.exe — це також application. Чи значить це, що там є архітектура ?

1. Чисто формально — да, это консольное приложение...
Но если мы говорим не о первой главе книги по программированию, то Ваше замечание выглядит как минимум не уместно. Вы хоть читали subj ? Человек пишет не hello woldы, а в полне себе фронт энд приложения, и уже не может в голове удержать их структуру. Собственно поэтому обратился за помощью, как это всё дело правильно струкутрировать, что бы было легче саппортить и добавлять код

2. Если бы Вы внимательно читали мой пост, то увидели бы там такое предложение:

Поэтому архитектура есть везде, где есть приложение размер которого больше нескольких классов.

В HelloWorld.exe один метод в одном классе или одна процедура/функция, в зависимости от языка.

Архитектура то есть, кто ж спорит, но че тогда синьйор фронт-эндеры делают?
Я тут пытаюсь донести, что нельзя быть архитектором двери или архитектором окна (хотя там тоже есть чертежи, рассчеты и тп), можно быть архитектором только всего здания

По разному бывает ИМХО. Тебе как девелоперу дают уже существующий API, и говорят — сделай фронт энд. API ты менять не можешь, можешь только его осознать. Следовательно ты проектируешь архитектуру фронт энда для уже существующего BackEnd API.

Я тут пытаюсь донести, что нельзя быть архитектором двери или архитектором окна

Ты хочешь сказать что окно архитектит архитектор всего здания ? Насколько я знаю, есть госты, и окна проетируют оконные архитекты, а здания — архиеткты зданий...

Вот именно, у ангуляров, редуксов и т.п. уже есть спроектированные решения.

Ну дело в том что на ангуляре и редуксе свет клином не сошёлся. Я так понимаю топик стартер использует нативный JS/CSS/HTML, ну может с какими то плюшками типа jQuery. Если бы он изучил какой-то фреймворк, который предлагает девелоперу некоторую архитектуру/дизайн приложения, этого топика бы не было... Он бы просто использовал те шаблоны, которые предлогает фреймворк ИМХО.

Тебе как девелоперу дают уже существующий API, и говорят — сделай фронт энд. API ты менять не можешь, можешь только его осознать. Следовательно ты проектируешь архитектуру фронт энда для уже существующего BackEnd API.

то есть сразу начинаешь называться архитектом? А в чем разница с обычным девом?

Там ващет java script-ниндзя девелопер :-) просто синьор или дев то не модно, а еще в компаниях любят давать разные тайтлы, не зря пошли шутки jumla-архитект, css-архитект...

Думаю есть различные классы архитектов:
Как минимум два:
1. Арихитектор приложения (он же по сути и имплементатор по совместительству)
2. Архитектор решения (тот товарищ который продумывает решение целиком: на какие сервисы/приложения дробить код, как эти айтемы и по каким контрактам будут общаться и т.д., т.е. по сути делает high-level архитектуру всего решения).

Так вот когда разрабатывается решение, его архитект всё тщательно планирует и назрачает отвественных та то или иное приложение, которые будут частью общего решения. Ну и потом TechLead/Architect/Senior Developer в одном флаконе конкретного приложения уже проектирует архитектуру приложение. Будет оно n-tier, MVC, MVVP и т.д.

Мне это видится как то так.

Как правильно здесь было замечено, присутствует путаница в понятиях. В случае «нескольких классов» более уместно понятие дизайн, а архитектура начинается, например, с MVC, и заканчивается архитектурой всего решения.

Ну вообще-то на дворе 21-ый век и уже во всю создаются SPA.

Та и в 20-м веке, еще когда жс ходил пешком под стол, На дельфях/c++ вполне были апликухи на миллионы строк коду.

Да, но тут речь то о js/css/html... А интернет каким мы его знаем +/- стал ативно развиваться как раз в конце 90-ых, начале 00-ых ИМХО

для початку занадто — може потонути...
P.S.
з іншого боку, потрібна ж селекція :)

Хорошая книга, но она скорее ориентированна для бэкенда. Зато позволяет понять какие паттерны лягли в основу того же Hibernate, Spring, Entity Framework, ASP.NET.

с удовольствием послушают ответы отличные от — маслать 5 лет на разных сложных проектах и набираться мудрости

Ищи книги по архитектуре и паттернам, как левый пример — Software Architecture with Python etc.

Software Architecture with Python

Хорошая книга? Стоит потраченного времени?
А то часто книги Packt, особенно от индийцев, проходные.
UPD. Глянул содержание, довольно обширно написано, боюсь что всё поверхностно. Хоть довольно точно с анти-паттернами описаны кейсы?

еще не читал, купил вместе с другими 20 книгами за 15 баксов, зато 2017 года
да, Орейли и Вилиамс лучше издания
Вот патерны, а антипатерны только по ридабилити, тоесть их вообще в книге нет
Chapter 7: Design Patterns in Python 327
Design patterns — Elements 328
Categories of design patterns 329
Pluggable hashing algorithms 331
Summing up pluggable hashing algorithm 334
Patterns in Python — Creational 335
The Singleton pattern 335
The Singleton — do we need a Singleton? 338
State sharing — Borg versus Singleton 340
The Factory pattern 342
The Prototype pattern 345
Prototype — deep versus shallow copy 346
Prototype using metaclasses 347
Combining patterns using metaclasses 349
The Prototype factory 350
The Builder pattern 353
Patterns in Python — Structural 360
The Adapter pattern 360
The Facade pattern 370
Facades in Python 371
The Proxy pattern 377
An instance-counting proxy 378
Patterns in Python — Behavioral 381
The Iterator pattern 382
The Observer pattern 385
The State pattern 393
Summary 400
Chapter 8: Python — Architectural Patterns 403
Introducing MVC 404
Model Template View (MTV) — Django 406
Django admin — automated model-centric views 407
Flexible Microframework — Flask 409
Event-driven programming 411
Chat server and client using I/O multiplexing with the select module 411
Event-driven programming versus Concurrent programming 418
Twisted 420
Twisted — a simple web client 421
Chat Server using Twisted 422
Eventlet 428
Greenlets and Gevent 430
Microservice architecture 432
Microservice frameworks in Python 433
Microservices example — restaurant reservation 435
Microservices — advantages 438
Pipe and Filter architectures 438
Pipe and Filter in Python 439
Summary 445

=)
Ну у меня так скопилось 933 книги(2014-2017), но я отсилы прочитал полностью процентов 5-7%.
Обычно читаю содержание и потом интересные для меня главы, так наверно ещё просмотрел 10%, остальные в большем числе дальше содержание не смотрел.
С каждым днем сложней читать, интересней полазить почитать бложики чем сканировать книгу на наличие интереснотей.

с удовольствием послушают ответы отличные от — маслать 5 лет на разных сложных проектах и набираться мудрости

звичайно, досвід потрібен (головне щоб релевантний — можна 5 років якесь г..о колупати)
я б сказав, що бажано самому спроектувати і реалізувати від початку до кінця архітектуру кількох проектів, з наростаючою складністю.
паралельно вивчення архітектури проектів, з якими працюєш чи опенсорс.
якщо є людина, якій потім можна свій проект показати і вона розкаже про помилки — взагалі дуже добре.
ще можна взяти того ж Фаулера і по кусочкам розібрати, чому відповідають частини твоєї архітектури проекту «у класиків». Не можеш знайти відповідності — треба щось в консерваторії правити.

с удовольствием послушают ответы отличные от — маслать 5 лет на разных сложных проектах и набираться мудрости

Некоторые племена верят, что если съесть печень врага, то его опыт перейдет тебе. Думаю стоит попробовать. Если не получится, то вроде есть еще вариант с сердцем.

Подписаться на комментарии