LINUX.ORG.RU
ФорумTalks

[devel] Соотношение времени


0

2

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

С другой стороны, подход «сейчас день потерять, потому за 5 минут долететь», во-первых, раздражает менеджеров, во-вторых, перфекционизм вреден.

Итак. Каково оптимальное соотношение времени, затрачиваемого на:

  1. кодирование/проектирование;
  2. автотесты, документацию, рефакторинг и т.п. инфраструктуру;
  3. самообразование?

Фредерик Брукс косвенно говорит нам, что время на (2) вдвое превышает время на (1). Но ничего не говорит про (3).

★★★★

Последнее исправление: lodin (всего исправлений: 2)
Ответ на: комментарий от drull

Хайлоад++ типа для безработных?

lodin ★★★★
() автор топика

второй пункт как-то странно выглядит. тогда уже и 1 с 3 объедини. и получится где-то 20/80

ananas ★★★★★
()
Ответ на: комментарий от ananas

Попробую объяснить разбивку. Самообразование, наверное, не очень правильный термин...

Ну то есть, вот у нас есть код, который приносит деньги, и команда разработчиков.

И есть три типа действий:
1) Непосредственно улучшающие потребительские качества (то есть, фичи минус баги) кода.
2) Облегчающие сопровождение кода.
3) Усиливающие команду разработчиков.

Вроде бы, теперь не должно путаться. Хотя опять же, чтение документации библиотеки, которая может решать/не решать одну из текущих проблем — это 1, 2 или 3?

lodin ★★★★
() автор топика
Ответ на: комментарий от lodin

не 3, так точно. а 1 или 2 - зависит от библиотеки.

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

ananas ★★★★★
()

сейчас день потерять, потому за 5 минут долететь

Стараюсь действовать по этому принципу. Заодно переписываю то что народ сделал «за 5 минут, лишь бы работало» потому сейчас этот код абсолютно не ложится на существующее ТЗ и рефакторингу не подлежит(моё мнение). Сроки иногда срываются на неделю(как в плюс так и в минус:)), но чем больше качественного кода написано тем легче и быстрее девелопить в будущем. Заодно качественный код, оформленный в виде отдельных модулей, поддаётся повтороному использованию, это существенно сокращает разработку.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

> Заодно качественный код, оформленный в виде отдельных модулей, поддаётся повтороному использованию, это существенно сокращает разработку.

при говенной архитектуре никакой качественный код не поможет

ananas ★★★★★
()
Ответ на: комментарий от ananas

при говенной архитектуре никакой качественный код не поможет

Когда я с таким столкнулся я разбил модуль на две части. Одну сделанную «как надо» и вторая это compat.c который учитывает «особенности» API. Т.е. добавляю уровень абстракции(или как это называется).

Конечно, бывает что в проекте всё-всё плохо, но с таким работать не хотелось бы :)

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

Вот это интересует. Хотя это, наверное, только опыт...

lodin ★★★★
() автор топика
Ответ на: комментарий от lodin

Только твой опыт и нюх помогут.

Но вот «посреди переправы поменялись требования» это ппц. Тут уже не имеет значения как ты писал код до этого, его придётся переделывать или выкидывать. И, кстати, хороших код лучше рефакторится, так что даже в этом случае я рекоммендую писать на совесть.

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

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.