/forums/comment/227255-quote-name-wasd-post-227243-vylozhi-v-temu-voprosy-po
05.01.2016 15:11
выложи в тему "вопросы по сайту", например :>

Собственно, задался вопросом - как выглядит UML-схема хорошо спроектированной архитектуры ? Что является показателем ? По схеме можно определить отсутствие "спагетти" кода ?
Можно по подобной схеме определить слабые места (нагромождения "гавнокода") ??

К примеру, вот такая вот схема:


Программисты, сталкивающиеся с проектированием приложений, может подскажете ?


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

Программисты, сталкивающиеся с проектированием приложений, может подскажете ?


??

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227257-sperva-byla-mysli-chto-svjazi-ne-dolzhny-peresekatsja
05.01.2016 15:25
Сперва была мысли, что связи не должны пересекаться.
Но это не так - весьма зависит от расположения (компоновки) объектов на самой схеме.

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

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

Может кто-то сталкивался с архитектурными решениями, с архитектурным рефакторингом, может посоветовать литературу по этим вопросам ?

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227272-chet-kak-to-ochen-mnogo-obektov-i-svjazej-dlja
05.01.2016 18:37
Чет как-то очень много объектов и связей для банальной ленты.
/forums/comment/227293-segodnja-ja-vot-chto-naguglil-no-jetogo-ochen-malo
05.01.2016 21:00
Сегодня я вот что нагуглил, но этого очень мало - фактически ничего (ни о чем)

Name:
Хорошая архитектура приложения - отображает принципы и использование ООП.
Крайности:
** Либо когда основной код всего приложения находился в одном классе, либо наоборот,
** создавалось под полсотни классов, что для приложения совершенно излишне.

[-] отсутствие четкой архитектуры и сильная связанность всех компонентов



"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227294-quote-name-dapper-post-227272-mnogo-obektov-i-svjazej
05.01.2016 21:02
много объектов и связей для банальной ленты.

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


"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227298-dapper-jeto-ja-tak-rassuzhdenija-vsluh-mozhet-slovo
05.01.2016 21:06
dAppEr, это я так - рассуждения вслух. Может слово - за слово.. так и определим ключевые моменты для рассмотрения ?

В частности, "елка" - это схема официального приложения workout.su (что там - работа с картой, с шаблоном площадок, с сообщениями привата, профилем пользователя, и реализация нескольких экранов - тоже как-то не очень густо).
Объектов - много. То что на пакеты не разнесено - ладно,.. насколько неинформативно представление схемы без локализации пакетов ?
Как по мне, то вообще мутно все. Не зная алгоритма, не зная точки входа - малоинформативно (вообще не информативно).
Да виден EventListener какой-то (звезда на елке), который задействован во многих объектах, но уровень Application - вообще не схеме не прослеживается (а по идее сеттеты и геттеры с ним работают довольно активно)..
Опять таки, это мы подходим к анализу схемы, рассуждая об объеме задачи, которая по нашему представлению в нем реализована.

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

* чтение http-страниц (банально),
* парсер страниц на предмет определения параметров сообщения, и вложенного квотинга,
* парсер страниц форума/разделов/тем на предмет заполнения вложенных структур (разделов/тем/сообщений), определение количества страниц (для соответствующего уровня),
* реализация механизма отображения сообщений в ленту (собственно сама лента - что там: список и адаптер на кастомизацию)
* реализация циклического запроса страниц с целью определения изменений (чтобы определять и выгребать новые сообщения в ленту),
* реализация механизма проверки - а не перешло ли сообщения на новую страницу, ведь могут остаться непрочитанные сообщения на предыдущей странице,
* всякого рода "плюшки" в виде фильтров - бан на тему, автора, раздел, а также диаметральная противоположность - вынесение этого же в фавориты (отслеживание),
* подсчет статистики сообщений по пользователям (банально - но также реализовано),
* тробер,
* свайп,
* реализаця по свайпу всплывающей панели с грядкой кнопок ))
* всякая хрень типа адаптера работы с базой данных, дебага (простого логирования), еще какой-то мелочи
* всякого рода callback интерфейсы (на работу фоновых процессов по запросу http страничек, отображение троббера и связанных процессов - медиа-бряки, и еще какие-то интерфейсы - насксидку не помню),
** еще что-то - поднятие сессии авторизированного подключение через REST API, бла-бла-бла..

Да, бесспорно, классов могло бы быть на процентов 10 меньше -в нескольких случаях класс сделать абстрактным, и на его основе сделать 2 новых (в нашем случае это дало бы мину 3, ну пускай минус 5 классов на общем фоне).. Но на тот момент я вопросом архитектуры не заморачивался :(
Сейчас же схема довольно прозрачна - и по ней не видно насколько где что плохо.

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

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227302-vse-chto-u-menja-est-na-sejchas-povtorjus-quote-name
05.01.2016 21:25
Все что у меня есть на сейчас (повторюсь)

Name:
Хорошая архитектура приложения - отображает принципы и использование ООП.
Плохо для приложения - отсутствие четкой архитектуры и сильная связанность всех компонентов.

По первой строке комментариев нет. Ну разве что - полиморфизм, наследование, инкапсуляция.
Большие блоки - значит много пабликов (плохо).
Полиморфизм на схеме не проявляется (особенно если он в привате).
Остается наследование.

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

:)

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227336-nastojashhemu-ajtishniku-sobesednik-lish-otvlechenie
06.01.2016 01:21
Настоящему айтишнику собеседник - лишь отвлечение от сути размышлений... Вот нафига так париться: каждый пишет, как он дышит! Надо же, что б работало, а не для учебника:)
Скучно жить одинаково!
/forums/comment/227342-a-zachem-tebe-parsit-html-dostup-k-baze-ne-dajut
06.01.2016 04:24
А зачем тебе парсить HTML? Доступ к базе не дают? :)
/forums/comment/227353-ploho-kogda-mnogo-ko-mnogim-jetogo-nado-izbegat-kak
06.01.2016 10:56
Плохо, когда "много ко многим" - этого надо избегать. (как? - частный случай у каждого свой, практически всегда решается увеличением количества таблиц в БД. Самое главное, что бы в итоге не возникало копипаста данных).

Ну разве что - полиморфизм, наследование, инкапсуляция.
Грамотное юзание ООП - что бы не было копипаста кода. Для этого и используются указанные тобой инструменты.

Я не знаю, смогу ли помочь, ибо с вебом еще не совокуплялся, только подсказать с классами и бд. Конкретные языки знаю C/C++/C#. Остальные поверхностно, + паскаль щупал и на MySQL калякал чутка.
Don't let your dreams be dreams...
/forums/comment/227358-quote-name-dapper-post-227342-a-zachem-tebe-parsit
06.01.2016 11:47
А зачем тебе парсить HTML? Доступ к базе не дают? :)


Доступа к базе нет, API форума не писали пока.
кто не сворачивает тот дойдет (c) DoXoD
/forums/comment/227370-quote-name-zml-post-227336-kazhdyj-pishet-kak-on
06.01.2016 13:07
: каждый пишет, как он дышит! Надо же, что б работало, а не для учебника
Я раньше тоже так считал. И компаниям предлагал код для review. Код выдергивал из рабочих модулей - а что еще надо, ведь реально работает ?!
Тестовое задание делал людям - говорят "да, вроде как даже работает, но у нас есть вопросы..."
Собственно - а что не так ? Что нужно для того, что бы по просмотру кода был виден уровень, а не "говнокод", которые сегодня наваял, а завтра сам же за голову берешься - "и кто так пишет"? ))))

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

Вот и возник вопрос, можно ли по виду архитектуры проекта определить уровень программиста (/програмистов), реаилующего проект ? Приложение работает, но этого не достаточно.

Настоящему айтишнику собеседник - лишь отвлечение от сути размышлений...

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


"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227372-quote-name-zml-post-227336-nado-zhe-chto-b-rabotalo-a
06.01.2016 13:14
Надо же, что б работало, а не для учебника
Встречал устрерждение, что первая версия программы - просто работает, вторая версия - исправляются баги, допиливается архитектура для улучшения... и как правило, вторая версия хуже, чем первая. А вот третья версия - допиливается все что можно, и она уже лучше первой версии.
Также встречал, что для того чтобы написать вторую версию программы, приходится не просто править, а зачастую чуть ли не все переписывать заново, потому что изначально модель не продумана. Вторая версия базируется на переписывании архитектуры, а третья - уже строится на оптимизации второй версии.
Как-то так.

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227373-quote-name-dapper-post-227342-a-zachem-tebe-parsit
06.01.2016 13:15
А зачем тебе парсить HTML? Доступ к базе не дают?
Антон уже ответил. На пока что - вот так. По другому - без вариантов. :)

"Принимай критику только от тех, кто добился больше тебя"(c)
/forums/comment/227376-quote-name-no1imits-post-227353-ploho-kogda-mnogo-ko
06.01.2016 13:24
Плохо, когда "много ко многим" - этого надо избегать. (как? - частный случай у каждого свой, практически всегда решается увеличением количества таблиц в БД. Самое главное, что бы в итоге не возникало копипаста данных).

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


"Принимай критику только от тех, кто добился больше тебя"(c)