именно это и говориться в книге С.Макконнелла "Совершенный код", открывает по чуть-чуть глаза на какие-то детали.
В корне не верный и утопичный изначально подход. Вероятно как раз следствие того что архитектура "не преподавалась в вузе". Так вот, построение информационной архитектуры начинается не с постановки главной задачи, а формулирования целей, которых должна достигать модель и проект на её основе (На самом деле и это не первый этап проектирования, почему - будет понятно ниже). Постановка задач это уже совершенно другой этап проектирования ИА. В сумме решаемые задачи позволяют конечной системе достигать определенных для неё на этапе проектирования целей. Не смотря на наличие нескольких подходов построения ИА применимых к разным сферам и отраслям, начинать нужно не с принятия решения о том, что разработчик хочет получить, как указал тс ("магазин, блог"), а, опять же, с цели которая вместе с задачами решаемыми системой обусловлены конкретными потребностями конкретных пользователей вашей будущей информационной системы (вот с изучения потребностей как раз и начинается любая разработка. Сюда же изучение текущих бизнес-процессов если разрабатывается ИА уже под существующие процессы). И именно от этих потребностей строятся информационные объекты, связи и действия выражающиеся в том числе в публикации поста, новости или товара. И только после этого вы можете сформированную на основании требований систему обозвать хоть блогом хоть магазином хоть чем-то средним, поскольку эти понятия аморфны и не имеют точного определения или границ значений поскольку лишь называют проекты по неким общим признакам. Это принципиальный момент и если для вас то что вы написали и мое последнее утверждение одно и тоже, то пожалуйста, по крайней мере не указывайте в своем посте что ваш подход соответствует принципам проектирования информационной архитектуры.
Да, кроме неоднозначных и опасных для начинающего разработчика вещей, там есть и полезные вещи. Я не советовал тебе эту книгу именно потому, что отличить "добро" от "зла" там, для начинающего программиста, практически невозможно.
Я не могу ввязываться в теоретические споры. Вы всё правильно говорите. Архитектура - это взаимодействие компонентов системы. Формальное описание - это уже второй уровень. Сначала решают кто и с кем, а потом уже как. Одним компонентом, как правило с редкими исключениями, является один класс, который может внутри себя создавать объекты других классов, но остальную систему это не волнует, чего он там внутри себя делает и как реализован. Она знает только интерфейс нужного ей компонента. Что может у него спросить и какой ответ получить. Я это показал, просто не всё назвал своими именами. Возможно, это ошибка. Но я, как уже писал, против обильной терминологии при обучении. Мне практическая сторона важнее. Я обязательно ещё дополню текст, когда мои новички станут задавать вопросы, что не понятно или где сложности возникли. Я исходил из того, что никто не будет сидеть и долго описывать компоненты будущей системы на бумаге. Вы их ещё попробуйте заставить UML-схемы принести. Возненавидят и правильно сделают. Люди жаждут сразу писать код. Есть вещи, с которыми приходится мириться. Если они хотя бы модельку кое-как напишут и будут её использовать, а не чистую шизу гнать, я уже буду счастлив. Сразу можно вести предметный разговор на уровне двух коллег. Поэтому и предлагаю сверху вниз разрабатывать. Сначала делать то, выше чего уже не прыгнешь в данном конкретном проекте. Мне не нужны академические знания у человека. У меня нет завышенных требований к программистам. Мне нужен рабочий код, который не стыдно будет отправить заказчику, чтобы, если в будущем он обратится за поддержкой к кому-то другому, нас не поливали говном. Я искал эти слова: стихийная разработка. Не нашёл Но все самоучители готовят именно к ней.
Нет в мире совершенства, оно только в теории бывает. Всё хорошо написали, правда без конкретных практических примеров. Вот только бывают, например, ситуации, когда проект нужен уже вчера, а все устали, работая над предыдущим
Зря. Огромная экономия времени, когда сразу видишь всю систему, а не по кусочку допиливаешь, перепиливая на ходу. Вот по этому в народе устойчивая ассоциация, пхпшник=быдлокодер. Возненавидят - пусть идут на мороз. Вот по этому в народе устойчивая ассоциация, пхпшник=быдлокодер. Не хотят учиться - пусть идут на мороз. Вот по этому в народе устойчивая ассоциация, пхпшник=быдлокодер. Не удивляйтесь потом, что будет говнокод и макароны. Интересный тезис, в сумме с предыдущими составляет взаимоисключающий параграф. Вы правда думаете, что то, о чем я говорю - результат зубрежки или "где-то прочитал"? Что это я для экзамена когда-то учил, а сейчас бахвалюсь? Отнюдь. Это не "академические знания". Это как раз знания практические. С этим приходилось работать. Все, что я утверждаю здесь - плод личного опыта. Опыта достаточного, чтобы, заглядывая в свой код 5-летней давности, хвататься за голову. Я говорю о вещах, которые нужно не "знать для галочки", а понимать. Вы хотите невероятное сочетание "быстро и качественно". Обычно, ему соответствует такое свойство, как "дорого". Потому что для этого нужны высококвалифицированные специалисты. Быстро без квалификации и понимания того, о чем я говорю, можно. Качественно - нет.
Позиция тс это позиция тс. Может быть для мини-студии или фрилансера, который штампует сайты по схеме: загрузил шаблон с темплейтмонстер, установил жумлу, натянул шаблон, дописал 20 строк кода к этой очередной визитке или блогу такой подход работает. Но практика показывает и, читая тему, вижу, что не только моя — всё что посложнее и посерьезнее требует уже совершенно иного подхода во избежании провала проекта. Ничего подобного. Зелень - может быть. А все кто сталкивался с проектами сложнее описанных выше не слезут с заказчика, тимлидера и проект-менеджера пока не получат наиполнейшее задокументированное представление о том что и как будет разрабатываться ибо обратное буквально обрекает их на приключения.
Истинно так. При этом. Быстро и дёшево, но криво - это прототип, который так и надо делать. Быстро и качественно - это корпоративный сектор и цены на порядок выше. Качественно и дёшево - это то, что все постулируют, делают реально долго, а выходит всё равно говно. =) Вот реальность моими глазами.
Открою тайну: не в народе, а среди программистов. Народу без разницы, как работает их сайт. Народу, главное - красиво и удобно. А зачастую только красиво. Т.е. проектирование интерфейса для народа более значимая вещь, чем проектирование архитектуры проекта. Причём народ даже не знает про проектирование интерфейса, он знает про дизайн. У сайта должен быть дизайн. Всё. Особенно, когда речь идёт о сайте стоматологии, который вряд ли когда-нибудь придётся докручивать до, например, социальной сети или вообще хоть как-то наращивать возможности. Заниматься этим, чтобы всё было по правилам - пустая трата времени. Никому не нужная. Ни разработчику, ни клиенту, ни руководству. Правила нужны для начинающих, остальным они только вредят. Самодисциплина - это сиди и работай, а не выполняй кучу действий, которые никто не оценит. Крупные проекты - это другое. В первую очередь, это командная работа. Как люди умеют договариваться между собой, таким проект и выйдет. Сколько бы формальных требований не было выполнено. Если плохо умеют договариваться, то проект будет ужасным, пусть даже всё по правилам, как кому-то нужно и надо. Выполнение правил опыт всё равно не заменит, а время потратите. Если клиент срёт от восторга, то программист - хороший. Я его люблю, Если ругается, то программист и все остальные - плохие. Для меня программирование - это больше творчество, чем механика. Я не вмешиваюсь в работу других программистов. Каждый делает, как ему удобно. Кто-то фреймворчит вовсю, кто-то свою цмску использует, кто-то джумлой ворочает, кто-то сам по себе один в мире пхп. Я ненавижу, когда мне навязывают неудобные инструменты и сам их никому не навязываю. Но используя те инструменты, которые ты любишь будь добр делать хорошо. Ревью кода всё равно будет. Костылей никто не потерпит. Выполнение правил не даёт качества, а вдохновение и желание работать убивает. Знание, что твой код будут просматривать и задавать неудобные вопросы с целью потопить, а ты будешь при этом присутствовать, дисциплинирует гораздо сильнее, чем рисование блок-схем и порча бумаги. Вы за формальный подход, а я за творческий. Мы не сможем друг друга переубедить. Я считаю, что для "быстро и качественно" достаточно желания сделать "быстро и качественно". Пусть даже в первый раз не получится, получится во второй или третий.
У меня так arttalk умер. При чем тут договоренности. Если система спроектирована до начала разработки, вообще договариваться никому ни с кем не надо. Все будет работать так, как запланировано. За косяки в отдельных фрагментах отвечает тот, кто их писал. Он же фиксит. Я тебя умоляю. 1) Это не правила, это необходимость. 2) Убивает не это, убивает, когда переделывать приходится все 10 раз, или городить костыли. Когда идея загибается от потока этих костылей и количество проблем нарастает так, что превращает все в рутину. Вот что убивает желание работать и вдохновение. Ты пойми, что это не обряд, мол испачкай два листа А4 и будет тебе счастье. Я не за формальный подход. Я за нормальный. А ты не за творческий, а за "будь-что-будет". Как раз "пачканье бумаги" - это чуть ли не самая творческая часть в разработке. У тебя полностью развязаны руки. Нет ни классов, ни ограничений языка, нет ничего. Сиди и твори в свое удовольствие. Во всех смыслах. Без формальностей и условностей. Нарисовал систему, взвесил за и против, не понравилось, отложил, делаешь новую. Понравилось, пересмотрел старую, нашел усредненное решение с плюсами от туда и от туда. И так далее. Потом, можно так же компоненты. Ты понимаешь, что за вечер можно создать целую систему, которую осталось только написать? Видя ее перед собой, целиком. Скорость разработки и качество результата будет в разы выше, чем "как пойдет, так пойдет". Просто потому, что ты уже будешь работать на результат, который ожидаешь. И потому, что все "за и против" взвесил заранее. Что-то откинул, что-то добавил. Гораздо легче проблемы решить ДО того, как они станут частью проекта. А не осознавать их лишь тогда, когда уже будет поздно, потому что появились компоненты и фрагменты, которые ты не учитывал и без костылей это все не будет уживаться... Когда поднатореешь, рисовать не придется. Можно будет в голове все делать. Просто потому, что определенные ранее использовавшиеся и проверенные решения можно будет смело заимствовать у себя же самого, а не пилить с нуля. Я сейчас очень редко рисую. Только, если уставший, или если что-то сильно детальное нужно увидеть целиком. И пишу текстом редко крайне. Но это сейчас. Поначалу, чтобы порядок в голове был, обязательно описывал, что хочу получить и как, по пунктам. Потом алгоритмизировал абстрактно, потом кодил. Но тогда и задачи стояли в разы проще, чем теперь.
Он нигде кстати не писал кто поддерживал проект? Узнавать должны героев. ТС, ваши представления о разработке приведёт в норму первый же проект сложнее клиники стоматологии когда грабли ударят больно и будете вынуждены подарить недели рабочего времени.
Нет, я не бывший владелец сайта. "У меня так ... умер" - что-то вроде мема, основанного на "у меня так брат/сосед умер". Добавлено спустя 41 секунду: Вроде не всплывали его исполнители.
А кто её проектирует-то? Крупный проект - это всегда коллективный разум, а не формальные действия. Подходов сотни, нужна комбинация нескольких. Посчитайте сколько возможных вариантов действий при таких условиях. Ну нету алгоритма правильного программирования. Нету! Чего я могу сделать? Если бы он был... Поэтому и творчество, а не механика. Попытка его найти - это и есть жизнь программиста. Есть рекомендации, зачастую противоречащие друг другу. От уровня мастерства программиста зависит какими именно рекомендациями он будет пользоваться и будет ли пользоваться вообще. Требование, что вот эти рекомендации обязательны, а иначе у тебя не код, а быдлокод - это очень ограниченный кругозор. Что такое мастерство? Как узнать, ты достиг его или нет? Мастерство программирования - это умение делать просто. Выбирать самое простое решение. Не всегда просто и нужно или принято или требуется - это одно и тоже. И никогда не работает так, как запланировано Есть проблема. Попытка ей обойти с помощью некоторых правил убивает способность мыслить творчески. Вот десять раз напорешься на такое, почитаешь чего-нибудь, велосипед изобретёшь, а потом уже опыт приобрёл и знаешь, как не напарываться. Я понимаю, что учиться на чужих ошибках - это очень круто, но не каждый таким навыком владеет. Я не знаю, чем пользуетесь вы. Но я часто говорю на собеседованиях с фанатами отдельных фреймворков. Знаете, что ставит их в тупик? Вопрос: а почему в этом фреймворке вот эта вот хрень сделана именно так, а не иначе. И как можно было сделать иначе? А если ещё и сравнить разные подходы, то всё - труба. Поэтому нельзя учиться с фреймворков. Чужой опыт хуже своего. Люди жаждут писать код. Чем быстрее, тем лучше. Я не властен над человеческими или даже своими пороками. Мне, например, сложно настолько абстрагироваться, чтобы всю систему придумать в уме. Мой разум не способен такой объём информации перерабатывать. Оперативы не хватает. Я только по частям умею. Одну придумал, нарисовал, пишешь. Другую придумал, нарисовал, пишешь. Пока одну не напишешь, не увидишь глазами, как оно будет выгдялеть, к другим невозможно приступить. Пошаговый подход ни чуть не хуже целостного, если человеку так проще. Да, возникают определённые сложности. Но мне каждый компонент можно хорошо продумать (как с ним будут взаимодействовать), а всё вместе - нет. Не умею. Люди разные.
надо постепенно придумывать, сверху вниз. Это нормально. Придумал несколько блоков, один закодил, потом другой. Потому и надо различать стадии, когда прототип - надо писать говно и быстро. А потом, когда система проверно работает, конвеер выстроен, потоки ясны - можно уже сесть и всё расписать на бумажке, спроектировать фабрику фабрик, потому что теперь ты знаешь и понимаешь, кто от кого родится, и где и в ком лучше что держать.
Дело не в оперативе, дело в опыте. И да, вот потому и рисунки. Вообще, все контраргументы, адресованные мне в посте выше, если честно, похожи на витания в облаках. И на поиск идеалов через розовые очки. Мол "вот я представляю себе это именно так". Зул правильно сказал - это пройдет после первого же серьезного проекта. Автор, честно, сколько сложносвязных систем у вас было спроектировано с нуля? Не "one-trick-pony" сайтов с логикой, прямой как как линия заката, где можно начинать разработку прям от главной странички, дописывая хотелочки одну на одну, а именно многоуровневых, полноценных систем?