Недавно был пост про то, как выбирать арбузы, помните? Мне тут подумалось об этом процессе немного с другой стороны.
Задача перед покупателем стоит достаточно простая — выбрать хороший арбуз, который будет чётко выполнять свои задачи и оправдает все возложенные на него ожидания. Некоторые амбициозно пытаются выбрать лучший арбуз, перебирая все подряд. Некоторые покупают десяток в надежде получить хотя бы половину хороших. Большинство примечают пяток арбузов и сосредоточивают своё внимание на них, пристально изучая каждый. И уже из этих кандидатов только один пройдёт собеседование и тестовое задание.
Очевидно, что самый верный способ определить качество арбуза — это вырезать такой маленький треугольничек и посмотреть что же там внутри. А может ещё и попробовать на вкус эту пирамидку из арбуза. Способ, безусловно, результативный, но вот только арбузу не очень нравится, когда от него отрезают кусочек, кусают и кладут назад в кучу кандидатов.
С другой стороны, большинство арбузов хотят, чтобы их просто брали и платили, без всяких предварительных игрищ, но такое себе могут позволить только те, кому не важен вкус арбуза и кто покупает арбузы не себе, а перепродаёт их.
Отсюда и имеем стотыщмильенов способов интервьюировать кандидатов с более или менее одинаковой результативностью.
#экстрасобеседование
Задача перед покупателем стоит достаточно простая — выбрать хороший арбуз, который будет чётко выполнять свои задачи и оправдает все возложенные на него ожидания. Некоторые амбициозно пытаются выбрать лучший арбуз, перебирая все подряд. Некоторые покупают десяток в надежде получить хотя бы половину хороших. Большинство примечают пяток арбузов и сосредоточивают своё внимание на них, пристально изучая каждый. И уже из этих кандидатов только один пройдёт собеседование и тестовое задание.
Очевидно, что самый верный способ определить качество арбуза — это вырезать такой маленький треугольничек и посмотреть что же там внутри. А может ещё и попробовать на вкус эту пирамидку из арбуза. Способ, безусловно, результативный, но вот только арбузу не очень нравится, когда от него отрезают кусочек, кусают и кладут назад в кучу кандидатов.
С другой стороны, большинство арбузов хотят, чтобы их просто брали и платили, без всяких предварительных игрищ, но такое себе могут позволить только те, кому не важен вкус арбуза и кто покупает арбузы не себе, а перепродаёт их.
Отсюда и имеем стотыщмильенов способов интервьюировать кандидатов с более или менее одинаковой результативностью.
#экстрасобеседование
Один из самых злых паттернов офисной работы, которую переносят на удаленную — это ежедневные митинги. По-большому счёту, и очные митинги в офисах не справляются с основной задачей распространения знаний между всеми членами команды, но там хотя бы есть элементы социальщины (когда всех собирают в одной комнате и они вынуждены смотреть друг другу в глаза), но вот онлайн созвоны лишены даже этого. Говорящий в микрофон внимательно смотрит в подготовленные заметки, а слушающий в наушниках в это время ленты соцсетей листать может.
Ещё один стрёмный офисный паттерн перекочевавший в удаленку — это фиксированные часы работы. Находясь в разных часовых поясах, с разными привычками, в разных условиях разработчики вынуждены работать не в самый эффективный способ. И в подавляющем большинстве случаев это требуется только потому, что топ-менеджер из каких-нибудь Штатов мог в своё рабочее время быстро написать и быстро получить ответ.
#экстраудаленка
Ещё один стрёмный офисный паттерн перекочевавший в удаленку — это фиксированные часы работы. Находясь в разных часовых поясах, с разными привычками, в разных условиях разработчики вынуждены работать не в самый эффективный способ. И в подавляющем большинстве случаев это требуется только потому, что топ-менеджер из каких-нибудь Штатов мог в своё рабочее время быстро написать и быстро получить ответ.
#экстраудаленка
Ещё одно жестокое издевательство над удаленными сотрудниками — это программы слежения. Которые пробег мыши фиксируют и скриншоты делают (некоторые даже вебкамеру заставляют включать, но такое редко встречается и вообще уже клинический случай). Оправдывается это никак, а навязывается с аргументацией «тыж работаешь и скрывать тебе нечего».
Дело в том, что офисные сотрудники находятся под бдительным контролем все рабочее время, а за «удаленщиками» так следить не получается, а хочется по аналогии с офисными. Отсюда и такое решение.
Правильный же подход крайне прост. Всего-то нужно полное доверие сотрудникам.
И абсолютно не важно, врет ли начальству сотрудник или не врет. Важно есть ли у начальства сомнения по поводу честности или нет. Если есть хоть какие-то сомнения — нужно сразу же расставаться. Ну, и само собой, сотруднику важно не давать повода сомневаться в своей честности.
#экстраудаленка
Дело в том, что офисные сотрудники находятся под бдительным контролем все рабочее время, а за «удаленщиками» так следить не получается, а хочется по аналогии с офисными. Отсюда и такое решение.
Правильный же подход крайне прост. Всего-то нужно полное доверие сотрудникам.
И абсолютно не важно, врет ли начальству сотрудник или не врет. Важно есть ли у начальства сомнения по поводу честности или нет. Если есть хоть какие-то сомнения — нужно сразу же расставаться. Ну, и само собой, сотруднику важно не давать повода сомневаться в своей честности.
#экстраудаленка
В тему предыдущего поста главы подписчик напомнил анекдот в тему:
– Василий Иваныч, как же вы у англичан в карты выиграли?!
– Да понимаешь, Петька, сели мы с ихними лордами в очко сыграть. Один и говорит: «очко!». я ему:
– Покажи! А он мне: «ну что вы, Василий Иванович, мы же тут все джентльмены, а джентльмен верит другому джентельмену на слово».
И вот тут мне, Петька, карта и попёрла...
– Василий Иваныч, как же вы у англичан в карты выиграли?!
– Да понимаешь, Петька, сели мы с ихними лордами в очко сыграть. Один и говорит: «очко!». я ему:
– Покажи! А он мне: «ну что вы, Василий Иванович, мы же тут все джентльмены, а джентльмен верит другому джентельмену на слово».
И вот тут мне, Петька, карта и попёрла...
Помнится, некоторое время назад, «верстальщик» и «тестировщик» считались крайне обидными ругательствами, дошло до того, что сейчас эти названия вообще встретишь редко. Кругом сплошные «кюэйщики» и «фронтендеры». Причины такого переименования достаточно очевидны, чтобы о них целым постом мусолить.
А рассказать я хотел о двух новых самоидентификацих разных профессий. Одно из них шуточное, а второе настоящее. Проголосуйте за название профессии, которое вам кажется настоящим. Мне почему-то кажется, что выбор не очень-то и очевиден.
А рассказать я хотел о двух новых самоидентификацих разных профессий. Одно из них шуточное, а второе настоящее. Проголосуйте за название профессии, которое вам кажется настоящим. Мне почему-то кажется, что выбор не очень-то и очевиден.
Как и предполагалось, реальная должность и выдуманная с первого взгляда неотличимы. Абсурдно (и в то же время довольно пафосно) звучит как и «адвокат талантов», так и «сомелье пользовательских интерфейсов».
Понятное дело, что профессиями эти штуки назвать сложно, это скорее связано с самоидентификацией. Как себя чувствует и к кому причисляет тот или иной специалист.
И как тут не вспомнить гендерную самоидентификацию, где количество вариантов уже превышает все разумные и неразумные пределы. В некоторых фейсбуках дошло уже до множественного гендерного выбора, что абсурдно уже даже с точки зрения понятия «гендер».
В общем, друзья, идентифицировать себя можно как угодно и причислять себя к любой группе людей. Но врачей будет на выбор только два: андролог и гинеколог.
Понятное дело, что профессиями эти штуки назвать сложно, это скорее связано с самоидентификацией. Как себя чувствует и к кому причисляет тот или иной специалист.
И как тут не вспомнить гендерную самоидентификацию, где количество вариантов уже превышает все разумные и неразумные пределы. В некоторых фейсбуках дошло уже до множественного гендерного выбора, что абсурдно уже даже с точки зрения понятия «гендер».
В общем, друзья, идентифицировать себя можно как угодно и причислять себя к любой группе людей. Но врачей будет на выбор только два: андролог и гинеколог.
Самый дикий и ужасный вид контрактной работы у разработчиков — это аутстаф. Конечно, виды аутстафа бывают разные, но вот хороших среди них все-равно нет.
Аутстаф, когда сейлз-менеджер берет проценты с контракта. Аутстаф — если разработчиков нанимают под проект отдельно. Он же, когда одна аутсорс-компания арендует у другой «срочного ангулар разработчика».
Еще о нём же можно говорить, когда заказчик не знает кто конкретно пишет код, а общается с посредниками, то бишь менеджерской прослойкой.
Последне, как по мне, вообще верх цинизма. Это когда заказчик, скажем, из Германии, хочет заказать разработку у компании, скажем, из Мюнхена, а та покупает разработчиков у киевской аутстаф-компании и выступает только лишь посредником между заказчиком и исполнителями. Это ещё хоть как-то можно было оправдать в двухтысячном и совершенно лишено логики сейчас.
Аутстаф, когда сейлз-менеджер берет проценты с контракта. Аутстаф — если разработчиков нанимают под проект отдельно. Он же, когда одна аутсорс-компания арендует у другой «срочного ангулар разработчика».
Еще о нём же можно говорить, когда заказчик не знает кто конкретно пишет код, а общается с посредниками, то бишь менеджерской прослойкой.
Последне, как по мне, вообще верх цинизма. Это когда заказчик, скажем, из Германии, хочет заказать разработку у компании, скажем, из Мюнхена, а та покупает разработчиков у киевской аутстаф-компании и выступает только лишь посредником между заказчиком и исполнителями. Это ещё хоть как-то можно было оправдать в двухтысячном и совершенно лишено логики сейчас.
Общение в чатах в большинстве своём придерживается неких норм этикета, соблюдать которые никто не учит и списком такие правила нигде не найдёшь. Некоторые правила настолько естественны, что не соблюдать их — высшее неуважение к собеседнику. Одно 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/
Кстати, на самой конфе, с помощью нашего чатика, можно будет скоординироваться и развиртуализироваться, да?