Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Информацию вы вольны искать любым доступным способом, можете сами найти, может вам что-то передаст заказчик или предаставит специалистов, которые поделятся сакральными знаниями.
Вопрос был как лично Вы и Ваша команда это делаете.
Бухгалтерские отчеты - это типовая задача, для этого даже полуфабрикаты в виде 1С есть, а то и готовые конфигурации
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Универсальное правило о чем? Я вообще то наоборот говорю что все проекты разные поэтому градировать их на типовые и сложные или еще какие-то бесмысленно.
Для меня это звучит противоположно. Наверняка есть множество градаций той или иной меры кастомности и сложности. Но что именно вы хотите показать этим вопросом?
Что градировать проекты бессмысленно, в "типовом" проекте может появиться сложная задача и "сложный" проект может наполовину состоять из типовых задач.
Требования к приложению - это проекция хотелок заказчика на реалии приложения. Если эти хотелки можно реализовать лучше и/или дешевле иным образом, то требования нужно поменять. Это как раз одна из целей обсуждения с командой.
Вроде бы у меня была простая мысль а мы до сих пор не на одной волне.
Временные рамки сильно утрирированы, но поздние митинги (часов в 7-8 вечера по Мск) с заказчиком из США - это прям типичная ситуация. Кому-то нравится сдвинутый на вечер рабочий график, кому-то - нет.
Может быть и утрировано (хотя на одной из моих работа был близкий к этому график) но чтобы по Вашей логике все работало то вся команда как минимум должна любить сдвинутый вечер, иначе как она (команда) целиком будет встречаться с заказчиком?
Учитывая вашу дотошность, упомяну, что под предсказыванием будущего имеется в виду не "бл* буду точно произойдет!", а оценка вероятности возможных будущих событий, а также принятие соответствующих решений в тех случаях когда оценочная вероятность превышает, например, 50%
Уж простите за дотошность но обычно в контексте "предсказаний" единственный критерий их результата это "сбылось" или "не сбылось" причем он проверяется когда-то потом в будущем по факту сего действа. Все ладно не буду душнить сойдемся на том что это стоит все же более корректно называть "планирование будущего" чем предсказание :)
PO приходит с такой-то проблемой, а уже требования по тому, как эту проблему можно решить - обсуждается с командой и выводятся требования к задаче.
Еще раз - Обсуждают реализацию требований (т.е. как решить проблему с которой пришел заказчик) а не сами требования (то что заказчик пришел с этой проблемой в принципе и надо ли оно ему вообще). Не вижу здесь противоречий, Вы написали ту же мысль.
Вы утрируете. В той или иной степени навык предсказывания будущего есть у каждого. Да хоть на уровне "завтра настанет утро и я пойду на работу". А развитие этого навыка по отношению к проработке архитектуры достигается за счет знаний, опыта, набитых шишек, а также погружения в предметную область.
Это не навык предсказания будущего, это просто опыт. Навык предсказания будущего как раз был бы если бы Вы придя в новую для себя предметную область, новый тип проекта и новую область разработки могли что-то там "предсказать" и это работало.
Поэтому на достаточно сложных проектах обычно работают специально выделенные команды, а не мимопробегающие фрилансеры. А на типовых проектах - типовые сценарии развития, там настолько много внимания не требуется.
Ну т.е. "типовые" и "сложные" проекты никогда не пересекаются и существуют в каких-то разных мирах?
Вполне укладывается в концепции SCRUM, где вся команда на равных обсуждает требования с PO.
Обсуждают реализацию требований а не сами требования.
Средства связи в наше время уже достаточно неплохо развиты, чтобы устраивать телефонференции хоть через океаны и материки.
Ну окей Ваш заказчик доступен по Вашему местному времени с 23 до 3 часов ночи. Связь решила эту проблему? :)
что это за навык такой? как его развить? у Вас развит? Если да то расскажите сколько раз он Вам помог и в чем?
Это требует плотного погружения в предметную область, тесного общения с заказчиком и накопления некоторого багажа опыта.
Полное погружение в предметную область возможна при full time работе на одном проекте и прямые контакты всей команды с заказчиком что уже звучит мало реалистично и применимо скорее к продуктовым командам и финтеху (потому что и там и там заказчик обычно сидит если не в той же комнате то точно в том же здании).
Проблема этого явления кроется в том что многие люди считают что они знают будущее могут считать что легко угадают куда дальше пойдет то или иное решение. И действительно иногда это работает, и заранее подготовленная подушечка выручает через время, но бывает и наоборот. Я бы сказал что оптимальная практика в данном случае начинать решение задачи всегда с самого простого решения, да оно будет не расширяемым/оптимальным/т.п. но оно будет решать задачу на момент ее возникновения. Т.е. сегодня задача решить 2+2, делаем одну функцию которая просто делает 2+2 внутри. Через неделю бизнес понял что 2+2 не достаточно и надо решить задачу 2+2*x/100, окей мы вернулись к нашей функции и добавили параметр x и обновили формулу. Да пример примитивный но на самом деле в реальности такой подход довольно часто работает, я и сам его применяю. Новый модуль делается максимально просто потому что и бизнес не всегда понимает что в нем будет до конца, а потом по мере того как модуль начнет обрастать деталями можно рассмотреть какие подходы и паттерны могут помочь с его решением и если подходят то уже внедрять. Переписывать несколько раз новые модули это обычная практика. А вообще могу сказать что людей с похожими заболеваниями тоже много, например "Микросервис головного мозга" и "SOLID головного мозга".
::> "Большая часть из списка вымершая, к сожалению"
::< "К сожалению нет "
Не увидел там подзаголовка "Dead projects"
А если поиском?:)
но уже у Nuklear и NanoGUI последние коммиты были 6 лет назад :(
Отсутствие комитов не означает что проект умер. Возможно он перешел в состояние только поддержки или контрибуторы его забросили. Тем не менее если он проверен в продакшене то вероятно его используют до сих пор. Наверно косвенный признак это наличие ишьюсов и ответов на них, также наличие активных форков. Еще есть такой момент что не все компании берущие какой-то open source продукт к себе в репозиторий возвращают что-то обратно в open source. Например на своей прошлой работе у нас был форк Qt-а со своими фиксами, патчами и дополнениями и там у людей даже мысли не было вернуть хотя бы фиксы обратно.
К сожалению нет, вымершие живут в отдельной секции этого списка если Вы вдруг до него не спустились. В то время как выбор вполне не маленький даже из тех которые представлены в этом списке. К тому же это всего лишь один из списков, если поискать дальше то можно найти много больше. Я не знаю конечно какие у Вас требования к UI, но даже первой десятки должно хватить на вполне сложные проекты в плане UI. Не нравятся эти есть много других, например на Unreal Engine можно не только игры делать но и программы писать, их редактор как раз сделан на самом Unreal Engine. Есть другие варианты на других языках например на Lazarus/Free Pascal можно делать UI.
Тем не менее, по-настоящему кроссплатформенных фреймворков исчезающе мало, а «одноплатформенными» фреймворками по-прежнему продолжают пользоваться
Ну хорошо вот например только для C++ кроссплатформенные либы https://philippegroarke.com/posts/2018/c++_ui_solutions/ . А еще есть много на таких языках как go и rust, некоторые поддерживают даже мобильные платформы. Вы точно уверены что их "исчезающе мало"?
WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.
Создавался не для этого, но сейчас используется в том числе и как раннер для инструментов типа AutoPrefixer, Babel и прочих которые решают эту проблему.
Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?
Насчет дизайна вопрос спорный но все остальное да. Вроде бы никто не мешает использовать кроссплатформенные инструменты, библиотеки, генераторы и прочее чтобы упростить себе жизнь работая больше чем на одной платформе. Приложения для Android разрабатывают не только на Java а для Windows не только на C++. Я бы даже сказал что для современных языков и фреймворков кроссплатформенность это обязательное требование, никому уже не нужен фреймворк работающий на одной платформе. Тулинг скрывает большую часть сложности на всех поддерживаемых платформах а генераторы и/или слой совместимости обеспечивает то самое пресловутое write once run everythere с оговорками естественно, но тут как бы и Electron делает тоже самое с оговорками.
Для большинства организаций скорость вывода продукта на рынок продолжает являться более важным аспектом, нежели его эффективность.
Звучит если честно довольно дико, потому что эффективность в моем понимании это выполнение задач для которых было создано приложение и если оно (приложение) выполняет эти задачи не эффективно то встает очевидный вопрос о том нужно ли оно вообще.
История Electron началась не так давно — всего лишь в 2013 году. Ещё до распространения техники поставки веб-приложений в десктопных обёртках разработчики, как правило, писали полностью отдельные нативные решения для каждой платформы. Нужна поддержка Mac? Пишите на Objective-C или Swift и разбирайтесь с Cocoa. Хотите поддержку Windows? Готовьтесь попотеть над C++, C# или .NET. Linux? Ещё веселее. У каждой платформы свои парадигмы UI, идиомы кода и пайплайны сборки, так что согласованное обслуживание мультиплатформенных приложений было болью. Многим командам в итоге приходилось обслуживать по две, а то и три базы кода, каждая из которых имела свои тонкие отличия.
Довольно странное утверждение, ведь разработка для Web-а, особенно в 2013 году тоже была далека от кросс/браузерности/совместимости, иначе не существовали бы такие инструменты как AutoPrefixer, Babel, WebPack и прочие. Уже несколько лет стал доминировать один браузер что по сути довольно сильно расхолодило многих разработчик. Но в 2013 были времена когда легко можно было разрабатывая на Chrome открыть свой сайт на Safari и обнаружить какой-нибудь странный баг и наоборот. Это еще не считая разных режимов (типа для людей с ограниченными возможностями и поддержки RTL), разных экранов и много чего еще. Моя мысль в том что для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron, просто многим не хочется что-то изучать когда можно использоваться уже знакомое, создается иллюзия что ты получишь что-то очень дешево. Но опять же Electron не "серебряная пуля" и если надо что-то сложнее чем просто функционал Web вряд ли это будет работа на вечерок.
Webpack в свое время стал популярен потому что был проще в конфигурации чем его более возрастные конкуренты на тот момент. Vite сейчас молодой и пока не обросший сложностью инструмент, будем надеяться что его не постигнет судьба webpack-а через время.
Вопрос был как лично Вы и Ваша команда это делаете.
А что тогда не типовая задача?
Расскажите как происходит "полное погружение" в предметную область, мне серьезно интересно. Вот допустим сегодня Вы начинаете новый проект знания о предметной области которого у Вас равны нулю. Какие нужны действия команды для погружения? Допустим Ваш новый проект связан с бухгалтерией, Ваши знания ограничиваются что бухгалтерия это что-то связанное с расчетом денег (ну допустим). Допустим заказчик присылает Вам 200 отчетов которые должны генериться Вашим проектом с минимальными объяснениями на бухгалтерском языке, все отчеты разные и нужны для разного. Какие Ваши и команды действия по погружению в предметную область и сколько времени это может занять? Как будет распределение погружения между командой, и если да то как потом погруженные сведения будут передаваться между командой? И в целом как выглядит процесс?
Тоже неплохой вариант
Универсальное правило о чем? Я вообще то наоборот говорю что все проекты разные поэтому градировать их на типовые и сложные или еще какие-то бесмысленно.
Что градировать проекты бессмысленно, в "типовом" проекте может появиться сложная задача и "сложный" проект может наполовину состоять из типовых задач.
Вроде бы у меня была простая мысль а мы до сих пор не на одной волне.
Может быть и утрировано (хотя на одной из моих работа был близкий к этому график) но чтобы по Вашей логике все работало то вся команда как минимум должна любить сдвинутый вечер, иначе как она (команда) целиком будет встречаться с заказчиком?
Уж простите за дотошность но обычно в контексте "предсказаний" единственный критерий их результата это "сбылось" или "не сбылось" причем он проверяется когда-то потом в будущем по факту сего действа. Все ладно не буду душнить сойдемся на том что это стоит все же более корректно называть "планирование будущего" чем предсказание :)
Еще раз - Обсуждают реализацию требований (т.е. как решить проблему с которой пришел заказчик) а не сами требования (то что заказчик пришел с этой проблемой в принципе и надо ли оно ему вообще). Не вижу здесь противоречий, Вы написали ту же мысль.
Это не навык предсказания будущего, это просто опыт. Навык предсказания будущего как раз был бы если бы Вы придя в новую для себя предметную область, новый тип проекта и новую область разработки могли что-то там "предсказать" и это работало.
Ну т.е. "типовые" и "сложные" проекты никогда не пересекаются и существуют в каких-то разных мирах?
Обсуждают реализацию требований а не сами требования.
Ну окей Ваш заказчик доступен по Вашему местному времени с 23 до 3 часов ночи. Связь решила эту проблему? :)
что это за навык такой? как его развить? у Вас развит? Если да то расскажите сколько раз он Вам помог и в чем?
Полное погружение в предметную область возможна при full time работе на одном проекте и прямые контакты всей команды с заказчиком что уже звучит мало реалистично и применимо скорее к продуктовым командам и финтеху (потому что и там и там заказчик обычно сидит если не в той же комнате то точно в том же здании).
Проблема этого явления кроется в том что многие люди считают что они
знают будущеемогут считать что легко угадают куда дальше пойдет то или иное решение. И действительно иногда это работает, и заранее подготовленная подушечка выручает через время, но бывает и наоборот. Я бы сказал что оптимальная практика в данном случае начинать решение задачи всегда с самого простого решения, да оно будет не расширяемым/оптимальным/т.п. но оно будет решать задачу на момент ее возникновения. Т.е. сегодня задача решить 2+2, делаем одну функцию которая просто делает 2+2 внутри. Через неделю бизнес понял что 2+2 не достаточно и надо решить задачу 2+2*x/100, окей мы вернулись к нашей функции и добавили параметр x и обновили формулу. Да пример примитивный но на самом деле в реальности такой подход довольно часто работает, я и сам его применяю. Новый модуль делается максимально просто потому что и бизнес не всегда понимает что в нем будет до конца, а потом по мере того как модуль начнет обрастать деталями можно рассмотреть какие подходы и паттерны могут помочь с его решением и если подходят то уже внедрять. Переписывать несколько раз новые модули это обычная практика. А вообще могу сказать что людей с похожими заболеваниями тоже много, например "Микросервис головного мозга" и "SOLID головного мозга".::> "Большая часть из списка вымершая, к сожалению"
::< "К сожалению нет "
А если поиском?:)
Отсутствие комитов не означает что проект умер. Возможно он перешел в состояние только поддержки или контрибуторы его забросили. Тем не менее если он проверен в продакшене то вероятно его используют до сих пор. Наверно косвенный признак это наличие ишьюсов и ответов на них, также наличие активных форков. Еще есть такой момент что не все компании берущие какой-то open source продукт к себе в репозиторий возвращают что-то обратно в open source. Например на своей прошлой работе у нас был форк Qt-а со своими фиксами, патчами и дополнениями и там у людей даже мысли не было вернуть хотя бы фиксы обратно.
К сожалению нет, вымершие живут в отдельной секции этого списка если Вы вдруг до него не спустились. В то время как выбор вполне не маленький даже из тех которые представлены в этом списке. К тому же это всего лишь один из списков, если поискать дальше то можно найти много больше. Я не знаю конечно какие у Вас требования к UI, но даже первой десятки должно хватить на вполне сложные проекты в плане UI. Не нравятся эти есть много других, например на Unreal Engine можно не только игры делать но и программы писать, их редактор как раз сделан на самом Unreal Engine. Есть другие варианты на других языках например на Lazarus/Free Pascal можно делать UI.
https://slint.dev/ rust, https://github.com/cogentcore/core go
Ну хорошо вот например только для C++ кроссплатформенные либы https://philippegroarke.com/posts/2018/c++_ui_solutions/ . А еще есть много на таких языках как go и rust, некоторые поддерживают даже мобильные платформы. Вы точно уверены что их "исчезающе мало"?
Создавался не для этого, но сейчас используется в том числе и как раннер для инструментов типа AutoPrefixer, Babel и прочих которые решают эту проблему.
Насчет дизайна вопрос спорный но все остальное да. Вроде бы никто не мешает использовать кроссплатформенные инструменты, библиотеки, генераторы и прочее чтобы упростить себе жизнь работая больше чем на одной платформе. Приложения для Android разрабатывают не только на Java а для Windows не только на C++. Я бы даже сказал что для современных языков и фреймворков кроссплатформенность это обязательное требование, никому уже не нужен фреймворк работающий на одной платформе. Тулинг скрывает большую часть сложности на всех поддерживаемых платформах а генераторы и/или слой совместимости обеспечивает то самое пресловутое write once run everythere с оговорками естественно, но тут как бы и Electron делает тоже самое с оговорками.
Сильное заявление, и Вы конечно же можете его подтвердить ссылкой на бенчмарки?
Звучит если честно довольно дико, потому что эффективность в моем понимании это выполнение задач для которых было создано приложение и если оно (приложение) выполняет эти задачи не эффективно то встает очевидный вопрос о том нужно ли оно вообще.
Довольно странное утверждение, ведь разработка для Web-а, особенно в 2013 году тоже была далека от кросс/браузерности/совместимости, иначе не существовали бы такие инструменты как AutoPrefixer, Babel, WebPack и прочие. Уже несколько лет стал доминировать один браузер что по сути довольно сильно расхолодило многих разработчик. Но в 2013 были времена когда легко можно было разрабатывая на Chrome открыть свой сайт на Safari и обнаружить какой-нибудь странный баг и наоборот. Это еще не считая разных режимов (типа для людей с ограниченными возможностями и поддержки RTL), разных экранов и много чего еще. Моя мысль в том что для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron, просто многим не хочется что-то изучать когда можно использоваться уже знакомое, создается иллюзия что ты получишь что-то очень дешево. Но опять же Electron не "серебряная пуля" и если надо что-то сложнее чем просто функционал Web вряд ли это будет работа на вечерок.
Если Вы в одиночку занимаетесь проектом?