Предложите ТЗ программы на С++ для новичка.

[Finch]

Когда то мне нужны были контрольные суммы Вот исходники, для расчета контрольной суммы. Как использовать, пример есть в коментариях h файлов. Исходники честно скомуниздил, насколько я помню на algolist. Просто чуть чуть их причесал.

[Fealeron]

Finch спасибо!

[Dale]

Попытался составить некоторое подобие задания на разработку.
...
С удовольствием выслушаю конструктивную критику.

"Это вы удачно зашли!" (С)

Я и на работе частенько рецензирую проекты коллег. Они считают, что если проект выдержал все мои придирки, его можно пускать дальше. Так что критики будет сколько угодно, дело привычное.

Но сперва рекомендация. Проект планируется как кроссплатформенный и с открытым кодом. А документация изначально ведется средствами MS Office, который, во-первых, привязан к MS Windows, во-вторых, имеет проприетарный формат (конечно, есть конверторы в другие форматы, но они обычно привязаны к конкретной версии). Я бы рекомендовал перейти на OpenOffice. При необходимости можно будет корректировать документацию, например, в Linux'е.

И еще OpenOffice имеет такое преимущество как средство ведения проектной документации. Я в своих домашних проектах пробовал заносить документы в систему управления версиями Subversion, и они обрабатывались весьма корректно: при сравнении версий явно указывается, какие строки добавлены, какие удалены, какие изменены. Документ MS Word ввиду закрытого формата воспринимается как двоичный файл, и в результате правок я получаю лишь перечень измененных байтов, от которого мне никакого прока. А поскольку на сайте вроде бы функционирует репозиторий и наверняка можно в него попроситься со своим проектом, такой аспект тоже немаловажен.

[Fealeron]

Dale. Кхм, я сижу, сейчас, в Linux и использовал OpenOffice, просто, сохранил в .doc формате, в расчёте на то, что док можно прочитать как на Linux, так и на Windows, в то же время под Windows я никогда не пользовался OpenOffice.

[Dale]

А я специально поставил OpenOffice под Windows, чтобы иметь возможность работать с версиями, кроссплатформенность пока меньше волнует. Если вдруг появятся еще желающие поучаствовать в проекте (всякое бывает), без управления версиями не обойтись, да и одному это тоже полезно, а в формате .doc это вряд ли получится.

[Fealeron]

Dale. В общем, это я уже учёл и далее буду сохранят в формате OpenOffice.

[Dale]

Исходники честно скомуниздил, насколько я помню на algolist. Просто чуть чуть их причесал.

При необходимости свериться можно здесь: http://www.ietf.org/rfc/rfc1321

Вроде бы максимально приближено к первоисточнику, документ написан самим автором алгоритма.

[Dale]

Ну а теперь - обещанная критика. Буду столь же беспощаден, как компилятор, который к каждой запятой придирается.

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

Итак, по пунктам:

Цель:

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

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

и синхронизации файлов

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

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

Сразу возникает вопрос: почему программа, способная синхронизировать книги, не справится с фильмами? В чем именно будет состоять ее дальнейшее развитие?

Функциональность программы:
...
Детали реализации:
...

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

Кроссплатформенность: один из инструментов обеспечения кроссплатформенности — использование C++ + Qt.

Тоже рано. В этом месте уместнее упомянуть, что мы хотим получить программу, работающую, как уже упоминалось, в Windows, Linux и, возможно, Windows Mobile. Выбор языков, библиотек, инструментария и т.д. архитектор проекта сделает позднее, определившись с задачей. Может, это будет C++ + Qt? а может, и Java, или Mono, или... В общем, всему свое время.

Лучше все же следовать шаблону ReadySET, он неплохо продуман. Согласно ему, на первом этапе мы должны описать:

1. В чем состоит суть проблемы, которую мы взялись решать.
2. Какую цель мы ставим перед собой в ходе проекта.
3. Границы проекта.

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

Ну вот пока вся критика...

[Fealeron]

Dale
Критика понятна. Значит завтра буду приводить всё это в порядок.

[Kivals]

Вставлю свои пару копеек:
Для универсальности документации ее хорошо бы вести в чем-то, типа DocBook - из него при необходимости генерится в один клик любой формат: набор HTML страниц, все в одну HTML, PDF, .... Ну а поскольку это xml - то и с системами контроля версий проблем нет априори.
Что касается контрольных сумм: есть идея (предложение) для продвинутого режима сравнения контрольные суммы считать по блокам файла, а не по всему файлу целиком. Если правильно придумать разбивку на блоки (возможно разбивка будет зависеть от формата) то это даст возможность найти различные версии одного и того же файла, даже если он был переименован. Например: есть аудио файл, в котором блоком считаем фрейм. Предположим мы "обрезали" начало и конец файла, или же подняли громкость в начале звучания - программа выдаст "вероятность совпадения файлов 1.mp3 и MyNewFile.mp3 - 75%. Что дальше с ним делать?"