Sergey Andreev on X: "Наверное, самая удивительная вещь в разработке это то, что наш код одновременно является как продуктом, так и рабочим местом.

При этом при разработке мы не можем не учитывать второе, иначе будет как в том меме про user experience vs design.

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

Это значит, что при изменении этих вводных мы должны получать разные программные решения для одних и тех же задач.

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

Есть знаменитый закон Конвея, согласно которому структура создаваемой системы будет копировать структуру коммуникаций организации, которая её разработала. (Опять же смотрим на прекрасную картинку про UX/UI.)

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

На компанию часто бывает сложно посмотреть как на парк с высоты птичьего полёта, поэтому эта часть часто ускользает.

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

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

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

По сути мы большую часть времени тратим на проектирование нежизнеспособных решений, потом на попытку их поддерживать, после этого пытаемся обкладывать их правилами, запретами, ограничениями (в случае парка, например, мы могли бы поставить забор: чего это народ топчет газон? Но в случае кода почему бы не добавить линтер, или бюрократии с согласованиями, или просто бегать и ругаться с коллегами, сетуя своим друзьям или интернету на глупых людей. Тут всё зависит от ваших полномочий.)

Где-то здесь уже хотелось бы получить какие-то практические советы. И что же с этим делать? Я бы даже мог попробовать их вам дать или сделать, например, курс (хе-хе).

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

Ну а хорошо это потому, что это и есть инженерная задача, а мы с вами как раз инженеры. На удивление, дисциплина разработки программного обеспечения сгенерировала тонны очень крутых и ценных подходов: DDD, SOLID, паттерны проектирования, микросервисный подход, модульные монолиты, Event Storming. Я уверен, вы можете добавить что-то своё, то, что вам нравится.

И это всё правда работает (да даже микросервисы, если учитывать структуру коммуникаций вашей компании). Это всё правда работает, если при проектировании опираться на оба аргумента функции: то, что наш код одновременно является как продуктом, так и рабочим местом.

P.S. Если вы дочитали досюда, наверное, вам это было близко и интересно. Поделитесь этим постом с коллегами, ну и просто репостом. Буду вам благодарен. А на этом у меня всё, спасибо! Жду вас в комментариях." / X<br>Post

Log inSign up

Post

Sergey Andreev

@DragorWW

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

При этом при разработке мы не можем не учитывать второе, иначе будет как в том меме про user experience vs design.

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

Это значит, что при изменении этих вводных мы должны получать разные программные решения для одних и тех же задач.

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

Есть знаменитый закон Конвея, согласно которому структура создаваемой системы будет копировать структуру коммуникаций организации, которая её разработала. (Опять же смотрим на прекрасную картинку про UX/UI.)

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

На компанию часто бывает сложно посмотреть как на парк с...