Pull to refresh

Comments 36

Истинно такъ! И нѣтъ, нѣтъ ничего болѣе мучительнаго въ нравственномъ отношеніи для программиста…
У вас 10 орфографических ошибок в двух предложениях.
Твою мать, Митгол снова мутировал и теперь еще и яти использует.
С добрым утром.
Он их использует с тех давних пор, как перешёл из CP866-шного фидо в юникодный интернет.
Я обдумываю задачу, и умножаю время на 2, пока хватало.
Помогает. Мы на работе страхуемся и умножаем на Пи. :-)
Расскажу случай из личной практики с подобной оценкой времени:

Руководитель: Сколько вам потребуется времени, чтобы разработать это, хотя бы примерно?
Я после 2х минут осмысления задачи и умножения представляющихся мне сроков на 3 (тут ближе комментарий выше): ~2 месяца**.

А потом руководитель отдал задачу на аутсорс, где наговнокодили результат за дня 3. Естественно, всё бажило, глючило, было уродско и велосипедно, документация отсутствовала как таковая. Но! Но оно было «сделано».

** — в этот срок я заложил изучение предметной области, непосредственную разработку бекенда, проектирование интерфейса, составление документации, тестирование и отладку.

Так вот, этот случай научил меня, новичка, что сроков лучше давать несколько. Утрируя, что-то в этом духе:

Минимальный: всё будет работать кое-как, будут ошибки кучами, неровности тут и там, но запускаться будет. Документация отсутствует.
Средний: всё будет работать и даже выглядеть «ничё так», но ошибки будут, немало. Минимальная документация.
Максимальный: всё будет работать, всё будет протестировано, отлажено, шанс критичных ошибок минимален. Полная документация.
UFO just landed and posted this here
Кстати, нет. Имея такие сравнительные сроки, всё-таки обычно выбирается средний.
Это как автомастера при обращении с проблемой спрашивают — для себя или на продажу. Соответственно, цены, сроки и качество результата сильно различаются. Хотя на первый взгляд выглядит одинаково.
Зачем все слова в заголовках и подзаголовках писать с большой буквы?!
Калька с английского, это же перевод.
Хороший перевод не подразумевает использования калек.
Наверно, чтобы было более «психологично» =)
Для более полного погружения в атмосферу оригинальной статьи :)
(в английских статьях так принято заголовки писать)
В русских (в т.ч. и переводах) — нет. Безграмотно.
Прямо моя история, только у меня не 3, а 9 месяцев из 3х недельного проекта вышло(но это по большей части из за громадного diff-а).
На www.philosophystorm.org/palex/2468 предложил шкалу времени в децибелах относительно 0,1 секунды

Получилось, что разница между тремя месяцами и тремя неделями = 79-72,6 = 5,4 децибела
Такая же разница в субъективной оценке между пятью днями и тремя неделями = 72,6 — 66,4 = 5,2

Выборка из таблицы
Децибелы | Сутки | Годы
0,0 | 0,00 | 0
40,0 | 0,01 | 0
50,0 | 0,12 | 0
59,4 | 1,00 | 0,003
60,0 | 1,16 | 0,003
70,0 | 11,57 | 0,032
80,0 |115,74 | 0,317
85,0 | 365,24 | 1
90,0 | 1,16E+03 | 3,17
100 | 1,16E+04 | 31,7
105 | 3,65E+04 | 100
110 | 1,16E+05 | 317
Можно проверить следующий алгоритм:

Прикидываем нижнюю tmin и верхнюю tmax границу, а верхнюю границу риска определяем пропорцией tmax*tmax/tmin

например, в днях: 21 * 21 / 7 = 63
При таком расчете кажущаяся лёгкость (t min) является прямой причиной увеличения срока, что совсем не так.
Лучше тогда уж давать оценки в частотах звука (= нотах). Если что, всегда есть универсальная отмазка:

"Да, я сказал, что выполню эту задачу за Ля времени. Но Вам же должно было быть очевидно, что это Ля второй октавы, а не первой! Поэтому не удивляйтесь, что задача решалась в два раза дольше"
— За сколько сделаете проект?
— За девять!
Перевод ужасен. Предложения несогласованы и попытки понять их просто взрывают мозг.
Давайте конкретнее. Конструктивная критика дает конструктивный результат)
Хорошо. Вот пример:
«Как только вы это осознаете, вы можете приниматься за следующую задачу, с которой, однако, довольно трудно справиться: как вы можете заставить вашу команду разработчиков производить тонны значений, даже при том, что вы не можете произвести более или менее значимые долгосрочные расчеты.»
Все, что написано после двоеточия, выглядит как бессмысленный набор слов. Например, слово «как» в начале фразы обычно подразумевает, что это какой-то вопрос, но дальше идет утверждение. И таких предложение в тексте много.
Что у вас с заголовком и подзаголовками? Почему Всё С Заглавной?
И зачем запятая после «программирование» в заголовке?
По просьбе руссофилов поправил буквы. Да, это конечно же калька.
А вот запятая, кажется, все-таки нужна.
UFO just landed and posted this here
Писал статью на эту тему. Говнокод, потом эволюционный рефакторинг.

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

Повторить три-пять раз, пока вся бизнес-логика не станет в голове. Отрефакторить, покрыть юнит и интеграционными тестами и идти дальше.

Все, никаких черных и белых подходов. Поняли на втором говнопрототипе, что будут вводить еще и китайчатину — показали прототип клиенту, работа идет, но изменилось требование — и срок вырос. Так как вы визуальный рпрототип показали, а не строили из себя гради буча и писали ошибочный сразу «правильный» вариант как дебил, без эмпирического опыта и живых данных, то клиенту можно продать изменение сроков.

Эволюция, рефакторинг, тесты. Частые релизы. И адекватные управленцы, а не мудаки. И будет вам щастье
В одном толк от статьи однозначен — 95% людей просто дохера о себе думают, чего нет на деле, и пытаются делать и претендовать на то, в чем не шарят ни хера. Отсюда и заказчики, лезущие в детали верстки, и каждый суслик-агроном, то есть тьфу, каждый кодер синьор и сразу сделает правильно (глоссарий терминологии бизнеса заказчика составляют единицы, а решать задачи не сео хуео, а в рамках бизнеса клиента в разработке сайтов вообще по пальцам одной руки ), каждый дизайнер чсв имеет не менее 100 килоэкслеров и эпатаж не ниже 100 мегаартемиев.

Так что срочно о себе, и допускать возможность своей ошибки — особенно допускать критику к себе.

Рост, увы, через сливание чсв и постоянную жопу. А если чсв слепит глаза и ты типа умнее всех — то и будешь стоять на месте, пока все уйдет вперед (чуть не написал в коммунизм, жить стало лучше, головокружение от успехов, и вот это все)
Определение времени разработки:
1) Спросить у программиста его оценку, принять ее за оптимистическую и выбросить.
2) Спросить у программиста оценку, если все пойдет не так (пессимистическая оценка). Обычно она будет вдвое больше, чем оптимистическая или около того.
3) Взять пессимистическую оценку и умножить на два. Эту цифру вписать в план.
Sign up to leave a comment.

Articles

Change theme settings