26 июля 2024 г. (изменено: 26 июля 2024 г.)
Канал: @cherkashindev
Если бы вас спросили, что самое сложное в вашей работе, чтобы вы ответили? Я думаю одна из самых сложных вещей - читать чужой код, или свой собственный, написанный пару лет назад.
👉 Сегодня статья о том, Как избежать когнитивной перегрузки: способы оптимизации кода для разработчиков.
Вот основные моменты из статьи, если вам лень читать всю статью в пятницу да ещё и летом 😅
-
Когнитивная нагрузка – это объем умственной работы, необходимый разработчику для выполнения задачи. Нашим приоритетом должно быть максимальное снижение такой нагрузки в проектах.
-
Типы когнитивной нагрузки:
- Внутренняя — изначальная сложность задачи, её нельзя уменьшить.
- Внешняя — создается способом представления информации. То есть то, как написан код, решающий задачу.
-
Знакомая и простая вещь — не одно и то же. Они ощущаются одинаково — та же легкость перемещения по пространству без особых умственных усилий, но по совершенно разным причинам. Каждый «умный» и нестандартный прием приведет к трате времени на обучение для остальных разработчиков. После того, как они его освоят, им будет легче работать с кодом. Именно поэтому не так легко понять, как можно упростить уже знакомый код.
-
Нет никакой «упрощающей силы», влияющей на базу кода, кроме вашего сознательного выбора. Упрощение требует усилий, а люди часто спешат.
-
Отладка в два раза сложнее написания кода. Следовательно, если вы пишете код максимально хитроумно, вы по определению недостаточно умны, чтобы его отладить.
-
Лучшие компоненты — это те, которые обеспечивают мощную функциональность при простом интерфейсе.
-
Лучше большой модуль с простым API, чем много маленьких модулей с раздутым API, которые связаны между собой.
-
Хорошо продуманный монолит с действительно изолированными модулями часто намного удобнее и гибче, чем набор микросервисов.
-
DRY (Don’t repeat yourself) — хотя в целом это хорошее и фундаментальное правило, его чрезмерное использование приводит к непосильной когнитивной нагрузке. У DRY есть альтернатива — AHA Programming
- Вы можете слишком рано извлечь общую функциональность, основываясь на предполагаемом сходстве, которого на самом деле в долгосрочной перспективе может не быть. Это может привести к ненужным абстракциям, которые будет непросто модифицировать или расширять.
- «Небольшое копирование лучше, чем небольшая зависимость».