?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Gaperton
gaperton at 2011-06-18 21:16 (UTC) (Link)
Могу описать, как я это сделал. В общем, все достаточно просто - в основе JIRA + SVN + WebSVN, никаких хитростей. Делается прямолинейно, без программирования, никакого хайтека.
миххон
mihhon at 2011-06-18 21:24 (UTC) (Link)
да, наверно это не так и сложно сделать технически

сложнее организационно

для небольшой компании это не так уж и нужно

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

а в софтверной конторе (у брокера, по-большому, весь бизнес софтом делается) на 100-200 человек, где решение принимается 2-5-10 ключевыми людьми, которые тесно сотрудничают, это возможно
Gaperton
gaperton at 2011-06-18 21:30 (UTC) (Link)
> для большой - не получится, митинги о целесообразности внедрения будут длиться дольше, чем время нахождение в текущей должности того, кто внесёт вопрос на обсуждение

Какие еще "митинги о целесообразности внедрения"? :) Принципиальные вопросыь , относящиеся к процессу разработки, решаются руководителем соответствующего уровня, а не "митингами". :) Каждый должен свою работу делать.

Вопрос процессов уровня компании, и технической политики - это вопрос руководителя R&D департамента. "Митинги о целесообразности" :).
миххон
mihhon at 2011-06-18 21:37 (UTC) (Link)
большая компания - это большая бюрократическая машина, мотивация частей которой не совпадает с интересами компании :)

Принципиальные вопросы, относящиеся к процессу разработки, решаются исходя из 2х принципов: 1. уменьшение собственной ответственности, 2. увеличение размера команды и бюджета, что прямо влияет на зарплату и вес внутри машины

Вопрос процессов уровня компании, и технической политики - это вопрос кому достанется больше власти и откатов :)
Gaperton
gaperton at 2011-06-18 21:39 (UTC) (Link)
Ну если все так - то конечно все погрязнет в митингах :).
миххон
mihhon at 2011-06-18 22:09 (UTC) (Link)
Впрочем, в больших компаниях и так есть jira, svn и почта. И без хуков весь процесс воспроизводится, даже и не думал, что это называется процессом документации:) : blame->log->source,поиск в email,поиск в instant messenger,поиск человека. Документацию типа "класс X далает Y" никто не пишет. А спецификации либо отсутствуют, либо оставляют желать лучшего.
Gaperton
gaperton at 2011-06-18 22:12 (UTC) (Link)
Оно не называется процессом документации.

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

Весь фокус в обязательности ссылки на задачу или ошибку в трекере. Это ключевое. Тогда не надо будет делать "поиск по e-mail".
Ilya
tech_mind at 2011-06-20 18:05 (UTC) (Link)
> Какие еще "митинги о целесообразности внедрения"? :) Принципиальные вопросыь , относящиеся к процессу разработки, решаются руководителем соответствующего уровня, а не "митингами". :) Каждый должен свою работу делать.

Буквально пару месяцев назад, я пришел в новую для себя компанию и мягко говоря был в шоке, когда посмотрел код, посмотрел вики(там было аж два стандарта), и понял, что стандарты кодирования мягко говоря не соблюдаются, а на вопрос к руководителю какого мне был дан ответ: "У нас анархия. Ввести стандарты кодирования вызовет больше срача, по их поводу, чем польза от внедрения". Вот как, то так, но продукт приносит деньги и немалые, так что всех все устраивает.
Gaperton
gaperton at 2011-06-20 21:39 (UTC) (Link)
"Стоимость внесения изменений". Maintainability. Это - показатель, на который влияют обсуждаемые здесь вещи.

Он аукнется "когда нибудь, и может быть". Посему - не принимается во внимание деревянным менеджментом.
kholodova
kholodova at 2011-06-21 20:21 (UTC) (Link)
А опишите, очень интересно.
Previous Entry  Next Entry