С подачи @niktimf (Никита, спасибо) прочитал
https://habr.com/ru/articles/919168/
https://habr.com/ru/articles/919368/
Мне понравилось - сам расставил все лайки на Хабре и подписался на канал автора и вам рекомендую как минимум ознакомиться:)
В целом с контентом постов согласен и их чтение навело меня на кучу мыслей, но опубликую размышления только по одной из веток.
В первом посте есть тезис:
Ну и завершим духоту следующим замечанием: [из результатов исследования] видно, что IT-Performance организации хоть и имеет связь с успехами организации, но явно слабую. С одной стороны, это весьма логично: было очень бы странно, если бы можно было облажаться с идеей, бизнес-планом, маркетингом, продажами, менеджментом, но иметь успешный бизнес чисто за счет крутых технарей. С другой стороны, это замечательно объясняет тот факт, что большинство компаний делает с точки зрения техники откровенный шлак и при этом имеют вполне себе прибыльные бизнесы.
В посте автор, судя по всему, говорит об архитектуре больших-огромных (500К+ строк?, десятки разработчиков) систем, а я могу это подтвердить для небольших-средних приложений (10-500к строк, 1-5 разработчиков).
При том мой опыт в этом смысле вообще ужасающий - в моей практике 5 из 5 систем, генерирующих прибыль, были "с точки зрения техники откровенным шлаком".
А все мои "жемчужины" в лучшем случае автоматизировали какой-то бизнес-процесс, эффект от автоматизации которого никто не считал (либо мне не рассказывал), либо годами прожирали инвестиции, либо тихо умирали в забвении. Пока что, по крайней мере.
В этой связи я не раз слышал тезис в духе "мы быстро делаем говнокод, поэтому быстро двигаемся, поэтому у нас бизнес успешен". Но, судя по посту, это не так - бизнес успешен, потому что у него бизнес-идея хорошая и продакт маркетологи/продажники толковые. И это дало системе время, пространство и деньги на то, чтобы вырасти и превратиться в "шлак".
И это противоречит тому, что и я сам пытался приземлить ЭП на деньги и ценность для бизнеса, и не раз встречал других разработчиков, которые оценивали/критиковали идеи/подходы вопросом "А что это даст бизнесу". И ответ, видимо - ничего. Как и все альтернативные технически упражнения.
И получается, что код надо писать так, чтобы вам было комфортно работать.
Тут можно сказать, что тогда придут ваши последователи и будут вас материть. Но, во-первых, вам ли не пофиг - вы об этом даже не узнаете. А, во-вторых, они будут вас материть, вне зависимости от того как вы проектируете и пишете код:
Когда вы в последний раз приходили на проект и думали: какая удачная получилась архитектура, кто тот гений с зарплатой вдвое больше, чем у меня, что придумал этот алмаз? Я вот такого не припомню
— цитата из того же поста
Я тоже такого не припомню. Я даже когда к собственным проектам возвращаюсь спустя какое-то время, не думаю что это прям "алмаз":)
И получается, что код надо писать так, чтобы вам было комфортно с ним работать в течении того, времени, на которое вы собираетесь задержаться на проекте. Если вам комфортно говнокодить и вы меняете проект раз в год - говнокодьте на здоровье. Если говнокодить не комфортно - выкладывайтесь на полную. Даже если уже ищите новую работу.
И ещё интересное соображение: если то, как вы пишите код не влияет ни на бизнес, ни на мнение о вас ваших последователей - то можно смело экспериментировать с подходами к разработке в поисках тех, что нравятся вам. Например, можно попробовать идеи ЭП:)
Эргономичный подход не является волшебной таблеткой, перед применением необходимо проконсультироваться с техлидом :)
#posts@ergonomic_code #philosophy@ergonomic_code
