LINUX.ORG.RU

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

anonymous ()
Ответ на: комментарий от Pups

Если вам подойдёт совет от неархитектора, то есть такой замечательный сайт, где можно посмотреть альтернативы вашей программы: https://alternativeto.net/software/enterprise-architect/?license=opensource&platform=linux

kogoth ()

На самом раннем этапе даже какой-нибудь VYM может иметь место быть, если задача слишком велика и не помещается в голову, а находится на уровне идеи/брейншторма. Но это больше про свои ресёрч проджекты, в проде с таким делать нечего. В совсем маразматичной проде обмажутся idef (больше всего idef0)/UML и вперёд и с песней (при том, чем хуже индусы и больше говнокода, тем больше UML будет вылезать из каждой щели). Прототипируется на питоне обычно, если есть готовые библиотеки которые можно заюзать быстро и которые известны тебе и команде. Из свободного и бесплатного что с натяжкой можно юзать в линуксе это dia и umbrelo. Но я не архитектор, юзал их для себя немного, когда было очень туго.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Но я не архитектор, юзал их для себя немного, когда было очень туго.

От чего же?
Раз проекты разрабатываете, то лучше создавать для них хорошую архитектуру.

Владимир

anonymous ()
Ответ на: комментарий от bvn13

Это не совсем то. Они на той программе пытаются объяснить основы ООП + пару паттернов, + проектирование. А так, чисто для набросков (по моему большего и не надо) программы хороши.

Pups ()
Ответ на: комментарий от anonymous

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

Pups ()

Я использую ручку с бумагой и говорение. В документах рисую только bpmn/idef схемы. Результатом этого является задача которую пограммист сам записывает в гиталаб или на бумажку. Дальше чем на неделю задачи не ставлю.

Но я не архитектор, так, рукамиводитель.

system-root ★★★★★ ()

для создания типовых архитектурных паттернов используем все что под руку попадется. на выходе все равно нужен powerpoint, загруженный в confluence. затем внедряем, посредством вливания информации в головы коллег, и код пишем по типовым шаблонам. при написании консультируемся с тем же powerpoint/wiki, и подсматриваем в соседние модули. см. всякие VIPER, VIP-clean, MVVM, и прочие.

waker ★★★★★ ()

Тетрадь, карандаш + ластик, капиляры, ручки иногда линейки полезны. Из ПО использую заметки в cherrytree и графы можно писать в .dot разметке, но прямо скажу бумагу и карандаш ничто не превзошло по удобству(доска с стирающимися маркерами тоже бывает удобна), но .dot тоже классная вещь, особенно если запариться с разметкой и оформлением.

AKonia ★★ ()
Последнее исправление: AKonia (всего исправлений: 2)
Ответ на: комментарий от AKonia

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

Pups ()
Ответ на: комментарий от Pups

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

AKonia ★★ ()
Последнее исправление: AKonia (всего исправлений: 1)
Ответ на: комментарий от AKonia

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)