Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит
Мой коммент был именно к
Разработка это индивидуальный вид спорта
про то, что всё сделать один человек не может и не должен (его ресурса не хватит).
нужно взаимодействие между исполнителями и делегирование.
Возможно меня несколько понесло выше и я не донёс эту мысль...
_____
А в вашем примере про три команды с разными менеджерами отсутствует владелец фичи. Исполнители есть, а ответственного нет, все отказываются под разными предлогами. Непорядок. Тут до разработки то дело не дойдет, разработчикам обсуждать даже нечего ещё. Мои комменты выше были уже к ситуации когда ресурсы имеются, за работу взялись, только что именно делать непонятно. И что это не должен решать один человек, в силу ограниченности его ресурсов (по времени, в основном).
В истории про три занятых команды по идее нужен некий владелец фичи (знает какой нужен результат и отвечает за него).
А его задача уже определить исполнителей (те три отдела), найти им ресурсы для выполнения задачи и контролировать процесс. Если ресурсов всё равно нет, то кто-то ответственный раздул скоуп задач больше чем возможности команд. Вопросы к составителю плана, надо решать, переприотеризировать задачи, что-то двигать в очередности или исключать из плана (что-то старое или эту новую задачу, смотря у чего приоритет выше)
Мне думается что это максимально похоже на плановую/рыночную экономики.
Партия владеет всей информацией по всем заводам и, конечно же, лучше знает как правильно и эффективно распорядиться ресурсами. Если заводам что-то надо, они идут к партии и обсуждают каких им запчастей нехватает. Партия пишет план, всё довольны. Между собой заводам общаться не надо, вредно. Ещё план нарушат идеальный.
Тем более что ассортимент давно известен, всем понятно какие трубы надо делать и из чего. Архитектура считай известна.
Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.
Это протокол, описание API ещё предстоит разработать
Садится архитектор
Фулстек фронт-бэк-дизайнер-аналитик? Который станет бюрократичным бутылочным горлышком для любого мелкого согласования? И будет эдаким почтальоном Печкиным.
Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.
Всё таки задача архитектора - дать направление и контролировать, что всё делается согласно общей задумке, а не прописывать в камне каждый пункт до мелочей.
Если же не в камне, то будут правки - надо обсуждать.
Вообще, архитектору из вашего примера неплохо было бы научиться делегировать.
распарить данные внешнего источника (какой-нибудь гос.базы тендеров или продуктов)
Обработать данные, извлечь нужное, что-то посчитать
Правильно сохранить в бд
Предоставить фронту API
Удобно и красиво это отрисовать
Совещающиеся:
Дата сайнтист - знает что извлечь из внешней бд, что посчитать на основе этих данных
Ведущий бэкендер - с него информация о том как парсить, реализовать эффективно то что сделал датасайнтист, хранить в бд, реализация API
По отрисовке нужен дизайнер.
Ещё нужен фронтендер которому получать данные из API и делать то что сделал дизайнер.
Тут, конечно, есть задачи где не надо совещаться (фронтендер и бэкендер сами свой код пишут).
Но вот всё что на стыках - это придется обсуждать, если только у вас не фулстек фронт-бэк-дизайнер-аналитик.
Что обсуждать:
А удобна ли предложенная схема API и фронту и бэку, удастся ли с такой схемой сделать приятное для пользователя приложение? (Мне тут неделю назад без совещаний втихую запили супер апишку, где каждое поле формы обновляется отдельным запросом. Пачкой в транзакции не обновить).
То что нарисовал дизайнер - это удобно делается на фронте, или странная не очень нужная хотелка, увеличивающая срок реализации в разы?
А на бэке? Как мне это считать и хранить? Как синхронизировать? Почему так? А можем по-другому считать?
Ой, в дело ещё вступил сисадмин и с ним ещё придется обсуждать какие бд и как можно использовать, где хостить парсеры. А то тут какие-то требования по безопасности, сертификации, бюджеты.
Наконец, и бэкендер с фронтендером у нас не в единственном числе. Оказывается что на фронте есть ведущий разраб который радостно запили архитектуру апишки, но вопросы по дизайну он как-то привык делегировать бывшему дизайнеру-верстальщику, а теперь мидлу-разработчику. У него тут экспертизы внезапно больше.
Короче, я к чему, то что в статье обсуждается, это не про собрать 20 человек, включая уборщиц, в одной комнате и за час решить. Это серия совещаний, на каждом несколько заинтересованных человек.
Правильно организовать такие группы для совещаний - задача сама по себе.
Ещё и результаты работы этих групп координировать. Тут, допустим,некий ответственный за фичу в целом. И этот ответственный не мог за всех вышеперечисленных диктовать все условия.
>>> Заметил, что люди с “синдромом отличника” делают гораздо больше ошибок. Человек-радикальный-перфекционист тратит много времени на мелочи вместо того, чтобы добавить ценности продукту и приблизить компанию к цели.
Из первого вообще следует второе? Или это две разных проблемы?
Есть хакер, делает не очень законные вещи (в тексте указано). Ребята вместо подачи на него в суд, решили предложить ему работу.
Если они на него давили и шантажировали, это статья, можно подать в суд, выиграть его, и тогда Нинтендо — сволочи.
А если они всё таки вели переговоры вместо немедленной подачи в суд — то уже не так плохо.
По обрывкам инфы из статьи не хотелось бы громко обвинять любую сторону в чем-то.
Ну там есть нюанс что цена на букинге идёт с комиссией платформы.
И нет возможности продать где-то дешевле, если в этом где-то комиссия ниже.
Фактически букинг требует завышать цены на других платформах до уровня букинга, или не пользоваться букингом
Или скажем нужно импортировать какое-то имя класса из другого модуля. А нельзя. Точка. Они полностью независимы.
Можно подробнее кейс? import styles from "shared.module.css" валидная конструкция, так можно делать хоть в нескольких файлах. А что тогда подразумевается под "А нельзя. Точка."?
Сайт огорожен кармой и желание комментировать хорошие статьи сразу пропадает, когда тебе говорят что ты «не полноправный».
Обилие этих маркетинговых статей с низким качеством, но большим рейтингом… Не хочется писать комментарии к таким статьям, скорее всего там «не моя аудитория».
Хорошо, 2 параллельных запроса, но с синхронным ожиданием их результата.
Ваше утверждение про неуловимые исключения по-прежнему не соответствует коду
await2 отработает как unhandled rejection. И мы не сможем поймать ошибку (которая reject(error) внутри await2) в try-catch выше по стеку.
async function test(){
const await1 = new Promise((res) => setTimeout(res, 1000));
const await2 = new Promise((_, rej) => setTimeout(()=>rej(new Error("myError")), 500));
console.log("1"); // я буду выведена в консоль сразу
await await1;
console.log("2"); // я только через 1000 мс
await await2; // я выкину ошибку, которая была создана 500 мс назад
console.log("3"); // меня не напечатают
}
async function test2(){
try{
await test();
} catch(err){
console.log("Catched!", err); // Ошибка из await2
}
}
Ещё можно было внутри test сделать try catch, тоже бы сработал. Я полностью согласен, что Promise.all тот самый правильный способ для параллельных запросов, но не мог не заметить ошибку про потерянные исключения. Хотя она встречается если забыть await
async function badAsync(){
await await1; // стартовал первый промис
// первый промис выполняется, второй ещё нет, ждём
// первый промис зарезолвился через 1000 мс
await await2; // первый уже зарезолвился, стартовали второй
// ждём второй
// второй падает через 500 мс
}
async function test(){
try{
await badAsync();
} catch(err){
// поймали reject от await2 через 1500мс
}
}
Итого через 1500 мс я поймал ошибку от второго промиса, и по-моему это корректно, так как я по каким-то причинам не мог выполнить второй запрос параллельно с первым (например ожидал его результата). Ничего не потерял, или Вы о чём-то другом?
Для меня
Пока мы ждем await await1, мы НЕ ждем await await2. Таким образом, await2 отработает как unhandled rejection
Звучит как минимум странно, потому что мы ещё не дошли до вызова и выполнения await2 при последовательном вызове, и потому он не мог выполниться раньше. И уж тем более он ни как не мог стать unhandled rejection
Это нельзя переложить на плечи компилятора, указав только имена и типы полей структуры?
"Глобальные переменные - плохо", тут мало кто спорит. Глобальные имена классов из css - почему-то часто.
Представил бы я современный проект, где заранее создан список имён переменных и используется гит для контроля их уникальности
в загнивающей президент толкал вот такие речи про айти
https://youtu.be/6XvmhE1J9PY
Шикарно будет, когда на код/публичный интерфейс Серёжи ещё пару отделов завяжутся и потом обратно-совместимо это поддерживать.
Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит
Мой коммент был именно к
про то, что всё сделать один человек не может и не должен (его ресурса не хватит).
нужно взаимодействие между исполнителями и делегирование.
Возможно меня несколько понесло выше и я не донёс эту мысль...
_____
А в вашем примере про три команды с разными менеджерами отсутствует владелец фичи. Исполнители есть, а ответственного нет, все отказываются под разными предлогами. Непорядок. Тут до разработки то дело не дойдет, разработчикам обсуждать даже нечего ещё. Мои комменты выше были уже к ситуации когда ресурсы имеются, за работу взялись, только что именно делать непонятно. И что это не должен решать один человек, в силу ограниченности его ресурсов (по времени, в основном).
В истории про три занятых команды по идее нужен некий владелец фичи (знает какой нужен результат и отвечает за него).
А его задача уже определить исполнителей (те три отдела), найти им ресурсы для выполнения задачи и контролировать процесс. Если ресурсов всё равно нет, то кто-то ответственный раздул скоуп задач больше чем возможности команд. Вопросы к составителю плана, надо решать, переприотеризировать задачи, что-то двигать в очередности или исключать из плана (что-то старое или эту новую задачу, смотря у чего приоритет выше)
Мне думается что это максимально похоже на плановую/рыночную экономики.
Партия владеет всей информацией по всем заводам и, конечно же, лучше знает как правильно и эффективно распорядиться ресурсами. Если заводам что-то надо, они идут к партии и обсуждают каких им запчастей нехватает. Партия пишет план, всё довольны. Между собой заводам общаться не надо, вредно. Ещё план нарушат идеальный.
Тем более что ассортимент давно известен, всем понятно какие трубы надо делать и из чего. Архитектура считай известна.
Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.
Это новая фича, формата ещё нет.
Это протокол, описание API ещё предстоит разработать
Фулстек фронт-бэк-дизайнер-аналитик? Который станет бюрократичным бутылочным горлышком для любого мелкого согласования? И будет эдаким почтальоном Печкиным.
Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.
Всё таки задача архитектора - дать направление и контролировать, что всё делается согласно общей задумке, а не прописывать в камне каждый пункт до мелочей.
Если же не в камне, то будут правки - надо обсуждать.
Вообще, архитектору из вашего примера неплохо было бы научиться делегировать.
Пример: новая фича, вывести данные фичи в админку
Нужно:
распарить данные внешнего источника (какой-нибудь гос.базы тендеров или продуктов)
Обработать данные, извлечь нужное, что-то посчитать
Правильно сохранить в бд
Предоставить фронту API
Удобно и красиво это отрисовать
Совещающиеся:
Дата сайнтист - знает что извлечь из внешней бд, что посчитать на основе этих данных
Ведущий бэкендер - с него информация о том как парсить, реализовать эффективно то что сделал датасайнтист, хранить в бд, реализация API
По отрисовке нужен дизайнер.
Ещё нужен фронтендер которому получать данные из API и делать то что сделал дизайнер.
Тут, конечно, есть задачи где не надо совещаться (фронтендер и бэкендер сами свой код пишут).
Но вот всё что на стыках - это придется обсуждать, если только у вас не фулстек фронт-бэк-дизайнер-аналитик.
Что обсуждать:
А удобна ли предложенная схема API и фронту и бэку, удастся ли с такой схемой сделать приятное для пользователя приложение? (Мне тут неделю назад без совещаний втихую запили супер апишку, где каждое поле формы обновляется отдельным запросом. Пачкой в транзакции не обновить).
То что нарисовал дизайнер - это удобно делается на фронте, или странная не очень нужная хотелка, увеличивающая срок реализации в разы?
А на бэке? Как мне это считать и хранить? Как синхронизировать? Почему так? А можем по-другому считать?
Ой, в дело ещё вступил сисадмин и с ним ещё придется обсуждать какие бд и как можно использовать, где хостить парсеры. А то тут какие-то требования по безопасности, сертификации, бюджеты.
Наконец, и бэкендер с фронтендером у нас не в единственном числе. Оказывается что на фронте есть ведущий разраб который радостно запили архитектуру апишки, но вопросы по дизайну он как-то привык делегировать бывшему дизайнеру-верстальщику, а теперь мидлу-разработчику. У него тут экспертизы внезапно больше.
Короче, я к чему, то что в статье обсуждается, это не про собрать 20 человек, включая уборщиц, в одной комнате и за час решить. Это серия совещаний, на каждом несколько заинтересованных человек.
Правильно организовать такие группы для совещаний - задача сама по себе.
Ещё и результаты работы этих групп координировать. Тут, допустим,некий ответственный за фичу в целом. И этот ответственный не мог за всех вышеперечисленных диктовать все условия.
>>> Заметил, что люди с “синдромом отличника” делают гораздо больше ошибок. Человек-радикальный-перфекционист тратит много времени на мелочи вместо того, чтобы добавить ценности продукту и приблизить компанию к цели.
Из первого вообще следует второе? Или это две разных проблемы?
Есть хакер, делает не очень законные вещи (в тексте указано). Ребята вместо подачи на него в суд, решили предложить ему работу.
Если они на него давили и шантажировали, это статья, можно подать в суд, выиграть его, и тогда Нинтендо — сволочи.
А если они всё таки вели переговоры вместо немедленной подачи в суд — то уже не так плохо.
По обрывкам инфы из статьи не хотелось бы громко обвинять любую сторону в чем-то.
Заголовок очерняет Нинтендо
А по тексту они вроде даже не то чтобы сволочи, а может даже и молодцы
Ну там есть нюанс что цена на букинге идёт с комиссией платформы.
И нет возможности продать где-то дешевле, если в этом где-то комиссия ниже.
Фактически букинг требует завышать цены на других платформах до уровня букинга, или не пользоваться букингом
Фронтендеры тоже вспомнили про пролог.
https://next.yarnpkg.com/features/constraints
Хм, да, в этом случае нельзя по той самой идеалогии. Может и к лучшему, что нельзя
Анимация либо глобальная, либо дубляж. Логично
Можно подробнее кейс?
import styles from "shared.module.css"валидная конструкция, так можно делать хоть в нескольких файлах. А что тогда подразумевается под "А нельзя. Точка."?Думаю что
Maybe<T>В итоге идиотократия.
Я не случайно в
rejectдобавил ошибку к вашему коду, а потом залогировал то, что я поймал вtest2.Хорошо, 2 параллельных запроса, но с синхронным ожиданием их результата.
Ваше утверждение про неуловимые исключения по-прежнему не соответствует коду
Ещё можно было внутри
testсделать try catch, тоже бы сработал. Я полностью согласен, что Promise.all тот самый правильный способ для параллельных запросов, но не мог не заметить ошибку про потерянные исключения. Хотя она встречается если забыть awaitИтого через 1500 мс я поймал ошибку от второго промиса, и по-моему это корректно, так как я по каким-то причинам не мог выполнить второй запрос параллельно с первым (например ожидал его результата). Ничего не потерял, или Вы о чём-то другом?
Для меня
Звучит как минимум странно, потому что мы ещё не дошли до вызова и выполнения
await2при последовательном вызове, и потому он не мог выполниться раньше. И уж тем более он ни как не мог стать unhandled rejection