Highload-разработка [статьи, книги]

[JuriIvanov]

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

Ссылка скрыта от гостей

 

[rrrFer]

Highload тут причем?
Банальные вещи типа:

1. В 90% случаев срабатывает правило – умножьте расчёты разработчика на два и получите реальные сроки. Причина – идеализация распорядка дня и «роботизирование» человека.
...
10. Вдохновение. Да, оно бывает и у программистов, а не только у дизайнеров или художников. Поэтому при планировании и оценке трудозатрат учитывайте любые возможные факторы, разрушающее «единение» кода и разработчика.

Статья уныла, кстати. Ну вот скажи мне, как учесть "вдохновение"? - речь ведь идет об оценке трудозатрат и планировании.

Или как мне на практике использовать это:

6. Ошибки. Ни один человек не признается в том, что намерен совершать ошибки, ломать код и т.п. Это из серии очередных иллюзий. Все мы люди.

?
Я вот загуглил и нашел тебя на хабре, но профиль readonly. Почему бы тебе не запостить одну такую статью в песочницу и сразу все узнать о себе и своих советах?

По САБЖу есть хорошая книжка Р. Т. Фатрелла "управление программными проектами". А вот такие недостатьи - не нужны.

 

[-master-]

Highload тут причем?

предлагаете грохнуть ветку? эт мы запросто

 

[rrrFer]

предлагаете грохнуть ветку? эт мы запросто

Да грохнуть ветку я вроде бы сам могу (всегда успеем), но автор статьи - "программист отдела высоконагруженных систем". МБ он зайдет да разъяснит тут все )).

 

[JuriIvanov]

За книгу спасибо. Статья для новичков в программировании, на которую переложен опыт работы. Далеко не все новички даже понимают такие прописные истины. Наверное, в топике нужно было сразу обозначить это.

 

[rrrFer]

Далеко не все новички даже понимают такие прописные истины.

Новички не занимаются оценкой задач, ничего не планируют и задачи по разработчикам не распределяют.

Это не только этой статьи касается, но и соседних, где дается в том числе капитанский совет типа - "сложные задачи надо давать опытным разработчикам, а простые - неопытным". Может быть "не все новички это понимают", но мне кажется, что если предложить распределить задачи второклассникам - большинство сделает так без чтения статей и вот таких советов.

Так для кого ваши статьи? - для "начинающего программиста" или для тимлида?
Причем тут highload? (повторяюсь уже)

 

[JuriIvanov]

И для тимлидов и для программистов. Статья про опыт оценки в нашем highload-отделе. Хотел бы услышать дополнения именно по highload'у в оценке трудозатрат от коллег. Особенности в технической части.

 

[rrrFer]

5. Высокая связность кода. При изменении простого участка кода разработчики могут перелопатить всю структуру. Закладывается ли это в оценку – вопрос риторический.

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

 

[rrrFer]

Хотел бы услышать дополнения именно по highload'у в оценке трудозатрат от коллег.

Чтобы дополнить"по highload-у" нужно чтобы уже хоть что-то было по этой теме, но у вас сочетание "highload" в статье не встречается вообще ни разу. Аналогия - "помочь и сделать за вас". Отсюда и вопрос (в третий раз) - причем тут highload?

И для тимлидов и для программистов.

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

Статья на 90% состоит из невнятных аналогий, кстати:

Составные задачи. Сравнить их можно лишь с марафоном. Реальные сроки составных задач всегда больше запланированных, поэтому главный помощник программиста в работе с ними – разбиение на подзадачи и оценка с учётом «утечки времени».

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


Полезной информации я вообще не нашел. Даже если отбросить highload, там просто нет ничего полезного. Выделите мне хоть одну строку, которая не очевидна студенту-второкурснику?

 

[rrrFer]

Да. Просто делайте то, чему хотите научиться. Постоянно и много. Когда мы устанавливаем для себя временные рамки – мы основываемся на своём опыте, а не на чужом. Этакий своеобразный внутренний замер. Помните, как нас учили в детстве – с утра зарядка и ещё раз зарядка? Так и здесь.

Я взял целый абзац. Меня в школе учили, что абзац - это отдельная мысль. Ты можешь сказать какую мысль несет этот абзац? - я тут вижу несвязный набор слов:
1. Непонятно чему именно я могу научиться. Даже предыдущий абзац не помогает разобраться (там написано что-то про бифштексы).
2. Какие временные рамки мы себе устанавливаем? - в остальной части статьи ты пишешь про Сталина, который устанавливает рамки всем окружающим.
3. Внутренний замер? ^^
4. Причем тут зарядка? - это такая же эпичная аналогия, как и с марафоном.

Как картинка с мужиком, лупящим ногами грушу, связана с highload?

Я понял что вы писали эту статью под мощными веществами. Смотри чтобы Федеральная служба РФ по контролю за оборотом наркотиков на вас не вышла. Я бы на их месте допрашивал авторов таких поделок.