После того, как Вы полчаса будете смотреть на свой код через пол-года после написания с мучительными мыслями «А что я имел в виду, когда переворачивал этот бит в этой одной строке?
Не надо драматизировать, это далеко не пример ужасного кода.
Везде, где Вы говорите про то, что задачи должны быть одного размера и тому подобное.
Неужели Вы не видите, что оперируете готовыми оценками, а статья повествует о том, как правильно суммировать трудозатраты? Это, безусловно, дело нужное и важное. Просто заголовок обещает совсем другое.
> T = N * A * k / D
> если один менеджер предпочитает создавать задачи не более чем на 8 часов
> Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов
Вы обещали рассказать, как оценивать задачи. Рассказали же, как на основе готовых достаточно надежных оценок посчитать итоговые трудозатраты. Это же простая арифметика * фактор риска, специфичный для команды/человека/окружения, о чем тут вообще можно рассуждать?
Неструктурированные данные всегда первичны, и зачастую содержат больше информации, чем структурированные. Потому что заранее неизвестно, какие сигналы из них могут потребоваться, не всегда структура, покрывающая все возможные случаи, удобна.
Сохранить изначально аналоговые данные со стопроцентной точностью все равно нельзя. Поэтому придать им структуру и чем-то пожертвовать все равно придется.
Человеку удобнее и понятнее последовательность: «включили одно, потом выкинули другое», а более сложное декларативное описание удобнее только машине.
Да ладно, все типичные машины выполняют как раз последовательность шагов. А вот людям это менее интересно, ибо «невыразительно».
Посмотрите на современный фронтенд — это настоящая большая программа на JavaScript, со своей архитектурой, модульным разбиением, объектно-ориентированным программированием, кешированием и так далее. Зачастую это не менее, а более сложный код, чем серверный. На клиенте все больше бизнес-логики, а сервер превращается в простое хранилище данных.
Похоже на попытку возвыситься над бэкендом (употреблением слов, давно с ним ассоциирующимся) :) По существу же здесь ошибка — бизнес-логика не может не дублироваться на сервере из соображений безопасности.
P.S. Ну и поверьте, бэкенд-технологии тоже не стоят на месте, хотя лично я за мир-дружбу-жвачку, если что. Работы всем хватит.
Чего плохого в том, чтобы перевести двигло в более экологичный режим, если автомобиль стоит на месте? Тем более, что контроллеры и так умеют адаптироваться к условиям движения сто лет в обед.
Замечение актуально, если верно утверждение «режим тестирования определяется по неподвижным задним колесам».
не хватает указателей (про принципиальную неспособность их понять некоторыми людьми писал Джоэль Спольски).
Не надо драматизировать, это далеко не пример ужасного кода.
Везде, где Вы говорите про то, что задачи должны быть одного размера и тому подобное.
Неужели Вы не видите, что оперируете готовыми оценками, а статья повествует о том, как правильно суммировать трудозатраты? Это, безусловно, дело нужное и важное. Просто заголовок обещает совсем другое.
> если один менеджер предпочитает создавать задачи не более чем на 8 часов
> Если одному человеку постоянно достаются задачи длительностью 1 час, а второму — 8 часов
Вы обещали рассказать, как оценивать задачи. Рассказали же, как на основе готовых достаточно надежных оценок посчитать итоговые трудозатраты. Это же простая арифметика * фактор риска, специфичный для команды/человека/окружения, о чем тут вообще можно рассуждать?
Да ладно, все типичные машины выполняют как раз последовательность шагов. А вот людям это менее интересно, ибо «невыразительно».
Не все здесь активно программировали в 60-е.
Спасибо автору за интересную тему и хорошую подачу.
P.S. Подождем статью о том, что студии берут в четыре раза больше, чем фрилансеры, при таком же/худшем качестве продукта и отношении к клиентам.
Да, это оно. Круто, что Постгресс именно так и работает.
Нифига там не четко. Куча спорных ситуаций подтверждает это.
ПДД — прекрасный пример того, что формализовать реальную жизнь можно лишь до определенной степени.
Похоже на попытку возвыситься над бэкендом (употреблением слов, давно с ним ассоциирующимся) :) По существу же здесь ошибка — бизнес-логика не может не дублироваться на сервере из соображений безопасности.
P.S. Ну и поверьте, бэкенд-технологии тоже не стоят на месте, хотя лично я за мир-дружбу-жвачку, если что. Работы всем хватит.
Замечение актуально, если верно утверждение «режим тестирования определяется по неподвижным задним колесам».