Разработка серьёзного ПО

← →
Сергей_77 (2008-06-19 12:55) [40]

> Ega23 ©
> Пардон, а откуда у Вас такая информация????

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

← →
Mystic © (2008-06-19 13:25) [41]

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

← →
den303 © (2008-06-19 14:04) [42]

Как можно быстро узнать количество строк кода в проекте? Где-то было, но забыл.

← →
VirEx © (2008-06-19 14:08) [43]

> [42] den303 © (19.06.08 14:04)
> Как можно быстро узнать количество строк кода в проекте?
> Где-то было, но забыл.

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

← →
DVM © (2008-06-19 14:19) [44]

> den303 © (19.06.08 14:04) [42]

Скомпилировать - там скажут сколько строк

← →
MsGuns © (2008-06-19 14:38) [45]

Самое важное в крупном проекте - это грамотная, максимально исчерпывающая ПОСТАНОВКА ЗАДАЧИ, т.е. упрощенно говоря, что из чего получается, в каком виде и для чего собственно все это делается. Потом идет МОДЕЛИРОВАНИЕ ДОКУМЕНТООБОРОТА и РАЗРАБОТКА ТЕХЗАДАНИЯ.
А вот уже потом всякие там распределения по людям, выбор инструментария, требования к интерфейсу и прочая лабуда

← →
isasa © (2008-06-19 14:40) [46]

Mystic © (19.06.08 13:25) [41]

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

:)
Этап циклический.
Перемежающийся с мыслью "На хрена я это делал?". Далее, поиск путей взаимодействия "кусков". Далее слияние. Далее - как разбить.

← →
DVM © (2008-06-19 14:42) [47]

> Самое важное в крупном проекте - это грамотная, максимально
> исчерпывающая ПОСТАНОВКА ЗАДАЧИ

Это точно! Пока заказчик сам не поймет, что он все таки действительно хочет.

← →
isasa © (2008-06-19 15:09) [48]

DVM © (19.06.08 14:42) [47]

> Самое важное в крупном проекте - это грамотная, максимально
> исчерпывающая ПОСТАНОВКА ЗАДАЧИ

Это точно! Пока заказчик сам не поймет, что он все таки действительно хочет.

Заказчик НИКОГДА САМ не поймет, чего он хочет, т.к. он считает, что это должен сделать исполнитель. За все оплачено. :)

← →
Mystic © (2008-06-19 15:22) [49]

Как я понял, изначально ставился вопрос о крупном проекте для себя :) Тут ТЗ может быть достаточно простым. Например, я сейчас в свободное время выполняю проект с ТЗ: "Написать движок го-программы, которая бы играла в силу первого про дана". В общем, никаких проблем с тем, что я хочу нет. Основной вопрос КАК?

← →
Anatoly Podgoretsky © (2008-06-19 15:33) [50]

> Ega23 (19.06.2008 9:55:26) [26]

А ты спроси Панова, как он компилятор и среду тестировал, сколько у него миллионов строк было и спроси крупный ли это проект.

← →
Anatoly Podgoretsky © (2008-06-19 15:36) [51]

> Kostafey (19.06.2008 10:48:33) [33]

По крайней мере одному из двух.

← →
MsGuns © (2008-06-19 16:16) [52]

>isasa © (19.06.08 15:09) [48]
>Заказчик НИКОГДА САМ не поймет, чего он хочет, т.к. он считает, что это должен >сделать исполнитель. За все оплачено. :)

Ерунда ! Заказчик всегда точно знает что он хочет. Но выразить это в "наших" терминах не может и понятно почему. ИсТр и составляются для того, чтобы на языке, понятном и ему и разработчкику описать что он хочет и в каком виде. При этом всякие рюшечки-бантики, сервисы-плагины его не интересуют - это делается для тех, кто будет сидеть за компом. Ему же нужна прежде всего ЭКОНОМИЧЕСКАЯ ВЫГОДА, которую ощутит лично он после внедрения и запуска проекта в эксплуатацию.

← →
stas © (2008-06-19 16:19) [53]

Сергей_77 (18.06.08 23:54)

Если что-то сложное в двоем или более. Особо эффективно если у всех разные точки зрения.

← →
Mystic © (2008-06-19 16:20) [54]

> Ерунда ! Заказчик всегда точно знает что он хочет.

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

← →
Sergey13 © (2008-06-19 16:31) [55]

> [52] MsGuns © (19.06.08 16:16)

+1

> [54] Mystic © (19.06.08 16:20)
Мне нужны штаны. Пойду выбирать - померяю, посмотрю как сидят, с женой посоветусь. Какие-нибудь куплю. Теща, если что подошьет немного. Какая же тут непределенность?

← →
Ega23 © (2008-06-19 16:34) [56]

> Мне нужны штаны. Пойду выбирать - померяю, посмотрю как
> сидят, с женой посоветусь. Какие-нибудь куплю.

Ну видишь, изначально-то неопределённость.
Сколько раз я от директора слышал: "Мне пофиг ваши заморочки, мне нужно штоб работало и было красиво."

← →
DVM © (2008-06-19 16:36) [57]

> Сколько раз я от директора слышал: "Мне пофиг ваши заморочки,
> мне нужно штоб работало и было красиво."

во-во.

← →
Sergey13 © (2008-06-19 16:45) [58]

> [56] Ega23 © (19.06.08 16:34)

Так это самые золотые клиенты! 8-)
Сделал им красивую анимашку и кнопку "Выход". Все красиво работает. Можно зарплату получать. 8-)

← →
Sergey13 © (2008-06-19 16:48) [59]

Все таки сайт и штаны вещи достаточно стандартные.
Вот если задача стоит как "комплексная автоматизация всего предприятия" - тут да, неопределенность. Но для этого и существует этап (очень кстати недешевый) обследования предприятия и составления ТЗ.

← →
Eraser © (2008-06-19 16:56) [60]

при разработке коробочных продуктов процесс немного иной, imho. Конечно всякие гиганты вроде MS, 1C, Abobe и т.п. могут себе позволить составлять полную проектную документацию, но в подавляющем большенстве продуктов вся документация сводится к системе баг-трекинга.

← →
Mystic © (2008-06-19 17:21) [61]

> Все таки сайт и штаны вещи достаточно стандартные.

Этот пример описан у К. Бека. В частности, ему не понравилось, что когда его фирма решила создать сайт, то им предложили несколько типовых проектов. А он сразу не мог понять, нужны они ему или нет. И предлагал вести разработку по XP, чтобы в процессе понять, какой сайт он действительно нужен :)

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

← →
MsGuns © (2008-06-19 19:34) [62]

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

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

← →
Игорь Шевченко © (2008-06-19 19:38) [63]

Mystic © (19.06.08 17:21) [61]

> И предлагал вести разработку по XP

При всем уважении к Беку, все-таки являюсь ярым противником XP или, скорее, интерпретаций XP, таких, что мол, давайте сделаем, а потом будем переделывать.

← →
Mystic © (2008-06-19 19:38) [64]

> Сайт - это скорее из области рекламы и маркетинга, а там
> несколько по-другому считается эффект.

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

Разумеется, как и я не имею представления в каких я должен быть штанах, чтобы все бабы дружно меня зажаждали ;)

> интерпретаций XP, таких, что мол, давайте сделаем, а потом
> будем переделывать.

Во-первых, это работает в комплексе с остальными методиками XP, в частности работа с заказчиком должна быть в стиле XP. Ну и разумные рамки должны быть. Если что-то описано в ТЗ, естественно, это придется реализовывать. И сделаем/переделаем тут на работает. А вот если некая возможность не присутствует напрямую в TЗ, но фигурирует якобы в перспективе... Стоит ли на нее закладываться? Например, ходят слухи о том, что заказчик хочет портировать систему под Linux, но в ТЗ этого нет. Стоит ли в этом случае сразу закладываться на возможный переход под Linux? Которого может и не быть?

Просто в XP ТЗ рассчитано на одну итерацию, и по правилам заказчик может сам выбирать, что ему надо реализовать потом. Может в этой ситуации указанный подход и работает, но... я никогда не работал в чистом XP :) А переносить практики XP в обычный проект надо очень осторожно.

> Разумеется, как и я не имею представления в каких я должен
> быть штанах, чтобы все бабы дружно меня зажаждали ;)

Но это не факт, что такие штаны невозможно изготовить. Это просто пример того, что ни заказчик, ни разработчик могут и не знать, что конкретно требуется, и что вписать в ТЗ :)

Mystic © (19.06.08 19:52) [66]

> Во-первых, это работает в комплексе с остальными методиками
> XP

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

> А вот если некая возможность не присутствует напрямую в
> TЗ, но фигурирует якобы в перспективе... Стоит ли на нее
> закладываться? Например, ходят слухи о том, что заказчик
> хочет портировать систему под Linux, но в ТЗ этого нет.
> Стоит ли в этом случае сразу закладываться на возможный
> переход под Linux? Которого может и не быть?

Да, стоит. Однозначно. Хотя бы архитектурно отделять системно-зависимые части от системно-независимых. И средствао разработки выбирать соответствующее. А то напишем, скажем, на delphi, а заказчик все-таки решит на Линукс перейти сдуру или спьяну. И все по новой писать (FreePascal не предлагать)

← →
Галинка (2008-06-19 23:49) [69]

isasa © (19.06.08 14:40) [46]

прямо философия... анализ (разбить), синтез (слить), анализ, синтез, ... и так до бесконечности...

← →
-koha (2008-06-19 23:57) [70]

говорят блокнот в windows разрабатывали и доводили до совершенства аж 3 года - чем не серьезное проектирование?

← →
Галинка (2008-06-19 23:59) [71]

правильно поставленная задача - это минимум 75% успешного решения. Поэтому надо начинать с ТЗ и плана разработки. ТЗ определит средства разработки, основные алгоритмы, структуру классов/данных. Средства определят специфические алгоритмы и реализацию всех алгоритмов и классов. А вот после этого наступит фаза:

> БарЛог © (19.06.08 10:13) [30]
>
> не ешь, не пьёшь, кодишь :)

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

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

И уж поверьте, я знаю о чем говорю, бо более 100000 юзеров используют прогу которую я написал именно так, как указано. И написал один. Впрочем, когда было около 50000 юзеров, ко мне подключились небезызвестные Гаврила, Розыч, и Джек который 128. :)
И вот нету у нас никаких техзаданий, всяких дармоедов аналитиков и т.п.

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

← →
VICTOR_ (2008-06-20 11:42) [74]

> И вот нету у нас никаких техзаданий, всяких дармоедов аналитиков
> и т.п.

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

Очень часто проекты имеют другую специфику
- финансовые ограничения Заказчика
- временные ограничения Заказчика
- требования к функциональности от Заказчика

И тут без Технического задания (в письменном виде), "дармоедов-аналитиков" и т.п. никак не обойтись. Все сводится к разговору "для бедных": "А как же Вы не предусмотрели, что нужно было сделать еще то и то и это. Для меня это очень важно, но я просто забыл сразу Вам про это сказать. Я заплатил Вам такие огромные деньги, а Вы сделали совсем не то. Переделайте пожайлуста". И все в тот же срок и за те же деньги.

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

> "А как же Вы не предусмотрели, что нужно было сделать еще
> то и то и это. Для меня это очень важно, но я просто забыл
> сразу Вам про это сказать. Я заплатил Вам такие огромные
> деньги, а Вы сделали совсем не то. Переделайте пожайлуста".
>

Знакомо. :) Вот только никакой аналитик этой ситуации не исключит. Потому и бездельник. Чтобы избежать таких вопросов, нужно чтобы постановщик задачи/программист/ну или пусть аналитик :) был глубоко в теме предметной. Что практически всегда нереально. Бывают впрочем и исключения. А раз не в теме, то никакого толкового ТЗ не выйдет. Что и наблюдается повсеместно. Хотя способы выхода из ситуации конечно есть.

> В одном из последних проектов (коробочный продукт)

А что за продукт если не секрет?

Разработка серьёзного ПО Найти похожие ветки