Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум на Исходниках.RU > Software Design > Как вы проектируете свои проги? |
Автор: p_kolya 05.03.05, 15:03 |
Здравствуйте! Ни ради опроса спрашиваю... передо мной стала проблема: нужно проектировать проги, иначе получается ерунда. Более-менее нормальная прога требует проектирования, а я с ним никак...незнаю как взяться за это дело. Потому интересует, как проектируете вы? Ну я вижу два основных способа: UML с помощью софта. Я пытаюсь сделать что-то в Visio. Насколько знаю есть еще такие: Rational Rose от IBM Sybase PowerDesigner Что лучше незнаю...но качать последние две по диалапу мне в тягость. А Visio я с поставкой VS2003 взял. Ну и есть способ проектировать на бумаге, но мне кажется это неудобным...нужно тебе вставить еще кое-что кое-куда, так тут либо снова рисовать, что проше, либо все перетирать. |
Автор: kl 05.03.05, 15:20 |
А мы не проектируем :) У нас XP in Action :)) |
Автор: p_kolya 05.03.05, 15:28 |
Цитата А мы не проектируем У нас XP in Action ) Это что? Экстремальное программирование? |
Автор: kl 05.03.05, 15:32 |
Ага.. я имею ввиду, что лично наблюдаю систему в состоянии перманентного рефакторинга, что весьма близко к идеям XP.. самое забавное, что этот подход тоже имеет право на существование |
Автор: AQL 05.03.05, 15:47 |
Эх, а за меня уже всё спроектировано. Вплоть до названия полей баз данных и их соответсвия друг другу. |
Автор: Krott 05.03.05, 17:01 |
Исключительно на бумажках. |
Автор: miksayer 05.03.05, 17:02 |
а я проектирую все в голове |
Автор: Мяут 05.03.05, 17:32 |
Нет, спроектировать ИМХО Стоит лишь взаимодействие классов... На бумажке |
Автор: .alex 05.03.05, 17:57 |
На бооольшой куче бумажек... |
Автор: Мяут 05.03.05, 18:00 |
Еще вспомнил, что суть алгоритмов тоже на бумажки записываю |
Автор: Domino 05.03.05, 18:07 |
Цитата miksayer, 05.03.2005, 20:02:14, 633876 а я проектирую все в голове Hello, world! Большой проект, особенно тот, что пишется не в одиночку, держать в голове невозможно. |
Автор: uj 05.03.05, 19:17 |
Цитата Domino @ Большой проект, особенно тот, что пишется не в одиночку, держать в голове невозможно. а я тут давеча начал прочитывать про интересную парадигму -- дизайн снизу-вверх (то, что обычно под ним подразумевается -- всего-лишь верхушка айсберга). Всем советую обратить внимание и погуглить на эту тему В частности, могу присоветовать Paul Graham "On Lisp". Там это достаточно активно... тово как-иво... |
Автор: Мяут 05.03.05, 19:19 |
Цитата Domino @ Большой проект, особенно тот, что пишется не в одиночку, держать в голове невозможно. Правильно. Поэтому его делят на модули и достаточно держать в голове интерфейс этих модулей |
Автор: exodus 05.03.05, 21:58 |
Как правило проектирую в голове, не хватает терпения задокументировать всё на бумажку - переполняет энтузиазм и поток новых мыслей (как бы сделать лучше, чтоб получилось, как всегда), в результате потом кусаю локти. На работе в плане алгоритмов документация пишется для начала, а потом пишется программа, которая мало имеет общего с документацией, так что окончательная документация пишется по готовой программе. Се ля ви... В общем, совет - позаботьтесь хотя бы о согласовании на бумаге всех интерфейсов, остальное приложится |
Автор: p_kolya 06.03.05, 15:20 |
А я тут проектированием страдаю на UML...а вы тут в голове Не... если я начну писать прогу, неспроектировав ее, то потом ТАКАЯ дурь часто получается... |
Автор: miksayer 06.03.05, 15:22 |
Цитата Domino @ Большой проект, особенно тот, что пишется не в одиночку, держать в голове невозможно. в этом ты прав, если честно я вспомнил, как пару раз проектировал что-то на бумажке |
Автор: nastenka 06.03.05, 18:31 |
я не еще не профессионал, но когда я полгода работала, то первое, что от меня требовали - анализ и дизайн софта. мне кучу книг надавали и не пускали программировать вообще, пока модели небольшой не было. я не думаю, что без планирования можно сходу создать совершенную программу. между прочим, в падении какого-то американского шатла была виной ошибка именно в дизайне софта. на лекции я пользовалась together (www.togethersoft.com), uml дает возможность посмотреть на программу "со стороны". еще я бы реркомендовала книги по анализу и моделированию, такие, как - Gamma/Helm/Johnson/Vlissides (GoF): Design Patterns, Elements of Reusable Object-Oriented Software (я думаю на русском тоже есть) - Booch/Rumbaugh/Jacobson: The Unified Software Development Process в первой есть уже готовые примеры моделирования и программирования, и следовательно не надо заново изобретать велосипед. |
Автор: miksayer 07.03.05, 07:28 |
совершенную программу сразу вообще нельзя создать - это мое мнение |
Автор: Алексей 07.03.05, 10:59 |
Да ну, перестаньте, всё проектируется либо на бумажках, либо в текстовом файле |
Автор: p_kolya 07.03.05, 15:13 |
Цитата Да ну, перестаньте, всё проектируется либо на бумажках, либо в текстовом файле Представь, если бы так проектировали Delphi 2005 .NET? Большие системы проектировать так не получится... |
Автор: Vasya2000 07.03.05, 16:32 |
Ну почему сразу "не получится"? Большие текстовые файлы и горы бумажек, бета 2005.НЕТ выходит в 2010 году |
Автор: Kutushut 09.03.05, 08:17 |
p_kolya Тебе как правильно или как по жизни получается? Очень широкие ты задал исходные данные. Давай уточняй. Лично я пока работал один - все в голове. Но когда руководишь командой (даже небольшой) - голова уже не поможет, телепатия у нас не распространена повсеместно. Соответственно, и сам рисую диаграммы UML, и других заставляю. Плюс к этому "feature list" и другие вспомогательные документы. Сам сижу на Rational Rose, а остальные рисуют в совершенно бесплатном Umbrello под пингвин. UML в нем, конечно, зачаточный, но основные идеи передать можно. Кстати, сейчас пытаюсь перейти на UP. Пока для проекта, который делаю сам для себя, возможно, как раз поэтому и плохо выходит. Но уже осознал положительные стороны прецедентов, итераций и релизов. Вопреки расхожему мнению, лишней документации UP как таковой не плодит. Ее плодят люди, которые неправильно им пользуются |
Автор: miksayer 09.03.05, 12:58 |
кстати, а где можно скачать UML? |
Автор: Kutushut 09.03.05, 13:38 |
www.uml.org ? UML - это язык вообще-то, без привязки к средствам. Где-то в этом разделе была тема, там перечислены основные среды для рисования диаграмм. |
Автор: p_kolya 09.03.05, 16:02 |
[b]2Kutushut[b], а UP - это что есть такое? |
Автор: Kutushut 10.03.05, 08:22 |
p_kolya Unified Process. Наиболее яркий и известный представитель - Rational Unified Process (RUP). Просто UP - это методика, во многом теоретическая и оставляющая на совести разработчика конкретные решения. RUP - база знаний от IBM, где написано кто, как, что и в какой последовательности делает. Но тоже можно трактовать вольно, если знаешь что выкинуть. |
Автор: Мяут 19.03.05, 17:04 |
ИМХО UML имеют три основных недостатка: С ним надо сначала разобраться. Маленькие неудобности исполнения такого программного продукта приведут к увеличению времени, ктоое тратишь на создание проги. Не всегда под рукой |
Автор: Gazon 19.03.05, 20:11 |
Проектировать надо большие проекты, которые пишутся несколькими людьми, особенно надо проектировать структуру базы, и т.д. А так проектирование(не базы данных), имхо, бесполезно. В процессе написания программы все время встречаются какие-то ситуации, в процессе которых какая-то функциональность изменяется, какая-то добавляется, другие функциональности объединяются, другие удалаются, другие разъединятся, все это влияет на интерфейс приложения(если он есть) и в итоге можно получить совсем не то, что ты запроектировал. |
Автор: Hydrogenium 19.03.05, 23:20 |
Я пользуюсь notepad.exe. Однако, у меня на работе один сотрудник делает так: Открывает IDE - создает необходимые модули - Пишет комментари - и нанизывает на них код. Сам так пробовал - какая-то дурь получилось, а ему ничего - очень эффективно. Я к тому, что мыслим мы все по-разному, и поэтому, каждому своё, кому UML, кому TXT, кому бумажки, а кому голова. Попробуй все варианты. Как тебе будет удобней так и делай в дальнейшем. |
Автор: Мяут 20.03.05, 04:26 |
Можно каждому выдать по модулю и установить единые стандарты их написания |
Автор: mikv 20.03.05, 11:22 |
Цитата Hydrogenium, 20.03.2005, 1:20:39, 651001 Открывает IDE - создает необходимые модули - Пишет комментари - и нанизывает на них код. Сам так пробовал - какая-то дурь получилось, а ему ничего - очень эффективно. Очень известная концепция. Сам такую практикую. Называется "литературное программирование". А автор ее - Доналд Кнут. Пока крупными вещами н занимался, поэтому проектируется все на бумажке. |
Автор: p_kolya 20.03.05, 15:01 |
Незнаю как вы...но я хочу научиться проектировать, ибо это надо. Я по своей дури уже не первый раз пол проги переписываю из-за корявостей моих... что-то забыл, что-то не учел. Но пока времени мало все это изучать, но проектирование изучать буду обязательно! |
Автор: Gazon 20.03.05, 16:53 |
Цитата Незнаю как вы...но я хочу научиться проектировать, ибо это надо. Я по своей дури уже не первый раз пол проги переписываю из-за корявостей моих... что-то забыл, что-то не учел. Значит либо проект такой большой, либо ты его просто неправильно структурируешь. Когда программа хорошо разбита на модули, и надо что-то поменять, то менять приходится совсем немного. ИМХО: А менять все равно что-то придется, даже если ты приложение хорошо спроектировал. Если только его проектировать очень долго и при написании ни за что не будешь отходить от плана, то может в процессе написания программы ничего не будет меняться. |
Автор: uj 20.03.05, 18:00 |
а это, по-твоему, не проектирование? хоть и в таком зачаточном виде... |
Автор: Kutushut 21.03.05, 11:31 |
Хорошо проектировать можно научиться только на основе опыта, причем по большей части своего. Попробуй освоить Test First из eXtreme Programming. Мозги встают раком довольно быстро, но если привыкнуть - научишься мыслить в терминах интерфейсов. Главное в этом деле - сначала ты пишешь как будешь использовать класс, а уже потом "под тест" пишешь интерфейс и набиваешь начинкой. При этом если ты хочешь что-то поменять - опять же начинаешь с теста. А если ты не знаешь какой интерфейс должен быть у класса - разбирайся с поведением, пробуй писать текстовые описания - что делает класс, обязанности, отношения (методика CRC). Самый прямой путь к грамотному проектированию - научиться мыслить в терминах интерфейсов. А уровень этих интерфейсов может быть любым - от системных операций (внешнее представление системы) до отдельного класса. И не забывай простое правило. "Если Вы не можете сказать это по-английски (русски, китайски... ), то Вы не сможете реализовать это в коде." |
Автор: PIL 31.03.05, 14:51 |
Не знаю как у вас, а мой заказчик не дает мне засохнуть, поэтому проэктировать что-то не возможно, по тому что в процессе разработки то интерфейс поменяеться, то концепция Я за экстремальное программирование |
Автор: chipset 01.04.05, 00:24 |
Я перепробовал много халявных UML-редакторов, и теперь все делаю в MSWord2003 Так гораздо лучше получается, ибо ты сразу: 1) пишешь спецификацию 2)проектируешь отдельные модули которые потом превращаются в реальные классы на сиппипи. |
Автор: Kutushut 01.04.05, 07:04 |
Хм... Вольная цитата из К. Бека: Для экстемального программиста процесс проектирования ведется постоянно, в начале каждого дня 10-15 минут уделяется архитектуре, в паре один из программистов проектирует, другой пишет код. Ты уверен что у тебя экстремальное программирование? Может просто это высокий темп работы + глючный заказчик? Добавлено А ворд теперь умеет рисовать UML? Или это ты про текстовые описания и блок-схемы? Добавлено Кстати, а как связан ворд с халявными редакторами? |
Автор: AQL 01.04.05, 07:09 |
Цитата Ты уверен что у тебя экстремальное программирование? Может просто это высокий темп работы + глючный заказчик? Доработка ТЗ в процессе работы - вещь традиционная, но если приходится менять более 50% архитектуры - гоните в шею писателя ТЗ. Или плотнее работайте с заказчиком. |
Автор: Kutushut 01.04.05, 08:20 |
Цитата AQL @ Доработка ТЗ в процессе работы - вещь традиционная, но если приходится менять более 50% архитектуры - гоните в шею писателя ТЗ. Или плотнее работайте с заказчиком. В точку! Есть правда еще один вариант - заказчик не заинтересован в получении результата. Может не хочет платить денег, может сам не знает что ему надо. Самый плохой вариант - когда ТЗ нет и заказчик выступает заодно в роли руководителья проекта без должного опыта. С таким хоть живи вместе - все равно толку не будет. Да что говорить - все итеративные подходы основаны на том, что в процессе работы мы все ближе подходим к "правильному" устойчивому состоянию. В XP колебания могут быть очень значительными, но все равно со временем все устаканивается и лихорадит не весь проект, а отдельные части (те же гуи). Так что уточнение - менять 50% архитектуры - это где-то середина срока разработки. В начале она может меняться очень значительно, а в ночь перед сроком сдачи даже 10-15% могут все на фиг поломать... |
Автор: PIL 01.04.05, 08:30 |
AQL, Kutushut - вся проблемма в том, что писатель ТЗ - правая рука заказчика... Поэтому приходиться мучиться, скрипеть зубами и переписывать.. Деньги платит, я готов писать хоть год проэкт на 2 месяца, только работы немного жалко... |
Автор: Kutushut 01.04.05, 08:34 |
Дык тогда вопросов нема. Сам в принципе на похожих основах сижу - любой каприз за зарплату. Тоже не счастлив от этого. Так что считай - коллеги. |
Автор: chipset 01.04.05, 08:45 |
Да, про них.. Мне большего не надо, пока Word у меня на компьютере всегда Кроме того, он у твоих партнеров по тиму есть, а уговорить их поставить Rational Rose - задачка интересная но трудная. |
Автор: Kutushut 01.04.05, 08:58 |
Это гуд. На самом деле если начать разбираться в этой кухне - прецеденты без диаграмм намного ценнее чем диаграммы без прецедентов... Да и вообще в последнее время часто всплывает фраза "Если вы не можете это сказать по-английски (русски,...), то вы не сможете это запрограммировать". Цитата chipset @ Кроме того, он у твоих партнеров по тиму есть, а уговорить их поставить Rational Rose - задачка интересная но трудная. Можно давать им снапшоты или печатать и давать в руки. Сложнее с тем, что их еще и UML надо обучать... |
Автор: chipset 01.04.05, 09:22 |
Цитата Kutushut @ Да и вообще в последнее время часто всплывает фраза "Если вы не можете это сказать по-английски (русски,...), то вы не сможете это запрограммировать". Солидарен C редактированием проблема... ... И вообще, взять бы да заставить всех делать словесную и математическую постановку задачи по госту |
Автор: fantasmagoriya 04.11.08, 17:02 |
можно скачать триал-версию с www.magicdraw.com я думаю, среди твоих знакомых найдется хоть один человек с анлимом, который тебе качнет MagicDraw UML. Насколько я знаю есть еще бесплатные дистрибутивы. позволяющие создавать бизнес-логику...Вообще, если есть возможность, попробуй найти у кого-нить Rational Rose. По крайней мере на сегодняшний день, это лучший программный продукт для таких целей. Может быть получится найти:) по крайней мере у меня получилось:) p.s. uml - это все-таки лучше блокнота))) поскольку ты можешь увидеть работу системы в целом, а не запоминать кучу всякой ерунды, которую может быть еще надо будет забыть и придумать заново:) |
Автор: vk 04.11.08, 19:59 |
Только достать трудно. А демо-версии многого не умеют. Ещё JUDE хорошая штука, её найти проще. Умеет кое-что, что не умеет Rational, но не умеет кое-чего, чего умеет Rational. Если есть возможность, лучше иметь обе |
Автор: rockbear 25.11.09, 14:57 |
А что такое прецеденты? можно небольшой пример? ) |
Автор: Flex Ferrum 25.11.09, 15:07 |
Прецеденты (иначе говоря Use Cases) - это варианты использования проектируемой системы. Например, "Регистрация пользователя в системе" - это прецедент. "Получение выписки по счёту" - это прецедент. И т. п. Внутри каждого прецедента может быть определено несколько возможных сценариев (типовой сценарий, альтернативные сценарии, обработки ошибочных ситуаций и т. п.) Но все эти сценарии должно объединять то, что они выполняют строго определенную бизнес-функцию. |
Автор: tensor 25.11.09, 15:07 |
http://library.mnwhost.ru/doc/UML_HTM/gl_17.htm |
Автор: kosten 26.11.09, 07:35 |
для проектирования сайтов используем SketchFlow |
Автор: Mr.Delphist 03.05.10, 13:27 |
Записываем: MS Word - халявный UML-редактор |