Что должно “начинающий разработчик” знать об архитектуре и [закрытом] планировании

Во-первых, общие ответы:

• Поймите, что любой данный инструмент не является серебряной пулей для решения всех ваших проблем. Поэтому, когда вы читаете о MVC или функциональном программировании, или кто-то говорит, что LISP решит все ваши проблемы, они этого не сделают. Они могут решить целый ряд ваших проблем, но не решат их всех. Во многих случаях, помимо решения одних проблем, они вводят целый ряд других.
• Поймите ограничения и преимущества различных компонентов / технологий / инструментов, которые всегда под рукой, чтобы найти решения любой данной проблемы. Принимайте решения, основываясь на оценке всех преимуществ и недостатков - не принимайте решения вслепую.
• Выберите правильные инструменты для работы, включая язык, разработку, методы интеграции.
• Кто будет обслуживать код? Код для ожидаемой аудитории. Если это вы, не ожидайте, что через шесть месяцев, когда от вас ожидается предоставление исправления, вы вспомните, каким был ваш мыслительный процесс сегодня ... напишите код, который просто читает и документирует ваш мыслительный процесс. Не «как» - это делает код, а «почему». Независимо от того, насколько легко читать ваш код, он не может сказать вам , почему вы сделали это именно так. Комментарии к коду предназначены для объяснения причин, а не для того, как.
• Поймите своих пользователей, как они работают, их менталитет по отношению к своим инструментам, какова их работа, каково их отношение к кривой обучения для вашего программного обеспечения.
• менталитет человека / команды, которые будут поддерживать ваше приложение - это также означает установку.
• Поймите необходимость контроля версий и используйте его.
• Резервные копии, всегда предполагайте и готовьтесь к худшему, если вы этого не хотите.
• Узнайте, как писать спецификации программного обеспечения, технические спецификации , тестовая документация, пользовательская документация.
• Тестирование FAT / SAT / UAT и процедуры подписания.
• Устанавливайте более низкие ожидания, чем вы способны выполнить, не обещайте клиенту Lambourghini и поставьте Volkswagon Beetle [Ошибка] . Гораздо лучше пообещать Beetle [Ошибка] и доставить Mercedes.
• Не усложняйте что-либо - в том числе архитектурно, программно или что-либо еще. Документация должна быть простой для чтения, интерфейс должен быть простым в использовании.

Теперь подробности:

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

Неспособность спланировать - значит отказаться план на случай отказа

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

• Веб-браузеры - IE / Firefox / Opera / Safari
• Серверы приложений / файлов - Windows Server, Linux, Unix
• Веб-серверы - IIS / Apache
• Разработка веб-приложений - ASP.NET/C#/VB.NET/ASP/PHP/JavaScript/AJAX/MVC
• Разработка консольных приложений - BAT / C # / VB.NET [Не пишите полноценное приложение на C #, если BAT-файл будет выполнять работу намного проще].
• Разработка приложений для Windows - C # / VB.NET
• Обслуживание данных - C # / VB.NET / Excel / VBA
• Серверы баз данных - SQL Server, MySQL, Oracle
• Службы интеграции сети / данных / файлов - MSMQ, BizTalk, SonicMQ, FTP

Я могу использовать одну или несколько из этих технологий для своего решения полностью в зависимости от того, что от меня требуется. Ключ к пониманию того, что актуально для данной ситуации, и использование только того, что необходимо. Например, не пишите полномасштабное веб-приложение, если утилиту командной строки может легко использовать один пользователь, не пишите приложение Windows, если многим пользователям нужен доступ к приложению, которое нелегко установить на их машины. из-за ограничений пользователей и ограниченного персонала системной поддержки. Не пишите утилиту командной строки для пользователей, которые с трудом перемещаются по окнам с помощью мыши и не ожидают, что эксперт Microsoft поддержит вашу систему на основе * nix.

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

Изменить : в ответ на ваш комментарий относительно UML, который отлично подходит для цель, но еще раз вы должны знать свою целевую аудиторию. Если вы программист-одиночка, который разрабатывает системы для небольшого клиента, персонал которого не понимает UML, вам следует предоставить обычную блок-схему, украшенную простым английским языком. Если вашей целевой аудиторией является консалтинговая компания, занимающаяся разработкой программного обеспечения, то, безусловно, UML - отличный инструмент, особенно с некоторыми инструментами UML, вы можете заставить его автоматически генерировать ваши классы / методы-заглушки, чтобы вы могли автоматизировать некоторые из них. обработать. Я обычно работаю в небольших командах для небольших компаний, поэтому я не использую UML так часто, как мне бы хотелось, и, вероятно, не понимаю его так хорошо, как должен, но это не означает, что если бы я был необходим, я бы не стал Не освежаюсь. Это отличный инструмент, который нужно иметь в своем арсенале, но не используйте его только ради него. Все, что вы используете при проектировании / архитектуре / разработке вашего решения, должно использоваться по объективной причине - не используйте / изучайте его вслепую, потому что кто-то говорит: «вам следует использовать это, потому что это здорово».

Ключ к хорошей архитектуре заключается в следующем:

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

И самое главное:

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