"Ну и говнокод, я бы сделал по другому!"
Давайте на чистоту, такая мысль часто возникает при работе с чужим кодом.
Но уверен что когда кто-то это писал, он говорил "Это же очевидно"
Так же как и матерый профессор в универе забывает с какими трудностями сталкивается студент при обучении.
Тем самым подавая материал с позиции "Ну это же очевидно"
Так же и "нам очевидно" какую задачу мы ставим себе в to-do list в Январе.
И не очевидно, когда мы возвращаемся к этой задаче через N месяцев.
🔺Все эти примеры к тому что это часть одного и того же явления, описанное и исследованное еще в 1989 году.
Проклятие знания — когнитивное искажение в мышлении человека заключающееся в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей.
Нам сложно понять какие задачи мы занесли в to-do list, потому что мы менее информированы сейчас, чем в прошлом.
Нам сложно понять примеры профессора в универе будучи студентом. Или senior'a, будучи junior'ом.
Потому что объем знаний и опыта на их стороне. Они могут рассуждать, рассказывать о проблемах используя более высокий уровень абстракции и обширный словарный запас
Нам сложно понять код, который был написан другим программистом. Потому что у нас может не быть того уровня погруженности в проблему и знаний, которые использовались при написании этого кода.
При работе это может приводить к:
🔸Чрезмерному усложнению/графоманству при написании документации
🔸Бесполезными комментариям в коде и сложным названиям файлов/папок и классов HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
🔸Уровень абстракции может быть слишком высокий
🔸Реализация/архитектура может быть переусложнена
И что самое интересное, что откликается во мне и на что я не обращал внимание:
🔻 Любой эксперт в своей инженерной области склонен усложнять систему в поисках доказательств своих знаний.
Т.е. мы заведомо экспериментируем, делаем системы сложнее, описываем документацию наиболее подробно, чтобы подтвердить, закрепить свои знания.
Иногда мы делаем это чтобы убедить себя, что мы действительно это знаем и достойны позиции, которую мы занимаем.
Узнали?
Из этого вывод:
❌ Не будьте авгуром, не утилизируйте свою сноровку в соображения о своем профессионализме 🤣
✅ Используйте свои профессиональные навыки и насмотренность для упрощения, не усложнения
Пара простых рекомендаций к практике:
🔹Простота документации важнее ее исчерпанности
🔹Простота понимания кода важнее абстракций и "масштабируемости"
🔹Суть и понимание диалога важнее используемых терминов
Это все к чему, к тому что архитектурные/дизайн решения могут и должны учитывать не только выводы из инженерии и эмпирических наблюдений, но и из других областей как психология, экономика, философия, математика и пр.
Я стараюсь писать свои статьи максимально просто, используя и перерабатывая сложную базу.
Дайте обратную связь в комментах ❤️🔥:
— Прокляты ли мои статьи?
— Сложно ли это читать/воспринимать?
— Удается ли мне выдерживать баланс между сложностью и интересом? Насколько для вас это важно?
Ставьте 👍 если такой контент заходит
#проект_в_разработке@UniArchitect