Comments 22
Статью бы украсили примеры кода "было-стало"... ;)
Действительно вначале была идея с иллюстрацией кодом. Даже, вроде, получилось раскопать пару примеров, которые не требовали бы копания в git-истории. Но после вставки этих примеров в текст они выглядели скорее какой-то вкусовщиной, нежели иллюстрацией моих слов. А что бы они приобрели действительно иллюстрирующую функцию пришлось бы выгружать много контекста, что уже сильно размывало бы смысл самой статьи (IMO).
По поводу "было/стало" могу сказать что удалось уменьшить сложность (cyclomatic complexity) с ~18 (для старого) до ~3.5 (для нового). А добились этого при помощи следующих шагов:
- с пристрастием подошли к разделению зон ответственности нашего текущего MVC-паттерна
- для уровня M (model) применили луковую архитектуру (onion architecture)
- внедрили в разработку принципы DDD (в том или ином виде)
Ожидание-реальность
Статья хорошая, но что за "кодоэйджизм" в заголовке? 10 лет для года не возраст - даже в "новых" ЯП типа Rust/Go/Kotlin есть уже код такого возраста (и не факт, что плохой). А в крупных компаниях и проектах и код постарше вполне себе трудится. Что-то из этого, конечно, надо переписать/причесать/документировать, что-то на вид от вчера написанного и не отличить. Причина плохого кода совсем не в возрасте, что и ваша статья подтверждает.
Человекочитаемость и понятность кода — важная мысль. Пытаясь решить эту задачу, я разработал язык ДРАКОН. К языку были предъявлены нетрадиционные требования:
предложить средства для описания не только алгоритмов, но и структуры человеческой деятельности в любой отрасли знаний (включая бизнес-процессы);
предоставить пользователю языковые средства, которые заставляют человека мыслить продуктивно;
облегчить межотраслевое и междисциплинарное общение между представителями разных организаций;
устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей и профессий;
за счёт использования когнитивно-эргономического подхода к проектированию синтаксиса и семантики добиться улучшения качества программного обеспечения по критерию «понятность алгоритмов».
На Хабре см. посты:
Как улучшить блок-схемы алгоритмов по ГОСТ 19.701-90? Эргономичный визуальный алгоритмический язык ДРАКОН. Критерии.
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН.
Медицинский алгоритмический язык ДРАКОН против пандемии и не только. Статья для профессиональных врачей.
Лабиринты из линий: превращаем сложный сценарий в понятную схему на языке ДРАКОН.
Визуальный язык ДРАКОН: математические истоки алгоритмической макроконструкции «силуэт» и метод Ашкрофта-Манны.
Клинические алгоритмы при пандемии COVID-19 на медицинском языке ДРАКОН. Часть 1.
Вместе с тем, разделяю чувства Parondzhanov, т.к. это невероятно сложно чисто психологически держать в себе накопленные знания и опыт в том виде, в котором он здесь продвигает свое детище в массы.
Мне вчера на корпоративе было психологически сложно держать в себе отзыв на моего начальника. К чему это я? К тому, что когда меня спрашивают сегодня «почему ты начальника вчера матом обругал», ответ «ну мне было психологически сложно» никак не оправдывает меня и ситуацию не исправляет.
Но и в целом, никто не судит: человек принес ссылку, человек получил минус. Повторять до исчерпания терпения/кармы. Процесс самостоятельно регулируется. Я лишь ответил на вопрос «Почему минусы?»
Поддержу. ДРАКОН как раз позволяет визуализировать ТЗ и часто определить "Царскую дорогу", одновременно снижая цикломатическую сложность решения разработчика.
Спасибо за замечание. Про "эйджизм" согласен — убрал из заголовка путающее уточнение. Дополнительно во вступлении уточнил что именно имелось ввиду под этими более чем 10 годами жизни кода.
Я вот не пойму только одного, с каких пор сайт по типу "БЛОГ" стал технически сложным? Что тут сложного? Весь хабр можно сделать за неделю. У вас пафоса будто шаттл космический запускаете в космос...
Видимо, это верхушка айсберга, и так «для души», а на самом деле там рокет саенс. На самом деле было бы интересно реальные кейсы сложности увидеть
А вы верно подметили по поводу космического корабля. Правда для меня, космический корабль Хабра уже создан и запущен. Своей задачей вижу тут наладку процесса безболезненного обслуживания и модернизации этого корабля еще в течение хотя бы лет 20-30. =)
зачем этот очередной холивар ? достали любители каллиграфии, особенно в менежменте. Красивый код лучше работать не станет, если у писателя кода понятия нет ,с какими аппаратными ресурсами он имеет дело. Или опять абстракция вывезет?
Замечательная статья и очень интересная тема. Постоянно встречающаяся при разработке, да и наверняка и другом кодинге, особенно если коллектив давненько сработавшийся. Люди доверяют друг другу и не анализируют код, и даже если случаются баги, исправляет код тот кто его писал привычным ему способом.
Борьба за человекочитаемость кода: опыт Хабра