Как построить большие приложения

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

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

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

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

Как всегда, спасибо за ваши ответы.

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

Ответ 1

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

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

Итак, что мы можем сделать?

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

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

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

Ответ 2

Заимствовано у tvanfosson:

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

Ответ 3

Вот книга, которую мы использовали для руководства нашими стандартами и методами кодирования:

Крупномасштабный C++ Дизайн программного обеспечения

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

Я бы также порекомендовал, как это уже было сделано многими другими, Code Complete и Software Esvaluation от Стива Макконнелла. Мне особенно нравится его метафора "растущего" программного обеспечения, а не конструирования или сборки. Этот способ просмотра программного обеспечения лучше подходит для чего-то, что будет иметь длительный жизненный цикл.

Ответ 4

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

Некоторые из этих проблем включают в себя:

(например, база данных, которая просто не помещается на один жесткий диск)
сложность (из приложения "все-в-одном" в несколько подсистем)
concurrency (от ноль до тысяч/миллионов одновременных пользователей)
доступность (от 9% до безотказной работы до 99,999%)
надежность (от ежедневных сбоев до нескольких лет MTBF)
скорость (от часов до миллисекунд во время отклика)
(от вашего любимого проекта до продаваемого товара)
и др.

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

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

С наилучшими пожеланиями.

Ответ 5

Определите, какие функции наиболее важны; забыть остальное
Определите, какая из тех функция наиболее важна и забыть остальные
Реализуйте их (требуется несколько недель, в противном случае повторите шаги 1 и 2).
Запуск
Посмотрите, какие функции работают, а какие нет и которые отсутствуют.
Вернитесь к шагу 1

Ответ 6

Крупные приложения не создаются за одну ночь. Корпоративные приложения начинаются с небольших кусочков, а затем их объединяют. Если вы разрабатываете приложения, это способ, который можно масштабировать, тогда будет проще интегрироваться со всеми окружающими факторами, такими как базы данных, сторонние инструменты и т.д. Если вы перейдете в infoq.com вы найдете множество замечательных примеров исследований и материалов о масштабировании и архитектуре, таких как Myspace, Amazon и многие другие. Ничто, кроме опыта, не приведет вас к разработке больших приложений.

Ответ 7

Постепенно, используя Test Driven Design

Ответ 8

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

Решите, что вам нужно для сборки и сборки.

Разбить его на модули, которые выполняют задачи отдельно.

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

Ответ 11

Как кто-то, кто отвечает за большое приложение, я бы сказал

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

НЕ ПАНИКА

Ответ 12

Некоторые мысли о блокировке продукта и поставщика:

Постарайтесь как можно более независимы от поставщика и платформы. Это не позволит вам переопределить все с нуля новым продуктом/платформой/фреймворком и т.д.
Это практически означает использование Java SE + Java EE + и RDBMS с открытым исходным кодом, таких как PostgreSQL, инкапсулированные JPA из Java EE. Не используйте дополнительные библиотеки, фреймворки (spring, hibernate,...) и т.д. Таким образом вы можете переключаться между продуктами и поставщиками в любое время.
Я думаю, что вы можете получить этот уровень независимости от продукта и платформы с помощью Java. Даже если вы используете библиотеки и рамки OSS, вы будете сожалеть об их использовании, если узнаете, что реализация не подходит вашим потребностям, и вам нужно все переделать.
Вы можете проверить независимость продукта от своего кода с помощью Java Application Verification Kit.
Проведите некоторое время в Архитектуре заранее, но также перепроектируйте Архитектуру во всей реализации. Хорошая книга (к сожалению, только немецкая) - это "Java EE 5 Architekturen" Адама Биена.

@j_random_hacker: На самом деле, нет, я все еще думаю, что мой первый пункт - это аргумент в пользу использования java в больших приложениях, а не против него. Каждый язык - ОДИН язык. Поэтому вы всегда должны делать обязательство по языку, конечно.

Но Java SE и EE включают язык, компилятор, виртуальную машину, а также все необходимые библиотеки/фреймворки. Но существуют разные ОСНОВАНИЯ всей платформы Java SE/EE: Java SE (JDK) от Sun, Apache, IBM, HP, Oracle, BEA. Java EE (Application Server) от Sun, Apache, Red Hat, IBM, Oracle и других..Net с С# имеет только одну реализацию (от Microsoft и реализацию аналогичного языка/платформы под названием Mono).
У PHP также есть только одна реализация, я думаю. Существует множество различных компиляторов С++. Но все они реализуют несколько разные языки С++, и они не связаны с библиотеками, которые имеют общий API. Выбирая Java, я знаю, что я могу выбирать между полдюжины реализаций Java SE и полдюжины Java EE Application Servers для запуска программного обеспечения, которое, в свою очередь, работает на Linux, Solaris, FreeBSD, HP-UX, IBM z/OS, Windows, Mac OS X и на очень большом количестве аппаратных платформ. Поэтому мне просто не нужно беспокоиться, если я нахожу очень плохую проблему реализации в конце разработки или даже в производстве - я бы просто ушел от Солнца и никогда не оглядывался назад. (Вот почему я рекомендовал набор проверки приложений Java. Проверяя ваш источник с ним, вы можете быть уверены, что Sun, IBM, Oracle или любая другая злая компания не скрывали какие-либо из своих проприетарных материалов в качестве зависимостей в вашем источнике, которые могли бы связывать вы в эту компанию. Вы свободны, как птица.)
Вы не можете сделать это с помощью PHP или Ruby. С этими языками вам придется самостоятельно исправлять проблему реализации, если никто другой не делает этого, потому что тратить месяцы на время исправления ошибок на PHP или Ruby все равно меньше усилий, чем переписывать ваше полное приложение.
Sun имеет открытый источник: Java SE (полный JDK) и Java EE (сервер приложений Glassfish). Единственное, что не является "открытым исходным кодом", это то, что существует спецификация языка привязки, которая управляется солнцем и получает массивные вклады других. Вот почему вы можете захватить реализацию Java от солнца, изменить язык Java и перераспределить этот источник и двоичные файлы, но больше не можете вызывать эту "Java", если это не соответствует спецификации языка (Sun защищает Java Trademark только быть применены к вещам, фактически java). Сначала это может звучать "зло", но на самом деле это гарантирует, что существует такая вещь, как "Java": вы можете написать приложение Java и запустить его для любой реализации Java. Вы не можете сделать это с С++, так как нет спецификации на С++, которая согласовывается с каждой реализацией С++ (исходный код может компилироваться с компилятором Intel С++, но не с GNU) и, что более важно, нет общей библиотеки: если я напишу программу на С++ с библиотекой QT, она не будет компилироваться с помощью библиотеки GTK, так как у них есть совершенно разные API.
Если вы не можете выдержать что-либо в Sun Microsystems, но хотите использовать Java с открытым исходным кодом, вы можете просто использовать Apache Harmony (Java SE) с Apache Geronimo(Java EE).