Где найти время для своих проектов?

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

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

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

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

В-третьих, рассчитайте архитектуру кода или её отсутствие так, чтобы можно было вернуться к нему даже на пенсии и быстро восстановить в памяти, что к чему. Не призываю писать легаси, но мне попадались интересные статьи с правилами написания оного и может быть пара правил оттуда пригодится. Можно написать сложнейший проект вообще без использования объектно-ориентированного программирования, и он будет работать. Некоторые известные языки программирования успешно обходятся без OOП. Основные преимущества ООП - максимальная гибкость и удобство при командной разработке. Нужно ли это в конкретном случае? Глобально переделывать для хобби-проекта ресурсов обычно нет, команды тоже нет и не появится. Отнимает же скорость, а вот это пригодится, тем более за мощности сервера вы будете платить из своего кармана. При этом вы обнаружите, что сможете в одиночку осилить такой большой проект, внося код согласно тому, как идёт ход мысли, но, если вы будете проектировать всё-всё заранее, особенность психологии такова, что он покажется недостижимым и вы его либо бросите сразу-же, либо будете искать напарника, чтобы писать интерпрайз код с предположительно таким же концом. Здесь работают другие правила. Если же это open source, соболезную, за минимальным общепринятым качеством кода нужно следить. Но, могу успокоить, большинство библиотек в open source используются без заглядывания в исходники и оценки кода. Главное - количество звёзд или лайков у него. Ну, так собственно, и с вашим будет. Если кому-то позарез нужно решить проблему, а ваш код её решает, то смотреть качество кода будут в последнюю очередь, и то в случае непредвиденных ошибок или отсутствия подробной инструкции. Достаточно позаботиться о последних двух нюансах.

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

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

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

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

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

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