Добрый день, Хотелось бы узнать какие у кого методики проектирования своих приложений? Сколько Вы на это отводите времени из общего проекта? При разработке официальных проектов как Вы описываете архитектуру приложения? Как часто у Вас бывает так, что после разработки 50% приложения приходится писать чуть ли не с нуля, из за того что меняются требования, или что-то не было учтено? Поделитесь великие гуру как правильно (и 100% верно) разрабатывать проект приложения. P.S. Стив Макконнел - Идеальный код, хорошая книга по этой теме, но не в том формате в котором хотелось бы.
Я, конечно, не гуру, но хочу поделиться как это делаю я. Изначально, когда уже определена тематика сайта, я продумываю, функциональность. Что будет присутствовать на сайте, как это будет работать. Потом рисую "дизайн", делаю шаблон и продумываю мелочи вывода. Далее приступаю к написанию главного обработчика, а потом делаю разделы. Бывает, что возвращаюсь к истокам и что-то улучшаю. Главное - расписать на бумаге все на стадии проектирования, вплоть до структуры таблиц. Тогда наглядно можно продумать все более тщательно.
Я тут листаю книгу: там немного раскрывается эта тема. Вот кстати вопрос так же к гуру, как часто они используют UML насколько это удобно в разработки и не отнимает ли процентов 30% общего времени? и вообще кто нибудь его использует?
Kreker А как боретесь с расширяемостью? Бывает ведь так что проект запущен, а через 3 месяца у заказчика куча новых фишек которые он хочет видеть на сайте. Причем по закону подлости бывает так, чтобы добавить какую-то фишку приходится перелопатить кучу кода (+ потом еще из-за этого могут выйти косяки). Hawk ИМХО работать по готовым UML диаграммам очень очень удобно, а вот разработка UML дело конечно муторное (проще накидать на ватмане карандашем ). Как-то сталкивался, промучился довольно долго (хотя скорее всего потому что до этого никогда сам схемы не составлял).
Быть с заказчиком откровенным, держите его в курсе, обусждайте с ним (на понятном уровне) реализацию той или иной фичи что бы он смог расставить приоритеты. Если он дополняет/изменяет требования укажите на проблемы которые могут возникнуть. Грубо говоря, заказчик платит вам за часы. Сделайте эти часы эффективными для него и для вас.
В твоём случае лучше подойдёт OOP + XP imho. Если заказчик не может определиться что понадобится через 2 месяца, то классический unified метод разработки неэффективен.
Amian Пока рассматривается общий случай а не конкретно мой =) В смоих проектах я итак использую ООП. Только причем тут XP??? Я так понял это вообще маст-дай? Или я ошибся? P.S. И вообще если почитать первое сообщение темы, то я просто хотел узнать как проектируют другие программисты, а не слышать кучу советов.