Безумная сторона программирования. Признаки ужасного кода. Злой / Часть 3.

Злой программный код - это история о нестабильности. Это моменты, когда разработчик берет на себя задачу, которую по каким-то причинам не может выполнить. Это проекты, где отсутствует качественное управление или опытное руководство, которые придают продукту структуру и устанавливают четкие рамки. Это ситуации, когда программист предпочитает "подделывать" решение проблемы, вместо того чтобы действительно ее решать.

Злой код - это история о нестабильности. Это моменты, когда разработчик берет на себя задачу, которую он по каким-то причинам не может выполнить. Это проекты без должного управления или опытного руководства, которые придают продукту структуру и устанавливают четкие рамки. Это ситуации, когда программист предпочитает "подделывать" решения задачи, вместо того чтобы на самом деле решать ее.

Часто безумный код возникает из-за недостатка смирения у разработчика. Это своего рода иллюзия, пытающаяся решить сложную проблему без должного понимания. Это отказ признавать собственные ошибки и переоценка своих способностей. Безумный код и подходы в программировании можно сравнить с ситуацией, когда ребенок скрывает разбитую вазу под ковриком, вместо того чтобы признаться в своей вине и обратиться за помощью к родителям.

Работа напрямую с prod-сервером 🔌

Самым смелым и уверенным в себе считается работа с программным кодом в реальном времени, то есть напрямую с рабочим сервером / облаком / экземпляром приложения. Это также включает в себя отладку программного продукта "на лету". Я встречал таких людей? Да, встречал. Достигли ли они успеха? Обычно - нет. Однако эти люди безусловно имели сильное желание рисковать.

Эффективный подход к разработке программных продуктов заключается в том, чтобы сначала писать код на локальной машине разработчика, затем тестировать продукт в специальной среде и только после этого размещать рабочую версию на общедоступном сервере или маркетплейсе. Важно соблюдать этот порядок и всегда отделять стабильную версию приложения от тестовых сборок.

В случае необходимости срочного внесения изменений в текущую версию программного продукта, настоятельно рекомендуется сначала провести исправления в тестовой среде, а затем перенести их на рабочий сервер.

Отсутствие резервных копий 📦

Согласно популярной шутке, люди делятся на тех, кто делает резервные копии, и тех, кто уже пожалел о том, что не сделал их. Резервная копия - это копия программного кода или данных, которая может спасти в случае утери оригинала. В хороших практиках программирования и администрирования систем, рекомендуется делать резервные копии ежедневно, а для некоторых узлов - даже чаще. Однако, не все следуют этому правилу.

Программирование устроено таким образом, что иногда возникают ситуации, когда исходный код или хранимая информация могут быть повреждены. Это может быть вызвано как аппаратным сбоем, так и ошибкой программиста. По данным какой-то статистики, которую я где-то прочитал, в среднем программисты сталкиваются с необходимостью восстановления бэкапа примерно раз в год. Эта цифра одновременно пугает и впечатляет, но, по крайней мере, заставляет задуматься о важности такого мероприятия.

Одной из наихудших практик в программировании является отсутствие резервного копирования. Несмотря на то, что вы можете быть абсолютно уверены в сохранности ваших данных или кода, нельзя быть на 100% уверенным в сохранности информации, если она хранится только на одном носителе. Поэтому необходимо делать резервные копии - это гарантирует безопасность ваших данных.

Мой личный опыт потери данных составляет 3 месяца работы над одним проектом. С тех пор я присоединился к числу тех, кто теперь регулярно делает резервные копии.

Мания величия и вера во всесилие 😇

Независимо от уровня мастерства программиста и его опыта работы в различных проектах, всегда существует вероятность допущения ошибок и неточностей. Даже самые опытные специалисты могут допустить недочеты в своей деятельности. Даже самые опытные архитекторы могут упустить некоторые важные детали. Важно, чтобы практикующий программист осознавал этот факт.

Работа над крупными программными продуктами обычно ведется в команде. Важно, чтобы код, написанный программистом, проходил проверку со стороны опытных специалистов и коллег. Однако, если автор кода не дает возможности другим специалистам оценить его работу, это может привести к иллюзии собственной непогрешимости. Постепенно качество кода, который не прошел аудит, начинает ухудшаться.

Даже если ты уже достиг высоких результатов и пользуешься популярностью на рынке, всегда найдется человек, способный дать новый взгляд на твои продукты. Не игнорируй мнения других. Не ограничивай себя собственными представлениями.

Отсутствие архитектуры 🏡

Как же романтично и вдохновляюще строить дом по вдохновению, без четкого плана. Приходит ли кому-то в голову идея складывать кирпичи один на другой, не имея представления о конечном результате? Начинают ли плотники строить корабль, не зная, что они хотят получить в итоге? Ты бы решился на ремонт в квартире "наугад"? Или построил бы дом из того, что нашел во время прогулки по улице? Вряд ли.

К сожалению, в сфере программирования многие люди действуют именно так. Увидев в своем воображении абстрактный образ или мечту, разработчик принимается за реализацию новой гениальной идеи, не имея четкого плана. Это может привести к получению на выходе "чего-то", что не соответствует ожиданиям. Необходимо понимать, что эксперименты важны, но для успешного проекта необходимо иметь четкий план. Важно иметь видение того, что мы хотим достичь в итоге. Также необходимо иметь представление о том, какие ресурсы потребуются для решения задачи и создания продукта.

Создание проектов часто начинается с графических скетчей и архитектуры в различных форматах. Это может быть обычный лист бумаги или специальные программы, такие как Figma. При старте нового дела важно иметь четкий план и представление о том, что ты хочешь достичь. Важно придерживаться этого плана, даже если приходится его корректировать. Если план не работает, не стоит отчаиваться - просто пересматривай, перерабатывай и создавай новые планы. Главное - не принимать решения наугад и не полагаться только на удачу.

Отказ от контроля версий / VCS 🔢

Использование систем контроля версий - это отличный способ управления проектами. Они обеспечивают возможность коллективной работы, поэтапного создания и объединения кодовых фрагментов в цельный программный продукт. VCS предназначены для того, чтобы несколько специалистов могли одновременно писать, объединять и проверять созданный программный код. Эти системы также позволяют поддерживать параллельное развитие веток, откатывать неудачные версии и выполнять множество других полезных функций. Одним из основных вариантов VCS является git. Известными примерами крупных проектов в этой области являются gitHub и BitBucket.

Практика использования VCS и хранения исходников в облаке является важной, даже если вы работаете в одиночестве. Наоборот, отказ от этого подхода часто приводит к неприятностям.

Отсутствие системности в процессе разработки программного обеспечения приводит к утрате дисциплины у программиста. Вместо последовательного подхода к работе возникает беспорядочный процесс, не имеющий четких этапов и временных рамок. Очевидно, что в таких условиях качество выпускаемых продуктов значительно страдает.

Использование глухих библиотек ⬛️

Таинственные, запечатанные, неизвестно кем и когда созданные, но все еще функционирующие библиотеки - так же как и зашифрованный программный код неопределенного качества - это настоящая загадка! Одна из наихудших практик - использовать программные модули с неопределенным содержанием, когда нет других вариантов. Даже если сейчас нет выбора - помни, что настанет момент истины, и вся эта история примет неожиданный оборот.

При выборе между различными компонентами, я всегда предпочитаю отдавать предпочтение более надежным, проверенным и популярным решениям. Особенно ценю наличие активного сообщества разработчиков вокруг выбранного компонента. Критерием также является возраст решения - предпочтение отдаю тем, которые были созданы несколько лет назад, а не вчера.

Использование безумного кода не является признаком высокой квалификации программиста. Это скорее попытка найти быстрое решение проблемы путем хитрости, избегая прямолинейного подхода. Важно не прибегать к безумному коду и быть честным как перед собой, так и перед другими.

🔥 Нравится? Подпишись! Вместе мы одержим победу над восстанием роботов! 🔥

🚀 P.S. Если вы хотите не только читать о программировании, но и начать свой путь джедая прямо сейчас, то приглашаю вас на Boosty! Там вы найдете эксклюзивный обучающий материал по программированию для любого уровня подготовки. Кроме того, вы сможете увидеть, как выглядит автор в реальной жизни. Нажмите здесь и отправляйтесь в путь!🚀

У меня также есть Telegram-канал, где публикуются более простые и веселые посты. Посетите ссылку, чтобы присоединиться!

P.S.3 Приглашаю делиться в комментариях своими личными впечатлениями о самых экстравагантных методах программирования. Рассказы из реальной жизни и уроки из мира IT будут весьма кстати!