Я конечно жутко извиняюсь, но статья называется "Полное понимание асинхронности в браузере". Зачем добавлять "в браузере", когда статья про асихронность в ДжаваСкрипте? Еще и есть раздел про Нод.жс.
А что касается браузера - то автор смешно пишет про очередь событий в браузере и сайте, ничего говоря про окна, табы, и ифреймы. Мы точно прочитали статью о программировании, где точность важна, как бы? Или это перевод?
Хотя это так, мелочные придирки, но мне кажется, если уж пытаться написать такой гайд, который вполне хорош, то надо уж его точнее называть и точнее рассказывать об именно внутренней специфике браузера, если уж это заявлено в заголовке.
Да, всё правильно. Но использование браузеров, как кросс-платформенного UI предполагает, что браузер уже запущен, и ваше приложение, как бы дополнительно запускается внутри данного инстанса. Если же для каждого приложения будет новый инстанс браузера — то это уже будет слишком. А вот когда таких приложений станет слишком много, то командам браузеров придется над этим задуматься и выпускать или легковесные варианты, либо же делать так, что такие приложение будут запускаться как бы «внутри» текущего инстанса браузера и не поднимать много разной ерунды для каждого инстанса. Но это только благие пожелание, наверняка всё ограничится тем, что «да, добавьте памяти».
Почему-то все стали обсуждать JS vs. Qt/Delphi/C#/Java как-то забывая, что, основная проблема не JS и не в Electron, а еще один инстанс Хрома. Главное преимущество JS в том, что в нынешних реалиях, браузер (а следовательно и JS) есть практически на любой платформе, чего не скажешь ни о Windows, ни о .Net, ни о JVM. Но это разумеется относится к UI. Поэтому, как только найдут решение как запускать JS приложение отдельным клиентом без дополнительной нагрузки в виде целого браузера (или же в Гугле что-то сделают с Хромом, т.к. будет расти количество приложений, использующих его) — пафос таких статей станет ненужным. Но когда это произойдет — это тот еще вопрос.
Не уверен, что кто-то будет (или даже должен) знать всё за пределами лабораторий, работающих с JVM или что-то оптимизирующих на низком уровне. Разве что, кто-то копался ради любопытства (но тогда и CV не так уж важно, если человек сам прошел так глубоко).
На практике же, описанный уровень абстракции интересен и любопытен, но не более того. Я много раз сталкивался с многопоточными проблемами, но не вижу ни единой, где знание, полученное из этой статьи можно применить. Везде было достаточно чуть высшего уровня абстракции (т.е. там где объясняется, что такое happens-before, без подробностей, что стоит за этим). Вернее, даже так: сама java и ее библиотеки и формируют уровень абстракции, который скрывает эти детали. Возможно это может пригодиться в случае совсем уж экзотических багов или в случае взаимодействия через JNI.
Я не пытаюсь сказать, что статья не найдет своего читателя. Просто всё знать невозможно, поэтому каждый человек по любой теме выбирает ту степень абстракции, в которую он готов вложить своё время (ожидая, что это окупит себя). Людей, которые действительно могут применить полученные знания на практике — я думаю, будут, единицы. И совсем, маловероятно, что найдутся те, кто «и так всё знал».
Мне кажется, что позиция, высказанная в статье очень утрированная и максималисткая. По моему мнению (хотя возможно автор этого не подразумевал), налицо недостаточная степень коммуникации и понимания между менеджером и разработчиком. С другой стороны, любая описанная проблема имеет много граней, что уже отмечено в других комментариях.
001. А у меня на компе работает
Здесь нужно понимать, в каком качестве вы рассматриваете разработчика, насколько узко он специализирован, есть ли у вас QA, саппорт и прочее-прочее. Нельзя объять необъятное. Такой ответ плох, если разработчик просто не хочет с этим разбираться. Но, если в этом могут разобраться саппорт и прочие — то почему этим должен заниматься разработчик? Я, можно сказать, ежедневно встречаюсь с этой ситуацией, причем лично. Так вот, у нас не принято при этом винить в этом разработчика. И, да, у него действительно это работает. Решение: предоставить информацию о проблеме, среду для воспроизведения — от этого разработчику будет трудно уже уйти, т.к. есть конкретная задача, конкретные данные.
010. Какой мудакпользователь так (с)делает?
У любого ПО есть свои ограничения. И не разработчик, а люди над ним, должны решать какие ограничения будут включены в продукт, а какие нет. Потому что, в общем случае, ограничений бесконечное множество, о многих вы не сможете догадаться. Если разработчик считает ограничение бессмысленным, то нужно объяснить ему логику ограничения. Иначе получается «я — начальник, поэтому будешь делать, как я хочу», что есть неправильно. Решение: описать все ограничения, которые вы поддерживаете, по каждому, разработчику и/или тестеру ставится конкретная задача. Если пользователь обходит какое-то ограничение, то опять же, не разработчик, а люди над ним решают поддерживаем ли мы это ограничение или нет. Да и еще, непредусмотренные ограничение, не обнаруженные ни разработчиком, ни тестером, ни сотней пользователь за первые 5 лет пользования, обязательно вылезут.
011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
По-хорошему, разработчики и тестеры должны быть одной командой. Если разработчики противопоставляют себя тестерам — это уже плохой знак. Если не идут на контакт — тоже плохо. И задача руководителя наладить этот контакт, чтобы о том, что Вася не разговаривает с Петей было известно заранее, а не тогда, когда пришел баг, а они не могут друг к другу подойти. Опять же, разработчики и тестеры должны друг другу рассказывать, что они накодили или натестили.
100. Какой идиот это писал?
Тоже знакомая ситуация, да, иногда натыкаешься на плохой код. И да, иногда, ты сам это написал. Но, постойте, так есть же решение: код ревью. Только «пообщайся с челом» — это, извините, было актуально 10 лет назад, а в дополнение к код ревью — самое то. Да и рефакторинг никто не отменял. Опять же, возможно, здесь подразумевается, что проблема в том, что разработчик не хочет иметь дело с чужим кодом. Но эта проблема психологическая (а, значит, зона ответственности руководителя). Если код действительно идиотский — то и руководитель должен понимать, что его лучше переписать, что улучшит его поддержку в будущем. Если разработчик просто не может понять, что в коде происходит — то это уже совсем другая проблема. Если сам разработчик некомпетентен, то нужно найти более опытного (если возможно). Если действительно код запутанный, то опять же рефакторинг. Если… (впрочем, здесь еще много «если» может быть).
101. Готово на 99%
Про будущее здесь уже написали. Про эстимейты тоже. Я не знаю про конкретную ситуацию в каждой компании, поэтому опишу, как подходят к этой проблеме в части из них. Эстимейт — это всегда оценка, он всегда должен подразумевать оптимистическую и пессимистическую оценку. По-хорошему, должны быть указаны риски (а вдруг в другой среде всё будет не так, а вдруг, мы не сможем найти решение за указанное время, и т.п.). А руководитель уже должен руководствоваться как эстимейтом, так и рисками (которые объясняют, почему мы можем пойти по пессимистической оценке). Немного странно, что статус задачи подразумевает сроки. Сроки нужно обсуждать до начала задачи. А во время спрашивать уже о статусе. Впрочем, здесь может быть длинная дискуссия, об этом написано немало книг. Опять же, по-хорошему, в эстимейт должен входить не только сам кодинг, но и исследование, и отладка, и тестирование. Всё это должен понимать и руководитель, и разработчик еще на этапе эстимейта и оценивания рисков. Также замечу, что руководитель чутьем или опытом, должен понимать адекватны ли эстимейты и риски, и обсудить это до начала задачи. Если вы начинаете работать с плагином, с которым вы никогда не встречались, если он плохо задокументирован, если… — это риск, его нужно оценить до начала задачи. Это проблема не только разработчика, но и самого руководителя. Его должны интересовать непростые отношения с этим плагином, потому что он должен понимать, сделает ли данный разработчик эту задачу или нет. Например, если есть разработчик А (знакомый с другими плагинами) и разработчик Б (не знакомый), но разработчик А занят на других задачах, то неадекватно полагать, что разработчик Б сделает ту же задачу за то же время, только потому что руководитель так хочет.
110. Это невозможно!
Здесь уже описали действительно невозможные задачи. В каком-то смысле, этот пункт тесно завязан с предыдущим. Да и непонятно, невозможно ли вообще, или невозможно за отведенное время. Если разработчик четко указывает почему невозможно — то всё обсуждаемо.
111. Я такую ерунду делать не буду.
Да, в принципе, всё просто — или делай, или увольняйся. Но, с другой стороны, это максимализм. Из собственного опыта — если ты умеешь объяснить рациональность мотивов, что стоит за задачей и зачем она нужна — разработчик может поменять мнение или согласиться, что это необходимо.
В общем говоря, все указанные пункты, высказанные в ключе «Я начальник, поэтому разработчик будет делать, как я говорю» естественно вызвали негативную реакцию. По крайней мере, я вижу, что многие именно так и поняли данную статью. Если автор этого не подразумевал — то дело другое, но, что написано, то написано. Все проблемы вполне решаемы, где-то виновата лень, где-то отрицание (гнев, торг, депрессия), но ведь задача именно руководителя мотивировать разработчика делать работу. Люди все где-то немножко ленивы, где-то безответственны, где-то капризные. Но ведь вы их почему-то приняли на работу, а, возможно, уже проработали несколько лет. Значит, есть у них плюсы — и задача руководителя заставить эти «плюсы» работать. Ведь вы же одна команда, не так ли?
Я конечно жутко извиняюсь, но статья называется "Полное понимание асинхронности в браузере". Зачем добавлять "в браузере", когда статья про асихронность в ДжаваСкрипте? Еще и есть раздел про Нод.жс.
А что касается браузера - то автор смешно пишет про очередь событий в браузере и сайте, ничего говоря про окна, табы, и ифреймы. Мы точно прочитали статью о программировании, где точность важна, как бы? Или это перевод?
Хотя это так, мелочные придирки, но мне кажется, если уж пытаться написать такой гайд, который вполне хорош, то надо уж его точнее называть и точнее рассказывать об именно внутренней специфике браузера, если уж это заявлено в заголовке.
На практике же, описанный уровень абстракции интересен и любопытен, но не более того. Я много раз сталкивался с многопоточными проблемами, но не вижу ни единой, где знание, полученное из этой статьи можно применить. Везде было достаточно чуть высшего уровня абстракции (т.е. там где объясняется, что такое happens-before, без подробностей, что стоит за этим). Вернее, даже так: сама java и ее библиотеки и формируют уровень абстракции, который скрывает эти детали. Возможно это может пригодиться в случае совсем уж экзотических багов или в случае взаимодействия через JNI.
Я не пытаюсь сказать, что статья не найдет своего читателя. Просто всё знать невозможно, поэтому каждый человек по любой теме выбирает ту степень абстракции, в которую он готов вложить своё время (ожидая, что это окупит себя). Людей, которые действительно могут применить полученные знания на практике — я думаю, будут, единицы. И совсем, маловероятно, что найдутся те, кто «и так всё знал».
001. А у меня на компе работает
Здесь нужно понимать, в каком качестве вы рассматриваете разработчика, насколько узко он специализирован, есть ли у вас QA, саппорт и прочее-прочее. Нельзя объять необъятное. Такой ответ плох, если разработчик просто не хочет с этим разбираться. Но, если в этом могут разобраться саппорт и прочие — то почему этим должен заниматься разработчик? Я, можно сказать, ежедневно встречаюсь с этой ситуацией, причем лично. Так вот, у нас не принято при этом винить в этом разработчика. И, да, у него действительно это работает. Решение: предоставить информацию о проблеме, среду для воспроизведения — от этого разработчику будет трудно уже уйти, т.к. есть конкретная задача, конкретные данные.
010. Какой мудакпользователь так (с)делает?
У любого ПО есть свои ограничения. И не разработчик, а люди над ним, должны решать какие ограничения будут включены в продукт, а какие нет. Потому что, в общем случае, ограничений бесконечное множество, о многих вы не сможете догадаться. Если разработчик считает ограничение бессмысленным, то нужно объяснить ему логику ограничения. Иначе получается «я — начальник, поэтому будешь делать, как я хочу», что есть неправильно. Решение: описать все ограничения, которые вы поддерживаете, по каждому, разработчику и/или тестеру ставится конкретная задача. Если пользователь обходит какое-то ограничение, то опять же, не разработчик, а люди над ним решают поддерживаем ли мы это ограничение или нет. Да и еще, непредусмотренные ограничение, не обнаруженные ни разработчиком, ни тестером, ни сотней пользователь за первые 5 лет пользования, обязательно вылезут.
011. Тестеры нифига не протестировали! Чем они там ваще занимаются?
По-хорошему, разработчики и тестеры должны быть одной командой. Если разработчики противопоставляют себя тестерам — это уже плохой знак. Если не идут на контакт — тоже плохо. И задача руководителя наладить этот контакт, чтобы о том, что Вася не разговаривает с Петей было известно заранее, а не тогда, когда пришел баг, а они не могут друг к другу подойти. Опять же, разработчики и тестеры должны друг другу рассказывать, что они накодили или натестили.
100. Какой идиот это писал?
Тоже знакомая ситуация, да, иногда натыкаешься на плохой код. И да, иногда, ты сам это написал. Но, постойте, так есть же решение: код ревью. Только «пообщайся с челом» — это, извините, было актуально 10 лет назад, а в дополнение к код ревью — самое то. Да и рефакторинг никто не отменял. Опять же, возможно, здесь подразумевается, что проблема в том, что разработчик не хочет иметь дело с чужим кодом. Но эта проблема психологическая (а, значит, зона ответственности руководителя). Если код действительно идиотский — то и руководитель должен понимать, что его лучше переписать, что улучшит его поддержку в будущем. Если разработчик просто не может понять, что в коде происходит — то это уже совсем другая проблема. Если сам разработчик некомпетентен, то нужно найти более опытного (если возможно). Если действительно код запутанный, то опять же рефакторинг. Если… (впрочем, здесь еще много «если» может быть).
101. Готово на 99%
Про будущее здесь уже написали. Про эстимейты тоже. Я не знаю про конкретную ситуацию в каждой компании, поэтому опишу, как подходят к этой проблеме в части из них. Эстимейт — это всегда оценка, он всегда должен подразумевать оптимистическую и пессимистическую оценку. По-хорошему, должны быть указаны риски (а вдруг в другой среде всё будет не так, а вдруг, мы не сможем найти решение за указанное время, и т.п.). А руководитель уже должен руководствоваться как эстимейтом, так и рисками (которые объясняют, почему мы можем пойти по пессимистической оценке). Немного странно, что статус задачи подразумевает сроки. Сроки нужно обсуждать до начала задачи. А во время спрашивать уже о статусе. Впрочем, здесь может быть длинная дискуссия, об этом написано немало книг. Опять же, по-хорошему, в эстимейт должен входить не только сам кодинг, но и исследование, и отладка, и тестирование. Всё это должен понимать и руководитель, и разработчик еще на этапе эстимейта и оценивания рисков. Также замечу, что руководитель чутьем или опытом, должен понимать адекватны ли эстимейты и риски, и обсудить это до начала задачи. Если вы начинаете работать с плагином, с которым вы никогда не встречались, если он плохо задокументирован, если… — это риск, его нужно оценить до начала задачи. Это проблема не только разработчика, но и самого руководителя. Его должны интересовать непростые отношения с этим плагином, потому что он должен понимать, сделает ли данный разработчик эту задачу или нет. Например, если есть разработчик А (знакомый с другими плагинами) и разработчик Б (не знакомый), но разработчик А занят на других задачах, то неадекватно полагать, что разработчик Б сделает ту же задачу за то же время, только потому что руководитель так хочет.
110. Это невозможно!
Здесь уже описали действительно невозможные задачи. В каком-то смысле, этот пункт тесно завязан с предыдущим. Да и непонятно, невозможно ли вообще, или невозможно за отведенное время. Если разработчик четко указывает почему невозможно — то всё обсуждаемо.
111. Я такую ерунду делать не буду.
Да, в принципе, всё просто — или делай, или увольняйся. Но, с другой стороны, это максимализм. Из собственного опыта — если ты умеешь объяснить рациональность мотивов, что стоит за задачей и зачем она нужна — разработчик может поменять мнение или согласиться, что это необходимо.
В общем говоря, все указанные пункты, высказанные в ключе «Я начальник, поэтому разработчик будет делать, как я говорю» естественно вызвали негативную реакцию. По крайней мере, я вижу, что многие именно так и поняли данную статью. Если автор этого не подразумевал — то дело другое, но, что написано, то написано. Все проблемы вполне решаемы, где-то виновата лень, где-то отрицание (гнев, торг, депрессия), но ведь задача именно руководителя мотивировать разработчика делать работу. Люди все где-то немножко ленивы, где-то безответственны, где-то капризные. Но ведь вы их почему-то приняли на работу, а, возможно, уже проработали несколько лет. Значит, есть у них плюсы — и задача руководителя заставить эти «плюсы» работать. Ведь вы же одна команда, не так ли?