Проблемы разработки программного обеспечения/архитектуры

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

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

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

У вас была знакомая проблема? Как вам удалось это решить? У вас есть какие-то намеки на то, как продолжать?

Ответ 1

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

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

Ответ 2

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

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

Вы никогда не получите 100% прав со всех сторон.

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

Вот несколько примеров книг:

Конечно, практический опыт также считается.

Ответ 3

 design bigger/more complex applications

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

Говоря об этих проблемах,

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

При проектировании для вашего приложения, если вы попытаетесь учесть эти проблемы и принять проектные решения на основе этих проблем, тогда это будет один из способов попытаться двигаться в правильном направлении. ОДНАКО, это легче сказать, чем сделать. Хотя, казалось бы, просто выглядящий список, получение права на дизайн - это то, что опытные архитекторы теряют сон/волосы/жизнь и обычно НИЧЕГО трудно получить право, особенно для новичка.

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

But no matter what i try, how long i try: i just can't get it right. 
My designs always seem wrong to me somehow.

Честно говоря, вы совершенно ошибаетесь, чтобы судить. Как вы действительно знаете, что ваш дизайн неправильный? Единственный реальный способ сказать дизайн неверен, если ваше приложение не делает то, что он должен был делать.

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

Cause of that i never drawn through a bigger project, i'm kinda never satisfied 
with the structure of my program.

К сожалению, некоторые из реальных сложностей при разработке приложения enterpise являются результатом множества вещей, которые просто невозможно имитировать иначе. Некоторые из них могут быть организационными ограничениями, например. мой клиентский CTO не использует использование технологии X) другим, например, нам необходимо интегрировать наше приложение с этим распространенным приложением MS Access, которое использует один из наших поставщиков. Такие осложнения, связанные с приложением и его дизайном, - это то, что вам нужно испытать, и из него обычно можно многое узнать.

Чтобы получить такой опыт, вы должны работать в таких местах, которые предоставляют такую возможность. Обычно, я видел, что чем крупнее компания, тем сложнее их ИТ-среда, и это дает максимальную возможность для сложных сценариев.

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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