Злой программный код - это как раз история про нестабильность. Это ситуации, когда программист берёт на себя работу, которую он по каким-либо причинам не в состоянии сделать. Это проекты, в которых нет качественного менеджмента или опытного руководства, которые придают продукту форму, и обозначают ясные рамки. Это такие ситуации, в которых разработчик предпочитает "имитировать" решение задачи, чем на самом деле решать задачу.
Злой программный код - это как раз история про нестабильность. Это ситуации, когда программист берёт на себя работу, которую он по каким-либо причинам не в состоянии сделать. Это проекты, в которых нет качественного менеджмента или опытного руководства, которые придают продукту форму, и обозначают ясные рамки. Это такие ситуации, в которых разработчик предпочитает "имитировать" решения задачи, чем на самом деле решать задачу.
Безумный код часто приходит в качестве ответа на отсутствие смирения со стороны разработчика. Безумный код - это иллюзия решения проблемы, возникающая как слабая надежда справиться с заведомо сложной ситуацией. Это неумение признавать собственные ошибки, либо же нездоровая переоценка собственных сил. Безумный код (равно как и безумные подходы в программировании) - это как если ребёнок прячет разбитую вазу под коврик, вместо признания своей вины и обращение к родителям.
Работа напрямую с prod-сервером 🔌
Наиболее лютая практика, для самых отчаянных и самоуверенных - это работа с программным кодом вживую, то есть напрямую с рабочим сервером / облаком / экземпляром приложения. Сюда же относится отладка программного продукта "на лету". Встречал ли я таких людей? Да, встречал. Пришли ли они к успеху? Как правило - нет. Но определённо, эти люди имели большое желание рисковать.
Здоровая практика создания программных продуктов - это изначальное программирование на машине "разработчика", потом запуск продукта в тестовой среде, и только потом доставка рабочей версии на публичный сервер / маркетплейс. Желательно не нарушать этот принцип, и всегда отделять стабильную версию своего приложения от его тестовых сборок.
Даже если в некотором моменте требуется экстренное вмешательство в текущую версию программного продукта, крайне желательно сделать исправления сначала в тестовой среде, а уже потом тащить их на prod.
Отсутствие резервных копий 📦
Как гласит известная шутка, люди делятся на тех кто делает бэкапы, и тех кто уже делает бэкапы. Если что, бэкап - это резервная копия программного кода или некоторых данных. В хороших практиках программирования и системного администрирования, делать бэкапы рекомендуется ежесуточно, а для некоторых узлов - и того чаще. Стоит ли говорить о том, что далеко не все так поступают.
Программирование устроено столь удивительным образом, что иногда происходит повреждение исходного кода или где-либо хранимой информации. Это может быть как аппаратный сбой, так и банальная ошибка программиста. Исходя из чьей-то там статистики, которую я когда-то и где-то вычитал, в среднем программист сталкивается с необходимостью восстановления бэкапа примерно раз в год. Цифра пугает и впечатляет одновременно, но как минимум заставляет задуматься о целесообразности сего мероприятия.
Одна их худших практик программирования - отсутствие бэкапов как таковых. Даже если ты на 100% уверен в сохранности данных или кода, даже если твой ноутбук или PC работает просто идеально - нельзя гарантировать сохранность информации, если она представлена одним-единственным носителем. В общем, делай бэкапы - и все будет хорошо.
Личный рекорд потери данных - 3 месяца в одном проекте. С тех пор, я отношусь к лагерю тех, кто "уже делает бэкапы".
Мания величия и вера во всесилие 😇
Каким бы хорошим ни был программист, и вне зависимости от того в скольких крупных проектах он участвовал - всегда найдется место для ошибки и неточности. Даже самые лучше специалисты допускают косяки в своей работе. Даже от взора самых опытных архитекторов ускользают некоторые важные нюансы. Очень хорошо, когда практикующий программист это понимает.
Над крупными программными продуктами, обычно, работают в команде. Хорошая практика здесь заключается в том, чтобы созданный код проходил аудит у старших специалистов и коллег. И обратная сторона в такой ситуации - когда написанный код видит только его автор, и он же запускает его в жизнь, минуя взоры сторонних критиков или тестировщиков. Спустя многие иттерации такого подхода, программист все больше и больше верит в безграничность своих сил, затуманивая свой разум иллюзией. Надо ли говорить, что качество неаудированного кода со временем падает.
Даже если ты очень хорош, уже реализован и известен на широком рынке - найди того, кто может периодически посматривать в продукты твоего творчества. Не пренебрегай внешними взглядами. Не замыкайся в ловушке собственного субъективизма.
Отсутствие архитектуры 🏡
Как романтично и прекрасно - строить дом наугад, и по наитию. Приходит ли кому-то идея складывать кирпичи друг на друга, без какого-то конкретного видения результата? Начинают ли плотники делать корабль, не зная что они хотят получить в конечном итоге? Стал бы ты лично делать ремонт в квартире "наудачу"? Или строить дом из подручных материалов, найденных в ходе прогулки по улице? Вероятно - нет.
К сожалению, в мире программирования, многие поступают именно так. Видя в голове некоторый абстрактный образ или призрачную мечту, программист садится штурмовать очередную гениальную идею, чтобы получить на выходе "что-то". И нет, я не говорю о том что эксперименты это плохо. В большей степени я обращаю внимание на то, что для любого нормального проекта нужен план. Нужно видение, что именно мы хотим получить на выходе. Нужно хотя-бы ориентировочное понимание того, какие материалы потребуются для решения некоторой задачи, для создания некоторого продукта.
Классика создания проектов - это графические скетчи (наброски) и архитектура в любом возможном виде. Это может быть простой лист формата А4, либо же условная Figma или другой удобный тебе инструмент. Начиная новое дело, тебе нужен план, что именно ты хочешь получить на выходе. И далее - нужно упорно следовать этому плану, хотя бы в общих чертах. План оказался не рабочим? Выкидывай, переделывай, рисуй новый, и снова следуй ему. Но не иди в проект с закрытыми глазами, всецело полагаясь на удачу.
Отказ от контроля версий / VCS 🔢
Системы контроля версий - это прекрасный инструмент для создания проектов. Они позволяют работать в команде, последовательно создавая и затем объединяя фрагменты кода в единый программный продукт. VCS созданы для того, чтобы множество специалистов могло одновременно писать, соединять и аудировать производимый программный код. Эти же самые системы позволяют поддерживать ветки параллельной разработки, откатывать неудачные версии и делать множество других полезных вещей. Базовый вариант VCS - это git. Ну и классические примеры крупных проектов на эту тему - это gitHub и BitBucket.
Даже работая в гордом одиночестве, использование VCS и хранение исходников в облаке - это хорошая практика. Обратный же подход часто приводит к проблемам.
Отсутствие последовательности в разработке программного обеспечения снижает дисциплину программиста. И вместо иттерационного подхода к делу, возникает что-то вроде непрерывного потока производства, без каких-либо ориентиров и без привязки ко временным меткам. Стоит ли говорить о том, что при таком режиме работы качество результатов сильно падает.
Использование глухих библиотек ⬛️
Закрытые вглухую, непонятно кем и когда сделанные, каким-то чудом работающие библиотеки - равно как и обфусцированный программный код неизвестного качества - ммм, романтика! Одна из самых ужасных практик, это использовать программные модули совершенно непредсказуемого содержимого, при отсутствии каких-либо альтернатив. Даже если сегодня нет выбора или иных вариантов - знай, что когда-нибудь наступит тот самый час Х, и вся это история полетит неизвестно в каком направлении.
Выбирая между несколькими компонентами, я всегда стараюсь выбирать более предсказуемые, более открытые, более известные решения. Желательно, если у такого решения есть публичное сообщество разработчиков. Очень желательно, чтобы решение было создано 3-5 лет назад, а не позавчера.
Безумный код - это не выбор сильных программистов. Это только попытка создать быстрый костыль, решить проблему через хитрость, отказ смотреть правде в глаза. Старайся не допускать использования безумного кода, и быть честным - с собой и окружающими.
🔥 Понравилось? Подпишись! Победим восстание роботов вместе! 🔥
🚀 P.S. Для тех, кто хочет не просто читать о программировании, а начать свой путь джедая прямо сейчас, приглашаю на Boosty! Там эксклюзивный обучающий материал по программированию для любого уровня подготовки. А ещё там можно посмотреть, как автор выглядит в жизни. Жми сюда и полетели!🚀
P.S.2 Ещё у меня есть Telegram-канал. Там посты чуть проще и веселее. Ссылка
P.S.3 Предлагаю делиться в комментариях личным взглядом на самые безумные подходы к программированию. Случаи из жизни и поучительные истории из IT приветствуются!