Средства для проектирования софта

Листик бумаги.

И что ты пишешь/рисуешь на этом листике?

Эдакие схемки, алгоритмы, формулы, диаграммы и т.д., и т.п. Иной раз сотню листов исписываю, пока чего-нибудь годного придумаю.

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

А еще я иногда сначала пишу документацию в тех-е, и кодить начинаю только когда получилась внятная документация - это вообще бумаги не требует;-)

Мы для этого используем доску с разноцветными маркерами

Дешевле бумагу использовать. Кто мне эту доску купит, да еще и по маркеру-два в неделю?

Экономьте бумагу!

Зачем?

я иногда сначала пишу документацию в тех-е

Я тоже иногда ТЗ сначала придумываю. Но получается хреново. Лучше наоборот делать: сначала что-то делаешь, а потом уже к этому делу ТЗ рисуешь и документацию ☺

Кстати, ты, похоже, первый программист, отписавшийся здесь.

Или все сразу начинают писать код, а логику продумывают на ходу?

Нет, так точно нельзя делать.

А так, да, тоже бумажки, как у Эдди.

Можно еще начинать с UML-схем.

Trac, Redmine, Dia, FreeMind

Я тоже на бумаге продумываю. Точнее в большой тетради формата A4. На развороте обычно слева схемы и «рисунки», а справа описание, формулы и наброски кода.

Я раньше более-менее окончательные варианты в тетрадку переносил. А теперь — в ЖЖшке пишу ☺

ТЗ -> Тесты -> Реализация ;)
да что там средства.. реально упрощает проектирование применение определенных методик, а уж какими средствами ты их применишь.. ;)

В которых можно продумать всю логику до мелочей, а уже потом переписать её в код ЯП.

это «поход на фейл», ибо не продумаешь

Или все сразу начинают писать код, а логику продумывают на ходу?

анализируется предметная область, взаимосвязи и процессы, пишется feature-list, крупно архитектура, планируется первая иерация - и вперёд к победе

реально упрощает проектирование применение определенных методик

Ну меня собственно методики и интересуют. Вот UML-схемы заинтересовали.

Кто мне эту доску купит, да еще и по маркеру-два в неделю?

А хранты на что? Какой же ты грантоед, если у тебя нет доски с маркерами? Маркеров купили в том году 100шт что ли (все равно кроме как на расходники и ЗП у нас деньги хрен на что потратишь), теперь главное выкидывать негодные... я хочу ввести маркерный баскетбол - попади негодным маркером в корзину на другом конце комнаты! Со стерками с доски кстати проблема большая чем с маркерами...

Я тоже иногда ТЗ сначала придумываю. Но получается хреново. Лучше наоборот делать: сначала что-то делаешь, а потом уже к этому делу ТЗ рисуешь и документацию

Если говорить про моделирование, то если ты не можешь внятно описать (с числ схемой) что собираешься делать, значит ты не можешь этого сделать. Я со студентов и себя требую сначала текст, потом код. Ну и при сдаче отчетов - времени часто нету, поэтому пишешь отчет о том как все работает, потом делаешь;-)

Кстати, ты, похоже, первый программист, отписавшийся здесь.

О_О? Я кто угодно, только не программист...

А хранты на что?

Я и так потребляю неплохо: то мне электронику подавай, то железо какое, то еще что. А доску еще и элементарно вешать-то куда-то нужно. Вообще, мне кажется это неудобным.

Если говорить про моделирование

Не, про воплощение в железе. Иной раз мысля приходит лишь в процессе разработки.

Я кто угодно, только не программист...

Значит, пока что программисты в эту тему не заглядывали.

А доску еще и элементарно вешать-то куда-то нужно. Вообще, мне кажется это неудобным.

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

Иной раз мысля приходит лишь в процессе разработки.

А если не приходит херачишь молотком по плате с криками «опять не получилось»?;-))))

Значит, пока что программисты в эту тему не заглядывали.

Shty вообще то как раз рулит проектами, и все правильно написал - я тоже примерно так делаю, тока этого не осознаю, поэтому и не рулю проектами;-)

анализируется предметная область, взаимосвязи и процессы, пишется feature-list, крупно архитектура, планируется первая иерация - и вперёд к победе

Расскажи по подробнее, что такое feature-list, первая иерация?
Есть литература по теме?

А в плане поругаться (со стиранием аргументов оппонента и рисованием от себя своим цветом) ничего лучше нету!

Согласен. Но у меня пока что и ругаться-то не с кем. А к начальнику ходить со своей доской как-то неудобно.

А если не приходит херачишь молотком по плате с криками «опять не получилось»?;-))))

Бывает.

Да вы там богато живете! У нас все ютятся в 2х комнатах, стульев и компов уже не хватает...

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

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

ну не в плане сразу разрабатывать а сразу наброски лепить

доску еще и элементарно вешать-то куда-то нужно

можно пленкой специальной стену обклеить, и на ней теми же маркерами рисовать.

Зачем далеко идти? Почему бы не рисовать сразу по монитору?

feature-list - это перечень вещей, которые программа должна уметь с точки зрения заказчика (например - открывать pdf, варить кофе, и т.д.)

первая итерация - это, собственно, начало разработки, здесь подразумевался итеративный подход к разработке, когда разработка ведётся итерациями, каждая длительностью по 2-3 недели (существенно: в конце каждой итерации должен получаться рабочий код)

книжка вот мне нравится

Или все сразу начинают писать код, а логику продумывают на ходу?

Нет, так точно нельзя делать.

Восходящее программирование.

разработка ведётся итерациями, каждая длительностью по 2-3 недели

Привет agile-методологии?

И насколько это действенно на практике? А то нам в универе про это рассказывали, но как-то не зацепило...

Сам я в небольшой компании работаю, соответственно ничем таким не пользуемся...

Или все сразу начинают писать код, а логику продумывают на ходу?

Нет, так точно нельзя делать.

Восходящее программирование.

Подходит для helloworld'ов и прочих студенческих лаб.

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

Здравствуй!

Желательно перед кодированием формализовать перечень требований к системе (лучше в виде ТЗ) и написать постановки задач, решаемых ею. Постановка задачи должна максимально четко формализовать ее оперативно-тактический смысл, периодичность ее решения, список лиц, в интересах которых она решается, а также содержать перечень входной информации, выходной информации и описание алгоритма формирования выходной информации на основе входной.

Погляди в сторону UML. Определенные диаграммы этого языка позволяют обозначить требования к системе и задачи, ею решаемые, являясь отличным дополнением к постановкам задач. Другие диаграммы регламентируют структурную схему ИС, свойства и характер взаимодействия входящих в ее состав компонент и другую архитектурную информацию. UML-инструментов много - гугл в помощь.

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

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

Или все сразу начинают писать код, а логику продумывают на ходу?

Нет, так точно нельзя делать.

Восходящее программирование.

Подходит для helloworld'ов и прочих студенческих лаб.

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

Далеко не все будут согласны с тобой. Например, у лиспов это рекламируемая фишка, на которую сильно напирают (см. проспекты LispWorks). Еще восходящее программирование хорошо ложится на хаскель и форт. Здесь ФП еще сильно способствует (к форту не относится). Языки без REPL типа Си++/Java/C#, ясное дело, оказываются в пролете.

Еще добавлю о роли ФП здесь. Стиль ФП заставляет по возможности использовать иммутабельные структуры данных. Это значительно облегчает отладку в REPL. Хотя некоторые (слегка ограниченные) лисперы кичатся тем, что знать не знают ФП, на самом деле следование стилю ФП повышает продуктивность программирования на лиспе при восходящем методе проектирования, а это основной метод в лиспе. Этому также способствует инкрементальная компиляция. Но все это темные материи для программиста Си++ :)

http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

ы?

Привет agile-методологии?

привет :)

И насколько это действенно на практике?

хорошо работает

Сам я в небольшой компании работаю, соответственно ничем таким не пользуемся...

от размера не зависит (при N > 3), на большом размере даже посложнее

Но все это темные материи для программиста Си++ :)

Не, я кое-что в этом пониманию, так как пишу еще и на Эрланге, который тоже ФП, REPL в нем тоже есть.

Но философия разработки на императивных языках въелась глубоко, поэтому и на ФП языках подход к разработке остается практически прежним :)

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

из современных, много разных подходов применяют в ruby (не пользую, но наслышан).
Например:
http://en.wikipedia.org/wiki/Scaffold_(programming)
Многие после руби переносят выработанные практики на другие платформы.

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

В которых можно продумать всю логику до мелочей

Это то, на чем застревают сразу-же при начале проектирования. Правильней будет отказаться от этой затеи. Важно осознать и помнить, что серебряной пули нет. Более правильно найти оптимальную стратегию из имеющихся в распоряжении. Решать проблемы по мере их проявления, а не предусмотреть все возможные варианты: более правильный подход. Хотя не идеальный.

На мой взгляд есть ряд практик, хорошо себя зарекомендовавших для современности:

Проектирование интерфейсами (тот который выглядит как «класс»
например : http://en.wikipedia.org/wiki/Interface_(Java)) (самая внятная статья на эту тему (не про яву): в книге «банды четырех»)

(Функциональная) декомпозиция.

Различные средства быстрого прототипирования, включая в умеренных дозах TDD и его развитие. wireframing. Но самое лучшее средство: блокнотик))

от размера не зависит (при N > 3)

Ну когда над проектом работают 2 человека (причем над двумя слабо связанными его частями), agile не нужен, имхо =)

хорошо работает

Что ж, возможно, когда-нибудь и нам пригодится, спасибо.

Макконелл одобряет карандаш и лист бумаги :)

Бумажки, наше фсё. Три чая господину.

Ну когда над проектом работают 2 человека (причем над двумя слабо связанными его частями), agile не нужен, имхо

agile - он не говорит тебе делай вот здесь так, а здесь так, он говорит - делате так как вашей команде удобнее

uml

swwwfactory

Важно осознать и помнить, что серебряной пули нет. Решать проблемы по мере их проявления, а не предусмотреть все возможные варианты: более правильный подход.

Золотые слова