Мифы из разработки или почему алгоритмы — это никакая не база

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

Transcript

1. Мифы из разработки или почему алгоритмы — это никакая не база Денис Аникин, https://xfenix.ru
2. Представлюсь — Меня зовут Денис Аникин — Я тимлид/техлид/лид сообщества в Райфе — У меня много команд — Я пишу на python, typescript, fullstack — Занимаюсь архитектурой, devops — Выступаю на конференциях, работаю в ПК http://xfenix.ru
3. Это очень предвзятый доклад!
5. Нам в голову «вбивают» стереотипы и мы рассуждаем ими
6. О чём будем говорить? О том, что я считаю «испорчено» стереотипами и предрассудками: — Собеседования (алгоритмы огонь) — Документация (СЛЫ, пиши документацию или извинись) — Паттерны проектирования (ну это БАЗА) — SOLID (элементарная тема) — Архитектуры чуток (иди сюда, сейчас я поясню про анемичные модели)
7. Ну и попробуем кое что из этого поправить
8. Собеседования
9. Собеседования в бигтехе 2025 — Алгосекция х2, х4, х10 — System design — Culture fit interview — Интервью с командой — … — <...> ой мама ВОЛКИ ЖЕ КРУГОМ
13. А на самом деле они боятся…
17. Как же так, ведь алгоритмы это… БАЗА Их же не подделаешь, они отсеивают!
18. Он не решает задачи с литкода!
21. Мы же проверяем как человек мыслит!
22. Неужели алгоритмы не работают?
24. Денчик Аникин
25. Денчик Аникин НОНСЕНС
26. Как же это исправить?
27. Как это исправят? — Погонят на мороз тех, кто это всё заварил — Может быть, откажутся от неработающих способов? Не очень-то алгоритмы работают… — Придумают что-то новое?
29. Правильный ответ: …
30. неизвестной компании Какая-то компания а
32. Правильный ответ: добавят больше алгоритмов!
33. Всё логично
34. Почему алгоритмы не работают — Никто и никогда не обосновывал, что они работают. Поищите, найти не сможете — Кодинг на глазах у незнакомых людей в стрессе — не показатель как вы пишете код спокойно и дома или в офисе (зачем в офисе… ну ладно) — Алгоритмы — это что вообще? (нет установленного списка этой «базы», нейросети вообще путают алгоритмы и структуры данных)
35. Аргументы защитников — У нас стоит очередь за забором (не стоит*) — Нам надо резать поток (любители резни) — Мы видим как вы думаете (наука современная не смогла, а вы как-то смогли?) — Показывает ваши умения (умения проходить собес да, всё остальное не обосновано и не имеет доказательств) — Показывает базовые навыки (базовые навыки это очердные bfs по островам на собесах?) — Объективность (ну конечно, сама объективность, ведут правда люди, и у них бывает плохое настроение, но мы очень объективные)
36. Что плохого? — Нам нужен работник, который делает +- то же, что и мы или наши коллеги — Нам не нужен человек, заточенный на наши собеседования, нам нужен его реальный опыт — Опыт не проверить на собеседовании (вы были в ситуациях, что после 150 собеса оказалось, что человек чего-то не знает или, наоборот, оказывается знает куда больше) — Программисты одержимы объективностью. Её нет, оценивают люди, люди болеют, не выпивают кофе, у них портится настрой и т.п. — Притворяться объективным — хуже, чем признавать свою субъективность и работать с ней
37. Мы все люди и работать нам с людьми, а не с машинами
38. Но. Плохая новость — алгоритмов будет больше
39. Ещё плохая новость — это никому не поможет Компании обозлятся ещё больше и так по кругу, пока всё не сломается
40. Компания 1 Компания 2 Компания 3 Компания 4
41. Это не значит, что мы должны любить алгоритмы и строить найм на этом Будете строить найм, прошу, посмотрите на другие пути!
42. Ваши альтернативы — Смотреть на софты — Смотреть не на «red flags»-фигню, а на человека комплексно. Человек не любит кошек? Плохой! Может у него аллергия? Человек пишет на пхп… :) — Давать разбирать вещи ближе к жизни: код ревью в удобном устном формате, «а как ты решаешь вот такую проблему», «как внедрял такой-то подход» — Брать людей на оплачиваемые «тестовые дни» (если у вас очень серьезный бизнес (тм))
43. Рекрутер: «Ты не говорил, что полгода писал на PHP!!!»
44. Клоунский нос отвалился :( Кусочки моего реального резюме
45. Документация
53. Документация — Заговор индустрии — Все хотят себе — Те, у кого есть, думают о том, что лучше не было бы — Рядом с вами сидит кто-то очень довольный собой, у которого все так же, но на СЛОВАХ
54. Виды документации: архитектура
56. А в жизни…
57. Мы это не пишем, ну это там не уследишь… Это вообще нереально, там это не надо ну в общем… Можем строить автоматом! Один раз написали, вечно актуально, чего бухтеть?
58. В итоге
60. Спустя год
63. Комментарии
64. class Calculator: """Calculator class for performing calculations.""" def add(self, a: int, b: int) -> int: """Adds two numbers together.""" # This function adds a and b return a + b # Return the sum of a and b def subtract(self, a: int, b: int) -> int: """Subtracts one number from another.""" # Subtract b from a # Note: This used to multiply before, but was changed return a - b # Returns the result of subtraction def multiply(self, a: int, b: int) -> int: """Multiplies two numbers.""" # Multiplication function, very complex return a * b # Multiplication occurs here def divide(self, a: int, b: int) -> float: """Divides a by b.""" # Important: This function will break if b is 0 return a / b + 1 # Divide a by b and return it
65. База знаний (конфлюенс и т.п.)
66. Их невозможно организовать — Я 7 лет проработал на медиа (газеты, агрегаторы) рынке, знаю про читаемость и глубину просмотра. Так вот, люди делают 1-2 клика и читают верх и низ статьи — Как люди вкладывают страницы в конфлюенсе и маркдаунах? Обычно очень глубоко. Всех научили «бить по модулям». Базы знаний пишут так же
67. Кто сказал, что документация работает?
68. Частый диалог на собеседовании — Что думаете про документацию? — Надо писать!!!!1111111 — Пишете? — Да, но эээ нет. Я знаю, что надо… Извините, очень будем стараться!
69. Что же делать?
70. Не писать документацию
72. Почему не надо писать документацию (1 из 3) — Писать текст, так чтобы люди поняли, умеют единицы — Программисты умеют очень плохо писать читаемый текст — Часто в программистских текстах претенциозность, понты и/или термины без определений Ты должен понимать, ты чё, не программист? Слышь? Сейчас я ПОЯСНЮ. СЕЙЧАС Я РАЗЖУЮ ДЛЯ ХЛЕБУШКОВ/ТУПЫХ — Ну правда, ты же умный — Эй, ну всё же понятно — Не знаю, моя воображаемая собака всё понимает, не то что ты
73. Почему не надо писать документацию (2 из 3) — А обновлять её кто будет? А, прости, я не понял, конечно ты будешь. А через 2 года? А через 5 лет? Много раз обновлял? Как твоя документация пятилетней давности? — Ок, ну я понял, что у твоего друга коллеги со второй работы всё работает, а у тебя? — Количество документов растёт, а количество людей в команде нет => ты не сможешь её обновлять
74. Почему не надо писать документацию (3 из 3) — Стоить один раз соврать, не договорить, и тебе перестанут верить — Документация, которой не верят, идёт в помойку, а мы идём в другой важный текст… — В исходный код!
75. поясню
77. Чем заменить — Самодокументируемый код — Минимальные readme.md (quickstart обязательно, для людей + минимальное описание репы + полезные ссылки + возможно, архи-схема сервиса) — Командные соглашения, архитектурные решения (пополняется иногда, не растёт сильно) — Общие гайды (пополняется иногда, не растёт сильно) — Автогенерация + code-first (как swagger ui) — Всё остальное чаще проще посмотреть в коде и спросить у людей
80. Попал в экранизацию мема we live in a society — Ты обосновываешь позицию чаc. А тебе «ну нет» и куча лайков — … — Что я хотел сказать: не ломается оно о жестокую реальность (у нас 5 лет живёт, это работает). Если уважаемый анон под быстро имел в виду лет 15-20, то это пока мой суммарный опыт в IT, посмотрим…
81. Полезные ссылки (почти) — https://github.com/community-of-python/pylines — https://speakerdeck.com/xfenix/kodovyi-stil-python-proiektov-v-2023-ghodu
82. Паттерны проектирования
84. А кто сказал…
86. …что они работают?
89. Почему я задался вопросом — Почти никто из опрошенных мною людей за многие годы общения не обосновывал. Всегда была «это база», «это знать надо», никогда не «вот доказательства» — Singleton опасен в мультипоточной среде. Некоторые его признают анти-паттерном — Фабричный метод и абстрактную фабрику многие путают — Спроси человека чем отличаются Адаптер, Прокси, Мост и Декоратор и ты услышишь… ничего. Я пробовал и проверял на собеседованиях
90. Поговорим о фабричных методах
91. class Animal: def speak(self): pass class Dog(Animal): def speak(self): return "Woof!" class Cat(Animal): def speak(self): return "Meow!" class AnimalCreator: def create_animal(self, animal_type: str) -> Animal: if animal_type == "dog": return Dog() elif animal_type == "cat": return Cat() creator = AnimalCreator() animal = creator.create_animal("dog") print(animal.speak()) # Output: Woof!
92. class SongSerializer: def serialize(self, song, format): serializer = self._get_serializer(format) return serializer(song) def _get_serializer(self, format): if format == 'JSON': return self._serialize_to_json elif format == 'XML': return self._serialize_to_xml else: raise ValueError(format) def _serialize_to_json(self, song): payload = { 'id': song.song_id, 'title': song.title, 'artist': song.artist } return json.dumps(payload) def _serialize_to_xml(self, song): song_element = et.Element('song', attrib={'id': song.song_id}) title = et.SubElement(song_element, 'title') title.text = song.title artist = et.SubElement(song_element, 'artist') artist.text = song.artist return et.tostring(song_element, encoding='unicode')
93. class SongSerializer: def serialize(self, song, format): serializer = self._get_serializer(format) return serializer(song) def _get_serializer(self, format): if format == 'JSON': return self._serialize_to_json elif format == 'XML': return self._serialize_to_xml else: raise ValueError(format) def _serialize_to_json(self, song): payload = { 'id': song.song_id, 'title': song.title, 'artist': song.artist } return json.dumps(payload) def _serialize_to_xml(self, song): song_element = et.Element('song', attrib={'id': song.song_id}) title = et.SubElement(song_element, 'title') title.text = song.title artist = et.SubElement(song_element, 'artist') artist.text = song.artist return et.tostring(song_element, encoding='unicode') Это в DI надо вынести Как оно связано с классом? Как оно связано с классом? Что с SRP?
94. А вот что люди делают, когда говорят о фабриках
95. class Car: def drive(self): return "Driving a car" class Bike: def ride(self): return "Riding a bike" def create_vehicle(vehicle_type: str): if vehicle_type == "car": return Car() elif vehicle_type == "bike": return Bike() # Client code vehicle = create_vehicle("car") print(vehicle.drive()) # Output: Driving a car
96. Это вообще был не паттерн! 󰤇 Хотя, если читать Мартина…
99. Что мне кажется подозрительным — Оригинальная книга 400 страниц, её мало кто читал и она не применима к питону — Каждый делает свой пример. refactoring.guru не стесняется иерархий в кучу классов и кучу abc, это всё выглядит скорее как анти-паттерны, чем паттерны — Даже сильно бывалые программисты «плывут» — Мало кто за обычными заборами слов может пояснить зачем нужны паттерны, кроме как «ну прост», «ну чё ты», «просто надо» — Иногда выходит плечистый программист и говорит «ТЫ НЕ ПРАВ, пять лет назад я реализовал обсервер и сделал ручку на 2 RPS»
101. Мой вывод: абстрактные паттерны проектирования не база
102. Что делать — Возможно, ознакомиться с базовыми паттернами в языке (итератор, декоратор, синглтон) — Возможно стоит узнать фабрики (не паттерн), билдеры иногда, фасады иногда (они простые), местами синглтоны, прокси (см. javascript), композицию (не путать с композитом, который паттерн) — И давайте перестанем друг друга натужно спрашивать их на собесах, это вообще пользы не приносит. Один вспоминает что хотел спросить, второй по буквам вспоминает названия, оба верят, что это каждодневный инструмент…
103. SOLID
104. А оно не работает…
105. Как объясняет сын маминой подруги — Вода мокрая — Земля твердая
106. Как я объясняю (на примере лора warhammer 40k)
108. Похожим образом объясняют SOLID… ну все!
109. Какие? Меньше чем что? Что такое расширяемость? А неправильно не наследоваться? Спасибо! В питоне нет интерфейсов :( В питоне нет интерфейсов :( И принцип не совсем понятен…
110. LSP (как репер типа)... ну да couldn’t care less Что такое ответственность? Что такое открытость и закрытость? Ещё бы понять что это
111. Что такое причина? Что такое сущность? Не цитата из основной книги + у нас нет указателей Что такое абстракция?
113. Почему не работает — Мартин не программист, а консультант, читать его сложно, поэтому никто не читал — На собеседованиях всегда абсурд. SOLID применяю каждый день. Буквы не помню… ну интуитивно я его понимаю — Изложение под python немного специфично — Термины из книги не объясняются (это бич архитектуры во многом)
115. Как исправить? — Написать свое изложение — Следить за каждым PR (вы не будете) — Покрыть 100% кода аннотациями типов (вы не будете) — Интуитивно, само — не работает
116. Что можно использовать? — Мы пишем человеческий гайд для питона (и почти написали, через страдание) — https://speakerdeck.com/xfenix/piterpy-2024-vniedriaia-solid есть мой доклад с рефлексией и советами
117. Работает ли?
118. По нашим наблюдениям, скорее да, чем нет
119. Архитектуры (ха ха, у нас нет времени)
120. Мой скромный enterprise проект 15 книг по DDD
122. Пару вопросов — Вы когда-нибудь писали гайды? — Они работали? — Сколько из них выполнялось? — Сколько там было страниц?
123. Работа с возражениями
124. Книгу по DDD Книга по DDD
125. В ответ на мои наблюдения слышу я обычно — А Я НЕ ЗНАЮ ЧТО У ТЕБЯ ЗА ПРОБЛЕМА У МЕНЯ ВСЁ РАБОТАЕТ ◦ а у меня нет, о чём я и говорю — Почитай книгу ◦ ты вот читаешь и тебе не помогает, потому что ты не можешь объяснить смысл коротко ◦ мотив читать книгу должен быть понятным, простое чтение — не аргумент ◦ объясни по пунктам чем тебе помогло, без оценочных категорий «раньше было плохо, стало хорошо»
126. В ответ на мои наблюдения слышу я обычно 2 — Ты не понимаешь, это другое — Ну, нет, это не так — Мы делали иначе (а мы тоже!) — Ты не прав
127. Обычно я просто делюсь наблюдениями, с ними сложно спорить
128. Поэтому — Я не говорю, что кто-то (вы) не правы — Я не говорю «делайте только так» — Я делюсь тем, что мне кажется странным и предлагаю свои решения — Если вам близки эти мысли, то вас это может продвинуть дальше — Надеюсь, вам что-то из этого показалось полезным
129. Это всё php треклятый и потому что алгоритмы не знаю…
131. Спасибо за внимание! Вопросы? Денис Аникин, https://xfenix.ru