Жили-были в одном городишке два ассенизатора — синьор и джун. Канализации у них там не было, а просто ямы с этим самым. И они это самое вычерпывали ведром и заливали в свою бочку, причем синьор, как более опытный специалист, спускался в яму, а джун сверху подавал ему ведро. И вот однажды джун это ведро не удержал и обрушил обратно на синьора. Ну, тот утерся, посмотрел на него снизу вверх и сказал ему с горечью: «Чучело ты, — говорит, — огородное, тундра! Никакого толка в тебе не видно. Так всю жизнь наверху и проторчишь».
В эфире «Экстраполяции» наш постоянный автор Дима и, я думаю, уже пора прекращать каждый пост его отдельно помечать эпиграфом. Теперь у него будет фирменный тег.
Недавно сформулировался парадокс компенентности нашей с вами общей профессии. Я бы выразил это так: чем ты круче, тем более глубока яма, в которой ты сидишь. Логика тут проста: можешь — значит, будешь.
Я вот могу затолкать себе в голову большой объём легаси-кода, выполнить его в уме, просочетать в разных вариантах, понять, что происходит и найти, что и как надо сделать, чтобы исправить баг или добавить фичу. А, значит, с неизбежностью, я и буду это делать. Потому что такая работа на рынке есть, её умеют делать не все, и за неё платят чуть больше, чем за клепание контроллеров и моделек с нуля, рассуждая о модульной архитектуре, SOLID, KISS, DCI и таком прочем. Потому что второе может больше народа.
Причём, легаси-код в любом проекте появляется за полгода, так что, от него не спасут даже серьёзные попытки не браться за легаси, а плясать по "generate new projectname" стартапчикам. Легаси-код неизбежен, как всадники апокалипсиса — проект или обрастает легаси-кодом, или аннигилируется заказчиком. В этом месте можете возражать и доказывать, что это не так, и что я не очень, надо просто хорошо писать и всё такое. Вспоминается старый анекдот про «и вы тоже рассказывайте».
#dimoneverything
Ну, ладно, судя по отзывам, анекдот не такой уж и известный, хотя и бородатый. Пересказываю:
85-летний дедушка приходит к своему участковому врачу и жалуется на проблемы с потенцией.
— Но это же нормальное явление в Вашем возрасте, — отвечает доктор.
— Да, но мой сосед, ему уже за 90, рассказывает, что он всё ещё спит со своей женой каждый день.
— Ну и что, — говорит врач, — и Вы тоже рассказывайте.
85-летний дедушка приходит к своему участковому врачу и жалуется на проблемы с потенцией.
— Но это же нормальное явление в Вашем возрасте, — отвечает доктор.
— Да, но мой сосед, ему уже за 90, рассказывает, что он всё ещё спит со своей женой каждый день.
— Ну и что, — говорит врач, — и Вы тоже рассказывайте.
Профессиональное отношение к делу — говорят нам авторы книжек о том, как быть хорошим специалистом — состоит в том, чтобы не бояться сложных задач и исправно перемалывать то, с чем сталкивает вас судьба. Теперь представьте, что ваш менеждер видит, что вы вот справились с задачей, которую вот те двое слили полностью, продолбавшись две недели, а эту вообще вы сами перенянули на себя, трижды найдя ошибки в пулл-реквесте работавшего над ней другого специалиста. Вы чисто эволюционно становитесь решалой сложных задач, и знаете что:
а) Сложные задачи встречаются слишком редко, например, применение высшей математики для токенизации свободного текста
б) Нырнуть в канализацию и применить там ключ на шесть и прокладку случается слишком часто.
А вывод, увы, в том, что ну и что. Есть много приятных вещей в жизни — хорошие книги, фильмы и компьютерные игры, шашлыки, девушки и путешествия. То, что мы на работе игногда умудряемся тоже получить пару дней в месяц удовольствие от красивого решения сложной проблемы — уже благословение.
Конечно же, существуют разработчики, которые свою компенентность действительно смогли конвертировать в интересную работу и у них rocket science каждый день. Но их мало, сильно меньше, чем сеньоров и чем архитекторов тоже. Так что, крутейте, ныряйте, а то так всю жизнь наверху и проторчите.
#dimoneverything
а) Сложные задачи встречаются слишком редко, например, применение высшей математики для токенизации свободного текста
б) Нырнуть в канализацию и применить там ключ на шесть и прокладку случается слишком часто.
А вывод, увы, в том, что ну и что. Есть много приятных вещей в жизни — хорошие книги, фильмы и компьютерные игры, шашлыки, девушки и путешествия. То, что мы на работе игногда умудряемся тоже получить пару дней в месяц удовольствие от красивого решения сложной проблемы — уже благословение.
Конечно же, существуют разработчики, которые свою компенентность действительно смогли конвертировать в интересную работу и у них rocket science каждый день. Но их мало, сильно меньше, чем сеньоров и чем архитекторов тоже. Так что, крутейте, ныряйте, а то так всю жизнь наверху и проторчите.
#dimoneverything
Минутка ложной слепоты и код-ревью.
Хочется задать вопрос уважаемой аудитории. Тут недавно «Экстраполяция» отправилась в прошлое и повторила свой старый текст, который, надо сказать, я тогда не прочитал, а зря, ведь там интересно. И вот хочется спросить про код-ревью.
Есть два разных подхода к код-ревью. Не, есть ещё больше, но я про нормальные, а не превращающие его в бюрократию с профанацией.
Первый — это открыть пулл-реквест и промотать его сверху донизу (или в каком-то другом разумном порядке, от тестов к коду или так, как рекомендует написавший этот код в текстовом описании пулл-реквеста), тщательно его прочитав, что-то выполнив в уме, прочитав тесты и убедившись, что они проверяют код. Потом взять в левую руку Фаулера, в правую Макконнела и указать на возможные косяки, плохие имена, выделите класс, заинлайните метод, тут же N+1 у вас, хватит мокать тесты, это не REST, вы забыли authorize, не надо писать собственный map, он в стандартной библиотеке уже есть, и всякое такое. Или сказать «молодец». В общем, побыть сильно продвинутым Code Climate.
Второй — это открыть задачу, прочитать её, решить её в уме, открыть пулл-реквест и посмотреть, здраво ли он решает поставленную задачу. И ответить, мол, ты чего, долбанулся, контроллер и три колонки в базе городить ради этой задачи, elastic search же есть, уберите эти три поля из формы и добавьте один чекбокс, это вредная задача и её вообще не надо было делать такой ценой. В общем, побыть человеку напарником в парном программировании, только задним числом. Это существенно дольше, выглядит дублированием усилий в масштабах команды и сильно отвлекает от текущей задачи.
Мы с моим коллегой расходится в мнениях по этому вопросу и применяем разные подходы.
Вопрос уважаемой аудитории: как делаете вы? Или как вы считаете, обязан поступать каждый уважающий себя человек и специалист, или какую практику вы бы настоятельно рекомендовали своим ученикам или форсировали на своём проекте?
Ленивые — голосуйте кнопочками, активные — пишите комментарии, и я там тоже буду и Алексей, давайте дискутировать.
#dimoneverything
Хочется задать вопрос уважаемой аудитории. Тут недавно «Экстраполяция» отправилась в прошлое и повторила свой старый текст, который, надо сказать, я тогда не прочитал, а зря, ведь там интересно. И вот хочется спросить про код-ревью.
Есть два разных подхода к код-ревью. Не, есть ещё больше, но я про нормальные, а не превращающие его в бюрократию с профанацией.
Первый — это открыть пулл-реквест и промотать его сверху донизу (или в каком-то другом разумном порядке, от тестов к коду или так, как рекомендует написавший этот код в текстовом описании пулл-реквеста), тщательно его прочитав, что-то выполнив в уме, прочитав тесты и убедившись, что они проверяют код. Потом взять в левую руку Фаулера, в правую Макконнела и указать на возможные косяки, плохие имена, выделите класс, заинлайните метод, тут же N+1 у вас, хватит мокать тесты, это не REST, вы забыли authorize, не надо писать собственный map, он в стандартной библиотеке уже есть, и всякое такое. Или сказать «молодец». В общем, побыть сильно продвинутым Code Climate.
Второй — это открыть задачу, прочитать её, решить её в уме, открыть пулл-реквест и посмотреть, здраво ли он решает поставленную задачу. И ответить, мол, ты чего, долбанулся, контроллер и три колонки в базе городить ради этой задачи, elastic search же есть, уберите эти три поля из формы и добавьте один чекбокс, это вредная задача и её вообще не надо было делать такой ценой. В общем, побыть человеку напарником в парном программировании, только задним числом. Это существенно дольше, выглядит дублированием усилий в масштабах команды и сильно отвлекает от текущей задачи.
Мы с моим коллегой расходится в мнениях по этому вопросу и применяем разные подходы.
Вопрос уважаемой аудитории: как делаете вы? Или как вы считаете, обязан поступать каждый уважающий себя человек и специалист, или какую практику вы бы настоятельно рекомендовали своим ученикам или форсировали на своём проекте?
Ленивые — голосуйте кнопочками, активные — пишите комментарии, и я там тоже буду и Алексей, давайте дискутировать.
#dimoneverything
Всю свою сознательную жизнь человечество находится в поиске Серебряной Пули. Многие считают, что её не существует и глупцами называют тех, кто пытается что-то такое придумать. Серебряная Пуля — это как Святой Грааль, только тот обещает мгновенный требуемый результат, а Серебряная Пуля гарантирует безболезненный процесс получения того самого результата.
Совершенно очевидно, что Грааль — мифический артефакт, получить который не позволяет закон сохранения энергии. Что же до Пули, то ее, родимую, получить гораздо проще даже несмотря на то, что все говорят о том, что Пули этой вообще бывает в природе.
Но дело в том, что как только какой-нибудь инструмент становится Серебряной Пулей, к нему перестают относиться, как к серебряной пуле и считают стандартом де-факто. Этот инструмент становится чем-то таким естественным и общепринятым, что разработчики даже не задумываются о выборе между этим и другими Медными и Бронзовыми аналогами. Никто не рассказывает о преимуществах Пули перед другими инструментами, никто не спорит о неуниверсальности, и никто не обзывает Пулю и не хвалит Штык.
Получается, что как только Пуля становится Серебряной Пулей, то сразу же Серебряная Пуля перестает быть Серебряной. И перестаёт быть Пулей. В итоге получаем, что термин «Серебряная Пуля» — это состояние, длительностью в одно мгновение, а потом тотальное признание и отсутствие альтернатив.
#перечитываяэкстраполяцию
Совершенно очевидно, что Грааль — мифический артефакт, получить который не позволяет закон сохранения энергии. Что же до Пули, то ее, родимую, получить гораздо проще даже несмотря на то, что все говорят о том, что Пули этой вообще бывает в природе.
Но дело в том, что как только какой-нибудь инструмент становится Серебряной Пулей, к нему перестают относиться, как к серебряной пуле и считают стандартом де-факто. Этот инструмент становится чем-то таким естественным и общепринятым, что разработчики даже не задумываются о выборе между этим и другими Медными и Бронзовыми аналогами. Никто не рассказывает о преимуществах Пули перед другими инструментами, никто не спорит о неуниверсальности, и никто не обзывает Пулю и не хвалит Штык.
Получается, что как только Пуля становится Серебряной Пулей, то сразу же Серебряная Пуля перестает быть Серебряной. И перестаёт быть Пулей. В итоге получаем, что термин «Серебряная Пуля» — это состояние, длительностью в одно мгновение, а потом тотальное признание и отсутствие альтернатив.
#перечитываяэкстраполяцию
Мнения по поводу целей пулл реквестов разделились, значит подбросим ещё дровишек в огонь.
Как уже сказал Дима, ревью пулл реквеста нужно глобально только по двум причинам: с целью улучшения техники или стратегии. Техника — это когда Фаулер доволен и тесты быстры и зелены, а стратегия — это когда код готов к глобальным изменениям, неожиданным капризам клиентов и внезапным пиковым нагрузкам не там, где подстелили соломки.
В комментариях совершенно справедливо заметили, что обсуждение стратегии должно предшествовать изменениям в коде, а технические неисправности с закрытыми глазами можно исправлять и после. Черт побери, обсуждать глобальные изменения архитектуры после пулл реквеста — это значит, что время на пулл реквест было потрачено впустую и надо все переделывать. А вот технические ошибки можно бы и самому проверить — отсматривать свои собственные пулл реквесты перед тем, как кому-то их показывать, очень полезное дело.
Ещё одна страшная проблема: исполнитель потратил сильно больше времени на обдумывание пулл реквеста, чем ревьювер. И если считается, что оба разработчика одинаково умны, то вряд ли ревьюверу может прийти какая-то клевая идея, которая не приходила в голову исполнителю. Иногда как бы да, но КПД этого процесса больше похоже на статистическую погрешность.
Конечно же, ревью пулл реквестов имеет ещё несколько дополнительных целей, вроде необходимости знать об каком-то коде нескольким людям, или проверка очевидности кода, но это лишь приятный и полезный бонус, но точно не основная цель.
А решение у проблемы достаточно элегантное. У задачи должно назначаеться не один исполнитель, а два. Один делает, другой командует. Прежде чем начать выполнять, командир и исполнитель обсуждают решение, командир принимает стратегическое решение, исполнитель его делает, командир принимает. Ответственность, вроде бы, точно так же распределяется, как и при классическом ревью пулл реквеста, только в механике парной работы это не просто формальные правила, а естественные условия работы.
Конечно же, современные команды состоят сплошь из профессионалов и считается, что все более-менее равны как по правам, так и по интеллектуальным способностям, поэтому количество ролей «командир» и «исполнитель» у каждого разработчика должно выходить приблизительно поровну. В итоге окажется, что в половине случаев каждый разработчик выступает исполнителем, а во второй — командиром.
Опять же, «исполнитель» вовсе не означает, что тварь он дрожащая и просто на кнопочки нажимает, вовсе нет. Обсуждения, аргументации и доводы должны быть с обеих сторон. Но окончательное решение должно быть за командиром.
Помимо всех основных дополнительных бенифитов обычного ревью, в этой схеме есть ещё один крайне важный, но о нем как-нибудь отдельно, а то и так много букв получилось.
Как уже сказал Дима, ревью пулл реквеста нужно глобально только по двум причинам: с целью улучшения техники или стратегии. Техника — это когда Фаулер доволен и тесты быстры и зелены, а стратегия — это когда код готов к глобальным изменениям, неожиданным капризам клиентов и внезапным пиковым нагрузкам не там, где подстелили соломки.
В комментариях совершенно справедливо заметили, что обсуждение стратегии должно предшествовать изменениям в коде, а технические неисправности с закрытыми глазами можно исправлять и после. Черт побери, обсуждать глобальные изменения архитектуры после пулл реквеста — это значит, что время на пулл реквест было потрачено впустую и надо все переделывать. А вот технические ошибки можно бы и самому проверить — отсматривать свои собственные пулл реквесты перед тем, как кому-то их показывать, очень полезное дело.
Ещё одна страшная проблема: исполнитель потратил сильно больше времени на обдумывание пулл реквеста, чем ревьювер. И если считается, что оба разработчика одинаково умны, то вряд ли ревьюверу может прийти какая-то клевая идея, которая не приходила в голову исполнителю. Иногда как бы да, но КПД этого процесса больше похоже на статистическую погрешность.
Конечно же, ревью пулл реквестов имеет ещё несколько дополнительных целей, вроде необходимости знать об каком-то коде нескольким людям, или проверка очевидности кода, но это лишь приятный и полезный бонус, но точно не основная цель.
А решение у проблемы достаточно элегантное. У задачи должно назначаеться не один исполнитель, а два. Один делает, другой командует. Прежде чем начать выполнять, командир и исполнитель обсуждают решение, командир принимает стратегическое решение, исполнитель его делает, командир принимает. Ответственность, вроде бы, точно так же распределяется, как и при классическом ревью пулл реквеста, только в механике парной работы это не просто формальные правила, а естественные условия работы.
Конечно же, современные команды состоят сплошь из профессионалов и считается, что все более-менее равны как по правам, так и по интеллектуальным способностям, поэтому количество ролей «командир» и «исполнитель» у каждого разработчика должно выходить приблизительно поровну. В итоге окажется, что в половине случаев каждый разработчик выступает исполнителем, а во второй — командиром.
Опять же, «исполнитель» вовсе не означает, что тварь он дрожащая и просто на кнопочки нажимает, вовсе нет. Обсуждения, аргументации и доводы должны быть с обеих сторон. Но окончательное решение должно быть за командиром.
Помимо всех основных дополнительных бенифитов обычного ревью, в этой схеме есть ещё один крайне важный, но о нем как-нибудь отдельно, а то и так много букв получилось.
Сегодня пост по-субботнему, ссылка, причём на перевод. Очень хорошо написано и не менее хорошо переведено.
https://habr.com/ru/post/450508/
https://habr.com/ru/post/450508/
Хабр
Джо Армстронг об Elixir, Erlang, ФП и ООП
В последние несколько дней на Хабре был опубликован ряд статей, общим лейтмотивом которых (особенно в комментариях) стало противостояние тупоконечников с остроконечниками – адепты ФП против ООП, хотя...
Совершенно очевидно, что за работу программиста нужно платить. Уже менее очевидно, но все ещё достаточно понятно сколько конкретно нужно платить тому или иному программисту. И совершенно неочевидно и совсем запутанно с тем, что же ещё влияет на желание работать и продуктивность разработчика.
Многие компании идут по пути наименьшего сопротивления и увеличивают разнообразие печенек на кухне, экзотичность кофейных зёрен, стриптизерш с иксбоксами и теннисных столов с корпоративами. Это, конечно же, помогает, но ненадолго.
Главными же побудителями хорошего настроения на работе является то, что составляет подавляющую часть рабочего процесса.
Если работа состоит в программировании, то важны технологии, техпроцесс и взаимодействие в команде. Если работа состоит в общении, то важным нужно считать дружелюбность и адекватность коллектива. Если работа состоит в организации всякого разного, то важным нужно считать правильно организованные штуки, вроде корпоративов или внутриофисных чемпионатов по бобслею. Ну, и так далее.
Очень жаль, что повышением настроения для тех, кто в основном программирует и заполняет джиру, занимаются те, кто в основном организовывает праздники и выбирает принты на футболки.
Многие компании идут по пути наименьшего сопротивления и увеличивают разнообразие печенек на кухне, экзотичность кофейных зёрен, стриптизерш с иксбоксами и теннисных столов с корпоративами. Это, конечно же, помогает, но ненадолго.
Главными же побудителями хорошего настроения на работе является то, что составляет подавляющую часть рабочего процесса.
Если работа состоит в программировании, то важны технологии, техпроцесс и взаимодействие в команде. Если работа состоит в общении, то важным нужно считать дружелюбность и адекватность коллектива. Если работа состоит в организации всякого разного, то важным нужно считать правильно организованные штуки, вроде корпоративов или внутриофисных чемпионатов по бобслею. Ну, и так далее.
Очень жаль, что повышением настроения для тех, кто в основном программирует и заполняет джиру, занимаются те, кто в основном организовывает праздники и выбирает принты на футболки.
«Я все, конечно, понимаю, но вы представляете себе праздник, организованный разработчиком? Ящик пива, мешок чипсов и турнир по третьему квейку — это максимум», пишет нам читатель «Экстраполяции» с крайне неочевидной отсылкой. Он, безусловно, прав. Программисты не умеют организовывать праздники, они умеют программировать.
Но вот глобальное заблуждение такой риторики состоит в том, что разработчикам плевать на праздники, им сильно не плевать на программирование вообще и проект в частности. Праздники, корпоративы, тимбилдинги и всякое такое, безусловно могут быть, и польза от таких штук есть. Но если в проекте используется джава 1.2 и джиквери, нет автотестов и дедлайны всегда сорваны, то корпоративы, иксбоксы и конкурсы будут чем-то вроде подорожника при открытом переломе.
Ответственным за хорошее настроение лучше бы заняться организацией труда, а не отдыха. Самое важное, что вы можете сделать для отдыха разработчиков, так это не мешать им отдыхать.
Но вот глобальное заблуждение такой риторики состоит в том, что разработчикам плевать на праздники, им сильно не плевать на программирование вообще и проект в частности. Праздники, корпоративы, тимбилдинги и всякое такое, безусловно могут быть, и польза от таких штук есть. Но если в проекте используется джава 1.2 и джиквери, нет автотестов и дедлайны всегда сорваны, то корпоративы, иксбоксы и конкурсы будут чем-то вроде подорожника при открытом переломе.
Ответственным за хорошее настроение лучше бы заняться организацией труда, а не отдыха. Самое важное, что вы можете сделать для отдыха разработчиков, так это не мешать им отдыхать.
Из отзывов к посту об пулл реквестах:
«А у нас борясь с херовыми кодревью решили, что кодревью станет лучше, если потребовать по два аппрува на пулл-реквест, вместо одного»
«А у нас борясь с херовыми кодревью решили, что кодревью станет лучше, если потребовать по два аппрува на пулл-реквест, вместо одного»
В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)
Ещё в телеграме всё ещё напрочь отсутствуют встроенные механизмы продвижения и популяризации каналов. Тут нет вкладки «тренды», нет «мои друзья читают», нет «рекомендаций». С точки зрения пользователя это безусловный плюс. И именно поэтому масса каналов изобилует рекламой других каналов и подборками каналов. Просто это чуть ли не единственный способ рассказать о канале новым читателям. «Экстраполяция» уже давно не рекламируется в других каналах, а рекламы в «Экстраполяции» вообще никогда не было.
Интересно подмечено, что любой пост в канале — это причина мгновенного уменьшения подписчиков на пять-десять человек. Потом, со временем количество подписчиков восстанавливается. Наверное, автоудаляются аккаунты, которые давно не заходили и телеграм их удаляет, а с каналов отписка происходит в момент доставки публикации в удаленный аккаунт.
Хочу попросить вас, мои любимые, рассказать о моем канале вашим друзьям. В телеграме ли, на фейсбуке ли. Может даже при личном контакте. Особенно приятно мне будет, если вы вместе со ссылкой на «Экстраполяцию» опубликуете понравившийся пост у себя на соц.страничке.
Люблю, целую, ваша «Экстраполяция».
Ссылка для ответственных, но ленивых: https://www.tgoop.com/itextrapolation
Ещё в телеграме всё ещё напрочь отсутствуют встроенные механизмы продвижения и популяризации каналов. Тут нет вкладки «тренды», нет «мои друзья читают», нет «рекомендаций». С точки зрения пользователя это безусловный плюс. И именно поэтому масса каналов изобилует рекламой других каналов и подборками каналов. Просто это чуть ли не единственный способ рассказать о канале новым читателям. «Экстраполяция» уже давно не рекламируется в других каналах, а рекламы в «Экстраполяции» вообще никогда не было.
Интересно подмечено, что любой пост в канале — это причина мгновенного уменьшения подписчиков на пять-десять человек. Потом, со временем количество подписчиков восстанавливается. Наверное, автоудаляются аккаунты, которые давно не заходили и телеграм их удаляет, а с каналов отписка происходит в момент доставки публикации в удаленный аккаунт.
Хочу попросить вас, мои любимые, рассказать о моем канале вашим друзьям. В телеграме ли, на фейсбуке ли. Может даже при личном контакте. Особенно приятно мне будет, если вы вместе со ссылкой на «Экстраполяцию» опубликуете понравившийся пост у себя на соц.страничке.
Люблю, целую, ваша «Экстраполяция».
Ссылка для ответственных, но ленивых: https://www.tgoop.com/itextrapolation
Telegram
Экстраполяция IT
Канал об IT в целом и о программировании в частности.
На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Высшее образование не нужно только тем, кто не умеет им пользоваться. Джобс, Цукерберг и Гейтс добились успехов не из-за отсутствия высшего образования, а несмотря на то, что его не было.
#перечитываяэкстраполяцию
#перечитываяэкстраполяцию
После поста о том, как правильно организовывать ревью пулл реквеста все ещё остались вопросы и недопонимания этой техники. Дополняю.
1. Обычно ревьюверам нет дела до пулл реквестов соседей по парте, пока этот пулл реквест к ним не относится.
2. Отвлекаться от текущей задачи не хочется вообще, поэтому ревью пулл реквестов становится обузой.
3. Ревьювер не может быть слишком строгим, потому как относится к нему, как к человеку могут стать хуже.
В итоге проблема сводится к тому, чтобы вовлечь ревьювера в работу этого пулл реквеста. И «вовлечь» это:
1. Дать ревьюверу чувство ответственности за пулл реквест.
2. Показать исполнителю, что ревьювер — это не формальность или бюрократия.
3. Наладить правильный диалог между этими двумя.
Метод «командир-исполнитель» хорошо решает эту проблему. К слову, название у этого подхода крайне дурацкое.
Поможете придумать адекватное? Пишите в личку (@aratak), отберу лучшие и устроим голосование.
1. Обычно ревьюверам нет дела до пулл реквестов соседей по парте, пока этот пулл реквест к ним не относится.
2. Отвлекаться от текущей задачи не хочется вообще, поэтому ревью пулл реквестов становится обузой.
3. Ревьювер не может быть слишком строгим, потому как относится к нему, как к человеку могут стать хуже.
В итоге проблема сводится к тому, чтобы вовлечь ревьювера в работу этого пулл реквеста. И «вовлечь» это:
1. Дать ревьюверу чувство ответственности за пулл реквест.
2. Показать исполнителю, что ревьювер — это не формальность или бюрократия.
3. Наладить правильный диалог между этими двумя.
Метод «командир-исполнитель» хорошо решает эту проблему. К слову, название у этого подхода крайне дурацкое.
Поможете придумать адекватное? Пишите в личку (@aratak), отберу лучшие и устроим голосование.
Telegram
Экстраполяция IT
Мнения по поводу целей пулл реквестов разделились, значит подбросим ещё дровишек в огонь.
Как уже сказал Дима, ревью пулл реквеста нужно глобально только по двум причинам: с целью улучшения техники или стратегии. Техника — это когда Фаулер доволен и тесты…
Как уже сказал Дима, ревью пулл реквеста нужно глобально только по двум причинам: с целью улучшения техники или стратегии. Техника — это когда Фаулер доволен и тесты…
Сверхквалификация, как современный тренд разработчиков.
Уже неоднократно слышу от разработчиков о том, что на собеседовании отказывают по причине того, что разработчик прямо чересчур крут и вообще, амбиции компании намного ниже, чем зведность и ослепительность разработчика.
Это далеко не единичный случай и у этой проблемы несколько сторон. Попробуем обсудить эту штуку коллективно под тегом #экстраквалификация, пишите свои мысли личным сообщением. И тег не забывайте писать, а то потеряю сообщение ваше.
Уже неоднократно слышу от разработчиков о том, что на собеседовании отказывают по причине того, что разработчик прямо чересчур крут и вообще, амбиции компании намного ниже, чем зведность и ослепительность разработчика.
Это далеко не единичный случай и у этой проблемы несколько сторон. Попробуем обсудить эту штуку коллективно под тегом #экстраквалификация, пишите свои мысли личным сообщением. И тег не забывайте писать, а то потеряю сообщение ваше.
Очевидно, что арбалет, как устройство появилось значительно позже лука. Проблема, которую решал создатель арбалета достаточно проста и очевидна — хотелось сохранить кинетическую энергию натянутой тетивы без участия мускулатуры стрелка. В итоге арбалет получился более громоздким, менее дальнобойным, более дорогим в изготовлении, менее скорострельным, менее убойным на средних дистанциях. Лук (особенно длинный лук) уделывал арбалет по всем показателям, тем не менее, после популяризации арбалета практически все армии так или иначе использовали в первую очередь именно арбалет, а не лук. И причина этому очень простая.
Чтобы вырасти и Робином Гудом и сделать так, чтобы стрела хотя бы летела в нужном направлении, не говоря уже о хоть какой-нибудь точности, нужно потратить не один месяц, а может быть даже и не один год. А получить целый отряд справных лучников, работающих в команде, еще менее вероятно и более тяжело. А вот с арбалетами и арбалетчиками все намного проще, ведь пары часов инструктажа вполне достаточно, чтобы организовать заградительную стену стрел в ближайшей стычке с врагом. Экономически и стратегически легче найти и нанять десять арбалетчиков и вручить им десять арбалетов, чем воспитать одного лучника.
Само собой, сеньор-лучник будет в пять раз лучше любого джуниора-арбалетчика и бюрократии для одного лучника не требуется вовсе. И организовывать командную работу одному лучнику не нужно. На десять арбалетчиков нужно еще одного тим-лида, пару офис-менеджеров и одного кадрового агента, чтобы заменять убитых и уволенных арбалетчиков и придворного организатора праздников, чтобы развлекал толпу арбалетчиков, пока те не стреляют. В итоге владение луком стало приятным бонусом при найме арбалетчиков, а потом лук и вовсе перерастёт скорее в хобби, чем в основную профессию. Хотя, безусловно, на конференциях арбалетчиков говорят все исключительно о том, как правильно владеть луком и как сильно техника владения луком помогает стрелять из арбалета. И что на десять арбалетчиков в команде нужно иметь пару лучников. И что если бы все десять тысяч арбалетчиков в регулярной армии владели бы луком, то можно было бы и Византию захватить.
Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.
#перечитываяэкстраполяцию
Чтобы вырасти и Робином Гудом и сделать так, чтобы стрела хотя бы летела в нужном направлении, не говоря уже о хоть какой-нибудь точности, нужно потратить не один месяц, а может быть даже и не один год. А получить целый отряд справных лучников, работающих в команде, еще менее вероятно и более тяжело. А вот с арбалетами и арбалетчиками все намного проще, ведь пары часов инструктажа вполне достаточно, чтобы организовать заградительную стену стрел в ближайшей стычке с врагом. Экономически и стратегически легче найти и нанять десять арбалетчиков и вручить им десять арбалетов, чем воспитать одного лучника.
Само собой, сеньор-лучник будет в пять раз лучше любого джуниора-арбалетчика и бюрократии для одного лучника не требуется вовсе. И организовывать командную работу одному лучнику не нужно. На десять арбалетчиков нужно еще одного тим-лида, пару офис-менеджеров и одного кадрового агента, чтобы заменять убитых и уволенных арбалетчиков и придворного организатора праздников, чтобы развлекал толпу арбалетчиков, пока те не стреляют. В итоге владение луком стало приятным бонусом при найме арбалетчиков, а потом лук и вовсе перерастёт скорее в хобби, чем в основную профессию. Хотя, безусловно, на конференциях арбалетчиков говорят все исключительно о том, как правильно владеть луком и как сильно техника владения луком помогает стрелять из арбалета. И что на десять арбалетчиков в команде нужно иметь пару лучников. И что если бы все десять тысяч арбалетчиков в регулярной армии владели бы луком, то можно было бы и Византию захватить.
Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.
#перечитываяэкстраполяцию
Во многих языках есть штука, которую называют «тернарным оператором». Как правило, эта штука записывается, как
Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения
Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло Негр. Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.
#перечитываяэкстраполяцию
'c ? t : f'. Штука замечательная, без споров, но вот её название звучит как-то коряво.Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения
(a+b) — с двумя аргументами, но мы не называем его «бинарным оператором», так как таких операторов у нас много и совершенно непонятно о каком конкретно операторе речь. А вот тернарник у нас один, и все как-то привыкли, что «тернарный оператор» — это на самом деле «условный оператор в тернарной форме».Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло Негр. Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.
#перечитываяэкстраполяцию
. Небольшой дисклеймер. Всей редакции «Экстраполяции» в полном составе кажется, что корректных мнений может быть несколько и то, что декларируется в канале лишь мнение одного из авторов. Авторы даже не должны быть согласны друг с другом, чтобы опубликовать пост в канале.
Более того, ваши мнения, которые вы присылаете, публикуются в канале не по принципу схожести мышления, а только если мысль сформулирована целостно и мысль не сильно банальная. А согласен ли я с ней или не согласен не имеет никакого значения. Об этом как-то отдельно напишем.
#экстраквалификация от трёх подписчиков. Предысторию ищите по тегу.
1. Я всегда думал, что под сверхквалификацией просто подразумевают «парень, ты слишком много хочешь!».
2. Если ты оверквалифайед в одном месте - то иди в то место, где ты недоквалифайед и расти там.
3. Мне кажется, что причина прагматичная и на поверхности. Таким крутым спецам будет скучно на проекте и вскоре они слиняют, т.к. скукота и рутина будет их угнетать.