Я недавно закончил университет и начал работать программистом. Мне не трудно решить «технические» проблемы или выполнить отладку с помощью вещей, которые, я бы сказал, имеют 1 решение.

Но, кажется, есть класс проблем, у которых нет единственного очевидного решения - такие вещи, как архитектура программного обеспечения. Эти вещи сбивают меня с толку и причиняют мне большие страдания.

Я часами пытаюсь решить, как «спроектировать» мои программы и системы. Например - делю ли я эту логику на 1 или 2 класса, как я называю классы, должен ли я сделать это частным или общедоступным и т. Д. Подобные вопросы отнимают так много времени, и это сильно расстраивает меня. Я просто хочу создать программу - будь проклята архитектура.

Как мне быстрее пройти этап архитектуры и перейти к фазе кодирования и отладки, которая мне нравится?

Совершенный враг хорошего.

Тем не менее, вы не должны срезать углы. Разработка программного обеспечения будет иметь более длительный эффект и сэкономит вам (и вашим коллегам) массу времени и усилий в будущем. Это займет больше времени, чтобы получить право. Большую часть времени программирование тратит не на клавиатуру, а на доску, на которой выясняется, как решить проблему.

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

(И, надеюсь, это также поможет, когда вы узнаете, что не существует только одного способа отладки / решения технических проблем.)

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

разделить ли я эту логику на 1 или 2 класса, как я называю классы, должен ли я сделать это частным или публичным и т. д. Подобные вопросы занимают так много времени

Они не должны. И они не имеют большого значения для маленькой программы (потому что маленькие, простые программы легче улучшить, например, поменять имена и т. Д.). Вам просто нужно быть последовательным и расставлять приоритеты читабельности вашего исходного кода. Вы можете время от времени находить необходимость в небольшом рефакторинге некоторых небольших частей вашей программы (и это не имеет большого значения).

Сравните это со многими проектами свободных программ (даже большими, такими как ядро ​​Linux). Разработчики не тратили значительных усилий на «архитектуру» на ранних этапах. UML почти никогда не используется в свободном программном обеспечении . Кроме того, вы многому научитесь, изучив исходный код нескольких проектов свободного программного обеспечения.

Будучи новичком, вы либо будете работать над большим программным проектом в команде, где вы можете просто доверять старшему разработчику (который принимает архитектурные решения), либо работать в одиночку над небольшими проектами (как правило, менее нескольких десятков тысяч). строки исходного кода). В последнем случае вы будете принимать поэтапные архитектурные решения, время от времени реорганизуя свое приложение, после чего «архитектурный дизайн» будет развиваться естественным образом.

Как я могу быстрее пройти через этап архитектуры и перейти к этапу кодирования и отладки, который мне нравится?

Для небольших программных проектов, которые занимают менее года работы, очень легко: не занимайтесь архитектурой. Потратьте, возможно, полчаса на мозговой штурм на общий дизайн. Затем начните писать код, используя итеративный и инкрементальный подход к разработке : напишите несколько десятков строк, скомпилируйте его (со всеми предупреждениями и отладочной информацией, например, g++ -Wall -Wextra -gс помощью GCC для C ++), пока не получите никаких предупреждений (и передайте его в некотором простом статическом источнике Анализатор кода, если он у вас есть, например, clang-analyzer ), протестируйте этот код с помощью отладчика , передайте его на контроль версий (например, git), промойте и повторите. Однако обязательно избегайте технического долга: когда что-то пахнет плохо, сделайте работу (путем рефакторинга и переопределения), чтобы улучшить это.

С другой стороны, в командной среде работа над архитектурой влечет за собой первоначальное обсуждение, чтобы определить ответственность каждого члена команды. Это обсуждение ведет старший разработчик (который не новичок). Читайте о гибкой разработке программного обеспечения и The Mythical Man-Month .

Я просто хочу, чтобы создать программу, архитектура будет проклята.

Отличная интуиция (по крайней мере, для небольших проектов). Поэтому подумайте несколько минут о своей программе и начните кодировать ее с помощью итеративного и поэтапного подхода к разработке : кодируйте несколько десятков строк и убедитесь, что они работают хорошо, а затем повторите. Перед этим изучите исходный код (и ознакомьтесь с архитектурой) подобных проектов свободного программного обеспечения и, в более общем случае, проведите библиографическую работу и исследования.

В некоторых случаях подумайте о подходе метапрограммирования : есть ситуации, когда вы хотите сгенерировать некоторый «исходный файл» (примеры включают использование генераторов синтаксического анализатора, таких как bison , генераторов клеевого кода, таких как SWIG , protobuf Google , и иногда вам может понадобиться написать простой сценарий - или используйте универсальный препроцессор, такой как GPP, - для генерации некоторого кода на C ++ или Java во избежание повторяющегося кодирования).

PS. Я инженер-исследователь, имею докторскую степень в области компьютерных наук и 40-летний опыт работы, и я никогда не занимался «архитектурой», как подсказывает ваш вопрос, хотя успешно работал над несколькими проектами среднего размера и несколькими крупными (сам компилятор GCC). ). Для меня «архитектура» - это просто этап планирования работы на следующие несколько дней или недель (и я обычно делаю это, когда сплю или сплю и, конечно, без какого-либо компьютера, и обычно даже без карандаша). Кроме того, когда я пишу исследовательские гранты , я каким-то образом и не полностью проектирую архитектуру.

NB: некоторые программные проекты нуждаются в гораздо большей архитектуре, чем другие. Например, если вы пишете систему управления искусственным сердцем или нейрохирургическим роботом, вы не будете работать так же, как при написании обычного приложения для мобильного телефона. Смотрите также Norvig's Teach самостоятельно программирование за десять лет .

Есть три девиза, которые я хотел бы запомнить.

• «Все должно быть сделано как можно проще, но не проще»

  Чтобы взять ваш пример «один класс или два?», Я бы спросил: «Какое простое решение?»

• «Нет очевидных ошибок» против «Очевидно, нет ошибок»

  Последнее предпочтительнее!

  И это причина, почему это должно быть простым, то есть, чтобы вы могли рассуждать об этом. Один большой класс может быть (или может стать) слишком большим и слишком сложным, чтобы его можно было рассуждать. В этом случае вы разбиваете его на несколько меньших классов, где вы можете сказать: «Каждый класс маленький и делает то, что, как он говорит, он будет делать - и их интерфейсы просты, и они объединяются в правильном пути. "

  1. Код должен работать в теории (то есть в вашей голове).
  2. Тогда, если это не работает на практике, вы можете отлаживать его, пока практика не будет соответствовать теории.

  Новичок иногда даже не беспокоится о шаге 1, то есть о том, что он работает в вашей голове (например, потому что он слишком сложный), но в этом случае он работает только «случайно», а не «в теории», возможно, потому что вы не Я проверил это достаточно, чтобы найти неочевидные ошибки.

• Закон Галла

  Это ака "рефакторинг".

  На практике это означает:

  1. Начните с [ny] простой системы, которая работает
  2. Теперь пришло время добавить новую функцию
  3. Рефакторинг существующей системы, чтобы (т.е. до) легко добавить новую функцию

  4. Добавить новую функцию

  5. ... и повторите, как указано выше

  Это соответствует девизам, таким как YAGNI, то есть не рефакторинг (беспокойство об архитектуре), прежде чем вам нужно ... но создание правильной архитектуры как раз вовремя, т.е. когда вам это нужно для какой-то конкретной цели.

Что вы можете сделать, это начать с минимального количества абстракций, которое вам нужно. Например, класс Person в одном файле. Теперь, когда вы продолжаете добавлять код и функции, вы начинаете видеть вещи, которые нужно перенести в другую абстракцию. Например, принцип единой ответственности (S of SOLID) говорит вам, что в классе Person не должно быть методов, связанных с разбором адресов. Теперь вы знаете, что вам нужен класс Address.

Но всегда хорошо подумать о том, как выглядит «минимальное количество абстракций» для вашей системы. Начните с достаточно хорошей архитектуры и улучшайте ее по мере продвижения.

edit: @Basile answer дает пример того, как вы можете выполнять итерации и улучшать свою минимальную архитектуру.

Время, потраченное на размышления об архитектуре системы, не тратится впустую.

Я считаю, что ваш вопрос можно перефразировать следующим образом: «Как я могу быть более эффективным при принятии архитектурных решений?».

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

-

И для более длинного ответа ...

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

Я думаю, что есть 3 важных вещи, которые следует иметь в виду при обсуждении этой темы:

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

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

• поскольку архитектура и дизайн существуют изначально и потому что кодовая база является живым существом, которое развивается со временем, архитектура и дизайн также должны развиваться. Они либо будут развиваться контролируемым образом с помощью сознательных решений, принятых в основное время, либо они будут развиваться хаотично, управляемые кодированием. Это важно понять, потому что это означает, что традиционный подход «сначала архитектор и второй код пишут» ошибочен. Конечно, при запуске проекта с нуля, некоторые архитектурные и дизайнерские работы должны быть выполнены заранее. Но помимо этого, при разработке системы еще предстоит принять много архитектурных и дизайнерских решений.

Чтобы еще больше понять вышесказанное, очень важно осознавать тот факт, что вы будете принимать проектные решения при написании кода, сознательно или нет. Вы должны стремиться к сознательному и критическому принятию таких решений, так как любое принятое решение может оказать большое влияние на будущую работу (это влияние обычно проявляется в кодовой базе, которую очень трудно изменить для исправления ошибок или реализации функций). Роберт К. Мартин прекрасно иллюстрирует это своими данными в своей книге «Чистая архитектура» (которую я, кстати, очень рекомендую).

Итак, теперь, когда мы знаем, почему архитектура и дизайн важны, каковы основные принципы, которые могут дать нам надлежащую основу для принятия правильных решений? У меня был этот вопрос в начале моей карьеры, я чувствовал, что чего-то не хватает в моем наборе инструментов, но не знал, что, не знал, как описать это или искать его. Я поделюсь некоторыми из этих принципов, которые я обнаружил со временем, и я надеюсь, что они немного облегчат вашу жизнь:

• набор очень простых, но мощных приемов кодирования можно найти, прочитав книгу Мартина Фаулера «Рефакторинг: улучшение дизайна существующего кода». Их слишком много, чтобы перечислять их здесь, но это очень низкоуровневые решения, требующие времени кодирования, которые вы можете принять, чтобы значительно улучшить структуру кода и помочь принять проектные решения. Книга также является хорошим примером для интеграции модульного тестирования в ваш личный рабочий процесс и того, как писать тестируемый код.

• специально для ООП, вы должны смотреть на принципы SOLID . Они немного абстрактны и поначалу сложны для восприятия, но очень мощные. Я предлагаю вам начать с первых двух, чтобы быстро получить максимальную выгоду:

Принцип единой ответственности : класс должен нести только одну ответственность (т.е. только изменения в одной части спецификации программного обеспечения должны иметь возможность влиять на спецификацию класса).

Открытый / закрытый принцип : «программные объекты… должны быть открыты для расширения, но закрыты для модификации».

• понятие композиции по наследству

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

• концепции связи («степень взаимозависимости между программными модулями») и когезии («степень, в которой элементы внутри модуля принадлежат друг другу».)
• DRY (не повторяться) концепция
• концепция разделения команд / запроса ( «каждый метод должен быть либо команда , которая выполняет действие, или запрос , который возвращает данные вызывающего абонента, но не оба»)
• Концепция системы с состоянием и системой без состояния (мое эмпирическое правило таково: избегайте обработки состояния; постройте как можно больше систем без состояния).

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

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

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

Там, где необходима архитектура, ДО проекта:

1. Соберите точные требования и нефункциональные требования (сколько запросов / секунду мне нужно поддерживать?). Любое несоответствие на этом этапе приведет к адскому кодированию - интеграции пропущенных идей после того, как факт отнимает много времени, раздражает и иногда невозможен. Я знаю, что это не так весело, как кодирование, но попытка заставить код сделать то, для чего он не был разработан, еще менее увлекательна.

2. Если это уместно, определите ограниченные контексты вашей системы и убедитесь, что ваш словарный запас прямой, например, если бизнес говорит о «Frobbels», убедитесь, что вы называете классы / интерфейсы и т. Д. С помощью «*** Frobbels». Звучит тривиально, но если вы говорите о рабочих процессах, а бизнес говорит об операциях, перевод очень быстро раздражает.

3. Если вы работаете с несколькими людьми / командами, опишите ваши интерфейсы заранее и убедитесь, что все предположения и проблемы понятны всем - если у вас нет общего контекста, интеграция будет «забавной». Например, вы создаете генератор банановых картинок, но вашему веб-разработчику нужен генератор яблочных картинок. Или вы создаете что-то, что может отвечать на 100 запросов в секунду, но необходимо 10000 об / сек.

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

Я не собираюсь бросать вам кучу терминов и сокращений (большинство из которых вряд ли будут согласованы большинством программистов / разработчиков программного обеспечения). Вместо этого рассмотрите следующее:

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

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

3. Как недавний выпускник, кодирование и отладка могут быть очень интересными, но это со временем утомится, и навыки, которые вы изучаете сейчас, будут вам полезны, когда это произойдет.

4. Я бы сказал, что создание программного обеспечения - это больше искусство / ремесло, чем разработка. Великое искусство - это не просто мазок, а решения высокого уровня и компромиссы, сделанные художником / мастером.

Я попытаюсь ответить на этот вопрос, исходя из точки зрения веб-разработки (имеется в виду: из области, где люди сильно мучаются из-за архитектуры). Я начну с объяснения, почему люди заботятся об архитектуре, а затем обрисую способы более быстрого прохождения части архитектуры.

Архитектура делает две вещи для вашего кода:

1. Это облегчает понимание вашего кода для вас и других.
2. Это помогает структурировать ваш код таким образом, чтобы облегчить его расширение и интеграцию.

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

Кроме того, хорошая архитектура обеспечивает сокращение для избежания многих ловушек, которые могут помешать вашему коду легко использоваться. Опять же, если вы принимаете архитектурное решение, оно должно создать соглашение, которое поможет вам меньше думать о том, как писать код.

Теперь часть, для которой вы на самом деле здесь:

Что вы можете сделать, чтобы пройти через часть архитектуры быстрее:

1. Не делай этого

Как много ответов уже указано. Сначала спросите себя, нужна ли вам архитектура. Если у вас не будет много кода (и вы можете быть уверены, что проект не будет расти в ближайшем будущем), вы можете просто пропустить часть архитектуры и собрать что-то, что просто работает. ОДНАКО, если вы находитесь в начале своей карьеры, я бы использовал возможность практиковаться, когда вы можете. В какой-то момент вы будете делать большие проекты, и в этот момент, вероятно, уже поздно учиться.

Что вы можете сделать, чтобы сделать архитектуру менее болезненной:

1. Сделай это рано
2. красть
3. Учись / Придерживайся
4. Не переусердствуйте

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

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

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

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

(PS: последнее предложение не является оправданием для ленивости. Приоритизация рабочего программного обеспечения не означает, что когда-нибудь вам не придется учиться хорошему кодированию.)

Ответ очень прост,

• Создать прототип (Время в штучной упаковке)
• Рефакторинг (тратьте столько времени, сколько хотите, или у вас есть множество факторов)

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

Как я могу быстрее пройти через этап архитектуры и перейти к этапу кодирования и отладки, который мне нравится?

Передав эту задачу (или попросив помощи) своим более опытным сотрудникам.

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

Работа с людьми, которые лучше на работе, чем вы, - самый быстрый способ научиться чему-либо. Если у вас нет никого старшего, к кому можно обратиться, вам нужна лучшая работа. «Лучше», как «лучше соответствует вашим потребностям». Потребность в знаниях и опыте является вашей самой острой потребностью в данный момент, что подтверждается вашей дилеммой. Вам нравится фаза кодирования и отладки? Похоже, идеальный младший. Но младший нуждается в руководстве старшего. В этом смысл этих должностных инструкций. Незнакомцы в интернете могут помочь только вам до сих пор, вам нужен наставник.

Я вижу некоторые серьезные проблемы с этим вопросом. Давайте начнем.

Как перестать тратить время на разработку архитектуры

Этот вопрос довольно загружен. Кроме того, вы не проектируете архитектуру. Вы архитектор . Архитектура и дизайн являются взаимодополняющими и связанными с ними видами деятельности, но не совпадают, даже если они могут перекрываться.

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

Надлежащая архитектура направлена ​​на предотвращение этой потери в кодировании. Это достигается путем ограничения, сужения и документирования возможных способов, которыми сложная система должна быть: 1) спроектирована, 2) закодирована и протестирована, 3) доставлена, 4) поддержана, 5) восстановлена ​​после сбоя и 6) в конечном итоге выведена из эксплуатации.

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

Но я отвлекся ...

Дело в том, что для систем достаточно простых, архитектура самоочевидна и проистекает из обоснованных методов проектирования и реализации.

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

Я недавно закончил универ и начал работать программистом. Мне не трудно решать «технические» проблемы или заниматься отладкой, у вещей, которые я бы сказал, есть 1 решение.

Это минимум, необходимый для этой профессии, и я рад, что у вас нет проблем с их выполнением (я бы волновался, если бы вы это сделали).

Но, кажется, есть класс проблем, которые не имеют единого решения

Это хлеб с маслом нашей профессии, тип проблем, за которые работодатели готовы платить нашу (как правило) зарплату намного выше средней.

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

такие вещи, как архитектура программного обеспечения.

Архитектура вещей является неизбежной характеристикой сложной системы, будь то виртуальная / программная или в конкретном мире. Каждая система, которая работает, которая принимает входные данные и производит выходные данные, будет сложной и будет иметь архитектуру.

Когда мы разрабатываем программное обеспечение для таких систем (банковская система, система контроля энергопотребления, система продажи билетов и т. Д.), Мы стремимся создать программное обеспечение, которое имитирует функции и требования такой системы.

Мы просто не можем просто придумать это и закодировать в ковбойском стиле. Нам нужна какая-то архитектура. Это особенно верно, если для проекта требуются десятки инженеров, если не больше.

Эти вещи сбивают меня с толку и причиняют мне большие страдания.

Все в порядке. Это не легкий предмет для изучения или преподавания, не без большой практики.

Я часами пытаюсь решить, как «спроектировать» мои программы и системы. Например, делю ли я эту логику на 1 или 2 класса, как я называю классы, должен ли я сделать это частным или общедоступным и т. Д. Подобные вопросы занимают так много моего времени, и это сильно расстраивает меня. Я просто хочу создать программу, будь проклята архитектура.

К сожалению, это не программная архитектура.

Это даже не дизайн, а просто кодирование. Я приведу некоторые предложения в нижней части этого поста.

Как я могу быстрее пройти через этап архитектуры и перейти к этапу кодирования и отладки, который мне нравится ?

Мне трудно найти способ ответить на этот вопрос, потому что это довольно эмоционально.

Пытаемся ли мы выполнить работу или просто наслаждаться практикой? Замечательно, когда оба они - одно и то же, но в реальной жизни много раз это не так.

Здорово делать то, что нам нравится, но в такой сложной профессии, как наша, сосредоточиться только на том, что нам нравится, это не способствует успешной карьере.

Вы не будете прогрессировать, вы не будете взрослеть или приобретать новые знания.

В армии есть такая поговорка: «Обними отстой».

Другие фразы имеют аналогичные советы. «Если оно не сосет, оно того не стоит», и мой любимый: «Если оно сосет (и это важно), делайте это, пока оно не перестанет сосать».

Мои рекомендации:

Мне кажется, что вы все еще пытаетесь понять разницу между

1. кодирование (как кодировать ваши классы, модули или что нет, соглашения об именах, видимость доступа, область действия и т. д.),

2. дизайн (сколько уровней, front-end / back-end / db, как каждый взаимодействует, что куда идет) и неявные архитектурные решения, которые приходят от проектирования простых систем,

3. архитектура (как в сложных системах, требующих тысячи, если не сотни тысяч человеко-часов.)

Поэтому я бы посоветовал вам углубиться в первый предмет (кодирование), чтобы перейти на следующий уровень.

Чистый код

Роберт "Дядя Боб" Мартина "Чистый код" - хорошее место для начала.

Сплоченность программного обеспечения

Кроме того, я бы посоветовал вам ознакомиться с конкретной метрикой объектно-ориентированного программного обеспечения под названием 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.

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

Я уверен, что будут другие профессионалы, которые добавят, вычтут или возразят на эти предложения. Они предложат другие предложения, вероятно, подтвержденные их собственным опытом.

Все, что я могу сказать, это - нет ярлыков.

Всего наилучшего.

Здесь много информации и, честно говоря, TL; DR. Есть одна главная вещь, которую я думаю, что люди ошибаются, пытаясь научиться проектировать систему: они пытаются думать об этом в том порядке, в котором будет выполнена работа. Вместо этого вам нужно работать в обратном направлении. То есть основная цель дизайна / архитектуры - определить, каким должен быть конечный результат.

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

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

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

Что касается именования вещей, для меня это часть «написания», но это, несомненно, очень важная часть программирования: не стесняйтесь задуматься над тем, как вы называете вещи, и усерднее думать, чем шире область действия имени.

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