Скоро випустять загальнодоступну бета-версію браузера Netscape 6.0. Версії 5.0 не було. Останнє серйозне оновлення до 4.0 було три роки тому. Три роки - дуже довгий термін в інтернеті. І весь цей час Netscape безсило спостерігала за стрімким скороченням ринкової частки свого браузера.
Але чи не занадто самовпевнено критикувати їх за тривалу затримку, на яку вони пішли свідомо?
Прийнявши таке рішення вони зробили гіршу стратегічної помилки з усіх можливих для компанії-розробника.
Вони вирішили переписати код з нуля.
Вони не перші зробили таку помилку. Borland зробила те ж саме, купивши Argo і спробувавши перетворити її в dBase для Windows, приречений з самого початку проект зайняв стільки часу, що після випуску не витримав конкуренції з Microsoft Access. Вони повторилися, переписавши з нуля Quattro Pro з разюче убогими можливостями. Такої ж помилки мало не зробила Microsoft, спробувавши переписати Word для Windows з нуля, в компанії намагаються не згадувати про приреченому з народження і незабаром закритому проекті Puramid. На щастя для Microsoft її розробники продовжували працювати зі старим кодом і завжди могли надати клієнтам хоч щось, так що фінансові катастрофа не переросла в стратегічну.
Ми програмісти. Всі програмісти в глибині душі архітектори, їм завжди хочеться зруйнувати старе вщент і побудувати щось грандіозне натомість. Нас мало приваблює поступове поліпшення на кшталт ремонту і розбивки клумб.
З боку це непомітно, але саме з цієї причини програмістам вічно хочеться видалити старий код і почати все заново. Старий код їм здається безнадійно зіпсованим. І найцікавіше те, що швидше за все вони помиляються. Старий код здається їм зіпсованим через основного закону програмування.
Саме через це так складно повторно використовувати код, а у кожного члена вашої команди є власна версія функції, що розділяє один рядок на масив з несколких. Простіше і приємніше їх написати, ніж розбиратися в чужих функціях.
Неминучим наслідком цієї аксіоми стане відповідь будь-якого програміста на питання про розроблюваний їм коді: "Він жахливий, найбільше мені хочеться плюнути на нього і почати все спочатку."
Чому він жахливий?
"Ось," - скажуть вони - "подивися на цю функцію, вона займає аж дві сторінки! І велика частина коду не потрібна! Я не розумі навіщо потрібна половина з тутешніх викликів API."
Перед випуском нової версії електронних таблиць від Borland для Windows преса постійно цитувала хвалькуваті висловлювання засновника Borland Філіпа Кана (Philippe Kahn) переваги Quattro Pro над Excel через те, що він переписаний з нуля. Вихідний код повністю новий! Начебто він може проржавіти.
Вважати, що новий код краще старого, безглуздо за визначенням. Старий код Превір практикою. Його тестували, знайшли багато глюків і виправили їх. З ним все гаразд. У ньому не заведуться глюки від того що він лежить на жорсткому диску. Навпаки! Програма що, іржавіють навіть при знаходженні в гаражі старі жигулі? Або на плюшевого ведмедя зі старих ганчірок, якого саме матеріал робить огидним?
Повернемося до тієї двохсторінковій функції. Вона всього лише промальовує вікно, але з невідомих причин обросла масою незрозумілого коду, я в курсі. І я обьясню чому: це виправлення глюків. Ось цей шматок коду виправляє глюк, що виникав у Каті, при запуску програми на комп'ютері без Internet Explorer'а. Он той виправляє глюк, що виникає в умовах нестачі пам'яті. Ще один виправляє глюк, що виникає коли користувач раптово виймає дискету з файлом, над яким працює наша програма. А цей жахливо виглядає виклик LoadLibrary забезпечує працездатність програми на ранніх версіях Windows 95.
Для виявлення кожного з них було потрібно багато тижнів працювати з програмою на практиці. Цілком можливо, що програміст витрачав кілька днів на воспорізведеніе їх в лабораторних умовах і виправлення. Швидше за все для виправлення довелося написати всього пару рядків коду, а то і просто змінити пару символів, але на ці символи пішло дуже багато часу і роботи.
Відмовляючись від старого коду і починаючи писати новий з нуля, ви втрачаєте всю цю інформацію. Ви втрачаєте все накопичені виправлення глюків і багато років програмістської роботи.
Разом з кодом ви відмовляєтеся від ринкового лідерства, даруєте кілька років конкурентам, повірте, в сфері розробки програм це дуже багато.
Кілька років продаючи стару версію коду через брак нової, не маючи можливості вносити серйозні зміни і реагувати на ринкові вимоги, ви самі себе заганяєте в дуже небезпечну ситуацію. З таким же успіхом можна просто закрити фірму на цей час.
І при цьому ви витрачаєте величезну кількість грошей на написання вже написаного коду.
А чи є альтернатива? Начебто ніхто не сперечається з низькою оцінкою якості старого коду Netscape. Знаєте, може він і був поганий, але відмінно працював на величезній кількості комп'ютерів.
Коли програмісти називають код жахливим (як завжди), швидше за все це викликано однією з трьох причин:
Перша з них пов'язана з архітектурою. У коду може бути неправильна структура. Мережевий код, наприклад, може самостійно промальовувати вікна, хоча це справа коду графічного інтерфейсу. Подібні недоліки можна виправляти по одному, обережним переміщенням і реструктуризацією коду, зміною інтерфейсів. Це під силу одному, обережно працює і перевіряти ще раз всі зміни, програмісту. І в старому коді можна дуже серйозно змінити архітектуру. У Juno ми одного разу витратили кілька місяців на переробку архітектури: просто переміщаючи код з місця на місце, вичищаючи його, створюючи осмислені основні класи та чіткі інтерфейси між модулями. Ми обережно працювали з основною масою коду, не вносячи нових помилок і не відмовляючись від старих напрацювань.
Ще одна причина через яку програмісти вважають код безнадійно зіпсованим - його неефективність. Кажуть, що код промальовування сторінок в Netscape був дуже повільним. Але це стосується дуже маленькій частині проекту. Для виправлення вам не треба переписувати все. При оптимізації за швидкістю 1% роботи приносить 99% результатів.
І третя причина - код може виглядати потворно. Я працював над проектом з типом даних FuckedString (ЕбанаяСтрока). В іншому проекті за початковим угодою імена функцій починалися з підкреслення, але пізніше перейшли на більш поширене "m_". В результаті одна половина функцій починалася з "_", а інша з "m_", виглядало це жахливо. Чесно кажучи, такі проблеми вирішуються за п'ять хвилин банальним скриптом в Emacs, а не переписуванням коду з нуля.
Немає ніяких підстав вважати, що розпочата заново робота буде зроблена краще ніж минулого разу, дуже важливо не забувати про це. Швидше за все її буде робити інша команда, так що ви навіть не будете "більш досвідченими". Ви повторіть більшість зроблених в минулий раз помилок і додасте до них нові.
YARPP powered by AdBistro