Антипаттерн №4 — Метод копипаста (Copy and paste programming)
Антипаттерн — понятие эволюционное. Точно также формировались правила дорожного движения — от происшествий на дороге, шаг за шагом, методом проб и ошибок зарождалась культура вождения. С антипаттернами история похожая — за более, чем 50 летнюю историю программирования мир разработки кое чего повидал. Всякого, знаете 🙂 Менялись технологии, подходы, методики. Кардинально изменялось всё — и по несколько раз. То, что сегодня считается дикой и жуткой ошибкой, когда-то давно могло быть единственным способом реализации задачи. Но есть один подход, который был всегда и будет, скорее всего, также всегда. Его суть проста и банальна, поэтому данная запись не будет большой.
Copy and paste programming (или C&P) — антипатерн и негативный опыт, в котором программист, как правило, бездумно копирует чужой код (или свой же, но из другого проекта) при помощи операции copy и вставки paste. Метод копипасты особенно остро встал в последние годы, когда интернет крепко вошёл в массы и появились целые сообщества разработчиков, сервисы онлайн документации и открытые хранилища исходного кода: будь-то stackoverflow, msdn или тот же github. Не стоит также забывать о выдранных под копирку примеров кода из книг, которые, как правило, носят сугубо демонстрационный и обучающий характер — не более.
В целом, суть практики C&P проста — часто, когда мы решаем какую-либо задачу, выходящую за привычную и удобную для нас границу — мы ищем информацию. Итого, найдя ответ мы можем получить два сценария дальнейшего поведения: либо мы разбираемся в теме и пишем код самостоятельно, либо берём чьё-либо готовое и потенциально рабочее решение. Второй вариант не является чем-то плохим или постыдным, но когда нет понимания этого переиспользования, когда происходит бездумный ctrl+c и ctrl+v — это и есть первым звоночком нашего анамнеза. Это и будет плохой практикой.
Чем плох чужой (неотрефакторенный под нас, скопированный) код? Во-первых, тем, что может содержать неявные сайд-эффекты. Особенно это касается каких-либо математических вычислений или сложных алгоритмов, которые мы до конца не понимаем — это всё и может начать работать в вашем случае, но при каких-либо других обстоятельствах может привести к беде. Без понимания «в глубину» — вы не сможете проверить несколько кейсов. Во-вторых, такое кодирование может выходить за рамки внутреннего порядка: не только стилистически, но и на более фундаментальном, архитектурном слое. Такой код труднее вычитывать и поддерживать. Это всегда диверсия.
Существует неплохая лакмусовая бумажка, помогающая понять проблематику такого подхода. Скажем, вы согласитесь использовать обфусцированный код? Скорее всего нет. Вас может напугать тяжеловесность и неизвестность того, что вы ставите в свой продукт. Также и с чужим кодом, который вы взяли без полного понимания его работы. Особой разницы нет. Вообще нет.
Кроме того, конечно, необходимо помнить, что полное 100% копирование чужого кода — это частный случай плагиата. Когда программист не понимает до конца (или полностью) то, что он делает и предпочитает взять чужое якобы рабочее — это не только минус к усидчивости и интеллектуальному бесстрашию, но и вредительство для команды, проекта в целом и иногда всей компании.
Не стоит путать дублирование кода внутри проекта с копированием чужого из внешних источников. Это два разных, хоть и немного похожих антипаттерна. Про непосредственное дублирование мы обязательно поговорим, но уже в следующий раз.