Не откладывайте на завтра то, что можно сделать сегодня. Именно эта мысль для меня стала одной из ключевых в разработке приложений. «Почему?» — спросите вы.

Все очень просто. Говорите себе: «Это я потом поправлю, а это я потом перепишу. А вот это пока подождет. А файловую систему я потом продумаю»? Так вот это «потом» может так и не наступить. А ваш проект превратится в мусор. А даже если вы и вспомните о том, что пора что-то куда-то переносить, вместо двух файлов у вас будет 100 или больше. И вы уже не будете помнить, что за что отвечает и где лежит. В итоге вместо одного часа вы потратите день или больше на рефакторинг, которого можно и нужно было избежать.

В общем, ключевое — это не бежать сразу писать код, а сначала все продумать. Структуру, архитектуру, всякие эти фишечки и прочее. Хотя бы в общих чертах. Иначе ваш проект очень скоро будет приносить вам боль, а время вы потратите совсем не на то, что вам бы хотелось.

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

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

Рефакторинг — сам по себе штука дорогая. Порой в командах и при разработке время всегда поджимает. Поэтому даже неделя-две на рефакторинг — это очень круто. А месяц — это просто мечта! Именно поэтому нужно и важно сразу правильно построить базовое дерево развития проекта.

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

Бывает, я смотрю на свой код, который писал год, два, три назад и думаю: ох, это правда я писал? Ну так же нельзя! Это все путь, эволюция.

Просто оставляйте себе время на рефлексию, анализ и наблюдение. Или даже созерцание. Оно сможет порой привести вас к правильному пути.

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

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

И будет крутиться. Просто можно сделать все несколько мягче и лучше.

Не всегда стоит нести какие-то тяжеловесные штуки в проект, если он прост, как две копейки. Вот пусть и остается простым. Но верно и обратное: не всегда можно обойтись простыми реализациями, без ts, классов или внешних сервисов.

В целом хотелось бы подытожить:

1. Прежде чем начать писать код вашего приложения, разберитесь: а что вообще вам нужно и что вы хотите сделать? Какие вам нужны будут инструменты для этого? Какие задачи ваше приложение будет решать? Что туда потенциально добавится? Но не считайте на 100 шагов вперед. Посмотрите на 1-2.

2. Если стек определен, то определите и инструменты, библиотеки и архитектуру.

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

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

А про легаси и свой опыт работы с ним я расскажу вам в следующей своей публикации.