Вхід і реєстрація
Навчання · 8 лютого 2018, 19:38 6785
No Name

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

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

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

Теми: архітектура
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Vlad Stelmahovsky Software Engineer в Verity AG 14.02.2018 13:58

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

Відповісти
Підтримати
Дмитрий Вежнин 14.02.2018 11:06

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

Відповісти
Підтримати
Sereban 14.02.2018 10:52

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

Відповісти
Підтримати
Олександр Шпак Oarsman в Self Employed 14.02.2018 10:55

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

Відповісти
Підтримати
Sereban
Alex Fogol Software Developer, C/C++ Expert 14.02.2018 13:48

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

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

Відповісти
Підтримати
Олександр Шпак
Vitaliy Fedoriv Java Developer 14.02.2018 15:26

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

Відповісти
Підтримати
Alex Fogol
Vlad Stelmahovsky Software Engineer в Verity AG 14.02.2018 15:40

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

Відповісти
Підтримати
Vitaliy Fedoriv
Grez 14.02.2018 23:22

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

Відповісти
Підтримати
Sereban
Oleg Kariakin Senior Java Developer 12.02.2018 08:39
Я Front-End Разоработчки с чуток опыта.
Дайте совет как прокачать скилл архитектора...И нужно ли это вообще джуну...мидлу?

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

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

Відповісти
Підтримати
De Money 13.02.2018 23:28

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

Відповісти
Підтримати
anonymous
Vasya Pupking 11.02.2018 22:44

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

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

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

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

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

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

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

и тп

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

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

Відповісти
Підтримати
TechnoBarbarian 11.02.2018 23:13

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 12.02.2018 00:36
Без команды архитекторов, во главе с Solution Architect или CTO, которые коллективно проектируют систему

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

Відповісти
Підтримати
TechnoBarbarian
Кодерок 12.02.2018 02:48
Основной мой посыл, что я хотел донести, что архитектор это больше, чем разбиение кода на классы.

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

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

Відповісти
Підтримати
Vasya Pupking
TechnoBarbarian 12.02.2018 21:26
будет работать на более высоком уровне, в т.ч. ходя и на сторону сервера, чтоб вместе с серверными архитекторами работать над моделью данных, протоколами взаимодействия и тп и тд.

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 12.02.2018 23:06

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

JS, HTML, CSS

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

Photoshop, After Effects, iMovie, Adobe Audition etc

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

Відповісти
Підтримати
TechnoBarbarian
anonymus ps 13.02.2018 05:34

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

Відповісти
Підтримати
Vasya Pupking
anonymus ps 12.02.2018 02:33

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

Відповісти
Підтримати
Vasya Pupking
Alex Fogol Software Developer, C/C++ Expert 12.02.2018 04:37
то это сделает и дев.

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

Відповісти
Підтримати
anonymus ps
anonymus ps 12.02.2018 05:59

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

Відповісти
Підтримати
Alex Fogol
Alex Fogol Software Developer, C/C++ Expert 12.02.2018 06:03

аркитект ))

Відповісти
Підтримати
anonymus ps
anonymus ps 12.02.2018 06:05

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

Відповісти
Підтримати
Alex Fogol
Alexandr Sova Developer 13.02.2018 19:54

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

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

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

  • нет возможности перезапросить состояние внешней системы или
  • вы не знаете каким образом сообщение влияет на состояние системы чтоб понять по состоянию, доставлено оно иои нет
Действительно интересно.
Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 13.02.2018 20:32

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

Відповісти
Підтримати
Alexandr Sova
Alexandr Sova Developer 14.02.2018 05:20

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

Відповісти
Підтримати
Vasya Pupking
Sereban 14.02.2018 10:56

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

Відповісти
Підтримати
Vasya Pupking
Valentin Nechayev уповноважений по милицях в Дарницькі печери 14.02.2018 14:52

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

Відповісти
Підтримати
Sereban
Vasya Pupking 14.02.2018 20:13

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

Відповісти
Підтримати
Valentin Nechayev
Vasya Pupking 14.02.2018 20:14

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

Відповісти
Підтримати
Sereban
VE 14.02.2018 20:28

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

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

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

Відповісти
Підтримати
Sereban
Grez 13.02.2018 23:03
Очень редко бывают системы, где нужен только юай (я даже не могу ни одного примера представить), по этому станно звучит «юай архитект»

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

Відповісти
Підтримати
Vasya Pupking
Valentin Nechayev уповноважений по милицях в Дарницькі печери 14.02.2018 14:46
Ворд

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

иксель

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

фотошоп

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

итд итп

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

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

Відповісти
Підтримати
Grez
Grez 13.02.2018 23:15
Как видите, тут были и bd, и UI и сервер и интеграция и выяснение требований и тп и тд.

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

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 14.02.2018 01:34

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

Відповісти
Підтримати
Grez
anonymus ps 14.02.2018 07:08

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

Відповісти
Підтримати
Vasya Pupking
Grez 14.02.2018 08:12

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

Відповісти
Підтримати
anonymus ps
anonymus ps 14.02.2018 08:32

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

Відповісти
Підтримати
Grez
Vasya Pupking 14.02.2018 20:19

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

Відповісти
Підтримати
anonymus ps
Sereban 14.02.2018 10:54

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

Відповісти
Підтримати
Vasya Pupking
Олександр Шпак Oarsman в Self Employed 10.02.2018 23:07

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

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

Відповісти
Підтримати
Олександр Шпак Oarsman в Self Employed 12.02.2018 00:21

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

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

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

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

Відповісти
Підтримати
anonymous
Artyom Krivokrisenko 12.02.2018 02:03
Якщо система сама слідкує за своїм станом, то її тестування буде проводитися по всіх трьох напрямках, при чому постійно.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 08:15

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

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 12.02.2018 08:17

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 08:26
я подсознательно хочу верить, что вы понимаете, о чем говорите. просто у вас слово «тестирование» с чем-то другим ассоциируется.

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

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

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

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

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

Відповісти
Підтримати
anonymous
anonymus ps 12.02.2018 08:40

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 09:08

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

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

Відповісти
Підтримати
anonymus ps
Artyom Krivokrisenko 12.02.2018 09:26

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 10:34

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

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 12.02.2018 11:19

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 13:03

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

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 13.02.2018 03:06

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 13.02.2018 08:40

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

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

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

Відповісти
Підтримати
Artyom Krivokrisenko
anonymus ps 12.02.2018 09:34

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 10:43

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

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

Відповісти
Підтримати
anonymus ps
anonymus ps 12.02.2018 10:58

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

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

Відповісти
Підтримати
Олександр Шпак
Vitaliy Fedoriv Java Developer 12.02.2018 11:14
Тестування буває різним. Але мова не про те, які варіанти тестування існують та коли їх треба приміняти, а про те, як будувати систему, яка це не потребує. Ви відчуваєте різницю в постановці задачі? Я вам намалював ідеал, не обов’язково його досягати, але це не значить, що до нього не треба йти.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 11:18

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

Відповісти
Підтримати
Vitaliy Fedoriv
Олександр Шпак Oarsman в Self Employed 12.02.2018 13:04

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

Відповісти
Підтримати
Artyom Krivokrisenko
Vitaliy Fedoriv Java Developer 12.02.2018 11:31
HTML браузера

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 13:04

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

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

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

Відповісти
Підтримати
Олександр Шпак
Valentin Nechayev уповноважений по милицях в Дарницькі печери 12.02.2018 15:30
Парсер обробляє помилки відповідно до специфікації, описаної в HTML-стандарті:

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

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

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

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

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

Відповісти
Підтримати
Vitaliy Fedoriv
Олександр Шпак Oarsman в Self Employed 12.02.2018 15:33

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

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

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

Відповісти
Підтримати
Vitaliy Fedoriv
Олександр Шпак Oarsman в Self Employed 12.02.2018 19:50

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

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

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 13.02.2018 09:40
то фактически контр пример вашему

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

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

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

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

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 12.02.2018 13:15
Просто ваши формулировки очень смахивают на то, что вы не сильно понимаете процесс поставки продукта.

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

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

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 12.02.2018 13:48
спойлер: вы начали с оценочного суждения, перехода на личности и додумывания за собеседника..

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 12.02.2018 19:44
так пример у вас есть?

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 12.02.2018 20:04
набір базових хендлерів, які викликаються при розповсюдженні події в певній структурі
Наявність або відсутність структури не впливає на загальний процес виконання

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

Відповісти
Підтримати
Олександр Шпак
Vitaliy Fedoriv Java Developer 12.02.2018 23:14

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 12.02.2018 23:48

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

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

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

Відповісти
Підтримати
Vitaliy Fedoriv
Олександр Шпак Oarsman в Self Employed 13.02.2018 09:34
1. как этот подход упрощает тестирование? там же нельзя разделить логику от вида?

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

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

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

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

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

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

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

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

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

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 10:30
можно всю жизнь потом дебажить, кто и что поменял, и как оно повлияло на другие компоненты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відповісти
Підтримати
anonymous
Valentin Nechayev уповноважений по милицях в Дарницькі печери 12.02.2018 15:33

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 13.02.2018 00:05

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

Відповісти
Підтримати
Valentin Nechayev
Vadim Kopanev Architect 13.02.2018 23:11

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:12

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:28
Что за каша у вас в голове, скрипты юникса это тулзы

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

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

Ні.

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

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:50

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 10:37
И соответственно изменоустойчивость юникса будет определяться тем как гибко система будет адаптироваться к новому железу

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

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

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

Відповісти
Підтримати
anonymous
Vadim Kopanev Architect 14.02.2018 03:05

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

Відповісти
Підтримати
anonymous
Vadim Kopanev Architect 14.02.2018 03:22
ухудшает перформанс

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

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

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

Відповісти
Підтримати
anonymous
Vadim Kopanev Architect 14.02.2018 03:38

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 13.02.2018 23:33

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:17

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:37

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:53
что бы проектировать систему с упором на это качество — нужны обоснования для этого

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

Відповісти
Підтримати
anonymous
Олександр Шпак Oarsman в Self Employed 14.02.2018 10:44

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

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

Відповісти
Підтримати
anonymous
Artyom Krivokrisenko 15.02.2018 21:21
Та, як однією із задач, яку можна було б спробувати вирішити, була задача побудови системи, в якій тестування займало мінімум часу.

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 15.02.2018 21:57
Если все покрыть тестами, то тестирование вообще не занимает времени.

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

Відповісти
Підтримати
Artyom Krivokrisenko
Max Shnurenok .NET Architect в LogiqApps 15.02.2018 22:15

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

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 13.02.2018 23:47

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

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

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

Відповісти
Підтримати
anonymous
Max Shnurenok .NET Architect в LogiqApps 14.02.2018 00:18

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

Відповісти
Підтримати
Олександр Шпак
Олександр Шпак Oarsman в Self Employed 14.02.2018 00:48
Но, если всё действительно очень плохо, то вполне возможно, что стоит поднажать на тесты, если их не хватает, а затем уже переходить к разгребанию.

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

Відповісти
Підтримати
Max Shnurenok
Max Shnurenok .NET Architect в LogiqApps 14.02.2018 08:04
Ви вирішили замінити цей шматок коду на інший, який використовує взагалі сторонній сервіс для прийняття рішення. Сенс в покритті тестами вмираючого рішення?

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

Відповісти
Підтримати
Олександр Шпак
Max Shnurenok .NET Architect в LogiqApps 14.02.2018 09:13
связанность кода

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

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

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

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

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

Відповісти
Підтримати
anonymous
proger 10.02.2018 20:12

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

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

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

Відповісти
Підтримати
Dmytro Shchurov Frontend/React Developer в KAJO s.r.o. 09.02.2018 20:43

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

Відповісти
Підтримати
flyman 09.02.2018 12:46

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

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

Відповісти
Підтримати
Artyom Krivokrisenko 09.02.2018 05:40

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

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

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

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

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

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

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

Відповісти
Підтримати
Alex Fogol Software Developer, C/C++ Expert 10.02.2018 09:43

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

Відповісти
Підтримати
anonymous
Ivan Boyaryn Senior Big Data Engineer в Ciklum 10.02.2018 18:27

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

Відповісти
Підтримати
Artyom Krivokrisenko
anonymous 09.02.2018 04:53

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

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

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

Відповісти
Підтримати
Кодерок 09.02.2018 01:05
Как качать скилл архитектора?

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

Відповісти
Підтримати
Нестор Иванович 09.02.2018 00:11

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

Відповісти
Підтримати
Vasya Pupking 09.02.2018 00:44

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

Відповісти
Підтримати
Нестор Иванович
Нестор Иванович 09.02.2018 01:52

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

Відповісти
Підтримати
anonymous
Vasya Pupking 09.02.2018 04:48

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

Відповісти
Підтримати
anonymous
Нестор Иванович 09.02.2018 04:11

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 09.02.2018 02:08

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

Відповісти
Підтримати
Нестор Иванович
Нестор Иванович 09.02.2018 04:12

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

Відповісти
Підтримати
Vasya Pupking
Vasya Pupking 08.02.2018 20:14

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

Відповісти
Підтримати
Sergii Voloshyn Product Manager в DOU.ua 08.02.2018 21:36

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

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.

Відповісти
Підтримати
Vasya Pupking
Vitaliy Fedoriv Java Developer 08.02.2018 22:20

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 08.02.2018 22:40
мы абсуждаем фронт-енд архитектора

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

Відповісти
Підтримати
anonymous
Vasya Pupking 08.02.2018 23:09

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

Відповісти
Підтримати
anonymous
Vasya Pupking 09.02.2018 00:42

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

Відповісти
Підтримати
anonymous
Vasya Pupking 08.02.2018 23:10

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

Відповісти
Підтримати
anonymous
Vasya Pupking 09.02.2018 00:44

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

Відповісти
Підтримати
anonymous
Vasya Pupking 09.02.2018 00:57

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

Відповісти
Підтримати
anonymous
Grez 10.02.2018 19:33

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

Відповісти
Підтримати
anonymous
Ivan Boyaryn Senior Big Data Engineer в Ciklum 10.02.2018 19:07

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

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

Відповісти
Підтримати
Vasya Pupking
Grez 10.02.2018 19:35
Хоча я бачив і такі проекти, де архітектура була створена явно людиною без достатнього досвіду у цьому..

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

Відповісти
Підтримати
Ivan Boyaryn
Vasya Pupking 11.02.2018 21:54
Senior може ... не вміти вибирати архітектуру.

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

Відповісти
Підтримати
Ivan Boyaryn
flyman 12.02.2018 12:40

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

Відповісти
Підтримати
Vasya Pupking
Ivan Boyaryn Senior Big Data Engineer в Ciklum 12.02.2018 18:53

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

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

Відповісти
Підтримати
Vasya Pupking
Mobile 10.02.2018 01:15

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

Відповісти
Підтримати
Vasya Pupking
Dmitriy Chaban 10.02.2018 09:31

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

Відповісти
Підтримати
Mobile
Vasya Pupking 11.02.2018 21:55

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

Відповісти
Підтримати
Mobile
Alex Fogol Software Developer, C/C++ Expert 10.02.2018 09:45

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

Відповісти
Підтримати
anonymous
Grez 10.02.2018 19:43

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

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 09.02.2018 00:29

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

Відповісти
Підтримати
anonymus ps
Rostislav Nikitin .NET Senior Developer в Freelancer 09.02.2018 13:23

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

Відповісти
Підтримати
Vasya Pupking
Vitaliy Fedoriv Java Developer 09.02.2018 14:04

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

Відповісти
Підтримати
Rostislav Nikitin
Rostislav Nikitin .NET Senior Developer в Freelancer 09.02.2018 15:45
HelloWorld.exe — це також application. Чи значить це, що там є архітектура ?

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

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

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

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

Відповісти
Підтримати
Vitaliy Fedoriv
Vasya Pupking 09.02.2018 20:29

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

Відповісти
Підтримати
Rostislav Nikitin
Rostislav Nikitin .NET Senior Developer в Freelancer 09.02.2018 22:52

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

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

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

Відповісти
Підтримати
Vasya Pupking
Dmitriy Chaban 09.02.2018 23:47

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

Відповісти
Підтримати
Rostislav Nikitin
Rostislav Nikitin .NET Senior Developer в Freelancer 10.02.2018 00:19

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

Відповісти
Підтримати
Dmitriy Chaban
Vasya Pupking 11.02.2018 21:59
Тебе как девелоперу дают уже существующий API, и говорят — сделай фронт энд. API ты менять не можешь, можешь только его осознать. Следовательно ты проектируешь архитектуру фронт энда для уже существующего BackEnd API.

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

Відповісти
Підтримати
Rostislav Nikitin
Bot Bot 12.02.2018 00:03

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

Відповісти
Підтримати
Vasya Pupking
Rostislav Nikitin .NET Senior Developer в Freelancer 12.02.2018 14:14

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

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

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

Відповісти
Підтримати
Vasya Pupking
Max Shnurenok .NET Architect в LogiqApps 09.02.2018 23:52

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

Відповісти
Підтримати
Rostislav Nikitin
Grez 10.02.2018 19:51
Ну вообще-то на дворе 21-ый век и уже во всю создаются SPA.

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

Відповісти
Підтримати
Rostislav Nikitin
Rostislav Nikitin .NET Senior Developer в Freelancer 10.02.2018 22:23

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

Відповісти
Підтримати
Grez
Vitaliy Fedoriv Java Developer 08.02.2018 22:23

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

Відповісти
Підтримати
code monkey
anonymous 09.02.2018 04:57

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

Відповісти
Підтримати
code monkey
Vladimir Danylevsky Python Developer в Django Stars 08.02.2018 20:20
Software Architecture with Python

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

Відповісти
Підтримати
anonymous
Vladimir Danylevsky Python Developer в Django Stars 08.02.2018 21:13

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 08.02.2018 23:03
с удовольствием послушают ответы отличные от — маслать 5 лет на разных сложных проектах и набираться мудрости

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

Відповісти
Підтримати
anonymous
Serhii Cherepanov ... 09.02.2018 18:40
с удовольствием послушают ответы отличные от — маслать 5 лет на разных сложных проектах и набираться мудрости

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

Відповісти
Підтримати
anonymous

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.