Ð
самый лучший вид прокачки - довести проект до прода, а потом начать его поддерживать, сразу видно где хорошо, а где плохо.
Size: a a a
2019 November 11
FD
Ð
самый лучший вид прокачки - довести проект до прода, а потом начать его поддерживать, сразу видно где хорошо, а где плохо.
Хороший подход, а вот в плане правильности структуры проекта где можно смотреть best approach?
Ð
ты знаешь, а его не существует
C
А кто как прокачивает свои навыки?
Смотрю Гошу Дударя и Хауди Хо
Ð
нет никакой правильной структуры, правильная структура - та, которая максимально проста и понятна, она может быть разной в зависимости от специфики проекта
И
А кто как прокачивает свои навыки?
Овербафера смотрю
Топ калтент
Топ калтент
G
Хороший подход, а вот в плане правильности структуры проекта где можно смотреть best approach?
Так если был бы какой то универсальный ключик, то зачем нужны были бы архитекты эти?
EB
Овербафера смотрю
Топ калтент
Топ калтент
про то как не поймать вилусы?
C
Овербафера смотрю
Топ калтент
Топ калтент
Плюс, вчера взломал дневник ру и убрал двойку по физре за то что не сдал конспект
EB
еще дополню тезис о правильной архитектуре, вернее ее отсутствии тем, что если бы такая была - не было бы такой штуки как рефакторинг из-за ненадобности
И
Пацаны шарят
Завтра на перемене после матеши обсудим
Завтра на перемене после матеши обсудим
SS
Хороший подход, а вот в плане правильности структуры проекта где можно смотреть best approach?
пока что более менее нормальная структура которая понятна новичку в typescript-node-starter
Ð
должна быть чуйка, что код получается сложнее, чем должен быть для этой задачи, эдакое чутье оккама, но оно появялется только с опытом
Ð
вообще правильную архитектуру можно в двух словах изложить так: в ней не должно быть дублирования логики и лишних сущностей
EB
типа пишешь код, получается хуйня, думаешь "что же пошло не так", ищешь решения (сам или с чьей-то помощью), внедряешь. Если получилось - качнулся, повторить. Если не получилось - не качнулся, повторить. И так без конца.
Ð
если вовремя заметить, что получается слишком сложно - то в перспективе сэкономишь больше времени
Ð
поэтому и появляюстя "версии 2.0"
Ð
если полномасштабный рефакторинг никогда не делать, получится очередной битрикс, который застрянет во времени лет на 20
PK
Ð
вообще правильную архитектуру можно в двух словах изложить так: в ней не должно быть дублирования логики и лишних сущностей
а как же возможность безболезненной адаптации к новым бизнес-требованиям?
Ð
когда архитектура проста, адаптация гораздо более безболезненна