Причины провалов сложных архитектур

Лекция для Innopolis University. Главные причины провалов сложных архитектур

Расшифровка видео
0:00
Здравствуйте, рады приветствовать всех слушателей передовой инженерной школы. Сегодня вебинар «Главные причины провалов сложных архитектур»
0:08
проведёт Бугаенко Егор Георгиевич, магистр компьютерных наук, руководитель лаборатории системного программирования Huawei,
0:17
сертифицированный разработчик и архитектор программного обеспечения, автор серии книг об объектно-ориентированном программировании,
0:24
блогер и влогер, преподаватель высшей школы экономики в инжерситете Иннополис.
0:31
Мы рады всех приветствовать, спасибо, что нашли время, и предоставляю слово Егору Георгиевичу, пожалуйста.
0:37
Ждём ваши вопросы, ну, вероятнее всего лучше в конце основного доклада Егора Георгиевича.
0:45
Пожалуйста, Егор, вам слово. Спасибо большое. Мне очень приятно рассказывать о том, о чём я буду рассказывать.
0:53
Мне кажется, аудитория весьма заинтересованная. Тему я выбрал достаточно широкую.
1:00
Я так понимаю, что наша задача сделать такой обзор
1:06
тех знаний, которыми я могу поделиться. То есть я буду не что-то конкретно рассказывать,
1:12
не какие-то технические глубокие детали, а таким широким охватом по проблеме, которая касается качественных архитектур.
1:21
Проблема, она с одной стороны, достаточно практическая, потому что касается, собственно, программистов, которые создают эти архитектуры,
1:29
то есть инженеров. Но с другой стороны, на мой взгляд, она содержит в себе и много науки,
1:35
содержит много того, что можно исследовать, из чего можно делать такие широкие абстрактные выводы.
1:42
В общем, посмотрим. Я посмотрите из доклада, о чём я скажу, и сами для себя сделайте выводы, что вам полезно, что нет.
1:49
Я разделил на 10 шагов, на 10 советов, которые я мог бы дать практикующим архитекторам
1:55
и тем людям, которые изучают архитектуры, изучают подходы, которые к софтверным, программным архитектурам применяются.
2:03
10 шагов, вот мы по ним пройдёмся. Они все, это всё 10 причин, даже не 10 шагов,
2:09
10 причин, по которым, на мой взгляд, сложные системы компьютерные, архитектуры, можно их так назвать, проваливаются.
2:19
То есть что-то идёт не так, приводит это всё не так к проблемам,
2:26
к потерям времени, к потерям пользователей, к ошибкам, которыми сталкиваются юзеры и так далее.
2:33
10 причин, которые, мне кажется, если их устранить, каждую из них, если по крайней мере обратить внимание на каждую из них,
2:40
то жизнь станет лучше у разработчиков, у пользователей, у всех. Итак, начнём. Первое, что я думаю, является… Я их не в каком-то конкретном порядке рассортировал,
2:50
попытаюсь просто пойти так приблизительно от более… от более… не то что высокоуровневых,
3:01
от причин, касающихся людей, и дальше, всё дальше и дальше, к причинам, касающихся программного обеспечения,
3:11
или может быть даже аппаратного обеспечения. От мягких причин к жёстким причинам, или как сейчас говорят, от soft к hard.
3:19
Итак, самая распространённая причина провалов, на мой взгляд, это большое количество архитекторов.
3:25
Существует такое мнение в современном мире разработки ПО о том, что командные решения,
3:35
при решении принятые группы людей, они, или в демократическом даже, не дай бог в формате, они качественнее, они более продуманные, они более взвешенные,
3:44
они более обоснованные, чем решения, которые принимает один человек.
3:50
Поэтому в современных командах, которые я встречал за свою практику, не выделяют архитектора, не выделяют человека,
3:58
который был бы автором решений, которые принимаются в этой команде,
4:04
и который был бы автором продукта, который создаёт команду. То есть команда есть, продукт есть, решения есть, а автора у них нет.
4:13
И мы не знаем, кто эти решения принял, мы не знаем, почему они эти решения приняты, и более того, что самое важное, мы не знаем, кто за всё это отвечает.
4:22
У нас нет никакой персональной ответственности за архитектурные решения, которые принимаются. На мой взгляд, это неверно, я считаю, что действовать нужно наоборот,
4:31
нужно выделять в команде, какая бы команда ни была, маленькая, большая, пускай даже в команде два человека,
4:37
всегда выделяет человека, который несёт личную, персональную полную ответственность за все технические решения. Это не значит, что он единственный, кто будет влиять на эти решения,
4:46
это не значит, что он единственный, кто будет иметь какое-то техническое мнение. Наоборот, скорее всего, этот человек должен иметь поменьше своего мнения,
4:54
но побольше, или по максимуму желания нести ответственность за решения, которые приняты. То есть он должен собирать мнение команды,
5:01
он должен выслушивать всех, кто как считает о том, как нужно разрабатывать систему, о том, какие нужно в ней иметь компоненты,
5:08
из чего она должна состоять, и потом, собрав всю эту информацию, он принимает решение и под ним подписывается.
5:14
Вот отсутствие такой подписи, что ли, это, конечно, не должно быть формально, в современном мире разработки ПО мы, конечно, ничем не подписываемся,
5:23
но авторство, отсутствие авторства у решений приводит к их…
5:30
ну, я пытаюсь сформулировать, что будет, если этого не будет, точнее, к чему в основном это приводит.
5:38
Ну, наверное, в первую очередь из последствий можно выделить хаотичность архитектур. Каждый модуль системы, каждый компонент системы, каждая его составляющая,
5:49
она будет создана кем-то, она будет создана каким-то группой людей
5:55
или каким-то отдельным человеком в команде. Но единого взгляда на систему у нас не будет, и никто не захочет в итоге брать ответственность за полное решение,
6:06
за всю полноту решения, которое мы реализовали. И то, что я видел на практике, получается, архитектура становится такой пятнистой.
6:17
Одно пятно в этой архитектуре, за него отвечает один человек, он в нем хорошо понимает другое, пятно в архитектуре принадлежит другому человеку,
6:25
и между собой они стараются не пересекаться, они стараются не заходить на территорию друг к другу, потому что им непонятно, потому что им не хочется входить в конфликт друг с другом,
6:34
и потому что им все равно, потому что нести ответственность за чужие проблемы никому особо не хочется. Каждый, в общем-то, волнуется в первую очередь.
6:42
Егор Георгиевич, пропала, извините, презентация.
6:49
Совсем пропала, сори. Моя ошибка.
6:56
Я прошу прощения, это у меня скринсейвер включился, и все пропало.
7:10
Наверное, будем. Провидим, да? Да, прошу прощения.
7:17
Получается, в архитектуре появляются островки ответственности, или островки пятно, островки группы кода, группы функциональности,
7:28
группы даже аппаратных и программных средств, за которые отвечает какой-то человек, и он более-менее готов нести ответственность за них,
7:35
но не готов нести ответственность за всю систему целиком. И это, как я хотел сказать, прервался,
7:42
что каждый больше всего волнуется о своей карьере, а не о программном продукте. Это естественно, наверное.
7:48
Люди часто переходят из команды в команды, из команды в команду программисты долго не задерживаются в одном проекте.
7:54
На современном рынке 3-4 года оставаться в одной команде, это уже очень долгий срок на нашем рынке.
8:01
Люди двигаются между проектами, переходят между компаниями, и, соответственно, их волнует больше личный рост внутри компании,
8:08
личная карьера внутри проекта, чем, собственно, судьба этого проекта. И поэтому им на глобальную архитектуру целиком,
8:15
как она устроена и какие в ней серьезные глобальные проблемы, им, в общем-то, дела нет до этого.
8:22
И победить это можно только, на мой взгляд, только таким силовым путем,
8:30
назначить архитектора, не ожидать, что архитектор сам появится, потому что это тяжелая роль,
8:36
и она сопряжена с большим количеством рисков, давления, архитектор, в общем-то, максимальный стресс испытывает эта роль
8:45
в любом программном проекте, потому что она несет ответственность за все ошибки, которые совершают программисты в разных частях этого проекта.
8:51
И, конечно, значительно легче сделать качественный модуль, чем сделать качественную интеграцию модуля. И нести ответственность за интеграцию тех модулей,
8:58
которые еще и самостоятельно не разрабатывал, крайне тяжело. Поэтому этот человек должен быть назначен, этот человек должен быть, его роль должна быть сформирована,
9:06
команда должна признать необходимость наличия такой роли, наличие такой роли, а потом на эту роль выбирается человек,
9:12
который максимально устойчив в своей технической морали,
9:20
технические свои принципы, к которым он привязан, он должен иметь силу и желание отстаивать.
9:27
В общем, это с одной стороны желание человека, это должно быть, с другой стороны, согласие команды, а с третьей стороны, это некая насилие над этим человеком нужно применить,
9:35
потому что многие будут отказываться. И если взять реально программный проект, к которому много лет, и допустим меня, если поставить этот проект как внешнего архитектора,
9:44
призвать туда, то я, конечно, буду иметь большие сомнения относительно того, хочется ли мне быть таким архитектором или нет.
9:51
Это должна быть большая мотивация личная и какая-то финансовая, для того чтобы в этой роли выступать. В общем отсутствие такой роли, суммирую, это причина провалов многих проектов,
10:01
потому что архитектура расползается, архитектура становится такая, расслаивается, расползается на части,
10:07
и в итоге объединить эти части становится трудно, между ними возникают связи, которые не документированы, непонятны,
10:14
которые временные, которые не имеют никакого обоснования. В итоге мы имеем просто набор каких-то частиц,
10:20
из которых трудно склеить целенархитектуру. Вот первая проблема – это проблема менеджмента, не проблема программиста. Программисты ошибки не делают, они каждый сделает свой модуль качественно.
10:29
Но собрать все вместе не получается, то есть менеджеры должны на это обратить внимание. Вторая причина провалов, как мне кажется, – это команды, которые collocated, так называемые,
10:40
команды, которые сидят слишком близко друг к другу. Это может прозвучать опять контруинтуитивно, потому что современный мир, он вроде бы движется к современной крупной компании,
10:50
двигают современный мир в сторону офисов, в сторону офисной работы, это вот после пандемии стало очень заметно,
10:57
нас на какое-то время отпустили по домам, но сейчас стали активно собирать обратно в офис.
11:03
И мотивирует это тем, что люди в офисах более продуктивны, люди в офисах не только пишут код, но и общаются друг с другом.
11:10
И это очень важная составляющая разработки программного обеспечения. Это безусловно так, безусловно, ничто не может заменить качественного личного общения при обмении техническими идеями, безусловно.
11:22
Но надо понимать, что чем ближе люди между собой находятся, чем они ближе находятся не только друг к другу, но и к аппаратному, к аппаратной платформе.
11:32
Когда мы находимся все в офисе, то у нас настроены соединения с серверами, у нас настроены доступы, настроены IP-адреса, сетки, в общем, все с конфигурированным.
11:42
И на компьютере все, на лаптопе, который всю историю проекта пробыл в офисе, конечно, все удобно и настроенно.
11:50
Но это приводит к такой удобства, к зоне комфорта, она приводит к деградации программного обеспечения, деградации процессов контроля качества,
12:01
деградации процессов сборки, процессов деплоймента, процессов тестирования. То есть софт находится в таком инкубаторе, находится в тепличных условиях.
12:11
И софт, и команда. То есть команда, находясь друг к другу, они перестают использовать, например, систему трекинга дефектов.
12:20
Если я сижу рядом с программистом условно за одним столом, то мне становится через время не нужно описывать проблемы, которые я встречаю в архитектуре, в текстовом виде,
12:33
и создавать для них новый тикет, и создавать для них подробное объяснение, почему эта проблема существует,
12:39
и как ее нужно исправить. Я просто поворачиваюсь к соседу за столом и рассказываю ему, как эту проблему, о чем эта проблема,
12:45
и как ее нужно исправить. Если этот сосед очень дисциплинированный, то, конечно, он опишет то, что я ему рассказал, и у нас появятся новые тикеты, мы будем дальше двигаться в электронном виде,
12:55
таким образом сохраняя архитектуру, сохраняя дисциплину внутри проекта, и сохраняя понятность и прозрачность технических решений, которые мы принимали.
13:03
Но эта дисциплина, ее будет количество уменьшаться, и она будет деградировать, как я сказал, в проекте,
13:11
если люди сидят в одном офисе долго, тесно, не пытаясь работать удаленно. И, соответственно, мы получим то, что мы получим, мы получим систему, в которой все знания об архитектуре,
13:25
или большинство из них, находятся в головах у людей, которые с этой системой работают. А значит, подвержены очень большому риску уничтожения этих знаний,
13:35
потому что, как было сказано в предыдущем топике, люди двигаются между командами, и через два года большинство участников этого проекта исчезнут из проекта, они перейдут в другую команду,
13:46
в другой проект, в другую страну, в другой город, они переедут, они поменяют свое место, и появятся новые люди, которые этими знаниями не обладают.
13:54
И вот формирование таких знаний внутри людей – это крайне опасное, как сказать,
14:05
появление таких людей, которые знают много, и которые весь путь проекта просидели в офисе,
14:13
проработали локально здесь, рядом со всей командой, – это серьезный симптом, серьезная угроза для потери знаний и потери стабильности.
14:23
То есть система, помимо того, что мы знания раздаем людям, и они с этими знаниями уходят, мы еще, как я сказал, система становится тепличной, неустойчива к разным хаосу,
14:38
неустойчива к тому беспорядку, с которым она встретится так или иначе в реальных условиях.
14:46
То есть это как, условно говоря, разрабатывать программный продукт, все время на одной операционной системе его тестировать,
14:53
все время на одном лаптопе, все время в одних условиях, с одними входящими данными. Безусловно, мы систему создадим так, и быстро, и качественно.
15:01
Это может казаться эффективным, это может казаться удобным, потому что все настроено, компьютер один, единственный, данные всегда одни и те же, операционная система не меняется,
15:10
настройка операционной системы та же. Но вы понимаете, какая устойчивость этого продукта будет, когда он попадет в реальный мир,
15:16
когда его запустят на другой операционной системе, когда его будут запускать с другими входными данными.
15:22
Это будет совершенно другая история, и выглядит это все будет по-другому. То же самое и с целиком программным продуктом, и его командой.
15:30
Вот команда и продукт, они должны… Команда – это как операционная система, команда – это как входные данные.
15:36
Она должна двигаться, меняться, и нужно к этому быть готовым. И нахождение людей вне офиса позволит людям столкнуться с проблемами запуска этого продукта вне той сети,
15:49
в которой они привыкли работать. Запуска – коммита изменений через системы безопасности.
15:56
Это позволит им увидеть, как со стороны выглядит среда разработки.
16:02
Оказавшись вне офиса и поработав несколько дней удаленно из дома или из кафе, они увидят, что рядом нет этих друзей, с которыми можно было бы обсудить проблемы, которые они хотят обсудить.
16:14
Они не могут больше так легко объяснить проблему, с которой они столкнулись. Им уже не так комфортно формулировать проблемы, формулировать баги, формулировать дефекты,
16:27
которые бы они хотели, чтобы другие участники команды исправили. Им придется искать эти пути формулировки и пути донесения информации до команды,
16:36
и они увидят, что они не такие свободные, они не такие открытые, не так это удобно делать, как это было в офисе.
16:44
И дисциплина начнет возвращаться. А дисциплина, если смотреть на архитектуру целиком, это, наверное, самый важный ингредиент качества.
16:53
Если дисциплина есть, если архитектура, если программный продукт разрабатывается, с максимальным вниманием к дисциплине разработки,
17:01
а это именно трекинг дефектов, связка дефекта и изменения кода, это формальные код-ревью,
17:07
это формальный анализ кода, статический анализ, стилистический анализ, это формальные юнит-тесты,
17:13
то есть весь этот формализм, который должен присутствовать во время разработки программного обеспечения, он при collocated team, при команде, которая сидит всегда рядом в одной комнате, он улетучивается,
17:24
потому что он становится таким, ну не то что рудиментом, а он становится излишним компонентом.
17:30
И всем становится очевидно, что мы делаем что-то, мы притягиваем, грубо говоря, за уши, всю эту дисциплину, которая нам не нужна.
17:38
Ну зачем мне описывать проблему, если вот сидит человек рядом? Я буду выглядеть странно, если мы все сидим в одной комнате, а я о всех проблемах делаю письменные отчеты,
17:47
меня в конце концов будут высмеивать с этим. Если же мы все сидим по домам, то это совершенно нормально, что мы общаемся электронно,
17:54
что все наши знания протоколируются. Как это происходит в open source проектах? Open source проекты, на мой взгляд, это проекты, которые обладают наивысшим качеством,
18:04
они, если вы сравните качество проектов, созданных проприетарно, то есть созданных внутри компании,
18:10
качество open source проектов, то на мой взгляд, на мой персональный субъективный взгляд, у open source решений качество, у кода и у архитектуры всегда значительно выше.
18:20
Ну в общем-то мы и пользуемся open source решениями в основном, а не проприетарными.
18:26
Так что collocated команда – это зло, на мой взгляд. Оно, конечно, его исключить 100% невозможно, все-таки людям, как я сказал, важно быть в офисе,
18:34
важно друг друга видеть и общаться, но позволять им и может быть даже заставлять их периодически работать удаленно и смотреть, что из этого получится.
18:44
Это очень полезно для программной архитектуры. Это была вторая причина провалов.
18:51
Третье. Ну вот только что задронуто тему – это приватная кодовая база. Есть два подхода к разработке программного обеспечения – это либо закрытый код-бейс, закрытая база с кодом,
19:03
либо открытая кодовая база. Есть open source разработка, есть proprietary разработка. В open source разработке мы даем всему миру видеть наш код и даже в него contribute, даже в него вносить изменения.
19:15
И мы более того, мы поощряем программистов из других стран, городов, компаний и континентов присылать нам свои изменения,
19:25
мы эти изменения рассматриваем, мы принимаем либо отвергаем. Таким образом получается, что наш софт, если он в open source, в общем-то разрабатывается не только нами,
19:33
но и всем сообществам, которому потенциально этот софт нужен. Они его не только разрабатывают, но они его еще используют.
19:40
Второй подход – это когда мы разрабатываем все внутри компании, мы никому не даем доступ к этой кодовой базе, и выдаем только конечный скомпилированный продукт, который программисты либо используют, либо не используют.
19:50
Они тоже могут нам какие-то рекомендации давать, но они не знают, как его улучшить, они не видят исходный код.
19:56
Они могут только писать баг-репорты и предлагать изменения, предлагать улучшения, и может быть как-то помогать
20:04
описанием симптомов тех ошибок, которые они видят. На мой взгляд, приватная кодовая база, она быстро приводит к деградации и снижению качества программного продукта.
20:17
По нескольким причинам. Первая причина – это очень субъективно, лишь мое мнение,
20:24
но первая причина – я как open-source разработчик и одновременно и разработчик закрытых решений, когда я ношу изменения в open-source репозиторий, я значительно более внимательно отношусь к тому, что я делаю,
20:36
потому что я знаю, что меня увидят не только два человека в офисе, а меня увидят потенциально сотни людей, то, что я пишу.
20:43
И к этому коду, в общем-то, мое имя привязано, прикреплено, я не хотел бы, чтобы…
20:49
В общем, я стараюсь лучше, стараюсь делать лучше, это совершенно, наверное, очевидно. Помимо моего желания закончить работу и получить зарплату, у меня еще появляются некие амбиции включаются.
21:00
Мне хочется быть программистом, которого… мне хочется гордиться своим кодом, мне хочется видеть, что он качественный.
21:07
В общем, какая-то некая одновременно стыдливость за некачественный код и, с другой стороны, амбициозность, желание сделать его лучше.
21:15
Это однозначно помогает сделать продукт лучше. Если кодовая база вся закрыта, то большинству программистов будет неважно, какой код они написали. Им будет только важно, получили они за него деньги или нет.
21:28
Некоторые программисты, они существуют, безусловно, но они все-таки в меньшинстве, которые даже создавая закрытый код, им все равно важно, какого он качества, и они к нему относятся внимательно.
21:38
Такие люди существуют, но мы имеем дело обычно с разными людьми в командах, и преобладают те люди, которым такие ремесленники. То есть он закончил, сделал, и красиво, некрасиво, лишь бы работал.
21:50
Если код работает, то люди воспринимают это как успешную завершенную задачу, и на этом все. В случае опенсорса на качество обращают внимание очень много. Это первое.
21:59
Второе, почему опенсорс выигрывает и почему приватные кодовые базы ведут к проблемам,
22:06
это отсутствие большой аудитории для тестирования.
22:14
Одно дело, вы делаете опенсорс-решение, которое выложив в онлайн, вы получаете потенциально сотни людей,
22:21
которые попробуют ваше решение в самых разных условиях, на разных операционных системах, с разными языками программирования, если это какой-то скрипт, например.
22:29
В общем, в разных совершенно формулах и сценариях. И это даст вам бесплатную и очень качественную среду для тестирования продукта.
22:40
А ничего не может повысить качество лучше программного продукта, чем люди, которые стремятся его сломать,
22:47
чем люди, которые пытаются доказать его неработа способность путем применения его в разных сложных ситуациях.
22:53
Ну, тут, я думаю, это такая азбучная истина, что хороший тестировщик – это тот, который замотивирован на деструктивную деятельность,
23:02
на то, чтобы сломать продукт и доказать автору продукта, что он не работает. Это самые эффективные тестеры.
23:08
Не те те тестеры, которые пытаются помочь разработчику и показать ему, что все хорошо в его продукте,
23:14
а наоборот. Это люди, которые работают в конфликте, в конструктивной конфронтации с разработчиками, пытаясь поломать.
23:22
Разработчик пытается построить, тестер пытается поломать, и на этом конфликте конструктивном появляется качество.
23:28
Отсюда мы имеем качественные продукты. Когда вы делаете open source, у вас этой аудитории желающих поломать вас и применить ваше решение в самых разных необычных условиях,
23:37
она получается очень большая, эта аудитория. В приватных все, опять же, получается в тепличных условиях.
23:43
Вы разрабатываете в изолированной среде, где есть только… Есть в основном люди, которые вам коллеги и которые вам друзья в той или иной степени.
23:52
И, конечно, их желание… Их деструктивные мотивы значительно слабее или, может быть, вообще отсутствуют по сравнению с open source миром,
24:02
миром открытого программного обеспечения. Ну и, наверное, еще одна…
24:08
Их много причин, почему open source эффективнее. Если вам интересно, у меня есть блог, как сказали в начале,
24:15
и на этом блоге у меня есть несколько статей, посвященных open source, в том числе статья о мотивах, почему компании имеет смысл переходить в open source.
24:24
Она даже, по-моему, называется “Почему вы до сих пор… Why you are not open source yet?” То есть почему вы еще не в open source?
24:31
И дальше такая критика тех решений. Я думаю, что вообще стратегически, если посмотреть на рынок 20 лет последний и 20 лет вперед,
24:40
я думаю, что за следующие 20 лет мы увидим, может быть, тотальный переход в open source разработку крупных даже корпораций.
24:48
Сейчас по-прежнему большие компании удерживают код внутри и стараются им не отмениваться,
24:54
стараются его спрятать для того, чтобы какие-то секреты свои не показывать другим. Я думаю, что это все… Мы как цивилизация, мы уйдем от этого формата
25:06
и уйдем к формату полностью открытого программного кода, и компании будут зарабатывать не на сокрытие тайн от других компаний,
25:14
а на добавление сервисов сверху над программным обеспечением. В общем-то, программное обеспечение – это не все, что составляет продукт, это не все, что составляет прибавочную стоимость.
25:27
Есть еще данные, которые необходимы для работы этого ПО, и есть еще люди, которые обслуживают это ПО, то есть уровень сервиса сверху, накладываемый на сам софт.
25:39
Есть еще железо, есть еще аппаратные платформы, которые тоже стоят чего-то.
25:45
Например, возьмите платформу Amazon Web Services. Мы ее все используем AWS. Она очень популярна, номер один в мире.
25:53
У нее есть некий софт, который делает все, что он делает, несколько десятков, может быть, под сотню сервисов.
26:01
Это все некий софт, который написали программисты за последние 15 или 20 лет существования Amazon.
26:07
Но если даже взять этот весь софт и взять его в open source, выложить и…
26:13
(неразборчиво)
26:25
Вот, если взять этот весь софт и выложить в открытый доступ, то это не даст тому, кто это сделает, конкурентного преимущества на рынке.
26:33
Ну, не даст. Можно это утверждать совершенно без всякой доли сомнения.
26:41
То есть вы получите просто софт, но вы не сможете дать того уровня сервиса, того качественного продукта, который дает Amazon.
26:48
Потому что у вас нет людей, которые умеют пользоваться этим софтом и обслуживать его. И у вас нет железа, который есть у Amazon, который тоже они приобретали в последние многие годы, и в который они инвестировали миллиарды долларов.
27:01
Вот эти две составляющие, люди и железо, оно, конечно, не будет… Я думаю, что в него, на нем останутся корпорации, на нем будут делать деньги.
27:13
А софт все-таки будет понятно, все корпорации наконец признают и осознают, что эффективнее, если весь софт, например, Amazon, будет лежать в open source.
27:23
И не только Amazon будет его разрабатывать, но и тысячи программистов во всем мире будут тоже туда контрибьюдить, будут создавать новые сервисы,
27:30
будут их улучшать, будут помогать им устранять ошибки, которых много в Amazon. Это будет значительно лучше для всей цивилизации целиком и для Amazon в частности, для его stakeholders, для его инвесторов.
27:43
В общем, для всех будет лучше. То есть приватные кодовые базы, они ведут к снижению качества и к потере интереса.
27:50
Ну, и последний мотив, который я укажу, это, наверное, интерес программиста к продукту, над которым он работает.
27:56
Одно дело, программист работает над закрытой кодовой базой, и все, что он получает, и все, что он получит после завершения этого проекта,
28:03
через несколько лет, когда он перейдет в другую компанию, это запись в его резюме, что он работал над каким-то проектом, некий опыт, который он получил,
28:11
ну и, в общем-то, те деньги, которые он получил. Когда же он работал над open source решением все эти несколько лет, то он, помимо денег и записи в резюме,
28:18
и некого опыта, он получает еще и определенный статус, и определенный артефакт, который он может показать дальше новым работодателям.
28:28
Он может свое авторство в этой кодовой базе open, открытой, он может ее, это авторство использовать дальше как инструмент получения более интересной должности,
28:39
более крупной оплаты в следующих проектах. Одно дело, я как человек, который нанимает иногда программистов, могу сказать, что одно дело,
28:46
когда к нам приходят программисты, у него в резюме лишь список компаний, в которых он работал, с описанием каких-то ответств, каких-то действий,
28:55
каких-то активностей, которые он там совершал, и каких-то технологий. Это одно. Мы смотрим на это и понимаем, что это трудно проверить,
29:02
и, в общем-то, это резюме, которое не сильно отличает его от остальных кандидатов. И другое дело, когда мы смотрим на резюме,
29:08
в котором показаны open-source-проекты, которые он разрабатывал или в которых он участвовал, я могу перейти по ссылке на эти open-source-проекты,
29:16
если они, например, на GitHub, открыть тот код, который он писал, и увидеть, как он программирует, увидеть какого качества его код,
29:23
как он общается с другими программистами. Я увижу значительно больше о нем, и меня к нему интерес значительно больше, особенно если эти open-source-проекты
29:32
чего-то стоят, особенно если они популярны, интересны и качественно сделаны. Вот это для программиста, мне кажется, мотивация значительно больше для работы,
29:42
а значит, он будет делать архитектуру лучше, значит, он будет ее поддерживать с большим интересом. Следующий пункт – это, опять, мы перечисляем проблемы,
29:53
мы перечисляем, что вредит программным архитектурам. Есть такая идея или такая концепция – code ownership – это принцип, согласно которому
30:07
у каждого блока кода должен быть владелец, должен быть онер, который его знает, который в нем разбирается и который за него отвечает, который является владельцем этого кода.
30:24
И вроде бы такое мнение существует, что это хорошо, если у нас весь код поделен на некие блоки, области, и у этого кода есть ownership, и каждый пользователь видит себя владельцем этого кода,
30:39
и это, мол, хорошо. Если я правильно сейчас вам рассказываю, я немножко начал сомневаться, может быть, code ownership – это такой термин, может быть, более широкий,
30:48
говоря о том, что человек должен относиться к своему коду, как будто это его собственность. Если это в этом понимании, то, наверное, это хорошо, это, конечно, не негативная составляющая.
30:59
Но я сейчас говорю о том, о той ситуации, когда код разделен на части, и у каждой части есть свой владелец. Вот эта ситуация, она, на мой взгляд, крайне опасная и приводит к трагическим последствиям.
31:13
И, в общем-то, она выгодна и менеджменту, и программистам, но она не выгодна продукту. Почему она выгодна менеджменту?
31:23
Ну, потому что человек, который работает над одним и тем же блоком кода или над одним и тем же модулем, он, конечно, в нем разбирается лучше, а значит, мы можем на него положиться,
31:31
а значит, мы можем давать ему задачи, касающиеся этого блока кода, и когда у нас возникнет какая-то проблема, мы этого человека попросим, и он ее быстрее всех решит.
31:40
И мы знаем, кто этот человек, и мы можем на него операться и полагаться. Если же у нас абсолютный такой хаос, то есть каждый программист отвечает за…
31:50
Ни за что не отвечает. То есть каждый программист во время выполнения задачи отвечает только за свою задачу. Ему прислали задачу в модуле A13 – ошибка, исправь ее.
31:59
Вот пока он исправляет модуль A13, он за него отвечает. Когда он его исправил, он опять ни за какой модуль не отвечает. Получая новый дефект от пользователя, который нужно исправить быстро,
32:10
нам, конечно, выгоднее, как менеджеру, знать, что за модуль A13 отвечает некий конкретный сотрудник, потому что тогда я имею хоть какую-то гарантию, что этот модуль будет исправен.
32:22
Но приводит это, это уверенность, это опять же зона комфорта, в которой менеджеру комфортно, а программисту тоже комфортно, потому что если все его тикеты, все его задачи, которые на него менеджер ставит,
32:35
они касаются одного и того же модуля, то, конечно, ему удобно, ему легче становится, ему удобнее поддерживать этот модуль, он в нем все понимает.
32:44
Но это все ведет к деградации системы контроля качества. Все больше и больше появляются компромиссов с качеством.
32:56
Все больше и больше мы имеем решений, удобных только одному человеку, решений, понятных только одному человеку,
33:09
решений, которые вообще обсуждены были только с одним человеком.
33:15
Получаются такие островки, технические островки, технические территории принятия решений, которые в перспективе будет трудно войти вновь прибывшим людям.
33:33
А еще раз возвращаюсь к тому же, что было сказано в начале, что люди меняются, надо из этого исходить.
33:40
Архитектура – это продукт людей. Архитектура во многом – это люди. И если людей постоянно менять, то архитектура должна быть готова к этому.
33:49
То есть наши программы-аппаратные средства, которые мы создаем, наш продукт, который мы строим, он должен быть готов к смене хозяев, готов к смене контрибьюторов.
34:01
И чтобы его сделать таким готовым, нам нужно запрещать код ownership, запрещать вот это владение кодом, нам нужно ротировать людей между модулями.
34:10
То есть как только мы видим, что какой-то человек начинает становиться экспертом в каком-то блоке нашего программного кода, какой-то территории нашей архитектуры,
34:19
мы должны его оттуда забирать и ставить его в другое место. Вообще в идеале, и мы это практиковали в наших проектах не раз, в идеале ставить задачи случайным образом.
34:29
То есть чтобы это делал условно робот, когда к нам приходят новые feature requests или bug reports, мы их не…
34:39
human factor используем, не человеческий фактор, не человек принимает решение, кому выгоднее эту задачу отдать, а робот.
34:47
И делает это робот случайным образом. И программист никогда не знает, из какой части системы к нему поступит задача.
34:55
И таким образом, имея такой контролируемый хаос, или даже не контролируемый, а задуманный или такой синтетически созданный хаос,
35:07
мы готовимся к хаосу реальным, который нас в любом случае ждет.
35:13
Мы в любом случае потеряем этого сотрудника, который работал над модулем А13. Это неизбежно, это факт, к которому мы должны быть готовы, это событие наступит.
35:21
Но если мы к нему готовимся, если мы над этим модулем А13 заставили поработать уже 10 человек подряд,
35:29
в разной последовательности, за несколько лет жизни этого модуля, то, конечно, сменив сотрудника, мы ничего не потеряем.
35:37
Мы готовы к тому, что да, придут новые люди. И таким образом, мы еще и повышаем качество этого продукта, который создается.
35:43
Мы повышаем качество программного продукта, потому что каждый новый человек, попадая в этот модуль, этот заполученный А13,
35:51
он должен в нем заново разобраться. Он должен понять, как там что устроено. А раз он должен понять, как там устроено, он неизбежно будет улучшать документацию,
36:01
он неизбежно будет повышать качество кода, чтобы сделать его понятнее для себя. Причем он будет понимать, что он его делает понятней, но на очень коротком промежутке времени.
36:09
То есть он не будет его делать понятным только для себя, потому что ему не дадут возможность так долго работать с этим блоком, с этим модулем.
36:16
Он сделает его понятным только для… Он сделает его понятным до той степени, насколько он понимает, что такое быть понятным в рамках всего проекта.
36:27
Вот такая вот общая идея.
36:33
Что мы, ратируя людей, они будут носить знания о том, что такое качество и какие принципы программирования приняты в этом проекте,
36:41
и как мы относимся к юнит-тестированию, к сатическому анализу, к диплойменту, к конфигурации взаимодействия между модулями.
36:49
Все эти знания они будут в равной степени переносить из модуля в модуль. Таким образом распространяете знания таким ровным слоем между всеми модулями.
37:01
Вот это четвертая проблема. Пятое. Значит, easy to contribute – это тоже причина провала.
37:08
Если программисту легко внести изменения в программный код, что я понимаю под легко,
37:17
что у него нет перед ним барьеров, выстроенных перед ним. То есть, программист открывает исходный код, вносит изменения и contributed это кодовую базу.
37:28
Присылает этот pull request или merge request, присылает это в проект, и у него принимают этот request,
37:34
если он внес изменения так, как, допустим, нравится архитекторам. Это быстрый, короткий путь между изменениями и фактом принятия этих изменений в проекте.
37:45
Этот путь, на мой взгляд, должен быть длинным и тяжелым. То есть, программисту должно быть трудно, больно, мучительно больно пройти через большое количество систем контроля качества.
37:56
Мы должны делать жизнь программистов тяжелой до того, как их код будет принят.
38:02
И после того, как код попал в кодовую базу, после этого мы их не обвиняем за то, что они сделали.
38:10
Такая должна быть философия разработки. Делайте их жизнь тяжелой, пока код находится на их компьютере,
38:18
и абсолютно никак не винить их за то, что они поломали или что они сделали после того, как код был принят программной командой проекта
38:27
или теми роботами, теми инструментами, которые проверяют качество. Обычно происходит наоборот. Обычно в командах все выглядит так.
38:36
Программист легко вносит изменения, потому что это наш программист, мы ему доверяем, он, безусловно, хороший человек,
38:43
он старается сделать как лучше, поэтому если он сделал что-то, написал что-то, то мы, чтобы не обижать его, чтобы он не терял мотивацию,
38:52
мы стараемся его принять все изменения, которые он сделал, и побыстрее их принять, но мы ему говорим, ты ж смотри, это же внимательно, система же очень важная, она работает с данными пользователей,
39:03
через нее проходят реальные транзакции, поэтому если ты что-то поломаешь, будешь ночью сидеть исправлять, будешь на выходных приходить исправлять,
39:10
поэтому будь внимателен, будь аккуратен с тем кодом, который ты пишешь. Я даже встречал, ну, такая это уже, наверное, форма мема, но есть и такое мнение о том, что я это встречал в индустрии,
39:22
когда менеджеры говорят, что хорошим программистам юнит-тесты не нужны, они пишут правильные коды, им не нужно какие-то дополнительные тесты писать, он качественный программист, ну, ему платим много денег,
39:32
у него опыт 20 лет программирования, поэтому он пишет код качественно, и зачем ему какие-то тесты? Зачем вообще проверять его код? Он написал, мы его положили в репозиторий, и мы уверены, что будет работать хорошо.
39:42
Это новичков нужно проверять, если у нас студенты работают, тогда они должны писать юнит-тесты, мы должны проверять стилистику их написания кодом, мы должны прогонять все тесты перед тем, как они сделали какие-то изменения,
39:54
вдруг они что-то поломали. Это должно быть, ну, это, наверное, только как шутку можно воспринимать, сейчас уже,
40:01
ну, 10 лет назад я такие высказывания встречал в реальных программных проектах. То есть все должно быть не так,
40:07
должно быть тяжело, программист должен, внеся какие-то изменения в программный код, ему должно быть тяжело
40:14
положить эти изменения в кодовую базу, его должны проверять 10 уровней проверки.
40:20
Но, когда эти изменения попали в кодовую базу, после этого мы забываем, кто их внес,
40:27
мы не ищем автора, не ищем того, кто что-то поломал, специально не ищем, даже если мы знаем, кто это поломал,
40:35
но мы признаем отсутствие авторства у проблем, это все становится нашей проблемой.
40:42
То есть если программисту получилось у него пройти сквозь системы защиты, и код попал в кодовую базу,
40:49
и сервер в итоге сломался, и в итоге пользователи получили негативный опыт работы с нашей системой,
40:56
это проблема тестов, это проблема вот этой системы защиты, это она пропустила некачественный код,
41:03
но ни в коем случае не вина программиста. Вот такой менталитет, такой майнсет,
41:10
он должен присутствовать у архитектора и у всей команды. Тогда программисты будут работать радостно,
41:16
эффективно, быстро, они будут носить изменения интенсивно, а мы, допустим, если мы, если я или архитектор,
41:24
то я буду постоянно думать о том, как эту систему защиты усложнить, как сделать еще тяжелее их проход через нее,
41:30
еще более качественные проверки вставлять, я буду писать интеграционные тесты, я буду делать эту проверку длинной,
41:37
я буду эту проверку делать многочасовой, когда запускается много тестов, система и система проверяется на разных операционных системах, на разных браузерах, на разных платформах,
41:47
для того чтобы исключить любую возможность случайной ошибки, регрессионные тесты буду писать. В общем, я буду усиливать и усиливать, а программистам буду говорить, не волнуйтесь,
41:56
как только вы прошли через систему защиты, с вас все вопросы снимаются. Вот такое вам о менеджменте на подумать.
42:07
Следующая проблема номер 6, всего их 10, проблема номер 6 – это кодируем сначала, релизим потом.
42:15
Это такой симптом, который я тоже, к сожалению, встречал частенько, заключается он в следующей майнсете, архитектуре,
42:25
люди думают так, что мы сначала должны написать то, что от нас ждет заказчик, то есть сделать функционал, который работает,
42:32
а потом, когда он у нас заработает, когда мы наконец увидим продукты и реализуем все фичи, которые нам нужны,
42:38
когда мы убедимся, что у нас рабочий функционал, после этого мы займемся процедурами релиза, continuous integration, unit-тестирование,
42:47
контроль качества, статический анализ, и вся вот эта вот, весь этот “детский сад”, в кавычках как они это называют, мы им займемся после,
42:55
потому что главное – это функционал, главное – это продукт. Я считаю, что это должно быть наоборот.
43:01
Я считаю, что обвязка вокруг продукта, его механизмы тестирования, его механизмы релиза, его механизмы упаковки, они важнее, чем функционал.
43:13
Функционал может написать и ремесленник, и инженер, и человек, работающий за еду условно, то есть ему сказали, делаем функционал, он делает,
43:22
я сейчас упрощаю специально, для того чтобы картинку сделать более выпуклой, а вот правильно сделать тесты, а вот правильно сделать релиз,
43:29
правильно сделать упаковку, контроль качества, проверку того, что мы делаем.
43:35
Это проблема более сложная, она требует значительно больше креатива, значительно больше инновационного подхода.
43:44
Каждый продукт, с которым я работал, практически каждый, имеет свою какую-то уникальную систему сборки и систему доставки конечному потребителю.
43:52
Практически, есть конечно классы продукта, допустим, джава-продукты, они похожи в чем-то, продукты на джаваскрипте, они тоже в чем-то похожи, но все равно,
44:00
каждый раз это искусство, каждый раз мы делаем практически, ну многое делаем, не практически все, конечно, но много делаем с нуля, много строим,
44:07
и ошибки там, которые мы должны в этой системе сборки, которые мы должны там устранить, они очень непростые, сложные,
44:14
и многие люди не разбираются в том, как это сделать. Но если мы сделаем release first, a code later, то мы сразу же с первого дня проекта получаем ту самую формулу,
44:27
о которой я вам только что говорил, когда программисту тяжело вносить изменения, то есть тяжело разрушить нашу архитектуру,
44:33
тяжело сделать, тяжело нам увидеть некий вандализм, а это в общем-то то, что убивает архитектуру, это такой не задуманный,
44:46
а само собой получающийся вандализм, когда программист берет какой-то модуль, смотрит на него, ему нужно закрыть задачу,
44:53
потому что ему уже до конца дня какую-то проблему решить, он смотрит на этот модуль, он понимает, что проблема здесь, из-за того, что какой-то класс используется неправильно, он как-то меняет порядок взаимодействия этих классов,
45:04
вносит какие-то изменения, ему кажется, что это должно работать, он это все отсылает на центральный репозиторий,
45:12
там его особо не проверяют, и этот код ложится туда, куда он должен лечь, он вроде бы решает эту проблему,
45:19
но объем технического долга, знаете, есть такой термин, технический долг, это объем проблем, которые остались в репозитории, не решенные,
45:28
и это проблемы, не которые видны, из-за которых рушится продукт у конечного пользователя, а это проблемы, которые внутри кода,
45:40
и как авторы термина технический долг, как он писал, это проблемы, которые можно было бы улучшить, то есть это код, который можно было бы сделать лучше,
45:51
и вот этот вот код, который можно было бы сделать лучше, мы его только что туда положили, программист, и это вандализм, на самом деле,
45:58
это такой вынужденный вандализм, потому что сроки работы с этим тикетом очень короткие, программист должен решить проблему за день, за полдня, за час,
46:09
и у него нет времени разбираться в том, как правильно это сделать, с точки зрения архитектуры, целиком, как правильно должен этот код быть оформлен,
46:16
с точки зрения архитектора проекта, он не знает, что именно нужно соблюсти, какие именно нужно правила и стандарты соблюсти,
46:24
которые были заложены туда архитекторам, он не знает, какие еще модули вокруг своего модуля, он внес случайным образом изменения, похалатности или просто случайно,
46:36
он этого всего не знает, ему это не интересно, ему нужно закончить конкретную задачу, и вот работа над такими изолированными конкретными задачами,
46:42
вне привязки к общей архитектуре, она и приводит к росту объема технического долга, поэтому нам нужно делать так, чтобы мы с первых дней проекта начали enforce,
46:52
начали контролировать, начали заставлять программистов следовать общим глобальным правилам, не только решать свою узкую задачу,
47:00
а каждый раз решая ее, надыкаться на правила, которые прописаны для всего проекта, если мы введем эти правила в конце, то есть сначала программист все разработает,
47:10
а в конце мы сядем и скажем так, а теперь давайте напишем unit test, а теперь давайте пройдемся по нашему коду и введем некую стилистику,
47:16
ну, причешем его, как многие говорят, это уже поздно, в этот момент мы уже имеем результат вандализма, мы уже имеем разрушенный программный код,
47:26
мы уже имеем огромный технический долг накоплен, поздно заниматься контролем попадания этого кода, этих дефектов, попадания внутрь нашей кодовой базы,
47:41
tool-lane, и вот это вот release later, я это встречаю, не поверите, в каждом программном проекте, в котором работают люди, мало знакомые с open-source,
47:52
когда мы начинаем разрабатывать софты, люди с open-source не сталкивались, они удивляются, когда я их призываю с самого начала проекта,
47:59
сначала настроить release pipeline, сначала настроить систему unit-тестирования, сначала настроить control-test coverage, например,
48:06
то есть контроль объема unit-тестирования, и только потом писать первый unit-test, для них это звучит странно, и они думают, что я такой в детский сад устраиваю,
48:16
я играюсь в игрушки вместо того, чтобы заниматься реальным делом, то есть писать функционал, писать классы, а тестированиями всеми займемся потом,
48:26
а еще тем более стилистическим анализом кода, ну какая разница, какая стилистика у кода, они мне говорят, ну мы потом все подчистим,
48:33
придет время, мы запустим какой-нибудь аутоформатер, и он нам все сделает красиво, я им говорю, когда будет потом,
48:39
за это все время, пока программисты писали 3-4 месяца или полгода этот проект, программисты писали его грязно, то есть программисты не использовали никакой стандарт стилистического,
48:50
контроля стилистики кода, никакой, а значит программистам все время говорилось каждый день, нам все равно, нам в этом проекте все равно, как вы пишете,
49:00
нам не важно какое у вас качество, нам не важно как хорошо протестирован ваш код, мы принимаем все подряд, ну представьте какое будет отношение у программиста к этой кодовой базе,
49:12
если кодовая база посылает ему такое сообщение, и говорит, нам не важно, несите что угодно, приносите, мы смёржем, приносите, лишь бы оно работало,
49:20
термин лишь бы работало, но он конечно разрушительен, я был на одном ворбшопе недавно, там профессор Зуев сказал, что привел такой факт интересный,
49:40
я не уверен, что цифры, которые он привел, они прям точны, но баланс между ними, он согласуется с тем, что я чувствую, будучи программистом,
49:51
что мы как программисты 90% времени тратим на чтение кода, а 10% на его написание, и это говорит о том, что мы код пишем для того, чтобы его читали,
50:08
не только для того, чтобы его выполнил компьютер, а во многом для того, чтобы его читал другой человек, для того, чтобы его читали наши же коллеги, и мы в том числе,
50:18
и если мы с самого начала проекта не настроим систему, которая блокирует неудобный для прочтения код, то мы получим неудобный для прочтения код в итоге в массовом порядке,
50:31
и более того, мы не просто его получим, а мы сделаем жизнь программиста на всем протяжении жизненного цикла проекта, пока мы не включим этот собственный контроль этого качества,
50:39
все программисты, которые будут читать код, который я пишу, они все будут чертыхаться, они все будут тратить много времени на его прочтение,
50:45
им всем будет некомфортно, они будут читать и не получать удовольствия читать и иметь затруднения в работе с этим кодом,
50:54
поэтому сначала релизим, потом кодируем, сначала настраиваем весь контроль качества, потом только начинаем писать, ну, условно, может быть, не первую строчку кода,
51:04
может быть, сначала нужно написать несколько каких-то базовых классов для того, чтобы сделать возможным компиляцию этого продукта, сделать возможным его,
51:15
хотя бы какую-то базовую сборку, то есть вы, конечно, не имея ни единого unit test и ни единого Java класса, у вас, конечно, не получится настроить релиз, потому что нечего будет упаковывать,
51:26
но как только у вас появляются первые несколько файлов с исходным кодом, первые несколько классов, в этот момент все собираем, упаковываем,
51:34
и только потом начинаем продолжать, и только потом продолжаем программировать. И теперь у нас еще осталось три пункта, они больше касаются технических таких более…
51:48
Егор Георгиевич, извините, я ворвусь, у нас есть комментарий, по-моему, вот к предыдущему, от одного из слушателей, от Николая, может быть, мы сразу же, чтобы потом не возвращаться, ответим на этот вопрос.
52:06
Да, хорошо, здесь такой комментарий… Про agile и процентовку, да, у кого там какие требования.
52:15
Ну это скорее больше шуточный такой комментарий, я так понимаю, что здесь сказано относительно этих цифр, 90-10, тут написано, Николаевич пишет, что условия нам диктуют…
52:28
Диктуют та ситуация, в которой мы находимся зачастую, требует от нас, чтобы мы больше писали и меньше читали.
52:37
Он пишет, что должно быть не 90-10, а 10-90, то есть больше пиши, меньше читай. Но это как бы желание, это, конечно, естественная мечта любого менеджера, чтобы программист ничего не читал и все писал.
52:49
И знаете, менеджер, плохой менеджер, средний менеджер, если он идет по офису и смотрит, что какой-то программист сидит и читает, например, какую-нибудь статью, или читает код, и не нажимает на кнопки,
53:00
то это у среднего менеджера вызывает вопросы, и он потом этого программиста отзывает и начинает с ним говорить о мотивации, о его вовлеченности в проект, и так далее.
53:09
Менеджерам кажется, что программист, не нажимающий на кнопки активно, это такой ленивый программист.
53:16
Хотя в реальности, конечно, нам программистам приходится читать коды и читать документацию, и хотелось бы, чтобы от этого мы получали удовольствие.
53:24
Никому не нравится читать код, который написан грязно, хотелось бы читать то, что написано чисто. Но, может быть, закончим мысль предыдущего слайда.
53:32
Программисты самостоятельно, по собственной воле, не будут писать качественный код. Это такой аксиом, из которой нужно исходить.
53:39
Я, как программист, который пишет в день достаточно много кода, последние уже не один десяток лет, я знаю, что если меня ничего не заставляет, я буду писать код все хуже, хуже и хуже.
53:50
Меня нужно только заставить писать хорошо. Плохо я писать буду сам по себе. То есть должны быть какие-то средства контроля над мной.
53:58
Лучше всего, если средства будут стоять максимально близко ко мне, в том смысле, что когда я написал код, сразу же меня контролируют, а не потом.
54:09
Знаете, есть такие механизмы, такие пост-ревью, когда команда собирается и открывает весь код исходный, и начинаются такие публичные ревью.
54:17
Так, кто его писал? А, Николай. Хорошо, Николай, посмотрим, что же вы тут написали.
54:25
И вся команда сидит, и начинаются шутки, юмор, начинают обсуждать, почему Николай здесь сделал так, почему потом Петр его здесь поправил.
54:33
И начинают высмеивать какие-то блоки кода, учить друг друга как нужно, как не нужно. Я считаю, что это крайне деструктивная практика, и я бы ее не использовал.
54:44
Анализ кода после того, как он попал в кодовую базу. Еще раз зацеплюсь за мысль, что мы никаким образом не связываем программный код с его авторами.
55:00
У программного кода автора нет, как только он лежит в репозитории, он уже безликий, он безличный, у него нет причины туда попадания.
55:09
Единственное, что есть причины его попадания, это, конечно, система контроля качества. Если у нас код туда попал, мы не ищем программиста и пытаемся его научить даже, пытаемся его заментарить, мы пытаемся его как-то пожурить за то, что он так сделал.
55:24
Нет, нет, нет, мы так не делаем. Мы смотрим, а, вот смотрите, здесь ошибка в программном коде. Вот здесь написал программист, некий программист написал неправильно.
55:32
Мы думаем, не думаем, почему он так написал, мы думаем, почему мы это пропустили. Почему у нас такая дефективная система контроля качества, что она такой код пропустила?
55:42
И мы думаем все вместе, так, а давайте мы усилим ее, давайте мы поставим еще вот такую систему контроля, давайте еще такой вот инструмент поиспользуем, который еще вот так на этот код смотрит и проверяет ее.
55:54
Сможет он поймать такую ошибку в будущем? Сможет. Окей, усилили систему контроля качества. Даже не говоря об этом программисту, который это допустил.
56:02
Не надо его учить, не надо его ментарить, не надо его мотивировать. Оставьте его в покое. Он сделал эту ошибку и сделал. Он второй раз ее не сделает.
56:09
Он ее сделает, но система контроля качества даст ему совершенно формальный, строгий, четкий риджерт с описанием, почему так больше делать нельзя.
56:18
И он сам научится. Никто к нему не приходил, никто ему лично не угрожал, никто с ним в конфликт не вступал, то есть нет никакой личной антипатии у нас в команде не возникает, какой бы плохой программист ни был.
56:31
У нас нет плохих программистов, у нас есть только медленные программисты. Почему? Потому что у нас есть быстрые и медленные.
56:38
Хороших плохих не бывает, если правильно настроена система контроля качества. Быстрый программист, он умеет проходить через систему контроля качества, значит он хороший,
56:46
он пишет код, который пролетает сквозь систему контроля качества, и медленный программист, который что не сделает, он утыкается в проблемы системы контроля качества.
56:55
Ну и хорошо, мы не называем его джунгер, не джунгер, синер, не синер, не важно. Мы берем любого студента, если у этого студента получается через нашу систему контроля качества проходить быстро, быстро, много кода писать,
57:08
то вот и замечательно, молодец, этому студенту нужно платить больше, чем любому другому синер-девелэкперу, который надувает щеки, сидит 30 лет на своем рабочем месте, и при этом от него кода в два раза меньше, чем от студента.
57:20
Почему? Ну у него не получается пройти через систему контроля качества, он долго думает, он долго свой код шлифует, он долго его причесывает, ну и грош ему цена, какой бы он он ни был.
57:31
Ну я опять же довожу до экстремума эту ситуацию, но вы поняли, вы должны понять философию здесь, что мы, программисты, не классифицируем как плохой-хороший, мы всем рады, любому коду мы рады, если он сможет пробраться, пройти сквозь нашу систему контроля.
57:54
Ну и у нас еще есть три пункта, которые я бы хотел отдельно рассказать каждый, здесь уже больше будет про технику, меньше про менеджменты, про философию.
58:02
Значит, tight coupling, наверняка вы знаете этот термин все, есть идея, давно была высказана еще в 74 году, если я не ошибаюсь, о том, что системы все можно разделить, любой модуль, точнее, любую систему программную, можно разделить на модули,
58:20
а дальше сказать, насколько модули между собой coupled, то есть насколько они между собой связаны, насколько тесно переплетены эти связи.
58:28
И авторы этого термина, они предложили, они, точнее, предположили, что на этот вот coupling влияет, наверное, три фактора.
58:39
Первый фактор – это то, какой силы связи между этими модулями, второй – это какой сложности эти связи, и третье, какое, я могу сейчас ошибиться, и третье – это количество этих связей.
58:55
То есть если мы имеем условно два модуля, один, например, это система печати отчетов для клиента, а втора – это база данных, где хранятся данные для этих отчетов,
59:08
то между ними есть определенная связь, они между собой coupled, то есть система печати отчета зависит от системы баз данных, она обращается к базе данных для того, чтобы получить данные и напечатать отчеты.
59:19
Вот насколько этот канал связи интенсивно используется, насколько в нем много разной информации, во-первых, насколько много информации через него передается,
59:30
насколько эта информация семантически сложная, насколько она разнообразна внутри этого канала, настолько плоха эта система,
59:41
то есть чем там больше информации, чем она более сложная, чем больше связи между этими двумя модулями, тем хуже для всей системы целиком.
59:50
Опять же, может быть, немножко контруинтуитивно звучит, потому что нам кажется, что, наверное, это хорошо, если система между собой, модули между собой общаются, они обмениваются данными, они друг про друга знают,
1:00:00
и в общем-то для этого мы и создаем модули, для этого мы и создаем систему многомодульно, чтобы их разделить и между ними наладить каналы связи.
1:00:09
Все это так, но в перспективе, представьте себе систему, в которой, давайте я через пример вам объясню, представьте себе, что у нас появляется еще один модуль,
1:00:22
у нас есть модуль базы данных, у нас есть модуль печати отчета, и мы строим еще третий модуль, который, например, будет, собственно, данные создавать,
1:00:31
отчета генерирует, а данные получать от пользователей и данные вносить базу данных. У нас появляется еще один элемент в этой системе, и еще один канал связи,
1:00:41
то есть этот модуль тоже зависит от базы данных, и он тоже обменивается с ней информацией. Представьте себе, что это база данных, она на языке SQL,
1:00:49
и через этот язык SQL оба модуля формулируют запросы к базе данных и объясняют базе данных, что они хотят получить, какие таблицы взять, с какими таблицами соединить,
1:01:00
в каком формате данные представить, и каждый делает, что хочет, потому что язык SQL очень богатый своими возможностями, если мы даем возможность модулю печати отчета
1:01:10
зайти в базу данных через SQL-интерфейс, то он сможет сделать все, что захочет от этой базы данных. Единственное, мы можем его ограничить, например, в апдейте данных,
1:01:19
в изменении данных, мы можем ему сказать, настроить конфигурации, чтобы модуль отчетности ничего не менял, а только читал, read-only такой доступ ему дать,
1:01:28
ну и, собственно, на запись разрешить модулю ввода данных от пользователя. Что мы получили? Мы получили tight coupling. Оба модуля имеют полный доступ в базе данных,
1:01:40
знают все о том, что находится в этом модуле, они знают имена всех таблиц, они знают имена всех колонок во всех таблицах, они знают все форматы данных, они знают все,
1:01:49
они фактически видят все внутренности нашей базы данных. И этот такой tight coupling приводит к серьезным проблемам поддерживаемости этой системы.
1:01:58
Представьте себе, что завтра я, не будучи автором и не будучи вообще заинтересован в изменении этих двух модулей, которые стоят сбоку, я захожу в структуру базы данных
1:02:10
и меняю там в какой-то таблице, мне кажется, что будет выгоднее, если эти поля будут, например, называться по-другому. Мне нужно будет поменять и два модуля тоже.
1:02:20
Причем как их поменять, это будет большой вопрос, как мне понять в каких местах внутри их кода. Прошу прощения снова.
1:02:29
Короткие технические перерывы, надеюсь, вы их enjoy. Так, сейчас видно мой экран? Надеюсь, да.
1:02:44
Вам нужно будет, попав в эти два модуля, нужно будет понять, что поменять. То есть если я поменял мне, точно не вам, а мне нужно будет понять, я допустим поменял в системе базы данных,
1:03:04
в схеме данных я поменял поля переименовала, потому что мне показалось, что так будет лучше, ну и все работает. Система базы данных, схема базы данных осталась стабильной, все триггеры попеременовывались, все внешние ключи автоматически были переименованы.
1:03:19
Все окей для меня, для автора этой базы данных. Но в двух модулях мне нужно зайти туда, они написаны на разных языках программирования, мне нужно найти в каких местах формируются запросы к базе данных,
1:03:30
где используются имена этих колонн, какой объем работы мне нужно сделать. Хорошо, если этих модулей два, если их двадцать, то тогда мы попадаем в ситуацию, в которой я не могу внести изменения в схему базы данных,
1:03:44
потому что от нее зависит очень много, и семантика этих зависимости, то есть их сложность, их глубина, она очень высокая, то есть глубина очень глубокая, они слишком глубоко, они слишком много знают про базу данных.
1:03:56
И это плохо, и это было в 1974 году, предложена эта концепция, каплинга, и было сказано, что чем у вас менее coupled система, чем они меньше знают друг о друге, тем лучше.
1:04:10
Я вам приведу пример, что нам делать с этой системой, о которой я вам только что рассказал, в которой два модуля и один сервер с базой данных.
1:04:20
Мы можем сделать третий модуль, вставить в эту систему, мы можем его поставить между ними, то есть оба эти модуля будут обращаться через некий интерфейс к нашему третьему модулю,
1:04:31
а третий модуль будет обращаться к базе данных. И вот эту, а саму базу данных мы скроем от всего внешнего мира, мы сделаем так, что только этот третий модуль будет иметь возможность обращаться к базе данных,
1:04:42
только он будет знать о языке программирования SQL. Все остальные модули будут к нему обращаться, и уже обращаясь к нему, они будут формулировать свои запросы в терминах бизнес-языка.
1:04:54
То есть они будут говорить, дай мне, пожалуйста, список всех сотрудников. Они не будут ему говорить, выбери мне список всех employee из таблицы employees и прикрепи обязательно туда еще одну колонку их salary.
1:05:08
Вот такого запроса они формировать не будут, они будут обращаться к этому третьему модулю и говорить, дай мне список всех сотрудников, пожалуйста, по алфавиту.
1:05:16
Этот запрос на каком-то их языке будет сформирован, на языке, который им этот модуль разрешит использовать. И они будут с ним взаимодействовать.
1:05:26
В этом случае значительно проще становится внести изменения в модуль базы данных. Изменять схему данных несложно, потому что я буду понимать, что только один модуль от нее зависит,
1:05:36
а значит я буду в него, в его код исходный попадать и корректировать там все, что мне нужно скорректировать.
1:05:46
Таким образом мы сделали decoupling, то есть мы их разделили, разделили, их разнесли, между ними вставили еще одну компоненту, а их между собой растащили по разным углам.
1:05:57
И конечно же мы замедлили систему, конечно она стала работать медленнее, потому что теперь запрос должен идти из модуля генерации отчета в этот промежуточный модуль, отсюда в базу данных, безусловно.
1:06:07
Но мы повысили maintainability, поддерживаемость системы, а это во многих случаях значительно важнее, чем performance, значительно важнее удобство работы системы, чем ее скорость, чем ее performance.
1:06:25
И этот tight coupling, в моей практике это самый главный технический враг технического решения, когда модули вот так между собой…
1:06:38
Это я вам сейчас привел очень, это очень лайтовый пример, очень легкий пример, который я вам привел, это два модуля, они соединены по языку SQL, это еще как-то все более-менее жизнеспособно.
1:06:49
Но бывают такие случаи и очень часто, когда модули, когда их создавали, их создавали как вроде бы независимые модули с каким-то тонким интерфейсом,
1:06:58
когда немного данных могут переходить из модуля в модуль, интерфейс тонкий в том смысле, что у него очень небольшое количество возможного функционала,
1:07:09
через который эти данные могут путешествовать, то есть он не разрешает большие потоки и разных данных проходить сквозь эти каналы, у него всего несколько способов запросить,
1:07:26
допустим у нас в базе данных 100 таблиц, но этот модуль наш промежуточный будет разрешать взять только список сотрудников и список департаментов,
1:07:34
а все остальное закрыто для доступа, никто к нему у него нет возможности прочитать эту информацию, это называется тонкий клиент, тонкий канал,
1:07:46
когда канал толстый, как он был у нас до этого, то он был толстый или широкий, по нему можно было передавать что угодно,
1:07:53
так вот люди сначала делают системы, в которых вроде бы модули связаны тонкими каналами, но потом со временем, когда систему начинаем поддерживать,
1:08:01
и не существует контроля качества архитектуры, а про это можно отдельную лекцию сделать, потому что на мой взгляд,
1:08:08
систем контроля качества кода много, систем контроля качества дизайна единицы, а систем контроля качества архитектуры отсутствует,
1:08:16
то есть у нас есть системы, механизмы для того, чтобы проверить, что программист пишет качественный код, это статические анализаторы,
1:08:22
file checkers, unit tests, test coverage, возможный control, mutation coverage, это можно целый курс на эту тему прочитать,
1:08:32
это системы контроля качества кода, то есть мы пишем код, мы смотрим конкретно на какой-то модуль, на какой-то класс, на какой-то файл,
1:08:39
и внутри этого файла можем программиста заставить написать идеальный код, а вот в вопросах комбинации модуля между собой,
1:08:49
в вопросах их кодизайна, в вопросах их взаимодействия, здесь количество инструментов на порядок или на порядке меньше,
1:08:59
их просто единицы, и я даже не знаю, какие это инструменты есть, наверняка они какие-то платные, и их в индустрии мы не используем в практическом смысле, то есть нет систем, которые бы мне проконтролировали,
1:09:08
по крайней мере я их не использую за многие годы, я их не видел, которые бы мне помогли проверить coupling между моими Java классами,
1:09:15
которые бы мне сказали, вот эти классы зависят друг от друга, слишком сложно, структура получается слишком coupled,
1:09:23
у вас в каких-то областях, в каких-то территориях кода превышен coupling, допустимые размеры превышены,
1:09:29
такого я не встречал, а вот в вопросах архитектуры так вообще-то, я думаю, что ничего и нет, которая бы система автоматически сказала, что ваш модуль базы данных слишком coupled с модулем отчетности,
1:09:41
вы слишком широкий толстый канал между ними проложили, это просто фантастика, может быть это система будущего,
1:09:48
может быть это все обязательно появится, но пока мы их не имеем, то есть люди просто пишут, как получается,
1:09:55
и даже если программист написал очень качественный код, все хорошо сделал в плане стилистики и прошел всю нашу систему контроля качества,
1:10:02
то все равно мы не избежим возможного нарушения архитектуры, возможного, например, tight coupling,
1:10:11
то есть программист, например, возьмет, у него был один модуль, он в нем программировал, ему понадобились данные из другого модуля, вместо того чтобы пойти по тонкому каналу к другому модулю, уже проложенному, то есть вызвать какой-то API метод
1:10:23
и оттуда получить, допустим, список сотрудников, он взял и установил connection к базе данных напрямую, и это вообще типичная ошибка, когда в model view контроллер архитектуры, NBC,
1:10:33
когда люди начинают прямо из модели делать обращение в persistence layer, это вообще классика, про это тоже мемов уже много,
1:10:42
когда прямо из модели, откуда не должно это случаться, идет напрямую обращение в базу данных, не через контроллер, как это предполагает система этого модуль, точнее, не из модели, из view, я не то говорю,
1:10:54
прямо из view идет обращение в модель, то есть без контроллера, должно быть view обращается к контроллеру,
1:11:00
использует данные, которые ему дал контроллер, и только их использует, но люди пишут так, что прямо из view,
1:11:07
прямо из HTML страницы идет запрос прямо в модель, а модель, соответственно, в базу данных, и это вообще классика,
1:11:14
вот это нарушение tight coupling, это появление tight coupling, то есть вместо того чтобы пойти по каналу уже проложенному,
1:11:22
то есть в контроллер, как это задумано архитектурой, они идут по тем каналам, которые им кажутся более удобными,
1:11:28
и это не поймать, это не предотвратить, это не проконтролировать на этапе принятия кода от программиста,
1:11:36
это должен контролировать архитектор на этапе code review, то есть помимо того, что у нас должны быть инструменты
1:11:42
программные-аппаратные, которые принимают код от программиста, которые блокируют некачественный код, у нас должен быть еще и мануальный код review, то есть должна быть еще командой людей, лучше их пускай будет несколько,
1:11:53
у нас всегда это два человека мы используем, один это коллега-программиста, который написал этот код, который пытается его покритиковать, и второй это архитектор, например, это я, некоторых проектов,
1:12:03
и я делаю второе review, то есть сначала первое review делать, сначала проходят все инструменты, если какие-то инструменты сказали нет, мы не принимаем этот код, до свидания, мы даже review не стартуем,
1:12:14
но если все инструменты сказали да, окей, тогда мы начинаем мануальное review ручное, и программист говорит да, меня все устраивает, или мы еще требуем от программиста все-таки давать комментарии,
1:12:23
не просто соглашаться, а обязательно как-то комментировать и спорить с автором кода, и вот если они закончили свой спор, и этот reviewer принимает его, тут включается архитектор,
1:12:32
я, например, присоединяюсь и опять начинаю спорить, вот после этого уже мы принимаем код, и все равно это не спасет вас от tight coupling, все равно люди будут делать эти cross-cuts такие,
1:12:41
из модуля в модуль, напрямую обращаться, как этого избежать, я не знаю, это вообще отдельная тема,
1:12:47
но вы должны понимать, что tight coupling – это зло, чем более интенсивно соединенные модули между собой, тем хуже.
1:12:54
Вторая проблема – это low cohesion, обратная сторона этого coupling, здесь мы коротко поговорим, это cohesion,
1:13:03
вообще было предложено две сразу метрики coupling and cohesion, coupling должен быть loose, так называемый, loose coupling,
1:13:10
то есть модули должны быть разнесены в сторону, если вы их правильно разнесете в разные углы вашей архитектуры,
1:13:17
то cohesion будет высокий, cohesion – это то, насколько внутри модуля все составляющие друг в другу нужны,
1:13:27
то есть что внутри модуля все, кто в нем внутри находится, например, если это класс, то все атрибуты, все методы, они между собой связаны,
1:13:35
или это модуль, то все классы, которые в нем внутри, они как-то друг другу нужны, они как-то между собой связаны,
1:13:41
то есть не должно быть модулей, в которых или систем, в которых или классов, в которых существуют такие порции кода,
1:13:48
что это одно что-то делает, а это другое, ну, например, если у вас есть класс, который, у него есть метод, не знаю, там,
1:13:56
получить данные от юзера, и второй метод – посчитать число фибоначи, но это не cohesive-модуль, потому что две совершенно разные,
1:14:07
совершенно два разных функционала, они между собой никак не связаны, и их нужно разнести на два модуля, вот если вы их разнесете на два модуля, у вас cohesion станет high cohesion, то есть они будут cohesive, они будут такие цельные,
1:14:20
это вторая проблема техническая, которая убивает программную архитектуру, это низкий cohesion, то есть мы лепим все в одно место,
1:14:28
программист открывает класс, он не понимает, для чего этот класс толком нужен, и он в него складывает все, что ему хочется,
1:14:35
он просто добавляет туда еще одну функцию, и она работает, и хорошо, компилятор ее понимает, и хорошо, и это все уходит на продакшен,
1:14:43
надо каким-то образом за этим бороться, то есть архитектор должен держать это под контролем и наблюдать за тем, чтобы классы были,
1:14:52
чтобы в классах было поменьше функционала, и в модулях было поменьше функционала, и если он там есть, то он точно принадлежит этому месту, точно принадлежит этому классу,
1:15:03
и это нас подводит к, а у нас всего 9, sorry, я вам обещал 10, я вас обманул, у нас всего 9 пунктов, это хорошо, так вот low cohesion это значит слабый cohesion,
1:15:15
с которым мы должны бороться путем review, я других способов здесь не знаю, это только review кода и его ручной анализ,
1:15:29
здесь я хотел бы еще один пункт упомянуть, я не стал его выносить в отдельный пункт, это именование, я думаю, что проблема именования классов, модулей, компонентов,
1:15:39
она очень релевантна этой проблеме cohesion, и она тоже является причиной провала архитектуры, когда люди мало внимания уделяют тому,
1:15:49
какие правильные названия дать модулям, классам, методам и так далее, если у нас классы названы непонятно или названы тривиально,
1:16:01
я вот даже обращу на это внимание, если мы называем классы тривиальным образом, например front page controller или data factor или database connection,
1:16:17
эти тривиальные названия, они кажутся программисту, который дает их простыми, потому что он их знает, он их видел в других системах,
1:16:27
но они негативно влияют на вот этот самый cohesion, потому что когда программист открывает front page controller,
1:16:33
он точно не знает, что может находиться в этом front page controller, а что не может находиться, касается ли, например, рендеринг CSS stylesheet этого front page controller,
1:16:46
вроде бы этот CSS – он для front page, ну давайте его вставим сюда, а касается рендеринга картинок front page этого контроллера,
1:16:54
ну, наверное, может быть, касается, программист, который не хорошо понимает архитектуру, не глубоко в него погружен,
1:17:00
и которому нужно решить проблему здесь и сейчас, то он вполне себе может принять такое решение, потому что имя, которое он прочитал на модуле, на классе, на методе,
1:17:09
оно тривиальное, оно очень избитое, оно с очень размытым смыслом, потому что этот смысл уже, это имя использовалось в миллионах разных комбинаций,
1:17:19
поэтому смысл у него не узкий, а суперширокий, и это позволяет программисту сделать ошибку, более того, это вводит его в состояние конфюза такого, конфуза,
1:17:32
и он в этом конфузе долго пребывать не будет, он все равно какое-то решение примет, он вряд ли будет внимательно изучать всю архитектуру, чтобы разобраться,
1:17:41
а что же все-таки этому контроллеру принадлежит, что нам сделать, он этим заниматься не будет, он просто напишет, куда попало, и на этом все закончится.
1:17:49
Ну и последнее, что нам мешает делать хорошие архитектуры программные, это, конечно, сложность и размер.
1:17:59
Чем система больше и чем она сложнее, тем у нее выше шансы на провал, тем скорее она развалится, тем скорее она придет в негодность и код начнет деградировать,
1:18:11
в общем, все будет стремиться к развалу и к разрушению. Что я имею в виду под сайзер, например, это размер класса, большой класс – это плохо,
1:18:19
размер метода, длинные методы – это, безусловно, плохо, всем это известно, большой модуль, в котором много функционал – это плохо, если ваш модуль много функционал,
1:18:29
если в нем разные фичи, если их фичи большое количество – это плохо, это ведет к разрушению архитектуры, потому что трудно обеспечить этот кахижин,
1:18:37
трудно прогарантировать, что все эти составляющие действительно принадлежат одному домену проблем.
1:18:46
И, соответственно, программисты начнут туда помещать вообще все подряд. Размер кодовой базы – это тоже очень плохо.
1:18:54
Я вот знаю известный спор относительно монолитных репозиторий, так называемых, и немонолитных.
1:19:00
То есть, я думаю, многие знают, о чем идет речь, это когда мы, например, в Git-системе или в любой другой системе контроля версий
1:19:07
размещаем один программный проект, другой программный проект, третий программный, они все находятся в одной кодовой базе.
1:19:15
Это просто разные директории, а еще, не дай бог, разные ветки. И вот это все размещается в разных директориях,
1:19:22
и люди многие из очень уважаемых компаний, начиная с Фейсбука и заканчивая нашими компаниями,
1:19:29
я много слышал мнений, много аргументаций в пользу такого подхода. Они говорят, нам удобнее, когда все вместе находится и все релизится вместе.
1:19:39
То есть у нас такой один монолитный процесс релиза, сборки, тестирования, нам не нужно настраивать в каждом месте по-своему,
1:19:45
и нам так комфортнее и удобнее. Я категорически не согласен. Я против монолитных репозиторий, я считаю, что репозитории должны быть маленькие.
1:19:54
Чем меньше, тем лучше, чем более, чем мельче модули, которые вы разрабатываете, тем легче их поддерживать, легче понимать, о чем они,
1:20:02
легче им найти для него архитектора, легче проконтролировать качество, легче проконтролировать жизненный цикл, легче увидеть баги, репортить баги. Все легче.
1:20:11
Я к этому пришел, к сожалению, не сразу. Я много лет потратил на именно создание таких монолитных решений,
1:20:18
и сейчас чувствую, насколько приятно разрабатывать компоненты, в которых условно 5 Java классов.
1:20:26
Вот 5 Java классов мы собрали вместе, увидели, что это определенный функционал. Сделайте из него отдельный пакет, сделайте из него отдельный релиз, сделайте это отдельной библиотекой, и выложите эту библиотеку в open source.
1:20:38
И все, пускай этот функционал из пяти классов лежит в open source, поддерживается отдельной группой людей, имеет свой жизненный цикл и оставьте его в покое.
1:20:46
Сделайте следующий модуль опять из пяти-десяти Java классов. Я Java, потому что я на Jav больше всего программирую.
1:20:52
Сделайте такие модули изолированные, самостоятельные, и поддерживайте у них у каждого свой жизненный цикл.
1:20:59
Вы увидите, что большинство из них будет сделано и будет лежать. У вас не будет там жизненного цикла активного.
1:21:05
Вы сделаете их, доведете до какой-то версии стабильной, и оно останется в этой версии. И будет существовать, вы будете одно изменение в полгода делать для этого продукта.
1:21:13
Другой продукт будет иметь свою динамику жизненного цикла, свою интенсивность разработки. У каждого будет по-своему.
1:21:19
Таким образом вы выиграете. Монолитные репозитории – это какое-то заблуждение 21 века, потому что их используют многие, многие компании на них переходят.
1:21:29
Я считаю, что это слабость менеджмента. Это слабость devops’ов. Это слабость программистов.
1:21:35
Они расписываются в собственной слабости. Они говорят, мы ленивые, мы глупые, мы неграмотные, мы не знаем, как поддерживать разные индивидуальные разродненные системы, мы не хотим наблюдать за разными жизненными циклами,
1:21:46
мы ничего не понимаем, что такое cohesion, мы не понимаем, как сделать, чтобы оно было cohesive. Нам лучше, чтобы все было ровным слоем размазано по одному большому репозиторию.
1:21:54
И мы как-то между собой здесь разберемся. Как-то у нас связи наладятся. Короче, оно работает, и не трогайте.
1:22:00
А когда вот все разносится, начинаются вопросы. А как же нам назвать эти модули? А как же нам действительно выделить функциональность? Оттал ли это функция? А правильно ли мы название дали?
1:22:10
А правильно ли мы разделили эти жизненные циклы? И так далее. А правильно ли мы их интегрируем? Все эти вопросы не имеют ответа. У слабых программистов, у слабых архитекторов.
1:22:20
И поэтому они говорят, мы эти вопросы задавать не хотим. Мы не хотим придумывать название каждому модулю из 40. У нас есть 40 разных каких-то компонентов.
1:22:27
Мы точно не знаем, как их назвать. Потому что они вот так перепрелетены. Один вызывает другой, другой вызывает его в обратную сторону.
1:22:34
Потом они опять вызывают друг друга. Как это все релизить? То есть они не смогли сделать модульную архитектуру, они не смогли сделать кахизев компоненты, которые декапывают.
1:22:43
И они сказали, все, монолидная архитектура – это спасение. Это спасение, да, но это не устранение симптомов. Точнее, это устранение симптомов, но не устранение болезни.
1:22:54
Ну и комплексити. Второе – это сложность. Вы тоже, наверное, все понимаете, что сложность, она приводит к негативным последствиям.
1:23:02
Чем сложнее код, который вы пишете, тем хуже. И тут, наверное, последняя мысль, на которую я закончу.
1:23:08
Многие программисты считают наоборот. Они считают, что чем сложнее код, который они написали, тем они более сложные сами по себе как личности.
1:23:19
И тем они более качественные программисты. Я не раз встречал такие вот посылы, когда программист с улыбкой реагирует на замечание о том, что
1:23:31
«слушай, ну здесь ничего непонятно что-то написал, какой-то сложный алгоритм». Его это радует. Он улыбается, он горд собой, он понимает, что он смог написать то, что другие не могут прочитать.
1:23:41
Это, конечно, супервредная философия, с которой нужно бороться.
1:23:47
То есть нужно программистам наказывать за сложность, нужно их не поощрять за то, что они написали код, который сложно прочитать.
1:23:53
А нужно его не принимать, риджектить. Ставить ему двойку за то, что он пишет сложный код. Код должен быть простой, архитектуры должны быть простые, компоненты должны быть простые, функционалы должны быть простой.
1:24:03
Все должно быть понятно человеку за несколько минут. Попадая в описание архитектуры, попадая внутрь класса, попадая внутрь метода, человеку должно быть понятно, что здесь происходит за несколько минут.
1:24:15
Если непонятно, то виноват автор. Ну, как мы уже знаем, виновата, конечно, система, которая приняла этот код в репозиторе, но мы должны найти брешь в нашей системе.
1:24:28
Почему она пропустила код с высокой сложностью? Мы можем считать cycle-matic complexity, вы знаете, такую метрику, ей тоже уже, наверное, лет, не знаю, в 74-ом или 72-ом году она придумана была.
1:24:41
То есть ей уже 50 лет. Cycle-matic complexity, cognitive complexity, которую недавно придумали буквально несколько лет назад и так далее.
1:24:49
Halstead complexity. Этих методов, метрика очень много, которые позволяют, maintainability, индекс – это тоже метрика очень известная, которая позволяет поймать сложный код и запретить его.
1:25:01
Вот мы должны бить по рукам программистов, которые пишут сложный код. И не просто технически бить по рукам, но и менять их менталитет.
1:25:08
Объяснять им, что они пишут код для других программистов, они пишут код для будущих других людей, которые придут за ними.
1:25:15
Вы уволитесь, но придут новые люди. Пишите для них, пишите, чтобы было понятно, а не так, чтобы мы вам, условно, больше заплатили за ваш сложный код.
1:25:25
За сложный код нужно платить меньше, я так думаю. Ну вот на этой позитивной ноте мы… я, наверное, закончу.
1:25:31
Если у вас есть вопросы, давайте, у нас буквально пару минут, если нет, то я, в общем-то, все сказал.
1:25:38
Надеюсь, было полезно.
1:25:44
Кому было полезно? Дайте мне какой-нибудь знак в комментах. Я понял. Кому-то было.
1:25:53
Захотелось в Open Source, тут говорят. Это хорошо. Open Source – это, безусловно, да, это пробуйте.
1:26:02
Open Source и попробуйте очень просто. Идете на GitHub, создаете аккаунт, делаете первый репозиторий, то, с чем вы и так работаете,
1:26:08
где-нибудь для… ну, в рамках учебной программы, любые эксперименты, любые пробные проекты,
1:26:14
делайте их в Open Source, открывайте код, и вы увидите, что на этот код начнется какая-то реакция появится. Люди будут реагировать, и вам будет это очень интересно видеть,
1:26:22
как какой-то программист из Бразилии вдруг вам поставил лайк, или какой-то программист из Аргентины,
1:26:29
или из Австралии вдруг прислал вам комментарий, написал, что «а у вас здесь ошибка, поправьте». И более того, если он еще и поправил эту ошибку.
1:26:36
У вас будет настолько много эмоций позитивных, вам настолько захочется делать еще, что вы потом не оторветесь.
1:26:42
Вопрос тут задают. Российские аналоги GitHub имеют активность какую-то, или Open Source на них не будет развиваться?
1:26:50
Ну, тут, знаете, у меня, наверное, я отвечу, может быть, не совсем политкорректно,
1:26:56
но я думаю, что это будет крайне сложно сделать так, чтобы какие-то, даже не дело не в российских,
1:27:03
китайские есть аналоги GitHub, есть какие-то российские аналоги GitHub, очень сложно будет сделать то, что GitHub сделала за последние 20 лет,
1:27:11
а именно, аккумулировал всю массу основных пишущих программистов в мире, а их, по разным оценкам, порядка 30 миллионов.
1:27:19
Вот эти 30 миллионов человек, они пришли в одну точку. Это то, что сделала Stack Overflow.
1:27:25
Вот у нас есть две, наверное, площадки, которые в 21 веке показали свою феноменальную эффективность. Это GitHub и Stack Overflow. Они соединили в себя всех программистов в мире.
1:27:34
Все ходят за вопросами и ответами на Stack Overflow. Никто не ходит на какие-то форумы больше, которые существовали еще 20 лет назад.
1:27:41
Я сам помню эти Java-форумы, Python-форумы, JavaScript-форумы, на которых в таком формате кривом, некрасивом, неудобном приходилось задавать вопросы и получать ответы.
1:27:50
Это было крайне тяжело. Потом появился Stack Overflow и решил эту проблему раз и навсегда. Можем ли мы сделать аналог этого? Мы или китайцы или бразильцы?
1:27:59
У меня на этот счет большой скепсис. Я думаю, что это будет крайне сложно. Потому что нам тут же дело… GitHub же почему GitHub?
1:28:08
Не потому что софт у него такой интересный. У него софт GitHub можно за неделю написать. Весь GitHub, основной его функционал, можно написать за одну неделю.
1:28:17
Он будет работать. В общем-то, так они его и написали. Он же родился GitHub, как на салфетке. Есть на этот счет легенда, что в кафе этих ребят, их там полдвое было,
1:28:27
они просто набросали эту идею на салфетке и закодировали на языке. Ruby он написан. Его написали очень просто на Ruby on Rails, по-моему, в тот момент.
1:28:35
И выложили его. То есть сам софт он копейки стоит. Но вот этот весь комьюнити, который они собрали, вот его, как его теперь перевести на другую платформу, трудно себе представить.
1:28:46
Я подозреваю, что никак. Поэтому создание аналогов GitHub, идентичных GitHub, на мой взгляд, это провальная идея.
1:28:53
Создание каких-то альтернативных решений, например, которые бы отличались по функционалу и давали бы что-то такое, чего не дает GitHub, здесь у нас есть, конечно, потенциал.
1:29:02
Например, одна из идей, вокруг которой мы уже давно общемся, это создание распределенного GitHub.
1:29:09
GitHub – это сейчас централизованная система. Весь код находится в руках у Microsoft. И это, конечно, волнует тех, кто не большой фанат Microsoft.
1:29:21
Этих людей, конечно, волнуют та ситуация, что их код, который они пишут, например, меня это волнует, тот код, который я пишу, находится в руках у фирмы Microsoft,
1:29:29
которая может завтра забрать этот код и закрыть мне доступ, например. На этом все закончится. И все, что я делал последние 15 лет на GitHub, все исчезнет.
1:29:38
Мне, конечно, жалко, не хотелось бы этого. Хотелось бы иметь какую-то систему типа блокчейна, типа биткоина,
1:29:44
где нет одного автора, где код не принадлежит одной компании, а есть какое-то распределенное хранилище, часть его поддерживается Microsoft, часть поддерживается IBM,
1:29:53
часть китайскими фирмами, часть российскими. Вот мы так обмениваемся. Если какая-то одна из этих фирм скажет, что я хочу что-то заблокировать,
1:30:00
у нее ничего не получится. Она просто выключит свои сервера, но остальные сервера будут работать.
1:30:06
Я думаю, будущее за этим. Тут еще один вопрос. Чем вы объясните прогнозируемый вами глобальный переход на Open Source в будущем?
1:30:15
Ну, как я сказал, я думаю, что Open Source просто станет… Компании, которые не перейдут на Open Source,
1:30:21
они начнут стремительно терять в поддержке пользователей. То есть от них будут уходить программисты,
1:30:27
бесплатная рабочая сила, которая будет интенсивно контрибьютить в открытые решения.
1:30:33
Вот посмотрите, есть проекты на GitHub, свежие проекты, у которых история, за год они получают 20 тысяч звезд на GitHub.
1:30:42
Это огромные цифры. 20 тысяч – это очень большая цифра для GitHub. Проект с 20 тысячами звезд – это суперпопулярный проект.
1:30:51
Обычно он развивается там 10-15 лет. А есть проекты, которые за год так стремительно набирают популярность. То есть люди выбрасывают какую-то идею интересную в открытое пространство,
1:31:00
делают каркас, а дальше тысячи программистов собираются и совместными усилиями поднимают это до уровня проекта.
1:31:07
Так, в общем-то, был создан Docker во многом. То есть Docker – это известный продукт, но его сначала он был закрытый.
1:31:14
Его сделали внутри одной компании, там, по-моему, из Нью-Йорка она. И потом они выложили это все в открытый доступ.
1:31:20
И когда они выложили в открытый доступ, то рост популярности этого продукта был просто стремительный.
1:31:26
Потому что люди стали активно контрибьють, им понравилась идея, и стали люди туда вносить свой вклад так быстро, как не может себе позволить ни одна компания.
1:31:34
То есть никакой Microsoft, никакой Google не может себе позволить такую интенсивную разработку, как может позволить себе какой-то школьник на GitHub.
1:31:42
То есть школьник, создавая какой-то интересный проект на GitHub, он получает огромную поддержку, если проект интересный.
1:31:48
То есть компании это все больше и больше понимают. Здесь это не моя мысль, это статистика об этом говорит, что все больше и больше компаний.
1:31:55
Microsoft же сейчас первый, самый крупный open-source-контрибьютор на GitHub – это Microsoft. То есть самое большое количество кода в открытом доступе, в который принадлежит какой-то компании – это код Microsoft.
1:32:07
Хотя 10 лет назад или 15, они рассказывали, что этот Стив Балмер рассказывал, что Microsoft никогда в open-source и Linux это все отлукавывает, это все вред, и код должен быть закрытым.
1:32:20
Ну, смотрите, что произошло. Они туда выходят из-за того, чтобы купить пользователей.
1:32:27
Это главный мотив выхода в open-source. Для того, чтобы быть ближе к пользователю, для того, чтобы больше понравиться пользователю, для того, чтобы пригласить пользователя, ну, кодера, программиста, пригласить к себе в экосистему.
1:32:38
То есть это борьба за экосистему. Вот так. Это тоже у меня есть про это статья, где-то я писал на блоге.
1:32:44
Кстати, я вам покажу, если вам заинтересовал мой доклад. Вот, кстати, список книг, которые я бы рекомендовал.
1:32:50
А это мой Telegram-канал, можете подписаться. Я там периодически выкладываю лекции, которые я кое-где читаю.
1:32:57
И там тоже вот на моем блоге можете найти статью про open-source. Я там делаю анализ, я рассказываю, какие компании в open-source вышли,
1:33:05
когда какие инвестиции в open-source делаются, почему. И мой главный вывод, который я делаю, он заключается в том, что компании борются за экосистему.
1:33:13
Они борются за территорию в этой экосистеме. Кто будет владеть программистами, тот и победит в борьбе за IT-продукт.
1:33:21
Сейчас уже борьба идет не то, кто даст какой-то продукт более качественный, не то, кто более дешевый продукт даст,
1:33:27
а кто заберет в себе эту комьюнити программистов, которые за собой приведут уже всех остальных. То есть у нас есть такая некая экосистема из 30 миллионов программистов.
1:33:37
Вот кто, какой экосистеме принадлежит какой программист, в общем-то, в этом весь вопрос и заключается. Вопрос успеха коммерческих компаний.
1:33:47
Надеюсь, я мысль бы сказал цельно. Почитайте блог, я еще подробнее сам. Все.
1:33:55
Спасибо, Игорь Горгиевич, очень интересно. По вопросам видим, что заинтересовала вас,
1:34:04
всех вашей информации наверняка новые подписчики будут, а может быть кто-то уже ими и является.
1:34:11
Спасибо вам большое, всего доброго всем. Пока. До свидания.