(no subject)

Уровень качества

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

В качестве примера можно привести функцию для Win32 из книги Рихтера, которая, несмотря на попытку достичь максимальной ясности, не была упрощена в силу принятых соглашений:

DWORD WINAPI SecondThread (LPVOID lpwThreadParm) {
BOOL fDone = FALSE;
DWORD dw;

while (!fDone) {
// Wait forever for the mutex to become signaled.
dw = WaitForSingleObject(g_hMutex, INFINITE);

if (dw == WAIT_OBJECT_0) {
// Mutex became signalled.
if (g_nIndex >= MAX_TIMES) {
fDone = TRUE;
} else {
g_nIndex++;
g_dwTimes[g_nIndex - 1] = GetTickCount():
}

// Release the mutex.
ReleaseMutex(g_hMutex);
} else {
// The mutex was abandoned.
break;// Exit the while loop.
}
}
return(0);
}

Однако мы можем сделать это и достичь максимального уровня качества

DWORD TheThread(void *ThreadParm)
{
while(Index < MAX_TIMES &&
WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0)
{
if (Index < MAX_TIMES)
Times[Index++] = GetTickCount():
ReleaseMutex(Mutex);
}
return(0);
}

Причём вместо

hThreads[0] = CreateThread(..., FirstThread, ...);
hThreads[1] = CreateThread(..., SecondThread, ...);

можно писать

hThreads[0] = CreateThread(..., TheThread, ...);
hThreads[1] = CreateThread(..., TheThread, ...);

и тем самым избежать поддержки нескольких версий одного и того же кода.

(no subject)

Знание, а не кликанье

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

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

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

(no subject)

Watch on YouTube