Добрый вечер.
Подскажите где можно почитать про проектирование больших приложений:
как лучше всего именовать отдельные части приложения и как лучше всего их раскладывать по папкам.
Там например:
В Dal только доступ к бд.
В Bl — бизнес-логика/модели коллекции.
В AppBlocks — дополнительные утилиты.
-- какой код должен сюда входить, какой в отдельные проекты
Как именовать под-папки
Где должны находиться юнит тесты, автоматизированные тесты.
Где должны находится скрипты по билдам.
Где должны находить посторонние программы/библиотеки, где хранить информацию о них: документацию, информацию о лецензиях.
Так же интересует процесс проектирования больших приложений: как выстраивается такая архитектура.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, IChensky, Вы писали: IC>Там например: IC>В Dal только доступ к бд. IC>В Bl — бизнес-логика/модели коллекции. IC>В AppBlocks — дополнительные утилиты. IC> -- какой код должен сюда входить, какой в отдельные проекты IC>Как именовать под-папки
с такими приложениями одна сплошная беда
основная проблема что ты не можешь просто вытащить данные и обрабатывать их — это можно сделать по человечески только в базе на ущербном языке
а так как интерфейс должен просто отображать то, что в базе, то возникает вагон копипасты которая просто конвертит одно в другое, его перекладывает в третье и т.д.
юнит-тесты непонятно что тестируют, так как логики обычно почти никакой и нет — все приложение просто что-то гоняет по базе и все. а кода много, так как много копипасты из-за попыток что-то разделить и асбтрагировать.
в общем, тут царит полная содомия. существующие книжки по этой тематике — собрание фимозной фигни. грамотного подхода как сделать что-то по человечески просто не существует.
On 25.04.2013 23:19, IChensky wrote:
> Так же интересует процесс проектирования больших приложений: как > выстраивается такая архитектура.
Боюсь, что книжки тебе не сильно помогут, но почитать их полезно.
Обычно архитектуру делают путем декомпозии. Т.е. делят нечто большое на
несколько "ортогональных" частей, т.е. каждая часть должна делать что-то
свое и не пересекаться функциональностью с другими. Кроме того, удобно
ориентироваться на число 7, частей на каждом уровне декомпозии не должно
быть больше 7, лучше меньше (такая вот особенность нашего мозга).
Ну а дальше иерархия папок отражает иерархию декомпозиции, проведенной выше.
С UT, тут на вкус и на цвет, я люблю их держать как можно ближе к коду,
разве что в соседней папке или подпапке с названием ut_*. Многим
нравиться их держать отдельно и там повторять иерархию системы.
Доку тоже люблю держать рядом с тем, что она документирует.
Стороннее обычно лучше держать в отдельном месте.
Остальное — вопрос личных предпочтений, но вот это выглядит мягко говоря странно. >Кроме того, удобно Ориентироваться на число 7, частей на каждом уровне декомпозии не должно быть больше 7, лучше меньше (такая вот особенность нашего мозга).
Если каждая часть кода отвечает строго за свой кусок и не лезет к другим, то в голове вовсе необязательно держать всё, что относится к текущему уровню, текущего контекста хватает за глаза. Если не получается и у вас сильная связность по всему коду, то ни пять классов, ни пятьсот не исправят проблем вида "исправил один раз, поломал везде".
Здравствуйте, IChensky, Вы писали:
IC>Добрый вечер. IC>Подскажите где можно почитать про проектирование больших приложений:
... IC>Так же интересует процесс проектирования больших приложений: как выстраивается такая архитектура.
Ну, можно посмотреть у Мартина Фаулера:
1. Архитектура корпоративных программных приложений
2. Шаблоны корпоративных приложений
До кучи:
Кент Бек. Шаблоны реализации корпоративных приложений
Грегор ХОП и Бобби Вульф. Шаблоны интеграции корпоративных приложений
Поль Дюваль. Непрерывная интеграция.
Но без опыта все эти книжки — как Фихтенгольца в 3-м классе читать...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
On 26.04.2013 10:58, Sinix wrote:
> Остальное — вопрос личных предпочтений, но вот это выглядит мягко говоря > странно.
Ну еще бы. Мы здесь только о личном опыте и предпочтениях говорим.
> Если каждая часть кода отвечает строго за свой кусок и не лезет к > другим, то в голове вовсе необязательно держать всё, что относится к > текущему уровню, текущего контекста хватает за глаза.
Люди не роботы и количество сущностей, которыми они могут одновременно
оперировать сильно ограничено (и это число около 7, селяви). И вот если
человек одновременно может удержать относящееся к текущему уровню в
голове он сделает работу лучше (как тут любят говорить не будет плодить
"говнокод").
З.Ы. 7 — это не доказанное число или данное нам богом — это всего-лишь
эмпирические наблюдения из разных областей и не более и по моему опыту
лучше на это число ориентироваться.
З.З.Ы. Вот только давай не поднимать здесь срач, что лучше 7 или 42. Еще
раз, я написал всего-лишь свое ИМХО, возможно тебе больше наравиться 42
(интересно, через сколько дней програмеры побьют такого архитектора).
On 26.04.2013 11:06, LaptevVV wrote:
> Но без опыта все эти книжки — как Фихтенгольца в 3-м классе читать...
А с опытом они вызывают улыбку (но и в них крупинки золота попадаются),
ибо не Фихтенгольц.
Здравствуйте, Vzhyk, Вы писали:
V>On 26.04.2013 11:06, LaptevVV wrote:
>> Но без опыта все эти книжки — как Фихтенгольца в 3-м классе читать... V>А с опытом они вызывают улыбку (но и в них крупинки золота попадаются), V>ибо не Фихтенгольц.
А без опыта — вообще непонятно, нафига все это написали...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
V>Люди не роботы и количество сущностей, которыми они могут одновременно оперировать сильно ограничено (и это число около 7, селяви).
Ну да. Вопрос не в этом, у тебя противоречие получается:
1. Нужно разбивать код на независимые друг от друга части (а эти части на подчасти и т.д.) — тут никаких возражений
2. Число частей при каждом разбиении должно быть небольшим, чтобы человек мог их все удержать в голове.
Вот со вторым утверждением я никак не могу согласиться. Проблема — не в количестве частей, на которые мы разбиваем код, проблема в зависимостях между этими частями.
Смотри сам: в большинстве проектов в одном пространстве имён слегка больше 7 классов, в одном классе — больше методов и никто особо против этого не возражает. Код развязан функционально (не зависит друг от друга) и держать в голове всё сразу не требуется, достаточно того что используется непосредственно в текущем контексте.
Этот принцип работает на всех уровнях, от решения в целом и до конкретного метода. Да, в хорошо написанном методе может быть с полсотни строк и это не будет вызывать проблем с чтением-пониманием кода. Просто само описание проблемы, решаемой этим кодом оказалось вот такого объёма.
On 26.04.2013 12:27, Sinix wrote:
> Вот со вторым утверждением я никак не могу согласиться. Проблема — не в > количестве частей, на которые мы разбиваем код, проблема в зависимостях > между этими частями.
Код к архитектуре имеет опосредованое отношение. К архитектуре у тебя
относятся модули и их интерфесы (упрощенно написал, но не вижу смысла
здесь в куче всего не относящегося к делу).
Так вот по опыту получается, что лучше всего работают системы, где на
каждом уровне иерархии (дерево) приблизительно не более 7 модулей. И
самое смешное, что лучше, когда интерфейс состоит из приблизительно не
более 7 функций.
> Смотри сам: в большинстве проектов в одном пространстве имён слегка > больше 7 классов,
Понятно, что это число не данное нам богом, но если у тебя в одном
слое/уровне/модул/пространствеимен лежит рядом под 30 классов и болле,
то разобраться в них уже очень сложно, их надо по подпространствам имен
распихать.
> Да, в хорошо написанном методе может быть с полсотни > строк и это не будет вызывать проблем с чтением-пониманием кода.
С этим все просто, метод, что занимает более 2-х экранов, нечитабелен.
Это проверено на сотнях программистов. Лучше его разбить на несколько
последовательно вызываемых.
On 26.04.2013 12:00, LaptevVV wrote:
> А без опыта — вообще непонятно, нафига все это написали...
Поэтому и получается, что сначала надо набить шишек на парочке проектов,
потом прочитать эти книжки и понять, что ты делал правильно, что нет.
При наличие некорого опыта очень многое из этих книжек отфильтровывается.
Здравствуйте, Vzhyk, Вы писали:
V>Поэтому и получается, что сначала надо набить шишек на парочке проектов, V>потом прочитать эти книжки и понять, что ты делал правильно, что нет.
Потом, просветленному, нужно опять набивать шишек на overdesign-е,
плюнуть на книжки, работать чтобы работало (и не стыдно было),
потом пересмотреть книги и сказать "а ведь толково написано, только я это не правильно понимал"
И этот цикл встречается много раз, супер когда этапы цикла проходят быстро, хуже когда медленно, плохо когда человек застревает на одном из этапов.
ИХМО, без книжек никак. Если есть рядом люди, у которых можно подсмотреть, посоветоваться, то хорошо, нет -- этап будет длиннее.
Здравствуйте, Vzhyk, Вы писали:
V>Код к архитектуре имеет опосредованое отношение.
Ок. Ты просто явно это не уточнил, поэтому подстраховался и на всякий случай оговорился, что такой подход работает и с кодом
Если мы говорим только об архитектуре, то можно смело сворачиваться
Тут нет гарантированно работающих рекомендаций, есть только эвристики, в большинстве основанные на личном опыте и заточенные под определённый стиль проектирования.
Я например предпочитаю действовать примерно следующим образом: перед написанием кода разобраться собственно в проблеме, разбить проблему на отдельные независимые куски (каждый из которых или делает строго одну вешь, или собирает решение из кусков помельче) и только для них пишу код.
Да, такой способ хорошо работает, по крайней мере для меня (иначе зачем мне его использовать?). Будет ли он удобен кому-то ещё — не факт.
V>Так вот по опыту получается, что лучше всего работают системы, где на каждом уровне иерархии (дерево) приблизительно не более 7 модулей.
Ок, принято.
V>Понятно, что это число не данное нам богом, но если у тебя в одном слое/уровне/модул/пространствеимен лежит рядом под 30 классов и болле, V>то разобраться в них уже очень сложно, их надо по подпространствам имен распихать.
Вот тут у меня вот не возникает проблем. Подозреваю, виноват дотнет где это обычное дело
>> Да, в хорошо написанном методе может быть с полсотни строк и это не будет вызывать проблем с чтением-пониманием кода. V>С этим все просто, метод, что занимает более 2-х экранов, нечитабелен. Это проверено на сотнях программистов. V>Лучше его разбить на несколько последовательно вызываемых.
В подавляющем большинстве случаев — да.
Были исключения, когда код из нескольких методов сливали в один и читаемость от этого только улучшалась, но это частные случаи.
Здравствуйте, IChensky, Вы писали: IC>как лучше всего именовать отдельные части приложения и как лучше всего их раскладывать по папкам.
Вряд ли здесь кто-то умеет читать мысли на расстоянии, поэтому неплохо бы указать платформу, на которой вы собираетесь разрабатывать. В рамках разных платформ используются разные способы организации кода.
Могу рассказать, например, про то, как это делается в Java.
Все Java-приложения состоят из компонентов (=библиотек, модулей), оформляемых в виде архивов специального вида — JAR-файлов. Каждый такой архив содержит в себе исполняемый байт-код (классы) и необходимые ресурсы (текстовые файлы, картинки, шаблоны документов и т.п.). В крупном приложении могут быть десятки или даже сотни таких компонентов. Организация хранения этих компонентов в папках зависит от типа приложения — Java EE, OSGi, WebStart или standalone.
Естественно, чтобы разобраться со всей этой кучей файлов, используются специальные инструменты из серии build lifecycle management. Эти инструменты управляют компиляцией исходного кода, копированием файлов ресурсов, созданием JAR-файлов, запуском автотестов и многим другим. Наиболее распространенные из них: Apache Ant, Apache Maven, Gradle.
Хотя инструменты BLM обычно позволяют вам организовывать свой исходный код произвольным образом, есть устоявшаяся система, принятая в многомодульных проектах Apache Maven:
0. В корневой папке компонента находится файл pom.xml, описывающий правила сборки этого компонента с помощью Maven (название, версия, зависимости и т.п.)
1. Весь исходный код компонента находится в папке src.
2. Основной код при этом находится в подпапке src/main, код автотестов — в src/подпапке test.
3. В этих подпапках исходный код на Java находится в папке java, ресурсы — в папке resources. Исходный код на других языках программирования находится в соответствующих подпапках.
4. Все результаты сборки сохраняются в подпапках папки target (скомпилированные классы — в classes и test-classes, архив компонента — в соотв. файле JAR и т.п.)
5. Компоненты (модули) могут быть сгруппированы иерархически в папки, например:
* myproject
* pom.xml — описание проекта, состоящего из групп модулей client и server
** server
*** pom.xml — описание модуля server, состоящего из модулей domain-api и domain-impl
*** domain-api
**** src/main/java/com/myproject/domain/model/MyEntity.java
**** src/main/java/com/myproject/domain/services/MyPublicService.java
**** pom.xml
*** domain-impl
**** src/main/java/com/myproject/domain/services/impl/MyPublicServiceImpl.java
**** pom.xml
** client
*** pom.xml
*** web
**** pom.xml
*** mobile
**** pom.xml
Код организуется по компонентам, исходя из возможности их независимого изменения и повторного использования. На диаграмме компонентов не должно быть циклических зависимостей. Нужно также различать compile time и runtime зависимости — для каждого компонента число первых имеет смысл минимизировать. Стоит при этом учитывать транзитивные зависимости: например, если слой DAL у вас использует какой-то ORM, целесообразно выделить компонент API DAL и компонент реализации. Тогда слои, использующие DAL, не будут зависеть от ORM в compile time.
Как можно видеть из примера, классы MyEntity, MyPublicService и MyPublicServiceImpl хранятся в разных папках. Это связано с тем, что в Java есть иерархические пространства имен — пакеты, которым соответствуют папки в файловой системе. Это позволяет группировать исходный код по слоям (layers — модель, сервисы, DAL, и т.п.) и функциональному назначению.
Таким образом в Java есть два способа организации кода — по пакетам и по компонентам.
On 26.04.2013 14:47, Sinix wrote:
> Я например предпочитаю действовать примерно следующим образом: перед > написанием кода разобраться собственно в проблеме, разбить проблему на > отдельные независимые куски (каждый из которых или делает строго одну > вешь, или собирает решение из кусков помельче) и только для них пишу код.
Это тип проектирования, если память не изменяет называется "снизу-вверх"
и хорошо работает, для достаточно небольших сисетм. Обычно лучше
объединять два подхода, "снизу-вверх" и "сверху-вниз". Попытаюсь
обяснить, в "снизу-вверх" система разбивается на много независимых
частей, они программируются, а потом из полученных "кирпичиков"
собирается то, что нужно. Но не всегда получается из кирпичиков собрать.
Поэтому применяют еще "сверху-вниз", когда делается сначала архитектура
без кода. В правильном варианте эти два подхода надо объединять.
Насколько помню это нам еще в универе в конце 80-х объясняли и были
какие-то книжки, сейчас, понятно, не вспомню.
Может Лаптев что подскажет из старого советского — он препод все-таки.
> Да, такой способ хорошо работает, по крайней мере для меня (иначе зачем > мне его использовать?). Будет ли он удобен кому-то ещё — не факт.
Конечно, но у него есть один недостаток, кирпичики можно и не собрать в
что-то единое.
On 26.04.2013 13:59, Aikin wrote:
> ИХМО, без книжек никак. Если есть рядом люди, у которых можно > подсмотреть, посоветоваться, то хорошо, нет -- этап будет длиннее.
Но для начала лучше сначала ввязаться в драку. Сделать хотя бы один проект.
Здравствуйте, Vzhyk, Вы писали:
V>On 26.04.2013 14:47, Sinix wrote:
>> Я например предпочитаю действовать примерно следующим образом: ... V>Это тип проектирования, если память не изменяет называется "снизу-вверх" V>и хорошо работает, для достаточно небольших сисетм.
Неа. вот это:
перед написанием кода разобраться собственно в проблеме, разбить проблему на
отдельные независимые куски (каждый из которых или делает строго одну
вешь, или собирает решение из кусков помельче)
как раз работает как проход сверху вниз, так что здесь всё ок.
V>Конечно, но у него есть один недостаток, кирпичики можно и не собрать в V>что-то единое.
Ну, да. Я подстраховываюсь тем, что кирпичики не добавляются по принципу "чтоб было", а возникают в процессе анализа проблемы. Повторюсь, работает оно _только_ если сама проблема понятна, известна и ты сам себе можешь её объяснить. Если на руках только детальный алгоритм, без самого описания задачи, такой подход работать не будет.
). Будет ли он удобен кому-то ещё — не факт.
