Самое ужасное, что может случаться с архитектурой проекта — это приватные пакеты в зависимостях. Ну, это когда инфраструктура языка предусматривает пакетный менеджер и отдельный пакет просто так не поставишь и не обновишь, нужна какая-то аутентификация. И это плохо по нескольким причинам.

Во-первых это микроскоп с гвоздями. Пакетный менеджер предназначен для расширений возможности языка, а приватные пакеты решают проблему переиспользования одного кода бизнес логики между разными микросервисами или вообще приложениями.

Во-вторых это неудобно. Любое изменение в этом куске кода требует дополнительных усилий, сопоставимых с релизом небольшого приложения.

В-третьих, это не устраняет проблему дублирования, а только прячет её. Если вдруг в пакете будут какие-то изменения, то нужно будет сделать изменения во всех местах, где используется этот пакет.

В-четвёртых, приватность таких пакетов уж очень условная, ведь все необходимое записано в основном репозитории.

Если уж не удаётся разделить код по-нормальному, можно воспользоваться сабмодулями гита. Эффект будет такой же со всеми преимуществами и отсутствием недостатков.

Ребята, судя по лайкам под постом, тема неоднозначная. Короче я не выдержал и создал чатик для «Экстраполяции». Ссылка на него, вроде как должна быть внизу экрана — кнопочка «Discuss». Там уже, к слову, обсуждение понеслось. Присоединяйтесь!

Не устаю повторять, что только понимание противоположного мнения может сделать меня лучше. Так и со вчерашней мыслью про сабмодули. В созданном чатике и личными сообщениями было несколько аргументов в пользу приватных пакетов.

1. Зависимости пакета и зависимости основного проекта могут отличаться. С сабмодулями контролировать версии зависимостей в некоторых языках тяжелей.

2. Обновление сабмодуля выглядит, как замена одного хеша в файлике на другой. Осознать что там поменялось без дополнительных действий тяжелей, чем при обновлении абстрактного пакета с версии 15 на версию 16. Там хотя бы ченджлог почитать можно.

3. При работе с отдельным пакетом проще абстрагироваться от основных проектов и сильно удобней писать независимый код. В отдельном пакете и тесты пишутся легче.

В общем, аргументы вполне себе, но то, в чем сошлись все участники дискуссии, так это в том, что как бы и вариант с приватными пакетами и вариант с сабмодулями плохи до ужаса.

При работе в команде, вопросов не возникает почему нужно придерживаться одного стиля написания, вплоть до решений ставить ли лишний отступ перед скобочками и использовать ли двойные или одинарные кавычки. Тут все очевидно и понятно. Но вот стоит принять работу над проектом от другого разработчика или вообще команды, то сразу же начинается ад. Сгущая краски приведенного примера, давайте скажем, что проект, который попал под вашу юрисдикцию писали несколько команд в разное время. Сначала одни, потом они свалили, потом другие, потом свалили и они, а потом проект достался вам.

Самое страшное в таком вот проекте — это неопределенность. Работать с таким проектом, как общаться с множественными личностями Билли Миллигана — каждый раз большая загадка что ждет в следующей строчке повествования. Каждый следующий разработчик видит какой ужас происходит в исходном коде вот этого вот файла и старается новый код писать, как ему кажется, хорошо, чем только усугубляет ситуацию, ведь до него проект был написан в N стилях, а теперь он написан в N+1 стилях. И абсолютно неважно насколько неправы предыдущие разработчики и насколько прав текущий.

Вот вам несколько правил работы с такими вот унаследованными проектами:

1. Отдельный мерж реквест может содержать либо логические изменения без изменений стиля написания кода либо изменения стиля во всем проекте сразу. Если вам не нравится использование, например, одинарных и двойных кавычек вперемешку, сделайте отдельный пулл реквест, в котором стандартизируйте использование кавычек во всем проекте сразу. А при решении непосредственной задачи используйте стиль, принятый в проекте на момент написания кода.

2. Рефакторить код, на который нет тестов недопустимо. Объяснение очевидно.

3. Писать тесты и рефакторить код нужно в разных пулл реквестах. При последовательных действиях мы сначала должны убедиться, что текущий код работает так, как он работает, а потом убедимся, что рефакторинг не сломал это поведение. Это не то же самое, что писать тесты и менять поведение приложения. Это делать можно так, как это обычно делается, одним пулл реквестом. Но если вы делаете какую-то фичу, в этом же пулл реквесте исправлять стиль кода всего приложения нельзя.

4. Если хочется рефакторить во время исправления багов, то сначала выполняем пункт 3. Сначала тесты, потом рефактринг, потом фиксы. Или сначала тесты, потом фиксы, потом опять тесты, потом рефакторинг. Отдельными пулл реквестами и в строго такой последовательности.

5. Используйте автоформатирование кода. Как правило, они все настраиваемые и вполне можно диктовать свой набор правил через конфигурационный файл прямо внутри проекта для всех его участников. После того, конечно же, как нарефакторились вдоволь и автоформатирование не меняет существующие файлы.

6. Прежде чем сделать пулл реквест на +100000 П -100000 строк кода, в котором вы исправляете все тот же тип кавычек, обойдите коллег и убедитесь что не сломаете никому жизнь таким пулл реквестом. Вдруг у кого-то затянулась текущая разработка и ему придется решать огромную пачку конфликтов. Вам решить эти конфликты будет значительно проще, чем другим.

7. Действуйте постепенно. Не нужно исправлять сразу все и сразу везде. Начните с малого и, скажем, возьмите за привычку вместе с утренним кофе делать маленький шаг в сторону стандартизации кода. Это не должно занимать много времени и каждодневные небольшие пулл реквесты сделают свое дело через пару недель.

8. Поделитесь этими намерениями с коллегами и убедитесь, что вы с ними на одной волне. Если они не хотят вам помогать в стандартизации, то пусть хотя бы не мешают и примут эти правила. Можно взять вот это сообщение и отправить в рабочий чат с предложением вроде «Как раз про наш проект рассказывают. Давайте так сделаем?». С большой радостью услышу возражения и отговорки коллег, если конечно же такие будут.

#перечитываяэкстраполяцию

Мнение из чата по поводу прошлой заметки, с которым я полностью согласен. Очень хорошо подмечено!

——

Основная проблема таких проектов как раз заключается в том, что каждый начинает его исправлять маленькими шажками, а потом его переводят на другой фронт, и его работа так и остаётся недоделанной. Поэтому, стоит делать не столько маленькие, сколько завершённые шаги, дабы не плодить ещё большее несоотвествия в коде проекта. Или же забить, если есть уверенность в том, что это изменение только на один раз, и больше не нужно будет трогать сие бедное тело, потому как потом будет проще его переписать, если будет нужно сделать какие-то более крупные изменения.

Теория избыточной информации, как подход к программированию. С ней я познакомился лет десять назад и совершенно забыл как она называется. Несколько раз были попытки восстановить знания гуглежом, но все тщетно. Быть может, кто-то знает правильное название этой штуки? Напишите в чат, пожалуйста. Сама теория очень простая и крайне очевидная: что-то, представленное в системе единожды является точкой отказа всей системы. Дублирование стоп-сигналов на автомобиле и двухфакторная аутентификация где-то об этом.

В программировании эта теория представлена в разных ипостасях, например в принципе «никому не доверяй». Это не о принципе работы в дружном коллективе, там и без этого принципа все не славабогу, а о взаимодействии между инкапсулированными участками кода (микросервисами или модулями, если угодно).

Один кусок кода должен быть морально готов к неожиданным запросам от другого куска кода и должен правильно реагировать на недостающие, избыточные и неправильные параметры. Это всегда так и абсолютно во всех случаях. Но вопрос исключительно в том, насколько вы готовы к наличию внезапных и редких ошибок. Если вы пишете софт к МРТ-аппарату, например, то доверие к входным параметрам должно отсутствовать вовсе и там, скорее всего, язык программирования будет выбираться строгий и суровый. Ежели это кусок кода, ошибки в котором в принципе изредка допустимы, то и проверок можно не сандалить, а довериться тестам и базовым возможностям компилятора-интерпретатора. К слову, тесты тоже к этому относятся и в числе прочего призваны снизить доверие к вызываемому методу.

Опять же, описывая какой-то интерфейс для вашего модуля или библиотеки, должно быть абсолютно наплавать где он собирается вызываться. Модуль решает конкретную задачу и требует конкретных аргументов и окружения, и на этом и нужно сосредоточиться. А как конкретно вот это вот вызывается прямо сейчас, второстепенно. Если помнить об этом при разработке, принцип «никому не доверяй» будет выходить как бы сам по себе.

«Узаконить проще, чем получить разрешение.
Можно потратить кучу времени на согласование какого-то изменения, но того же самого можно было бы добиться намного проще, просто сделав.
Возможно, причина в том, что во втором случае высказываются только те, кто реально категорически не согласен с изменениями, а не все, кто просто любит дискуссии»

С автором этих слов мнения у нас разнятся, причём довольно сильно, но сейчас мне бы хотелось послушать ещё других мнений. Что вы думаете по этому поводу? Если хотите обсуждения, пишите в чатик, если хочется декларативного изложения или анонимности, то пишите мне в личку (@aratak) с тегом #узаконитьпроще, все сформулированные и не банальные мысли оформим постом.

Один из самых универсальных ответов на любой вопрос: «это от многого зависит». И в целом, на любую сформулированную мысль, на любое правило найдётся эксперт, который скажет, что правило неправильное и назовёт дюжину факторов, которые влияют на результат. Как правило, за чередой таких уточняющих вопросов господа эксперты пытаются скрыть свой непрофессионализм и неспособность строить логическую цепочку рассуждений по неполным данным.

— Всегда смывай за собой в туалете.
— Это не всегда так. Разработчик руки зашёл помыть может? Есть ли перебои с водоснабжением? А два подряд человека могут смыть один раз? Сломан ли бачок унитаза? Если не получилось сходить, нужно ли смывать? А если кнопка на бачке грязная? Дети в Африке голодают, быть может, экономить воду?

Если ты одним движением навстречу меняешь и код и тесты — так бывает, да, бывает, что это нужно и оправдано — ты просто обязан потом задним числом поменять код назад, увидеть, что тест падает, и починить код.

Если этого не сделать, взаимодействие между частями может породить такое, блин.

Я тут сейчас наблюдаю, как незамутнённый фронтендер, неспособный вообще запускать тесты, пришёл и сделал фичу, очевидно, проверяя её на практике и она у него работала. Поменяв две строчки бекенда и сделав остальное на своей стороне. Но попадала половина тестов и пришёл замутнённый бэкендер. Он одним движением поменял код и тесты, тесты стали проходить, но... но он сломал фичу. Об этом он не узнал, поскольку в свою очередь, он это не запускал — тесты же есть.

Короче, если не было чистого движения "код починил тест", нужно предполагать, что ты себя обманываешь и ничего не работает.

#dimoneverything

Ребята, еще одна #экстравакансия от моего хорошего знакомого. Если чувствуете в себе силы, обязательно попробуйте. Резюме шлите сразу Павлу (@jtootf), у него же можно спросить остальные детали.

Работа удалённая контрактная и долговременная. Компания сервисная, своих продуктов пока не имеет, уровень текущих сотрудников очень высокий. поставленного процесса пока нет, офиса пока нет, а вот хорошие заказы за счёт репутации основателей есть. Компания еще очень маленькая, основатели находятся в Киеве.

Области деятельности - AI, data science, machine learning, computer vision. В данный момент - в области систем безопасности. Необходимые знания: хороший математический уровень (анализ, линейная алгебра, вычислительная геометрия, статистика), умение использовать оптимизировать и строить нейросетевые модели, свободное владение Python, способность читать научные работы и реализовывать предложенные там модели. инструментарий любой. Вилка зарплаты приблизительно $4k-$4.5k в месяц при полной загрузке.

Ребята, 7 сентября в Киеве будет конференция «IT Weekend» и нас с вами туда зовут и даже скидку небольшую предлагают подписчикам «Экстраполяции» по кодовому слову 4itextrapolation. Я вот планирую посетить эту конфу, ведь обещают говорить о продуктовой разработке. В общем, приходите!

https://itweekend.events/event/it-weekend-ukraine-2019-ukrainian-it-awards-2019/

Кстати, на самой конфе, с помощью нашего чатика, можно будет скоординироваться и развиртуализироваться, да?

Принципиально существует два вида обмена информацией в команде с условными названиями «push» и «pull».

Очевидно, что pull намного ленивее, потому как, собственно, делать ничего не надо: просто делаешь свою работу и всё. Если кому будет надо что, тот обратится и вытянет всю необходимую ему информацию. И его заботой будет убедится, что информации достаточно и ничего не упущено из виду. Если же что-то понадобится тебе, то задачей будет раздобыть и вытянуть всю нужную инфу. Понятное дело, что носитель сакраментальных знаний будет занят целую неделю и вообще ему не до ваших проблем. И передавать знания он будет по пути наименьшего сопротивления, мол «ты спрашивай что тебе надо, а я все отвечу и подготовь вопросы заранее, чтобы время не терять». В итоге передача знаний затягивается и бюрократизируется. Обработать и переварить ответы можно и не сразу и задать уточняющие вопросы наверняка нужно будет, а для этого отдельную встречу планируй и все по новой.

Способ с кодовым названием «push» напротив сосредотачивается на том, что весь процесс тщательно записывается и ответы на все вопросы уже как бы есть и ничего узнавать ни у кого не нужно. Достаточно просто знать где искать. Этот подход более требователен как к исполнителям, так и к менеджерам, ведь любой чих и пук должен быть запротоколирован и каталогизирован. Был выбор между двумя библиотеками? Нужно описать все сомнения, факторы, повлиявшие на решение и само решение в специальное место, чтобы если вдруг у кого-то появится желание использовать противоположную библиотеку, он мог узнать о предыдущем решении и проникнуться всеми сомнениями прошлого исполнителя. Прилетело резюме от кандидата, с которым мы уже имели дело в прошлом? Об этом нужно незамедлительно узнать и выяснить все детали прошлого расставания или отказа. Недостатком такого подхода будет стабильно увеличенное время разработки. А серьезной проблемой будет простая человеческая лень и забывчивость. А самое сложное в этом подходе будет придумывание структуры хранения всего этого

И вообще все современные методологии разработки в принципе нужны исключительно для того, чтобы уйти от принципа вытягивания знаний к процессам доступных и структурированных знаний о проекте и всех его процессах.

Хорошей аналогией, кстати, будут строгие и ленивые вычисления. Преимущества и недостатки будут приблизительно совпадать.

#полныйаджайл

#полныйаджайл от подписчика Михаила (@mgolubtsov), который не согласен с предыдущим постом.

———

В ИТ-индустрии при слове «аджайл» многие ошибочно первым делом думают о процессе, и о всяких скрамах, канбанах, митингах и командных ритуалах.

Если вспомнить «Аджайл манифест», то там самым первым принципом стоит «люди и взаимодействие важнее процессов и инструментов» и прежде всего это проявляется в подходе к решению проблем.

Допустим, у нас типичный случай – программист Иван реализовал фичу, её выкатили в продакшн, там возникла некоторая проблема и её нужно решить. Но Иван не может уделить этому 100% своего времени, потому что ему необходимо срочно подготовить отчёт на другом проекте. Поэтому к решению подключается Сергей, но документации почти нет, в код вникнуть сразу не получается, проблема не может быть решена вовремя.

Хороший скрам-мастер или тимлид сразу скажет, что тут же проблема с процессом! Документации нет, потому что нет правила писать документацию и нужно такое правило ввести и ещё в чеклист код-ревью это добавим и такой ситуации больше не будет.

А очень хороший тимлид или скрам-мастер обратит внимание, что у нас же проблема с коммуникацией. Почему Иван работал один и не смог передать знания о системе? На это может быть множество причин, причем некоторые из них чисто человеческие. Может быть нам нужно как-то изменить наш процесс, чтобы развивать культуру коммуникации, например, для более важных задач применять парное программирование. А может быть и не нужно, может быть дело в том, что Сергей сычует в другой комнате и отвечает по имейлу, и достаточно его просто пересадить поближе к Ивану. Готового рецепта нет, нужно разбираться и пробовать разное. Ключевой момент это в чем мы видим корень проблемы в процессе или в людях, в их коммуникации.

Если мы игнорируем людей, реальную культуру взаимодействия, а просто пытаемся построить Идеальный Процесс, в котором люди будут взаимозаменяемыми винтиками, то это вполне может привести к печальным последствиям. Например, Иван пишет подробную документацию, вместе с Сергеем в пул-реквесте они долго выясняют наилучшие формулировки и вводят стандарт форматирования диаграмм. Правда иногда всё равно в ключевой момент выясняется, что важный кусок документации забыли обновить или отписались формально. В итоге Сергей пишет Ивану раздраженный имейл с просьбой обновить документацию, Иван обновляет документацию и только тогда Сергей решает проблему. Все по правилам, но осадочек остался.

А может быть ребятам нужно просто поговорить и почаще вместе работать, тогда и проблемы не будет. Один из принципов манифеста об этом говорит: «Непосредственное (face-to-face) общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды».
В одной моей команде были трудности в общении. У нас были формальные ретроспективы с модератором, стикерами и четким таймингом, но напряжение накапливалось, пока однажды наш лид не предложил провести ретро в баре в неформальной обстановке. Это была наша лучшая ретроспектива, с наиболее осмысленными и классными дискуссиями! Просто людям не хватало атмосферы открытого общения в простом человеческом ключе.

Итак, процесс должен способствовать коммуникации в конкретной команде и ни в коем случае не мешать, потому что люди и их взаимодействие важнее. В аджайле есть множество практик и процессов, но пользоваться ими нужно мудро и аккуратно.

Появилось новое слово в лексиконе: «bulk-approve».

Чувак отметил меня и старину Эда и пинганул обоих в слаке.
Пулл-реквестов десять где-то.
Пока я писал ответ на первый, старина Эд балк-аппрувнул всё. А те из них, где уже был ещё какой аппув случайный тут же смержил.

#dimoneverything

​​Эйнштейн помогает с пулл реквестом.

Задачи, о которых просят пользователи.

Существует небезосновательный миф о том, что делать нужно только те задачи, о которых прям умоляют пользователи, а те, о которых не просят, делать не надо. Это как бы и не миф вовсе, задачи действительно нужно делать только тогда, когда они будут полезны пользователям, но вот интерпретация пользовательских реквестов — это прям целое искусство.

Есть две крайности, ударяться в которые будет очень плохо.

Первая крайность бездумно потакает всем похотям пользователей и максимум что делает — группирует входящие запросы по подобию. А если в команде есть бизнес-аналитик, то ещё очень быстро появляется желание оценивать полезность реквестов и отсеивать их. Мол, «удовлетворим 20% вот этих желаний, получим 80% выгоды, а на остальные подзабьём» или ещё как-то так. Принципиально аналитики картины не меняют, хотя да, эффективность повышают.

Вторая крайность говорит, что нужно вообще забить на отдельные реквесты пользователей и даже не пытаться их записывать. Те штуки, которые действительно нужно делать, будут сниться в ночных кошмарах всем членам команды. Пользователи прям достанут, умоляя сделать ту или иную фичу.

А фишка в том, что пользовательским запросам нужно относиться, как к капризам и просьбам своего ребёнка. Когда дети хотят конфету, это скорее значит, что им надо дать каши. Это в том смысле, что комбинация из понимания потребностей пользователей, причин, вызывающих эти потребности и того, как пользователи это интерпретируют, может дать очень хорошее видение будущих фич. Но никак не прямое исполнение декларируемых желаний.

90% кодревью на практике неотличимы от code-style тестов, которое вроде бы должен делать CI. В смысле, замечания, которые люди пишут в пулл-реквесты, такие же, как должен был бы написать сильно продвинутый CI. Мол, а тесты где? А тесты твои не тестят нифига — ты попробуй, код свой удали, и посмотри, проходят? Да, проходят. Вот и выкинь свои моки. Отступы поправь. Английский выучи, индус, прежде, чем многострочные комменты писать — тут the надо. Метод приватным сделай. В раутах весь ресурс не открывай. И индекс на поле поставь.

Понятное дело, что кодревью должен быть другим, но речь тут о практике, а не о теории.

#dimoneverything

Ещё одна #экстравакансия, на этот раз ищу я и ищу фронтендера с большой буквы Ф в продуктовую разработку.

Работать будем на острие прогресса и писать предстоит на реакте, а данные получать с помощью графкюэль и вебсокетов. Вкуснота. Ещё вместе с джаваскриптом предстоит заняться и версткой тоже, поэтому чувство прекрасного должно быть развито не по годам.

Работа будет удаленная, само собой, но увидеться и поработать вместе недельку-другую можно будет в Киеве. Пишите мне в личку (@aratak) и отправляйте это сообщение знакомым джаваскриптизёрам. Спасибо.

Ребята, я читал и плакал. Дмитрий, в рамках тега #dimoneverything решил попробовать слегка по-другому мысли свои передать и у него это получилось просто превосходно.

https://telegra.ph/Full-stek-matros-08-29

Ребята, инфопартнерство. В Одессе в конце сентября будет хакатон. Всем, кто как-то связан с визуализацией информации, хакатон этот будет интересней, чем тем, кто не связан. Это я так, типа, дизайнеров обозвал. В общем, обратите внимание, мне кажется, что это может быть интересным.

https://hackodessa.photolab.me/