Как правильно писать софт

← →
djaUser (2008-04-04 00:11) [0]

Кто реально занимается разработкой серъезных программ подскажите пожалуйста, с чего обычно следует начинать: или полностью прорисовать интерфейс со всеми бебехами а потом браться за код или вначале полный функционал написать, а потом уже думать о дизайне?

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

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

Буду благодарен за любой ответ\мнение :)

← →
Andy BitOff © (2008-04-04 00:25) [1]

На счет, что сначала - тут сейчас начнется холивар =) ИМХО, как удобнее.

На счет функцианала, так здесь и лучше и проще "сразу продумать на листочке весь алгоритм, все связи и т.п."

← →
korneley © (2008-04-04 00:36) [2]

> тут сейчас начнется холивар =)

Всё и сразу. Но в первую очередь - архитектуру. Чтобы не было мучительно (потом) больно. И все равно, версии к, один с половиной, всё переписывать придётся :) Потому, что задумывали, не зная до конца предметной области. Кстати, с неё и надо начать. Чтоб не было:
-Бывает?
-Нет! Ну, разве,что, очень редко...

← →
DrPass © (2008-04-04 00:43) [3]

← →
djaUser (2008-04-04 00:43) [4]

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

значит буду думать сразу, но тут, как всегда, наверное про треть функционала даже не подозреваю что она будет)

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

← →
Loginov Dmitry © (2008-04-04 00:56) [5]

> Кто реально занимается разработкой серъезных программ подскажите
> пожалуйста, с чего обычно следует начинать: или полностью
> прорисовать интерфейс со всеми бебехами а потом браться
> за код или вначале полный функционал написать, а потом уже
> думать о дизайне?

интерфейс "со всеми бебехами" никому не нужен. Красота - в последнюю очередь (если конечно речь идет не о Web-дизайне). Главное - это удобство, надежность, функциональность и производительность. Если этого нет, то на красоту никто не посмотрит. Всегда старайся минимизировать количество утраченных нервных клеток пользователя, работающего с твоей программой.

← →
DrPass © (2008-04-04 01:04) [6]

> Красота - в последнюю очередь (если конечно речь идет не
> о Web-дизайне). Главное - это удобство, надежность, функциональность
> и производительность

Ну а тут можно спорить и спорить. Красивый - еще не значит, что удобный. Однако некрасивый - почти гарантированно неудобный. Убогая внешне программа, будь она триста раз надежна и функциональна, сожрет нервных клеток не меньше, чем красивые окошки с кривой реализацией.
Да и функциональность очень часто обратно пропорциональна надежности...

← →
oldman © (2008-04-04 01:07) [7]

> Кто реально занимается разработкой серъезных программ подскажите
> пожалуйста, с чего обычно следует начинать

1. ТЗ
2. алгоритмизация, блок-схема и т.д.
3. мат-код
4. дизайн-код
5. собственно дизайн в соответствии с ТЗ
6. хелп
7. пиво, подарки, зарплата, поцелуи (возможно плевки, пинки, проклятья)
8. ТЗ на доработку, корректировку, исправление багов
9. goto 2

← →
Loginov Dmitry © (2008-04-04 01:12) [8]

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

Какое-то жуткое сочетание получается: убогая внешне, удобная, надежная, функциональная. Довольно трудно представить :)

> Да и функциональность очень часто обратно пропорциональна
> надежности...

нужно стремиться к надежности!

← →
djaUser (2008-04-04 01:19) [9]

Насчет красоты DrPass"а поддерживаю.
Тот же fooBar, сколько раз ставил, но из-за простоты интерфеса все равно использовал другие плеера.
Да и вот кстати писал бы свой плеер, начал с дизайна, когда уже все нарисовал и половину кода слепил тут же начали вырисовываться новые желаемые требования, например увеличить полосы эквалайзера и т.п. и пришлось перерисовывать все. Но с другой стороны и код начинать писать, когда все голо и для теста стандартные убогие визуальные компаненты берешь то же не удобно. Дилема прям..

← →
Ega23 © (2008-04-04 01:20) [10]

с ТЗ надо начинать, с ТЗ.

← →
djaUser (2008-04-04 01:22) [11]

oldman, извиняюсь, забыл написать что сам пишу и сам себе так сказать ТЗ в голове даю... и конечно же и в данном случаи будет goto 2 ;)

← →
Германн © (2008-04-04 02:06) [12]

> djaUser (04.04.08 01:22) [11]
>
> oldman, извиняюсь, забыл написать что сам пишу и сам себе
> так сказать ТЗ в голове даю

В таком случае это не подходит к "разработке серъзных программ".
Серьёзные программы нынче редко пишутся одиночками.

← →
Семеныч (2008-04-04 05:22) [13]

> djaUser (04.04.08 00:11)

1. Кто реально занимается разработкой серъезных программ, начинают с написания документа под названием "ТЗ" или "Постановка задачи". В нем оговаривается функционал, а если надо - то и интерфейс тоже. И если этот документ еще и будет подписан заказчиком, то совсем хорошо.

2. Кому нужна красивая программа, если функционально она делает не то и/или не так, как должна?

Кому нужна НЕкрасивая программа, если функционально она делает именно то и именно так, как должна?

Так что функционал важнее. А бантики можно привесить и позже.

← →
Wood (2008-04-04 06:48) [14]

Скажите, плз, а поддержка тем Win.XP (обязательное включение в проект ХPmanifest) это "бебеха"?

← →
Loginov Dmitry © (2008-04-04 07:55) [15]

> Насчет красоты DrPass"а поддерживаю.
> Тот же fooBar, сколько раз ставил, но из-за простоты интерфеса
> все равно использовал другие плеера.

плеер это разве "серьезная программа"? Их как грязи! Только ленивый их не пишет! И отличаются они только красивым интерсейсом, а функциональность у всех сходная (и все поголовно требуют каких-то кодеков ;)

> [14] Wood (04.04.08 06:48)
> Скажите, плз, а поддержка тем Win.XP (обязательное включение
> в проект ХPmanifest) это "бебеха"?

скорее нет, чем да.
К примеру в Delphi2007 ХPmanifest всегда встраивается в приложение, но поскольку все компоненты с ним ведут себя корректно, то отключать его нет смысла (в Delphi7 отображение многих компонентов при подключении ХPmanifest портилось).

← →
Смирнов (2008-04-04 08:06) [16]

> поддержка тем Win.XP (обязательное включение в проект ХPmanifest)
> это "бебеха"?

сами темы ХР - это "бебеха" от MS.

← →
TUser © (2008-04-04 09:08) [17]

> Какое-то жуткое сочетание получается: убогая внешне, удобная, надежная, функциональная. Довольно трудно представить :)

консольные

← →
tesseract © (2008-04-04 10:13) [18]

> или полностью прорисовать интерфейс со всеми бебехами а
> потом браться за код или вначале полный функционал написать,
> а потом уже думать о дизайне?

Нарисовать классовую структуру, расписать функционал. Интерфейс в последню очередь продумываеться.

← →
Torry © (2008-04-04 10:35) [19]

Начинать надо с иконки и диалога "About", все остальное - от лукавого :-)

← →
DVM © (2008-04-04 10:45) [20]

> интерфейс "со всеми бебехами" никому не нужен.

Неправда это. Интерфейс для конечного пользователя играет не меньшую роль, чем функционал. Не думаю. что пользователю сильно понравится суперфункциональная программа, где все действия требуется задавать, например, ключами в командной строке.

← →
Kolan © (2008-04-04 10:48) [21]

Устройся на работу.

← →
Alkid © (2008-04-04 11:09) [22]

> Устройся на работу.

Поправлю - устройся на работу в ХОРОШУЮ фирму, где тебя научат чему надо, а не загубят невинную душу. Рекомендую всяческие новые конторы, в т.ч. западные. Не рекомендую гос.конторы - там такое болото, как правило...

А вообще - есть умные книжки, почитай лучше их. Здесь тебе всё равно такого объёма знаний не дадут.

← →
Илья Корстин (2008-04-04 11:11) [23]

> Устройся на работу.

И пойми как не надо делать :)

← →
Игорь Шевченко © (2008-04-04 11:11) [24]

Серьезные программы это миф. Их нету. Начинать надо с поиска в интернете - все программы давно уже написаны.

DVM © (04.04.08 10:45) [20]

> Неправда это. Интерфейс для конечного пользователя играет
> не меньшую роль, чем функционал. Не думаю. что пользователю
> сильно понравится суперфункциональная программа, где все
> действия требуется задавать, например, ключами в командной
> строке.

Если пользователь будет на нее любоваться, то не понравится. Если пользователь будет с ней работать, то понравится.

GUI мастдай.

← →
VICTOR_ (2008-04-04 11:12) [25]

Как вариант - на основе реально реализованного проекта.
1. Проанализировать предметную область.
2. Проанализировать программы с аналогичной планируемой функциональностью.
3. Написать временной план разработки программы.
4. Составить плановый бюджет проекта.
5. Написать спецификацию.
6. Моделирование системы (основных функциональных блоков, основных алгоритмов, базы данных)
7. Нарисовать прототип интерфейса.
8. Создание плана тестирования готового продукта
9. Ведение разработки, параллельное тестирование готовой функциональности.
10. Запуск продукта в пробную эксплуатацию у клиента
11. Доработка согласно замечаний, предложений и ошибок
12. Написание пользовательской документации
13. Запуск в эксплуатацию.
В принципе на любом этапе выполнялась и работа из предыдущих этапов, но в ограниченной степени согласно п.3, п.4., п.5

Еще можно почитать и использовать одну из методик разработки: MSF, RUP, XP, классическую и т.п.

← →
morgoth © (2008-04-04 11:31) [26]

1. ТЗ

← →
DVM © (2008-04-04 11:34) [27]

> Игорь Шевченко © (04.04.08 11:11) [24]

> GUI мастдай.

наверное эти строки написаны из текстового браузера Lynx?

> Если пользователь будет на нее любоваться, то не понравится.
> Если пользователь будет с ней работать, то понравится.

Хороший интерфейс - это не только красивости, как вы понимаете, это еще и удобство работы. Содать действительно хороший интерфейс ничуть не проще, чем "движок". И времени занимает не меньше зачастую, даже в Delphi или MS C#, о MS VC я вообще молчу.

← →
Alkid © (2008-04-04 11:40) [28]

> GUI мастдай.

Слишком однозначно.
GUI/CLI - всё от задачи зависит.

← →
VAleksey (2008-04-04 11:50) [29]

Делать так, или делать сяк...
Вопрос не имеет смысла, т.к. кодить приходится в разных условиях с разной степенью детализированности задачи, с разными знаниями предметной области, разными заказчиками и т.п.
По сути в литературе упоминаются два типа жизненных цикла разработки ПО. Это каскадный и циклический.
В реальных условиях, чаще всего работает циклический.
Каскадный применяется для систем с жестко заданным функционалом и/или повышенным требованиям к надёжности.

← →
Eraser © (2008-04-04 11:59) [30]

> djaUser (04.04.08 00:11)

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

не плохо бы с самого начала разрабоки использовать систему баг-трекинга и систему контроля версий.

← →
Игорь Шевченко © (2008-04-04 12:28) [31]

DVM © (04.04.08 11:34) [27]

> наверное эти строки написаны из текстового браузера Lynx?

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

> Хороший интерфейс - это не только красивости, как вы понимаете,
> это еще и удобство работы. Содать действительно хороший
> интерфейс ничуть не проще, чем "движок". И времени занимает
> не меньше зачастую, даже в Delphi или MS C#, о MS VC я вообще
> молчу.

Безусловно. Но из этого вовсе не следует утверждение "Не думаю. что пользователю сильно понравится суперфункциональная программа, где все действия требуется задавать, например, ключами в командной строке"

Alkid © (04.04.08 11:40) [28]

> Слишком однозначно.
> GUI/CLI - всё от задачи зависит.

А кто ж спорит ?

Когда народ запускает Winzip для распаковки архива - это уже от избытка времени.

Кроме того, за семь лет работы с VAX/VMS, где, пардон, CLI довольно развитый, я как-то не ощутил особого неудобства по сравнению с GUI.
Единственное, что в GUI по-настоящему удобно, это двухпанельный интерфейс файловых менеджеров а-ля Norton Commander и FAR - набирать команду copy скучно.

← →
Игорь Шевченко © (2008-04-04 12:29) [32]

VAleksey (04.04.08 11:50) [29]

> В реальных условиях, чаще всего работает циклический.

Агаблин. Сделали - не работает. И цикл по новой.

← →
Ega23 © (2008-04-04 12:30) [33]

> Единственное, что в GUI по-настоящему удобно, это двухпанельный
> интерфейс файловых менеджеров а-ля Norton Commander и FAR
> - набирать команду copy скучно.

Гиперссылки ещё.

← →
clickmaker © (2008-04-04 12:40) [34]

> Как правильно писать софт

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

← →
Kolan © (2008-04-04 12:41) [35]

> За столом, в удобном кресле, соблюдая правильность посадки.
> Иначе с годами будут проблемы с позвоночником и суставами

+1. С другой стороны в армию не возьмут :)

← →
Ega23 © (2008-04-04 12:49) [36]

> +1. С другой стороны в армию не возьмут :)

Поверь, уж лучше во второй раз в армию, на колёсах из-за проблем с позвоночником сидеть. :(

← →
Циркуль (2008-04-05 00:22) [37]

По поводу проектирования GUI - стоит почитать "Психбольница глазами пациента". В двух словах мораль книжки - детальное проектирование интерфейса должно быть выполнено до написания первой строки кода. И при том проектировать интерфейс (в идеале) ни в коем случае не дожен программист. :)

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

← →
Andy BitOff © (2008-04-05 00:27) [38]

> Циркуль (05.04.08 00:22) [37]

+500
Истина.
Книжку не читал, но после такой анатации обязательно прочту.

← →
Циркуль (2008-04-05 00:33) [39]

Пардон, название книги - "Психбольница в руках пациентов", автор Алан Купер :)

← →
Andy BitOff © (2008-04-05 00:34) [40]

> Циркуль (05.04.08 00:22) [37]

Что-то яндекс и гугл молчат по поводу такого названия. Может сцылочку?

Нашел.
Вот, кстати, отзывы о ней достаточно извесных людей - http://www.fictionbook.ru/author/kuper_alan/psihbolnica_v_rukah_pacientov/kuper_psihbolnica_v_rukah_pacientov.html#TOC_id2864350

Удивляюсь даже... Какой интерфейс? Главное - грамотное расширяемое ядро с продуманным API (тоже интерфейс, но вовсе не юзерский, а программный). А морд можно с десяток уже после наклепать.
Иначе получится совмещение логики с отображением, что неизбежно заставит переписывать всё при неизбежных изменениях функционала.

ПС. занимаюсь как раз разработкой такого ядра, отсюда и несколько пренебрежительное отношение к UI-команде =)

> Слоник © (06.04.08 01:08) [42]
>
> Удивляюсь даже...

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
(с) W. Shakespeare, Hamlet

> Слоник © (06.04.08 01:50) [45]
>
>

Скорее: "познаём культуру вместе с delphimaster.ru!"
Можешь и этот слоган выставить на продажу. Дарю. :)
Хотя тут безкультурья гораздо больше. (((

> Кроме того, за семь лет работы с VAX/VMS, где, пардон, CLI
> довольно развитый, я как-то не ощутил особого неудобства
> по сравнению с GUI.
> Единственное, что в GUI по-настоящему удобно, это двухпанельный
> интерфейс файловых менеджеров а-ля Norton Commander и FAR
> - набирать команду copy скучно.

Картина маслом - ИШ в командной строке пишет ответ на Delphimaster :-))

← →
Поп Гапон (2008-04-06 02:53) [49]

>
> djaUser (04.04.08 00:11)
>
> Кто реально занимается разработкой серъезных программ подскажите
> пожалуйста, с чего обычно следует начинать: или полностью
> прорисовать интерфейс со всеми бебехами а потом браться
> за код или вначале полный функционал написать, а потом уже
> думать о дизайне?
>
> И насчет функциоанала как лучше\проще: сразу продумать на
> листочке весь алгоритм, все связи и т.п. или сразу начинать
> кодить основу и по-ходу уже дописывать дополнительные модули?
>
>
> Что-то для себя никак не определюсь в этих вещах, собираюсь
> начать более-менее громоздкий проект поэтому прошу высказать
> мнения опытных кодеров, учитывая что небольшой опыт среднего
> класса программ уже у меня есть...
>
> Буду благодарен за любой ответ\мнение :)

Rational Unified Process
http://ru.wikipedia.org/wiki/Rational_Unified_Process

А вообще читай "Программистский камень" и "Путь Камикадзе"/"Смертельный марш"

> [41] Andy BitOff © (05.04.08 00:37)
> Нашел.

Отличная книга. В ней собрано все что я читал в разных местах. Особенно на Лармана, Джоэла похоже, только сжато, интересно&#133

Спасибо за Купера. Скачал

> Германн © (06.04.08 02:51) [48]
>
>
> > Marser © (06.04.08 02:40) [47]
>
> Какой клиент форума пользуюшь, Серёга?

Последний, который юзал - DMClient, до того питеровский, сейчас только из-под браузера.

>DrPass © (04.04.08 00:43) [3]
>Кто реально занимается разработкой серьезных программ, тот не думает о дизайне и функционале. Он это получает в виде техзадания

Ага, от Всевышнего ;)

>oldman © (04.04.08 01:07) [7]
>1. ТЗ
>2. алгоритмизация, блок-схема и т.д.
>..

-1. Исходные требования
0. Постановка задачи

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

В частности, хэлп нужен в большинстве случает только если проект задуман как продукт, т.е. для продаж. "Внутреннее" ПО, как правило, осваивается тыком, документация читается мало кем, читается редко, читается очень редко внимательно и практически никогда не читается до конца. Всегда проще спросить у автора, чем разбираться в инструкциях, писать которые программер, как правило, совершенно не умеет (у меня вообще часто возникает ощущение, что технари изучение русского литературного завершили где-то в 4-5 классе).

> MsGuns © (11.04.08 00:50) [54]

> В частности, хэлп нужен в большинстве случает только если
> проект задуман как продукт, т.е. для продаж. "Внутреннее"
> ПО, как правило, осваивается тыком, документация читается
> мало кем, читается редко, читается очень редко внимательно
> и практически никогда не читается до конца. Всегда проще
> спросить у автора, чем разбираться в инструкциях, писать
> которые программер, как правило, совершенно не умеет

И для "продажной" ситуации хэлп очень часто не нужен. Читать его и различные инструкции поставляемые вместе с ПО очень часто пользователи считают не барским делом. Гораздо проще позвонить в техподдержку.

У интерфейсов вообще отдельная "кухня"
По своему опыту моггу сказать то, что в моем понимании должно соответсвовать нормальному (есть такое сермяжное словцо - "дружественному") интерфейсу :

1. Пользователь сразу по стартовому окну видит для чего, собственно, предназначено приложение
2. Все элементы интерфейса оформлены в одном стиле, "мягких" тонах. Не допустимы разноцветные яркие пятна, кричащие или плохо разбираемые шрифты, наезжающие друг на дружку надписи и т.д.
3. Наличие трех-четырех уровневого управления - главное меню, панель с кнопками, всплывающие контекстные меню, шорткаты. Весь функционал должен преподноситься контекстно, т.е. доступно-недоступно, вспл.меню не должны включить лишнего и т.д. Надо помнить, что с приложением могут работать как чайники-"мышатники", так и опытные пользователи - "клавишники".
4. Автоматическая подстройка элементов интерфейса под размеры формы - категорически отвергаю формы, разработанные "под весь экран" программистом-новиком - наличие сплиттеров и управления открытием-закрытием отдльых фргментов интерфейса (не нужна панель фильтров - можно спрятать, нужна-можно показать)
5. Если имеются таблицы, в обязательном порядке "джентльменский" набор сервиса - сортировка, поиск, выделение (если требуется), фильтры и т.д.
6. Грамотно составленные и к месту отображаемые хинты
7. Отображение длительных процессов на панели статуса или в мод.окошках - пользователь должен видеть, что прога не повисла, а пытаетя приконнектиться к ftp-серверу
8. Если возможно, завертка длительных операций в потоки, чтобы прога не "висела" и человек мог спокойно просматривать те данные, которые уже имеются на экране, да и имел возможность прервать неосмотрительно запущенный длительный процесс
9. Интерфейс для ввода данных должен быть понятен и достаточно прост. Обязательные к заполнению поля отличать цветом (шрифтом) от необязательных, удобный и визуально понятный доступ к справочной информации, связанной с полем
10. Умение хранить и восстаналивать при повторном запуске текущие параметры экрана: размер и позицию форм, порядок сортировки, фильтры, выставленные опции (режимы) и т.д. Короче, чтобы Марьиванна могла, включив утром комп и запустив приложение, получить тот же вид экрана, который она видела вчера без 15 мин. 5, когда выключала комп и спешила в детсад за ребенком ;)
11. Возможность получить печатную форму полученных данных (обычно в виде таблиц)
..

Короче, чтобы понять как должен быть спроектирован профессиональный интерфейс, достаточно посмотреть на тот же IE, почтовый клиент или тот же офис

> [54] MsGuns © (11.04.08 00:50)
> -1. Исходные требования
> 0. Постановка задачи

поваторю -2 бюджет.
действительно серьезный софт без понимания кто оплатит разработку не делают:)
Ибо если программиста долго не кормить он помрет

Как правильно писать софт Найти похожие ветки