Pull to refresh
-6
0
Send message

Это наверное еще на одну статью потянет... постараюсь описать

Не, ну засем же утрировать.

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

Вот вообще не согласен.

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

Влезла бы, если бы это было задумкой автора, но это не так

Так-то для всех, а какая разница для кого?

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

Правильный комментарий, но фокус должен быть на другом - предположение о том, насколько рискованным будеи ваш проект.

Информация, которую мало знает из начинающих специалистов.

Такие тоже считаались как неуспешные...

Тут фокус внимания должен быть на другом: аутсайдеры взаимодействия - они не плохие, наоборот - они нуждаются в дополнительной заботе и внимании

Точно!

Ну там видимо проектная группа маленькая совсем.

Или ИТ-отдел в непрофильной компании, как вариант.
Мне кажется такое знание ничего не даст.
Можно подумать, что у программиста есть только два состояния — работает или общается с менеджером. И при этом все это занимает 8 часов в день.

По этому поводу мне вспомнилось следующее — в прошлом году на ADD-2010 в Ярославле кто-то рассказывал, что они в компании несколько раз проводили исследование и выяснили, что в каждый момент времени непосредственной работой занято примерно 30-35 процентов сотрудников. Все остальные заняты чем-то другим.
А вот могу тоже привести кусочек C#-говнокода, обнаруженный в коде реального проекта компании, известной и старой не менее, чем Интел.

И это не прикол — это реальный код.

string s = Request.QueryString["action"];
// s may have "remove" or "restore" values

switch (s[2])
{
case 's':
case 'S':
..............
break;

case 'm':
case 'M':
..............
break;

}
P.S. Все вышесказанное не умаляет достоинств новых команд.
Но их производительность, на самом деле, надо бы оценить в более боевых условиях, чем предложенные в статье.
Пример для SQL 2000 с постраничным выбором данных изначально написан не оптимальным образом, именно поэтому он и работает медленнее всех.

Я сталкивался с необходимостью организации постраничного просмотра на SQL 2000 для очень больших таблиц (сотни миллионов строк) — его тоже можно заставить работать очень и очень быстро.

Для этого надо сделать следующее:
1. В таблицу #Temp надо вставлять не весь набор записей, а только первые (@RowSkip+ @RowFetch) записи — остальные там просто не нужны.
Очень помогает уменьшить время.
Правда для этого придется писать генеренный запрос и использовать exec, но это не проблема, если уж пришлось писать для SQL 2000.

2. В #Temp надо вставлять опять же не поля, а только поле [Person ID]. Это будет работать намного быстрее — лишние данные не будут гонятся из таблицы в таблицу.

Затем уже в выборке искомых данных надо добавить join таблиц #Temp и tblSample по полю [Person ID] и вернуть в результате запроса выборку полей из таблицы tblSample.
Я в общем-то не против, но это тянет на большую большую статью…
1

Information

Rating
Does not participate
Location
Кострома, Костромская обл., Россия
Date of birth
Registered
Activity