Как писать ТЗ?

← →
kull (2004-09-05 01:31) [0]

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

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

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

← →
Cobalt © (2004-09-05 21:46) [1]

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

← →
Красный молоток (2004-09-05 21:48) [2]

> тз на написание кода
Если писать тз на код, то тз никогда не будет написано, ИМХО %-)

← →
DrPass © (2004-09-05 22:33) [3]

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

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

← →
kull (2004-09-05 23:33) [4]

Почему у меня возник этот вопрос...
Я устроился на работу в компанию, название не буду говорить, не важно.

Так вот, там существует такая практика:
Аналитики пишут тз на ГРОМАДНУЮ процедуру в виде подробной последовательности действий, какие переменные выделять, как их называть, что с ними делать, ну и т.п. Потом програмеры по этому тз пишут код.В итоге получается, что программеры и аналитики выполняют двойную работу.

Когда я увидел одну из процедур, сделанную по одному из этих тз, я был просто в трансе. Я и сейчас испытываю легкий шок, когда мне на глаза попадается этот код.

Представте себе процедуру в 6000!!! строк, полную case-ов, всевозможных условий и прочего, с кучей дублирующегося кода, и сильно попахивающую ассемблерным стилем, и (О ужас) с кучей операторов goto...

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

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

И вообще я в панике. Что мне делать, как вывести людей на путь истинный?

ПОМОГИТЕ!!!

← →
DrPass © (2004-09-05 23:57) [5]

Софт работает? Ну так и не трогай ничего. С другой стороны - даже плюс: глюки в коде легко свалить на отдел аналитиков

← →
kull (2004-09-06 10:36) [6]

> DrPass © (05.09.04 23:57) [5]

Это верно, но есть одно "НО".
С этим кодом приходится постоянно работать.
Код-то нужно менять и добавлять новый. В смысле, добавляются новые фичи, те же самые новые процедуры. И не хотелось бы плодить Lagодром...

Себе же хуже будет.

← →
kull (2004-09-06 15:53) [7]

Может ссылочки какие подкинете?

http://search.rambler.ru/srch?old_q=%C0%EB%E5%EA%F1%E5%E9+%DF%F0%F6%E5%E2&words=%C6%E8%E7%ED%E5%ED%ED%FB%E9+%F6%E8%EA%EB +p%E0%E7p%E0%E1%EE%F2%EA%E8+%EFp%EE%E3p%E0%EC%EC&set=www%2Finfound

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

http://pmprofy.ru/content/rus/rubr25/rubr-251.asp

Как писать ТЗ? Найти похожие ветки