Я вижу некоторые серьезные проблемы с этим вопросом. Давайте начнем.
Как перестать тратить время на разработку архитектуры
Этот вопрос довольно загружен. Кроме того, вы не проектируете архитектуру. Вы архитектор . Архитектура и дизайн являются взаимодополняющими и связанными с ними видами деятельности, но не совпадают, даже если они могут перекрываться.
Точно так же, таким же образом можно тратить время на архитектуру (чрезмерное построение архитектуры), вы также можете тратить время на чрезмерное проектирование и избыточное кодирование (кодирование чего-либо гораздо более сложным, чем необходимо, или невозможность код для вещей, которые требуются.)
Надлежащая архитектура направлена на предотвращение этой потери в кодировании. Это достигается путем ограничения, сужения и документирования возможных способов, которыми сложная система должна быть: 1) спроектирована, 2) закодирована и протестирована, 3) доставлена, 4) поддержана, 5) восстановлена после сбоя и 6) в конечном итоге выведена из эксплуатации.
Мой опыт показывает, что люди, которым просто нравится программировать, просто пишут код, не задумываясь о том, как система должна работать и обслуживаться в долгосрочной перспективе, переходя к следующему горячему картофелю, оставляя бедную душу для поддержания уродливого голема.
Но я отвлекся ...
Дело в том, что для систем достаточно простых, архитектура самоочевидна и проистекает из обоснованных методов проектирования и реализации.
Это только для больших систем, в которых задействовано довольно большое количество людей или системного программного обеспечения, которое выполняет очень сложные задачи, требующие явной архитектуры.
Я недавно закончил универ и начал работать программистом. Мне не трудно решать «технические» проблемы или заниматься отладкой, у вещей, которые я бы сказал, есть 1 решение.
Это минимум, необходимый для этой профессии, и я рад, что у вас нет проблем с их выполнением (я бы волновался, если бы вы это сделали).
Но, кажется, есть класс проблем, которые не имеют единого решения
Это хлеб с маслом нашей профессии, тип проблем, за которые работодатели готовы платить нашу (как правило) зарплату намного выше средней.
На самом деле, стоит решить те проблемы, которые могут иметь более одного решения. Проблемы реального мира, они такие. И мир требует от нас, как разработчиков программного обеспечения, нашего опыта, чтобы найти приемлемые компромиссы.
такие вещи, как архитектура программного обеспечения.
Архитектура вещей является неизбежной характеристикой сложной системы, будь то виртуальная / программная или в конкретном мире. Каждая система, которая работает, которая принимает входные данные и производит выходные данные, будет сложной и будет иметь архитектуру.
Когда мы разрабатываем программное обеспечение для таких систем (банковская система, система контроля энергопотребления, система продажи билетов и т. Д.), Мы стремимся создать программное обеспечение, которое имитирует функции и требования такой системы.
Мы просто не можем просто придумать это и закодировать в ковбойском стиле. Нам нужна какая-то архитектура. Это особенно верно, если для проекта требуются десятки инженеров, если не больше.
Эти вещи сбивают меня с толку и причиняют мне большие страдания.
Все в порядке. Это не легкий предмет для изучения или преподавания, не без большой практики.
Я часами пытаюсь решить, как «спроектировать» мои программы и системы. Например, делю ли я эту логику на 1 или 2 класса, как я называю классы, должен ли я сделать это частным или общедоступным и т. Д. Подобные вопросы занимают так много моего времени, и это сильно расстраивает меня. Я просто хочу создать программу, будь проклята архитектура.
К сожалению, это не программная архитектура.
Это даже не дизайн, а просто кодирование. Я приведу некоторые предложения в нижней части этого поста.
Как я могу быстрее пройти через этап архитектуры и перейти к этапу кодирования и отладки, который мне нравится ?
Мне трудно найти способ ответить на этот вопрос, потому что это довольно эмоционально.
Пытаемся ли мы выполнить работу или просто наслаждаться практикой? Замечательно, когда оба они - одно и то же, но в реальной жизни много раз это не так.
Здорово делать то, что нам нравится, но в такой сложной профессии, как наша, сосредоточиться только на том, что нам нравится, это не способствует успешной карьере.
Вы не будете прогрессировать, вы не будете взрослеть или приобретать новые знания.
В армии есть такая поговорка: «Обними отстой».
Другие фразы имеют аналогичные советы. «Если оно не сосет, оно того не стоит», и мой любимый: «Если оно сосет (и это важно), делайте это, пока оно не перестанет сосать».
Мои рекомендации:
Мне кажется, что вы все еще пытаетесь понять разницу между
кодирование (как кодировать ваши классы, модули или что нет, соглашения об именах, видимость доступа, область действия и т. д.),
дизайн (сколько уровней, front-end / back-end / db, как каждый взаимодействует, что куда идет) и неявные архитектурные решения, которые приходят от проектирования простых систем,
архитектура (как в сложных системах, требующих тысячи, если не сотни тысяч человеко-часов.)
Поэтому я бы посоветовал вам углубиться в первый предмет (кодирование), чтобы перейти на следующий уровень.
Чистый код
Роберт "Дядя Боб" Мартина "Чистый код" - хорошее место для начала.
Сплоченность программного обеспечения
Кроме того, я бы посоветовал вам ознакомиться с конкретной метрикой объектно-ориентированного программного обеспечения под названием LCOM или, вернее, LCOM4.
Он может быть скорее математическим и не пуленепробиваемым, но ваша цель должна состоять в том, чтобы эмпирически понять и обнаружить (или, если хотите, глазной ком) класс, если он сплоченный или ему не хватает сплоченности.
http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4
https://www.computing.dcu.ie/~renaat/ca421/LCOM.html
Принципы программного обеспечения
Это тесно связано с «Принципом единой ответственности» или SRY, с которым мы все должны быть знакомы. SRY является одним из 5 «твердых», с которыми мы все должны быть знакомы, если мы хотим стать опытными в кодировании.
По мере продвижения по принципам SOLID нам также необходимо ознакомиться с принципами «GRASP» , которые определяют или, скорее, направляют процесс кодирования классов.
Дополнительные книги
Наконец, я бы также предложил следующее:
«Рефакторинг» Мартина Фаулера и Кена Бека будет следующей книгой, которую я прочитаю в этом списке.
«Дизайн по контракту, по примеру» Ричарда Митчелла, Джима МакКима и Бертранда Мейера (позднее известность Эйфеля.) Эта книга не печатается, но вы можете найти дешевые, использованные копии в Amazon.
При этом вы должны получить хорошее представление о том, как начать программирование и проектирование, а с практикой - перейти и освоить (или хотя бы понять) архитектуру программного обеспечения.
Я уверен, что будут другие профессионалы, которые добавят, вычтут или возразят на эти предложения. Они предложат другие предложения, вероятно, подтвержденные их собственным опытом.
Все, что я могу сказать, это - нет ярлыков.
Всего наилучшего.