Проектирование сайтов - Rapid Application Development (RAD) для сайтов / rapid application development web - Comments

Может быть. Но

Дмитрий Сергеев — Thu, 12 Jul 2007 15:14:50 +0400

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

А для того

Васильев Артем — Thu, 12 Jul 2007 15:00:58 +0400

А для того существует контроль качества, сделал плохо, переделай.

[Представь, ты говоришь людям: «Вот вам два проекта, работаете посменно. Если выберете любимый, можете не меняться».]

Если так сказать, то точно по вашему получится.
Это вопрос индивидуальный.

Тут могут

Дмитрий Сергеев — Thu, 12 Jul 2007 14:49:39 +0400

Тут могут возникнуть проблемы с дисциплиной. Представь, ты говоришь людям: «Вот вам два проекта, работаете посменно. Если выберете любимый, можете не меняться». Программеры, чуть что, будут менять «любимый проект» и бегать туда-сюда. У них всегда будет лазейка: сделал плохо -- перешел в другой любимый проект.

Возможно

Васильев Артем — Thu, 12 Jul 2007 14:17:34 +0400

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

Согласен. Вот

Дмитрий Сергеев — Thu, 12 Jul 2007 14:07:23 +0400

Согласен.

Вот еще минус придумал: у некоторых программистов наверняка появится любимый проект. И тогда полдня он будет вдохновенно работать, а еще полдня ждать следующего раза. Не получится ли так, что один из проектов будет делаться спустя рукава?..

Названы минусы,

Васильев Артем — Thu, 12 Jul 2007 14:03:07 +0400

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

Альтернатива

Сергей Кочанов — Tue, 13 Mar 2007 14:01:11 +0300

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

Спасибо,

Дмитрий Сергеев — Tue, 13 Mar 2007 13:17:13 +0300

Спасибо, почитаю. Выглядит многообещающе.

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

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

В любом случае

Сергей Кочанов — Tue, 13 Mar 2007 12:04:38 +0300

В любом случае придется разделять тех, кто "играет в кубики" и тех, кто эти кубики "создает". Ибо квалификация разная нужна и совмещать ее нецелесообразно. Предвкушаю Ваше возражение на данный счет по поводу того, что системы, порой, бывают очень сложные. Но это не отменяет сию концепцию. В любом случае любой, даже самый сложный проект, можно разбить на составные блоки - те самые кубики, как и сколь угодно сложную функцию на конечное число элементарных функций (с известной долей приближения есс-но). Блоки эти со временем накапливаются и существуют уже практически на 90% случаев из жизни. Не зря ведь люди придумали ООП и повторное использование кода. На сему вопросу ОЧЕНЬ рекомендую прочесть книжечку http://www.books.ru/shop/books/25950. Как раз она очень полезна при разработке сложных систем.

Даже притом,

Дмитрий Сергеев — Tue, 13 Mar 2007 09:47:38 +0300

Даже притом, что базовые методы уже давно написаны, постоянно появляется что-то новое.

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

В этом и интерес. Разработчик развивается, постоянно учится. Если бы этого не было, сайтами бы занимались только роботы-сборщики.

Свои проекты по

Кочанов Сергей — Tue, 13 Mar 2007 09:29:50 +0300

Свои проекты по идее и не должны никогда заканчиваться, а просто обязаны постоянно совершенствоваться. Что же касается сложных сайтов, то это смотря с какой стороны посмотреть. Реализация логики может быть и сложной, но в итоге задача сводится лишь к генерации данных для страницы и рендеринга ее из шаблона представления. Свойств у страницы не так много. Сильно упрощая, конечно, меняются только пара-тройка свойств. По сути, есть класс, генерирующий страницу. Для реализации ЛЮБОГО функционала необходимо лишь наследовать базовый класс и перекрыть функцию генерации страницы. При этом все сопутствующие базовые функции уже реализованы в родительском классе. В этом и преимущество ООП со всеми вытекающими. Какой бы сложной не была структура данных, базовые функции формирования страниц в 90% остаются неизменными (построение меню, хлебных крошек, набора информационных блоков и etc). Т.е. в моем случае построение страницы производится автоматом, необходимо лишь правильно организовать наборы данных.

Мы, наверное,

Дмитрий Сергеев — Tue, 13 Mar 2007 01:03:10 +0300

Мы, наверное, делаем разные сайты :) У меня в последнее время что ни проект -- так серьезная база данных, в которой полно связей "многие ко многим". Такие структуры сложно вписать в какую-нибудь CMS. И приходится выдумывать разные штуки.

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

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

А на счет "Лего" вы правы. Вот захотел я себе блог, взял Drupal и настраиваю под себя. Правда этот тюнинг длится уже четвертый месяц и конца не видно. Эволюция :)

Млин, ребята,

Кочанов Сергей — Mon, 12 Mar 2007 23:29:58 +0300

Млин, ребята, читаю я вас и складывается впечатление, что вы каждый сайт с нуля начинаете писать. Вы в каком веке живете? 95% сайтов по функционалу похожи как близнецы. Я сайтами начал заниматься лет 5 назад. Сначала появился класс доступа к данным, который использовался в каждом проекте. Позже появилось еще куча всяких классов и модулей. Теперь в 80% случаев программирование заключается в игру с конструктором "Лего". Больше времени уходит на верстку и написание шаблонов представления. Когда есть уже куча модулей, которые и составляют движок сайта, программистов можно разделить на системщиков и прикладников. Первые пишут недостающие модули, вторые ими пользуются. Вот и не будут уставать люди, потому что больше 3-5 дней над одной задачей не работают. А сайт делкется по такому принципу за 3-4 дня, в зависимости от сложности верстки (при условии, что дизайн уже отрисован).

Есть еще и

Дмитрий Сергеев — Thu, 15 Feb 2007 12:20:17 +0300

Есть еще и платные компоненты. Иногда к ним стоит присматриваться. Например, CodeCharge. Как-нибудь посмотрю демку.

У меня в хорошие дни получается качественно писать код часа четыре подряд.

Однажды приснился кошмар: я отлаживал форумный движок, а он всё не работал и не работал. Проснулся в холодном поту.

Использовать

Mr. Mishin Oleg — Thu, 15 Feb 2007 12:11:53 +0300

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

Кстати, 2 часа программирования в день про !кодера! - это очень мало. Для проектировщика - допустимо.

А про сны.... - согласен, случается =)

Rapid Application Development (RAD) для сайтов / rapid application development web

Дмитрий Сергеев — Tue, 13 Feb 2007 11:16:41 +0300

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