Комментарии 19
Вы меня простите, но зачем в каждый заголовок добавлять визуальный мусор из символа «▍»?
Статья ломается об колено, как и все другие с подобными советами, одним простым фактом - не бывает приложений которые закладываются на какой-то абстрактно-гипотетический уровень сложности, вообще никто и никогда не может гарантировать что проект не разрастется. Есть огромный пласт боли, в прошлом "средне размерных" приложений, когда проектировалось на тяп ляп и не переусложненно, потому что вот вот сдадим и забудем а на деле проект разрастается превращаясь в неподдерживаемый ад.
И каждый раз одно и тоже и каждый раз хочется вспомнить фразу - "Никак бы бл..ь не научитесь"(с).
Есть большая разница между проектом для большой корпорации и стартапом. В первом случае - да, можно потратить миллионы человеко-часов и сделать так, чтобы вам ни в коем случае на ум эта фраза не пришла.
Что касается стартапов, то их выживает на промежутке в 10 лет, по одним оценкам, не более 10%, по другим - не более 5%. И в данном случае плевать на качество кода, главное экономическую модель найти. С вероятностью 95% этот код никому нужен не будет в скором времени.
Подумайте над такой вещью: если вы регулярно встречаете проекты, где разработчики никак, блядь, не научатся, и эти проекты живы и разрастаются - можно ли предположить, что эти разработчики и их менеджмент, напротив, что-то такое умеют, что приводит их в эту точку развития?
Кстати, а много вы встречали проектов с хорошей по вашим критериям архитектурой, которые разрастались и гладко масштабировались без существенных изменений? Это были стартапы или кровавый энтерпрайз?
помогут ли они избежать чрезмерного усложнения или же создадут больше проблем, чем решат.
— Да
— Да
— Да
— И да, и нет
...
Далеко не сразу становится понятно, что означают эти "Да" - помогут или усложнят?
Чрезмерное техническое усложнение является корнем всех зол.
Ой да ладно. Корень всех зол - это непонимание (причем в самом-самом корне - непонимание себя, своих потребностей, задач, проблем и глупости). Ложная картина мира, отрыв от реалий. Отсюда любая деятельность будет мимо кассы. Например, если 2+3=7 то снег зеленый, и такое будет казаться пресвятейшей истиной. Вместо этого бреда можно подставить любые обоснования любых идиотских решений на проекте.
Вот корень всех зол:
КТО ТАМ?
Это я, добрый Ээх. Я здесь.
И я здесь!
А ты кто такой? Откуда взялся?
С того берега моря.
На чем приехал?
Оседлал хромую блоху, сел и приехал.
Море, что, лужа?
Может и лужа, да только ту лужу орел не перелетел.
Значит, орел - птенец!
Наверно, птенец. Да только тень от его крыльев город закрывает, в городе ночь настает.
Город-то, небось, крооохотный!
Через тот город заяц бежал - не перебежал.
Выходит, заяц маааленький!
Заяц – как заяц. Из его шкуры тулуп вышел.
Куда вышел?
Вышел из того города, где заяц бежал, на который тень от орла упала, и пошел, куда глаза глядят.
Чьи глаза???
Глаза того тулупа, который из шкуры зайца вышел, в городе, где ночь настает, когда над ним птенец пролетает верхом на хромой блохе.
ЧЕГО?!!!!
Чего-чего. На хромой блохе с того берега моря, которое зайцу не перелететь, орлу не перебежать, хоть море - не море, а так - лужа посреди города, где тень от блохи на зайца упала и насмерть убила, а из шкуры зайца тулуп вышел и пошел, куда глаза глядят. Тут заяц кааак прыгнет!
КАКОЙ ЗАЯЦ???
Насмерть убитый – как прыгнет, куда глаза глядят, аж на тот берег моря, которое ни перелететь, ни перебежать, из которого тулуп вышел, на который тень от блохи упала и зайца убила, хоть заяц – не заяц, а орел!
КАКОЙ ЗАЯЦ??? КАКОЙ ОРЕЛ??? КАКАЯ БЛОХА??
Повторить? Ну, значит, та самая блоха с того берега лужи…
АААААААААААААААААААА!!!!!!!!!! ДА ХВАААТИТ!!!!!!!!!
Всё правильно, не надо проектировать, надо сразу писать код. Мы все умеем видеть будущее и совершенно точно знаем, что вот этот небольшой проект никогда не станет большим. Да что уж говорить, это когда MVP запускали в продакшен как полноценное решение? Просто смешно. Просто пишите код. Не думайте. Понапридумывали всяких паттернов, архитектур, с единственной целью раздуть масштабы разработки, и не получить никакого результата :)
проектирование это важный шаг.
Понапишут дилетанты так, а потом специалист переписывает) двойная работа.
А когда станет понятно, что дальше этот труп пинать не получится, просто перепишите все с нуля, на сей раз проектируя нормально, закладывая в архитектуру гибкость, учтя все свои ошибки, проведя тонну ресерчей, потом мигрируйте туда всю пользовательскую базу, и потратьте в 2 раза больше времени, чем на предыдущую разработку, лишь за тем, чтобы дойти до ее уровня функциональности,и лишь потом, спустя все это время, продолжить развитие проекта. Зато как быстро выкатились в релиз-то на старте!
P. S. Все вышесказаное - из личного опыта.
Идеального кода не бывает
проектирование важно, как минимум на уровне, при котором изменения архитектуры не требуют переписать все с нуля )
но с другой стороны, попытка написать код под все возможные варианты его будущего, приводит к мертворожденному долгострою который все никак не поспеет за реальностью.
Самое главное помнить, что важнее SEO и рекламы нет ничего и думать нужно не о всяком бреде, вроде SPA на TypeScript-e, а о том как продвигать этот продукт. И возможно тут намного лучше пойдёт серверный рендеринг страниц, потому что SPA индексируется поисковиками ХУЖЕ и думать нужно не над Redux-ом, а про PHP или NodeJs MVC.
Система проектирования
На русском это все-таки будет "дизайн-системой"
Не усложняйте свои приложения