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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Разработка крупномасштабного программного обеспечения C ++

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

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

Answer 4

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

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

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

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

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

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

Answer 5

Инкрементно, используя Test Driven Design

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

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

Answer 9

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

Решите, что вам нужно построить и построить это.

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

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

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

Answer 10

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

• Старайтесь быть как можно более независимыми от поставщика и платформы. Это избавит вас от необходимости переопределять все с нуля с новым продуктом / платформой / структурой и т. Д.
• Это практически означает использование Java SE + Java EE + и СУБД с открытым исходным кодом, таких как 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 (Сервер приложений) от Sun, Apache, Red Hat, IBM, Oracle и других. .Net с C # имеет только одну реализацию (от Microsoft и реализацию несколько похожего языка / платформы под названием Mono).
• PHP также имеет только одну реализацию, я думаю. Существует множество различных компиляторов C ++. Но все они реализуют несколько разные языки C ++ и не связаны с библиотеками, которые используют один и тот же API. Выбирая Java, я знаю, что могу выбрать между полдюжиной реализаций Java SE и полдюжиной серверов приложений Java EE для запуска программного обеспечения, которое в свою очередь работает на Linux, Solaris, FreeBSD, HP-UX, IBM z / OS, Windows , Mac OS X и на очень большом разнообразии аппаратных платформ. Поэтому мне не нужно беспокоиться, если я обнаружу действительно плохую проблему реализации в конце разработки или даже в процессе производства - я просто отойду от Sun и никогда не оглядываюсь назад. (Вот почему я рекомендовал Java Application Verification Kit. Проверяя свой источник с его помощью, вы можете быть уверены, что Sun, IBM, Oracle или любая другая злая компания не внедрила ни один из своих патентованных компонентов в качестве зависимостей в ваш источник, который может связывать Вы в эту компанию. Вы свободны как птица.)
• Вы не можете сделать это с помощью PHP или Ruby. С этими языками вам придется исправлять проблему реализации самостоятельно, если никто больше этого не делает, потому что потратить месяцы на исправление ошибок в PHP или Ruby по-прежнему меньше усилий, чем переписывать ваше законченное приложение.
• Sun имеет открытый исходный код: Java SE (полный JDK) и Java EE (сервер приложений Glassfish). Единственное, что не является «открытым исходным кодом», это то, что существует обязательная языковая спецификация, которая возглавляется солнцем и получает огромный вклад со стороны других. Вот почему вы можете получить реализацию Java от Sun, изменить язык Java и перераспределить этот источник и двоичные файлы, но больше не можете называть эту «Java», если это не соответствует спецификации языка (Sun защищает товарный знак Java только быть применены к вещам на самом деле Java). Поначалу это может показаться «злым», но на самом деле это гарантирует, что существует такая вещь, как «Java»: вы можете написать Java-приложение и запустить его на любой Java-реализации. Вы не можете сделать это с C ++, так как нет спецификации C ++, которая согласовывается каждой реализацией c ++ (исходный код может компилироваться с компилятором Intel C ++, но не с GNU), и, что более важно, нет общей библиотеки: если я напишу программу на C ++ с библиотекой QT, она не будет компилироваться с библиотекой GTK, поскольку они имеют совершенно разные API.
• Если вы не можете ничего выносить в микросистемах Sun, но хотите использовать Java с открытым исходным кодом, тогда вы можете просто использовать Apache Harmony (Java SE) с Apache Geronimo (Java EE) сверху об этом.