В тему предыдущего поста главы подписчик напомнил анекдот в тему:
– Василий Иваныч, как же вы у англичан в карты выиграли?!
– Да понимаешь, Петька, сели мы с ихними лордами в очко сыграть. Один и говорит: «очко!». я ему:
– Покажи! А он мне: «ну что вы, Василий Иванович, мы же тут все джентльмены, а джентльмен верит другому джентельмену на слово».
И вот тут мне, Петька, карта и попёрла...
– Василий Иваныч, как же вы у англичан в карты выиграли?!
– Да понимаешь, Петька, сели мы с ихними лордами в очко сыграть. Один и говорит: «очко!». я ему:
– Покажи! А он мне: «ну что вы, Василий Иванович, мы же тут все джентльмены, а джентльмен верит другому джентельмену на слово».
И вот тут мне, Петька, карта и попёрла...
Помнится, некоторое время назад, «верстальщик» и «тестировщик» считались крайне обидными ругательствами, дошло до того, что сейчас эти названия вообще встретишь редко. Кругом сплошные «кюэйщики» и «фронтендеры». Причины такого переименования достаточно очевидны, чтобы о них целым постом мусолить.
А рассказать я хотел о двух новых самоидентификацих разных профессий. Одно из них шуточное, а второе настоящее. Проголосуйте за название профессии, которое вам кажется настоящим. Мне почему-то кажется, что выбор не очень-то и очевиден.
А рассказать я хотел о двух новых самоидентификацих разных профессий. Одно из них шуточное, а второе настоящее. Проголосуйте за название профессии, которое вам кажется настоящим. Мне почему-то кажется, что выбор не очень-то и очевиден.
Как и предполагалось, реальная должность и выдуманная с первого взгляда неотличимы. Абсурдно (и в то же время довольно пафосно) звучит как и «адвокат талантов», так и «сомелье пользовательских интерфейсов».
Понятное дело, что профессиями эти штуки назвать сложно, это скорее связано с самоидентификацией. Как себя чувствует и к кому причисляет тот или иной специалист.
И как тут не вспомнить гендерную самоидентификацию, где количество вариантов уже превышает все разумные и неразумные пределы. В некоторых фейсбуках дошло уже до множественного гендерного выбора, что абсурдно уже даже с точки зрения понятия «гендер».
В общем, друзья, идентифицировать себя можно как угодно и причислять себя к любой группе людей. Но врачей будет на выбор только два: андролог и гинеколог.
Понятное дело, что профессиями эти штуки назвать сложно, это скорее связано с самоидентификацией. Как себя чувствует и к кому причисляет тот или иной специалист.
И как тут не вспомнить гендерную самоидентификацию, где количество вариантов уже превышает все разумные и неразумные пределы. В некоторых фейсбуках дошло уже до множественного гендерного выбора, что абсурдно уже даже с точки зрения понятия «гендер».
В общем, друзья, идентифицировать себя можно как угодно и причислять себя к любой группе людей. Но врачей будет на выбор только два: андролог и гинеколог.
Самый дикий и ужасный вид контрактной работы у разработчиков — это аутстаф. Конечно, виды аутстафа бывают разные, но вот хороших среди них все-равно нет.
Аутстаф, когда сейлз-менеджер берет проценты с контракта. Аутстаф — если разработчиков нанимают под проект отдельно. Он же, когда одна аутсорс-компания арендует у другой «срочного ангулар разработчика».
Еще о нём же можно говорить, когда заказчик не знает кто конкретно пишет код, а общается с посредниками, то бишь менеджерской прослойкой.
Последне, как по мне, вообще верх цинизма. Это когда заказчик, скажем, из Германии, хочет заказать разработку у компании, скажем, из Мюнхена, а та покупает разработчиков у киевской аутстаф-компании и выступает только лишь посредником между заказчиком и исполнителями. Это ещё хоть как-то можно было оправдать в двухтысячном и совершенно лишено логики сейчас.
Аутстаф, когда сейлз-менеджер берет проценты с контракта. Аутстаф — если разработчиков нанимают под проект отдельно. Он же, когда одна аутсорс-компания арендует у другой «срочного ангулар разработчика».
Еще о нём же можно говорить, когда заказчик не знает кто конкретно пишет код, а общается с посредниками, то бишь менеджерской прослойкой.
Последне, как по мне, вообще верх цинизма. Это когда заказчик, скажем, из Германии, хочет заказать разработку у компании, скажем, из Мюнхена, а та покупает разработчиков у киевской аутстаф-компании и выступает только лишь посредником между заказчиком и исполнителями. Это ещё хоть как-то можно было оправдать в двухтысячном и совершенно лишено логики сейчас.
Общение в чатах в большинстве своём придерживается неких норм этикета, соблюдать которые никто не учит и списком такие правила нигде не найдёшь. Некоторые правила настолько естественны, что не соблюдать их — высшее неуважение к собеседнику. Одно nohello.com чего стоит.
Есть ещё одно правило, которое менее популярно, чем nohello, но не менее важное — ссылки без описания. Особенно в общий чат.
Сидишь такой, себе работаешь, и тут, бац, приходит ссылка. Надо оно мне? Не надо? Важно открыть её прямо сейчас или можно потом? Там мемасик или секьюрити патч? Объявление о выключении серверов в датацентре или рассуждения на тему того, что аджайл — это плохо? В общем, вопросов много, решение одно. Ссылки без сопроводительного описания посылать в чат нельзя никому.
Дополнить можно, что крайне важно не рассказать что там по ссылке будет (с этим и превью справится) и не свои эмоции передать, а рассказать почему читателю это надо обязательно прочитать. Вместо «Зацените что DO себе позволяет», нужно написать «У кого сервера на Диджиталоушен, берегитесь, в субботу их выключат на час». И ссылку добавить.
Есть ещё одно правило, которое менее популярно, чем nohello, но не менее важное — ссылки без описания. Особенно в общий чат.
Сидишь такой, себе работаешь, и тут, бац, приходит ссылка. Надо оно мне? Не надо? Важно открыть её прямо сейчас или можно потом? Там мемасик или секьюрити патч? Объявление о выключении серверов в датацентре или рассуждения на тему того, что аджайл — это плохо? В общем, вопросов много, решение одно. Ссылки без сопроводительного описания посылать в чат нельзя никому.
Дополнить можно, что крайне важно не рассказать что там по ссылке будет (с этим и превью справится) и не свои эмоции передать, а рассказать почему читателю это надо обязательно прочитать. Вместо «Зацените что DO себе позволяет», нужно написать «У кого сервера на Диджиталоушен, берегитесь, в субботу их выключат на час». И ссылку добавить.
Ребята, у меня к вам внезапный вопрос.
Дело в том, что периодически личным сообщением вы присылаете отзыв о том, что посты слишком философские и малопрактичные. Оно как бы и да, но в это же время я стараюсь писать о всяких штуках, которые интересны всем, вне зависимости от предпочитаемых языков программирования или самоидентификации.
Как рассказывать о штуках всяких в языках программирования я до сих пор не понимаю, все мы разные и знаем много чего разного, общих тем мало. Разве что Джаббаскрипт.
Темы разные и одинаково интересные могут быть в основном у новичков в программировании. Ну, или у смежных профессий, которые интересуются программированием.
Так вот, не отдельный же канал для этого добра заводить? В фейсбук такое писать не принято, линкедин вообще, как соцсеть, отстой дикий.
В общем, непонятно. Напишите мне личным сообщением (@aratak), пожалуйста, что думаете по поводу отдельного канала для новичков. Ленивые, но ответственные просто жмите на кнопочки. Спасибо.
👍 заводи, подпишусь
👨🏻💻 пиши прям сюда, норм
🧐 заводи отдельно, мне не интересно
🤮 нафиг надо на джунов время тратить, лучше сюда больше пиши
👽 не нажимайте на инопланетянина!
Дело в том, что периодически личным сообщением вы присылаете отзыв о том, что посты слишком философские и малопрактичные. Оно как бы и да, но в это же время я стараюсь писать о всяких штуках, которые интересны всем, вне зависимости от предпочитаемых языков программирования или самоидентификации.
Как рассказывать о штуках всяких в языках программирования я до сих пор не понимаю, все мы разные и знаем много чего разного, общих тем мало. Разве что Джаббаскрипт.
Темы разные и одинаково интересные могут быть в основном у новичков в программировании. Ну, или у смежных профессий, которые интересуются программированием.
Так вот, не отдельный же канал для этого добра заводить? В фейсбук такое писать не принято, линкедин вообще, как соцсеть, отстой дикий.
В общем, непонятно. Напишите мне личным сообщением (@aratak), пожалуйста, что думаете по поводу отдельного канала для новичков. Ленивые, но ответственные просто жмите на кнопочки. Спасибо.
👍 заводи, подпишусь
👨🏻💻 пиши прям сюда, норм
🧐 заводи отдельно, мне не интересно
🤮 нафиг надо на джунов время тратить, лучше сюда больше пиши
👽 не нажимайте на инопланетянина!
Самое ужасное, что может случаться с архитектурой проекта — это приватные пакеты в зависимостях. Ну, это когда инфраструктура языка предусматривает пакетный менеджер и отдельный пакет просто так не поставишь и не обновишь, нужна какая-то аутентификация. И это плохо по нескольким причинам.
Во-первых это микроскоп с гвоздями. Пакетный менеджер предназначен для расширений возможности языка, а приватные пакеты решают проблему переиспользования одного кода бизнес логики между разными микросервисами или вообще приложениями.
Во-вторых это неудобно. Любое изменение в этом куске кода требует дополнительных усилий, сопоставимых с релизом небольшого приложения.
В-третьих, это не устраняет проблему дублирования, а только прячет её. Если вдруг в пакете будут какие-то изменения, то нужно будет сделать изменения во всех местах, где используется этот пакет.
В-четвёртых, приватность таких пакетов уж очень условная, ведь все необходимое записано в основном репозитории.
Если уж не удаётся разделить код по-нормальному, можно воспользоваться сабмодулями гита. Эффект будет такой же со всеми преимуществами и отсутствием недостатков.
Во-первых это микроскоп с гвоздями. Пакетный менеджер предназначен для расширений возможности языка, а приватные пакеты решают проблему переиспользования одного кода бизнес логики между разными микросервисами или вообще приложениями.
Во-вторых это неудобно. Любое изменение в этом куске кода требует дополнительных усилий, сопоставимых с релизом небольшого приложения.
В-третьих, это не устраняет проблему дублирования, а только прячет её. Если вдруг в пакете будут какие-то изменения, то нужно будет сделать изменения во всех местах, где используется этот пакет.
В-четвёртых, приватность таких пакетов уж очень условная, ведь все необходимое записано в основном репозитории.
Если уж не удаётся разделить код по-нормальному, можно воспользоваться сабмодулями гита. Эффект будет такой же со всеми преимуществами и отсутствием недостатков.
Ребята, судя по лайкам под постом, тема неоднозначная. Короче я не выдержал и создал чатик для «Экстраполяции». Ссылка на него, вроде как должна быть внизу экрана — кнопочка «Discuss». Там уже, к слову, обсуждение понеслось. Присоединяйтесь!
Не устаю повторять, что только понимание противоположного мнения может сделать меня лучше. Так и со вчерашней мыслью про сабмодули. В созданном чатике и личными сообщениями было несколько аргументов в пользу приватных пакетов.
1. Зависимости пакета и зависимости основного проекта могут отличаться. С сабмодулями контролировать версии зависимостей в некоторых языках тяжелей.
2. Обновление сабмодуля выглядит, как замена одного хеша в файлике на другой. Осознать что там поменялось без дополнительных действий тяжелей, чем при обновлении абстрактного пакета с версии 15 на версию 16. Там хотя бы ченджлог почитать можно.
3. При работе с отдельным пакетом проще абстрагироваться от основных проектов и сильно удобней писать независимый код. В отдельном пакете и тесты пишутся легче.
В общем, аргументы вполне себе, но то, в чем сошлись все участники дискуссии, так это в том, что как бы и вариант с приватными пакетами и вариант с сабмодулями плохи до ужаса.
1. Зависимости пакета и зависимости основного проекта могут отличаться. С сабмодулями контролировать версии зависимостей в некоторых языках тяжелей.
2. Обновление сабмодуля выглядит, как замена одного хеша в файлике на другой. Осознать что там поменялось без дополнительных действий тяжелей, чем при обновлении абстрактного пакета с версии 15 на версию 16. Там хотя бы ченджлог почитать можно.
3. При работе с отдельным пакетом проще абстрагироваться от основных проектов и сильно удобней писать независимый код. В отдельном пакете и тесты пишутся легче.
В общем, аргументы вполне себе, но то, в чем сошлись все участники дискуссии, так это в том, что как бы и вариант с приватными пакетами и вариант с сабмодулями плохи до ужаса.
При работе в команде, вопросов не возникает почему нужно придерживаться одного стиля написания, вплоть до решений ставить ли лишний отступ перед скобочками и использовать ли двойные или одинарные кавычки. Тут все очевидно и понятно. Но вот стоит принять работу над проектом от другого разработчика или вообще команды, то сразу же начинается ад. Сгущая краски приведенного примера, давайте скажем, что проект, который попал под вашу юрисдикцию писали несколько команд в разное время. Сначала одни, потом они свалили, потом другие, потом свалили и они, а потом проект достался вам.
Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.
Вот вам несколько правил работы с такими вот унаследованными проектами:
1. Отдельный мерж реквест может содержать либо логические изменения без изменений стиля написания кода либо изменения стиля во всем проекте сразу. Если вам не нравится использование, например, одинарных и двойных кавычек вперемешку, сделайте отдельный пулл реквест, в котором стандартизируйте использование кавычек во всем проекте сразу. А при решении непосредственной задачи используйте стиль, принятый в проекте на момент написания кода.
2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.
3. Писать тесты и рефакторить код нужно в разных пулл реквестах. При последовательных действиях мы сначала должны убедиться, что текущий код работает так, как он работает, а потом убедимся, что рефакторинг не сломал это поведение. Это не то же самое, что писать тесты и менять поведение приложения. Это делать можно так, как это обычно делается, одним пулл реквестом. Но если вы делаете какую-то фичу, в этом же пулл реквесте исправлять стиль кода всего приложения нельзя.
4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.
5. Используйте автоформатирование кода. Как правило, они все настраиваемые и вполне можно диктовать свой набор правил через конфигурационный файл прямо внутри проекта для всех его участников. После того, конечно же, как нарефакторились вдоволь и автоформатирование не меняет существующие файлы.
6. Прежде чем сделать пулл реквест на
7. Действуйте постепенно. Не нужно исправлять сразу все и сразу везде. Начните с малого и, скажем, возьмите за привычку вместе с утренним кофе делать маленький шаг в сторону стандартизации кода. Это не должно занимать много времени и каждодневные небольшие пулл реквесты сделают свое дело через пару недель.
8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.
#перечитываяэкстраполяцию
Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.
Вот вам несколько правил работы с такими вот унаследованными проектами:
1. Отдельный мерж реквест может содержать либо логические изменения без изменений стиля написания кода либо изменения стиля во всем проекте сразу. Если вам не нравится использование, например, одинарных и двойных кавычек вперемешку, сделайте отдельный пулл реквест, в котором стандартизируйте использование кавычек во всем проекте сразу. А при решении непосредственной задачи используйте стиль, принятый в проекте на момент написания кода.
2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.
3. Писать тесты и рефакторить код нужно в разных пулл реквестах. При последовательных действиях мы сначала должны убедиться, что текущий код работает так, как он работает, а потом убедимся, что рефакторинг не сломал это поведение. Это не то же самое, что писать тесты и менять поведение приложения. Это делать можно так, как это обычно делается, одним пулл реквестом. Но если вы делаете какую-то фичу, в этом же пулл реквесте исправлять стиль кода всего приложения нельзя.
4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.
5. Используйте автоформатирование кода. Как правило, они все настраиваемые и вполне можно диктовать свой набор правил через конфигурационный файл прямо внутри проекта для всех его участников. После того, конечно же, как нарефакторились вдоволь и автоформатирование не меняет существующие файлы.
6. Прежде чем сделать пулл реквест на
+100000 П -100000 строк кода, в котором вы исправляете все тот же тип кавычек, обойдите коллег и убедитесь что не сломаете никому жизнь таким пулл реквестом. Вдруг у кого-то затянулась текущая разработка и ему придется решать огромную пачку конфликтов. Вам решить эти конфликты будет значительно проще, чем другим.7. Действуйте постепенно. Не нужно исправлять сразу все и сразу везде. Начните с малого и, скажем, возьмите за привычку вместе с утренним кофе делать маленький шаг в сторону стандартизации кода. Это не должно занимать много времени и каждодневные небольшие пулл реквесты сделают свое дело через пару недель.
8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.
#перечитываяэкстраполяцию
Мнение из чата по поводу прошлой заметки, с которым я полностью согласен. Очень хорошо подмечено!
——
Основная проблема таких проектов как раз заключается в том, что каждый начинает его исправлять маленькими шажками, а потом его переводят на другой фронт, и его работа так и остаётся недоделанной. Поэтому, стоит делать не столько маленькие, сколько завершённые шаги, дабы не плодить ещё большее несоотвествия в коде проекта. Или же забить, если есть уверенность в том, что это изменение только на один раз, и больше не нужно будет трогать сие бедное тело, потому как потом будет проще его переписать, если будет нужно сделать какие-то более крупные изменения.
——
Основная проблема таких проектов как раз заключается в том, что каждый начинает его исправлять маленькими шажками, а потом его переводят на другой фронт, и его работа так и остаётся недоделанной. Поэтому, стоит делать не столько маленькие, сколько завершённые шаги, дабы не плодить ещё большее несоотвествия в коде проекта. Или же забить, если есть уверенность в том, что это изменение только на один раз, и больше не нужно будет трогать сие бедное тело, потому как потом будет проще его переписать, если будет нужно сделать какие-то более крупные изменения.
Теория избыточной информации, как подход к программированию. С ней я познакомился лет десять назад и совершенно забыл как она называется. Несколько раз были попытки восстановить знания гуглежом, но все тщетно. Быть может, кто-то знает правильное название этой штуки? Напишите в чат, пожалуйста. Сама теория очень простая и крайне очевидная: что-то, представленное в системе единожды является точкой отказа всей системы. Дублирование стоп-сигналов на автомобиле и двухфакторная аутентификация где-то об этом.
В программировании эта теория представлена в разных ипостасях, например в принципе «никому не доверяй». Это не о принципе работы в дружном коллективе, там и без этого принципа все не славабогу, а о взаимодействии между инкапсулированными участками кода (микросервисами или модулями, если угодно).
Один кусок кода должен быть морально готов к неожиданным запросам от другого куска кода и должен правильно реагировать на недостающие, избыточные и неправильные параметры. Это всегда так и абсолютно во всех случаях. Но вопрос исключительно в том, насколько вы готовы к наличию внезапных и редких ошибок. Если вы пишете софт к МРТ-аппарату, например, то доверие к входным параметрам должно отсутствовать вовсе и там, скорее всего, язык программирования будет выбираться строгий и суровый. Ежели это кусок кода, ошибки в котором в принципе изредка допустимы, то и проверок можно не сандалить, а довериться тестам и базовым возможностям компилятора-интерпретатора. К слову, тесты тоже к этому относятся и в числе прочего призваны снизить доверие к вызываемому методу.
Опять же, описывая какой-то интерфейс для вашего модуля или библиотеки, должно быть абсолютно наплавать где он собирается вызываться. Модуль решает конкретную задачу и требует конкретных аргументов и окружения, и на этом и нужно сосредоточиться. А как конкретно вот это вот вызывается прямо сейчас, второстепенно. Если помнить об этом при разработке, принцип «никому не доверяй» будет выходить как бы сам по себе.
В программировании эта теория представлена в разных ипостасях, например в принципе «никому не доверяй». Это не о принципе работы в дружном коллективе, там и без этого принципа все не славабогу, а о взаимодействии между инкапсулированными участками кода (микросервисами или модулями, если угодно).
Один кусок кода должен быть морально готов к неожиданным запросам от другого куска кода и должен правильно реагировать на недостающие, избыточные и неправильные параметры. Это всегда так и абсолютно во всех случаях. Но вопрос исключительно в том, насколько вы готовы к наличию внезапных и редких ошибок. Если вы пишете софт к МРТ-аппарату, например, то доверие к входным параметрам должно отсутствовать вовсе и там, скорее всего, язык программирования будет выбираться строгий и суровый. Ежели это кусок кода, ошибки в котором в принципе изредка допустимы, то и проверок можно не сандалить, а довериться тестам и базовым возможностям компилятора-интерпретатора. К слову, тесты тоже к этому относятся и в числе прочего призваны снизить доверие к вызываемому методу.
Опять же, описывая какой-то интерфейс для вашего модуля или библиотеки, должно быть абсолютно наплавать где он собирается вызываться. Модуль решает конкретную задачу и требует конкретных аргументов и окружения, и на этом и нужно сосредоточиться. А как конкретно вот это вот вызывается прямо сейчас, второстепенно. Если помнить об этом при разработке, принцип «никому не доверяй» будет выходить как бы сам по себе.
«Узаконить проще, чем получить разрешение.
Можно потратить кучу времени на согласование какого-то изменения, но того же самого можно было бы добиться намного проще, просто сделав.
Возможно, причина в том, что во втором случае высказываются только те, кто реально категорически не согласен с изменениями, а не все, кто просто любит дискуссии»
С автором этих слов мнения у нас разнятся, причём довольно сильно, но сейчас мне бы хотелось послушать ещё других мнений. Что вы думаете по этому поводу? Если хотите обсуждения, пишите в чатик, если хочется декларативного изложения или анонимности, то пишите мне в личку (@aratak) с тегом #узаконитьпроще, все сформулированные и не банальные мысли оформим постом.
Можно потратить кучу времени на согласование какого-то изменения, но того же самого можно было бы добиться намного проще, просто сделав.
Возможно, причина в том, что во втором случае высказываются только те, кто реально категорически не согласен с изменениями, а не все, кто просто любит дискуссии»
С автором этих слов мнения у нас разнятся, причём довольно сильно, но сейчас мне бы хотелось послушать ещё других мнений. Что вы думаете по этому поводу? Если хотите обсуждения, пишите в чатик, если хочется декларативного изложения или анонимности, то пишите мне в личку (@aratak) с тегом #узаконитьпроще, все сформулированные и не банальные мысли оформим постом.
Один из самых универсальных ответов на любой вопрос: «это от многого зависит». И в целом, на любую сформулированную мысль, на любое правило найдётся эксперт, который скажет, что правило неправильное и назовёт дюжину факторов, которые влияют на результат. Как правило, за чередой таких уточняющих вопросов господа эксперты пытаются скрыть свой непрофессионализм и неспособность строить логическую цепочку рассуждений по неполным данным.
— Всегда смывай за собой в туалете.
— Это не всегда так. Разработчик руки зашёл помыть может? Есть ли перебои с водоснабжением? А два подряд человека могут смыть один раз? Сломан ли бачок унитаза? Если не получилось сходить, нужно ли смывать? А если кнопка на бачке грязная? Дети в Африке голодают, быть может, экономить воду?
— Всегда смывай за собой в туалете.
— Это не всегда так. Разработчик руки зашёл помыть может? Есть ли перебои с водоснабжением? А два подряд человека могут смыть один раз? Сломан ли бачок унитаза? Если не получилось сходить, нужно ли смывать? А если кнопка на бачке грязная? Дети в Африке голодают, быть может, экономить воду?
Если ты одним движением навстречу меняешь и код и тесты — так бывает, да, бывает, что это нужно и оправдано — ты просто обязан потом задним числом поменять код назад, увидеть, что тест падает, и починить код.
Если этого не сделать, взаимодействие между частями может породить такое, блин.
Я тут сейчас наблюдаю, как незамутнённый фронтендер, неспособный вообще запускать тесты, пришёл и сделал фичу, очевидно, проверяя её на практике и она у него работала. Поменяв две строчки бекенда и сделав остальное на своей стороне. Но попадала половина тестов и пришёл замутнённый бэкендер. Он одним движением поменял код и тесты, тесты стали проходить, но... но он сломал фичу. Об этом он не узнал, поскольку в свою очередь, он это не запускал — тесты же есть.
Короче, если не было чистого движения "код починил тест", нужно предполагать, что ты себя обманываешь и ничего не работает.
#dimoneverything
Если этого не сделать, взаимодействие между частями может породить такое, блин.
Я тут сейчас наблюдаю, как незамутнённый фронтендер, неспособный вообще запускать тесты, пришёл и сделал фичу, очевидно, проверяя её на практике и она у него работала. Поменяв две строчки бекенда и сделав остальное на своей стороне. Но попадала половина тестов и пришёл замутнённый бэкендер. Он одним движением поменял код и тесты, тесты стали проходить, но... но он сломал фичу. Об этом он не узнал, поскольку в свою очередь, он это не запускал — тесты же есть.
Короче, если не было чистого движения "код починил тест", нужно предполагать, что ты себя обманываешь и ничего не работает.
#dimoneverything
Ребята, еще одна #экстравакансия от моего хорошего знакомого. Если чувствуете в себе силы, обязательно попробуйте. Резюме шлите сразу Павлу (@jtootf), у него же можно спросить остальные детали.
Работа удалённая контрактная и долговременная. Компания сервисная, своих продуктов пока не имеет, уровень текущих сотрудников очень высокий. поставленного процесса пока нет, офиса пока нет, а вот хорошие заказы за счёт репутации основателей есть. Компания еще очень маленькая, основатели находятся в Киеве.
Области деятельности - AI, data science, machine learning, computer vision. В данный момент - в области систем безопасности. Необходимые знания: хороший математический уровень (анализ, линейная алгебра, вычислительная геометрия, статистика), умение использовать оптимизировать и строить нейросетевые модели, свободное владение Python, способность читать научные работы и реализовывать предложенные там модели. инструментарий любой. Вилка зарплаты приблизительно $4k-$4.5k в месяц при полной загрузке.
Работа удалённая контрактная и долговременная. Компания сервисная, своих продуктов пока не имеет, уровень текущих сотрудников очень высокий. поставленного процесса пока нет, офиса пока нет, а вот хорошие заказы за счёт репутации основателей есть. Компания еще очень маленькая, основатели находятся в Киеве.
Области деятельности - AI, data science, machine learning, computer vision. В данный момент - в области систем безопасности. Необходимые знания: хороший математический уровень (анализ, линейная алгебра, вычислительная геометрия, статистика), умение использовать оптимизировать и строить нейросетевые модели, свободное владение Python, способность читать научные работы и реализовывать предложенные там модели. инструментарий любой. Вилка зарплаты приблизительно $4k-$4.5k в месяц при полной загрузке.
Ребята, 7 сентября в Киеве будет конференция «IT Weekend» и нас с вами туда зовут и даже скидку небольшую предлагают подписчикам «Экстраполяции» по кодовому слову
https://itweekend.events/event/it-weekend-ukraine-2019-ukrainian-it-awards-2019/
Кстати, на самой конфе, с помощью нашего чатика, можно будет скоординироваться и развиртуализироваться, да?
4itextrapolation. Я вот планирую посетить эту конфу, ведь обещают говорить о продуктовой разработке. В общем, приходите!https://itweekend.events/event/it-weekend-ukraine-2019-ukrainian-it-awards-2019/
Кстати, на самой конфе, с помощью нашего чатика, можно будет скоординироваться и развиртуализироваться, да?
Принципиально существует два вида обмена информацией в команде с условными названиями «push» и «pull».
Очевидно, что pull намного ленивее, потому как, собственно, делать ничего не надо: просто делаешь свою работу и всё. Если кому будет надо что, тот обратится и вытянет всю необходимую ему информацию. И его заботой будет убедится, что информации достаточно и ничего не упущено из виду. Если же что-то понадобится тебе, то задачей будет раздобыть и вытянуть всю нужную инфу. Понятное дело, что носитель сакраментальных знаний будет занят целую неделю и вообще ему не до ваших проблем. И передавать знания он будет по пути наименьшего сопротивления, мол «ты спрашивай что тебе надо, а я все отвечу и подготовь вопросы заранее, чтобы время не терять». В итоге передача знаний затягивается и бюрократизируется. Обработать и переварить ответы можно и не сразу и задать уточняющие вопросы наверняка нужно будет, а для этого отдельную встречу планируй и все по новой.
Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого
И вообще все современные методологии разработки в принципе нужны исключительно для того, чтобы уйти от принципа вытягивания знаний к процессам доступных и структурированных знаний о проекте и всех его процессах.
Хорошей аналогией, кстати, будут строгие и ленивые вычисления. Преимущества и недостатки будут приблизительно совпадать.
#полныйаджайл
Очевидно, что pull намного ленивее, потому как, собственно, делать ничего не надо: просто делаешь свою работу и всё. Если кому будет надо что, тот обратится и вытянет всю необходимую ему информацию. И его заботой будет убедится, что информации достаточно и ничего не упущено из виду. Если же что-то понадобится тебе, то задачей будет раздобыть и вытянуть всю нужную инфу. Понятное дело, что носитель сакраментальных знаний будет занят целую неделю и вообще ему не до ваших проблем. И передавать знания он будет по пути наименьшего сопротивления, мол «ты спрашивай что тебе надо, а я все отвечу и подготовь вопросы заранее, чтобы время не терять». В итоге передача знаний затягивается и бюрократизируется. Обработать и переварить ответы можно и не сразу и задать уточняющие вопросы наверняка нужно будет, а для этого отдельную встречу планируй и все по новой.
Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого
И вообще все современные методологии разработки в принципе нужны исключительно для того, чтобы уйти от принципа вытягивания знаний к процессам доступных и структурированных знаний о проекте и всех его процессах.
Хорошей аналогией, кстати, будут строгие и ленивые вычисления. Преимущества и недостатки будут приблизительно совпадать.
#полныйаджайл
#полныйаджайл от подписчика Михаила (@mgolubtsov), который не согласен с предыдущим постом.
———
В ИТ-индустрии при слове «аджайл» многие ошибочно первым делом думают о процессе, и о всяких скрамах, канбанах, митингах и командных ритуалах.
Если вспомнить «Аджайл манифест», то там самым первым принципом стоит «люди и взаимодействие важнее процессов и инструментов» и прежде всего это проявляется в подходе к решению проблем.
Допустим, у нас типичный случай – программист Иван реализовал фичу, её выкатили в продакшн, там возникла некоторая проблема и её нужно решить. Но Иван не может уделить этому 100% своего времени, потому что ему необходимо срочно подготовить отчёт на другом проекте. Поэтому к решению подключается Сергей, но документации почти нет, в код вникнуть сразу не получается, проблема не может быть решена вовремя.
Хороший скрам-мастер или тимлид сразу скажет, что тут же проблема с процессом! Документации нет, потому что нет правила писать документацию и нужно такое правило ввести и ещё в чеклист код-ревью это добавим и такой ситуации больше не будет.
А очень хороший тимлид или скрам-мастер обратит внимание, что у нас же проблема с коммуникацией. Почему Иван работал один и не смог передать знания о системе? На это может быть множество причин, причем некоторые из них чисто человеческие. Может быть нам нужно как-то изменить наш процесс, чтобы развивать культуру коммуникации, например, для более важных задач применять парное программирование. А может быть и не нужно, может быть дело в том, что Сергей сычует в другой комнате и отвечает по имейлу, и достаточно его просто пересадить поближе к Ивану. Готового рецепта нет, нужно разбираться и пробовать разное. Ключевой момент это в чем мы видим корень проблемы в процессе или в людях, в их коммуникации.
Если мы игнорируем людей, реальную культуру взаимодействия, а просто пытаемся построить Идеальный Процесс, в котором люди будут взаимозаменяемыми винтиками, то это вполне может привести к печальным последствиям. Например, Иван пишет подробную документацию, вместе с Сергеем в пул-реквесте они долго выясняют наилучшие формулировки и вводят стандарт форматирования диаграмм. Правда иногда всё равно в ключевой момент выясняется, что важный кусок документации забыли обновить или отписались формально. В итоге Сергей пишет Ивану раздраженный имейл с просьбой обновить документацию, Иван обновляет документацию и только тогда Сергей решает проблему. Все по правилам, но осадочек остался.
А может быть ребятам нужно просто поговорить и почаще вместе работать, тогда и проблемы не будет. Один из принципов манифеста об этом говорит: «Непосредственное (face-to-face) общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды».
В одной моей команде были трудности в общении. У нас были формальные ретроспективы с модератором, стикерами и четким таймингом, но напряжение накапливалось, пока однажды наш лид не предложил провести ретро в баре в неформальной обстановке. Это была наша лучшая ретроспектива, с наиболее осмысленными и классными дискуссиями! Просто людям не хватало атмосферы открытого общения в простом человеческом ключе.
Итак, процесс должен способствовать коммуникации в конкретной команде и ни в коем случае не мешать, потому что люди и их взаимодействие важнее. В аджайле есть множество практик и процессов, но пользоваться ими нужно мудро и аккуратно.
———
В ИТ-индустрии при слове «аджайл» многие ошибочно первым делом думают о процессе, и о всяких скрамах, канбанах, митингах и командных ритуалах.
Если вспомнить «Аджайл манифест», то там самым первым принципом стоит «люди и взаимодействие важнее процессов и инструментов» и прежде всего это проявляется в подходе к решению проблем.
Допустим, у нас типичный случай – программист Иван реализовал фичу, её выкатили в продакшн, там возникла некоторая проблема и её нужно решить. Но Иван не может уделить этому 100% своего времени, потому что ему необходимо срочно подготовить отчёт на другом проекте. Поэтому к решению подключается Сергей, но документации почти нет, в код вникнуть сразу не получается, проблема не может быть решена вовремя.
Хороший скрам-мастер или тимлид сразу скажет, что тут же проблема с процессом! Документации нет, потому что нет правила писать документацию и нужно такое правило ввести и ещё в чеклист код-ревью это добавим и такой ситуации больше не будет.
А очень хороший тимлид или скрам-мастер обратит внимание, что у нас же проблема с коммуникацией. Почему Иван работал один и не смог передать знания о системе? На это может быть множество причин, причем некоторые из них чисто человеческие. Может быть нам нужно как-то изменить наш процесс, чтобы развивать культуру коммуникации, например, для более важных задач применять парное программирование. А может быть и не нужно, может быть дело в том, что Сергей сычует в другой комнате и отвечает по имейлу, и достаточно его просто пересадить поближе к Ивану. Готового рецепта нет, нужно разбираться и пробовать разное. Ключевой момент это в чем мы видим корень проблемы в процессе или в людях, в их коммуникации.
Если мы игнорируем людей, реальную культуру взаимодействия, а просто пытаемся построить Идеальный Процесс, в котором люди будут взаимозаменяемыми винтиками, то это вполне может привести к печальным последствиям. Например, Иван пишет подробную документацию, вместе с Сергеем в пул-реквесте они долго выясняют наилучшие формулировки и вводят стандарт форматирования диаграмм. Правда иногда всё равно в ключевой момент выясняется, что важный кусок документации забыли обновить или отписались формально. В итоге Сергей пишет Ивану раздраженный имейл с просьбой обновить документацию, Иван обновляет документацию и только тогда Сергей решает проблему. Все по правилам, но осадочек остался.
А может быть ребятам нужно просто поговорить и почаще вместе работать, тогда и проблемы не будет. Один из принципов манифеста об этом говорит: «Непосредственное (face-to-face) общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды».
В одной моей команде были трудности в общении. У нас были формальные ретроспективы с модератором, стикерами и четким таймингом, но напряжение накапливалось, пока однажды наш лид не предложил провести ретро в баре в неформальной обстановке. Это была наша лучшая ретроспектива, с наиболее осмысленными и классными дискуссиями! Просто людям не хватало атмосферы открытого общения в простом человеческом ключе.
Итак, процесс должен способствовать коммуникации в конкретной команде и ни в коем случае не мешать, потому что люди и их взаимодействие важнее. В аджайле есть множество практик и процессов, но пользоваться ими нужно мудро и аккуратно.