…Культурні відмінності між програмістами мікро і мейнфрейм

Original: http://www.stevemcconnell.com/articles/art01.htm

Число людей, які пишуть програми для мікрокомп’ютерів вибухнула в останні п’ять років. Департамент США праці повідомляє менше, ніж 1,5 мільйона чоловік, що працюють в різних роботах з програмування у всіх середовищах програмування (DOL 1990). Але цифри з мікрокомп’ютера індустрії припускають, що набагато більше людей, ніж ті, що програмування мікрокомп’ютерів – Borland International, наприклад, було продано більше 2 мільйонів копій Turbo Pascal для IBM PC (Kahn 1989), і це тільки одна мова продукт від однієї компанії ,

Незважаючи на суму активності в мікрокомп’ютерів, розробка програмного забезпечення мікрокомп’ютера в значній мірі ігнорується програмно-інженерного співтовариства. Швидкий погляд через останніх статей в IEEE Software і комунікацій ACM показує статті про вбудованих систем, систем реального часу, паралельної обробки, Ada, LISP і Unix, але кілька статей на C, Basic, Microsoft Windows, на Apple Macintosh, або інші теми, що представляють особливий інтерес для програмістів, які працюють на мікронів.

Автори, які писав про програмної інженерії протягом 10 або 20 років, до цих пір ігнорувала унікальні аспекти розвитку мікрокомп’ютера, по-різному, вважаючи, що розвиток мікрокомп’ютер недостатньою величини, щоб гарантувати навчання про, поступається розвитку мейнфреймів, або просто незрілі і буде поступово зростати в набір мейнфреймів подібних практик. Кожен з цих сприйнять, по крайней мере, частково помиляється. Micros не тільки інший, слабший платформа. Вони являють собою іншу культуру програмування в цілому, той, який слабкіше в деяких відносинах і сильніше в інших, ніж та, вона поступово витісняє. Той, хто хоче, щоб в повній мірі зрозуміти існуючу практику обчислень потрібно прийти до розуміння мікрокомп’ютер підходів розробки програмного забезпечення.

Характеристика типових зусиль розвитку мікрокомп’ютера

Стереотипне процес розвитку на мікро складається з одиночки розробника хакерського на його кухонному столі в досвітні години ранку. Його тільки супутники кілька банок кофеїну багатих коли і нескінченним запасом золотий бісквіта.

У стереотипу, програміст має кілька дизайн списані нотатками на паперовій серветці, але він несе велику частину дизайну в його голові. Він не зробив жодних формальних досліджень, щоб визначити, чи буде його програма буде затребуваною; його натхнення для функціональності і призначеного для користувача інтерфейсу програми надходить від приватних музами програмування. Коли продукт закінчений, він не проходить через будь-якої діяльності офіційного гарантії якості, але звільняє його негайно до програмно-покупки громадськості. Результатом цього є поспішно задуманого, безсистемно написано, схильною до помилок продукт.

Цей стереотип, можливо, були точні 10 років тому і в деякій мірі точним 5 років тому, але мікрокомп’ютер оточення стало досить складним, що продукт, розроблений самотній програміст злому з коду в даний час практично застаріли. Більш типовий проект розробки включає в себе команду програмістів, і що є предметом цієї дискусії. Давайте розглянемо реальні відмінності між мікропроцесорними і розвитку мейнфреймів підходів.

Відмінності в підходах розвитку

Найбільші відмінності між мейнфреймів і розвитку micrcomputer підходів полягають в наступному:

*Мікрокомп’ютер програміст має машину, повністю присвячений його використання.
*Мікрокомп’ютер програміст волів би робити помилки і виправити їх, ніж йти на великі зусилля, щоб уникнути помилок в першу чергу.
*Прийняття рішень влади проштовхується вниз до рівня окремого програміста.
*Коректність не є найбільш важливою характеристикою продукту; своєчасність.
*Типовий мікрокомп’ютер програміст відрізняється від свого аналога для мейнфреймів.

У наступних підрозділах розглянемо кожен з цих відмінностей більш докладно. Моя точка зору виходить від витрачати близько 80 відсотків мого часу протягом останніх десяти років роботи в мікрокомп’ютер середовищах і близько 20 відсотків працюючих в середовищах мейнфреймів.

виділена машина

Маючи машину, присвячений одного програміста змінює кілька аспектів, як працює програмістом.

Коли машина призначена для індивідуального програміста, рівень підтримки програміст може бути значно поліпшена. Середовище може включати в себе компілятор, присвячений отладчиков, автоматизованих контрольно-вимірювальної апаратури, а також всебічну допомогу онлайн для мови програмування і інших інструментів. Середовища розробки мікрокомп’ютера носить інтерактивний характер; наприклад, навіть в найгірших умовах ви можете редагувати, компілювати, виявити помилки і виправляти помилки в програмі, не виходячи з редактора програм. Цей рівень підтримки є набагато менш поширені на великих ЕОМ.

Мікрокомп’ютерні укладачі, як правило, мають більш швидкі часи обороту. У середовищі мейнфреймів 15 хвилин поворот відносно швидко. Це більше часу вступає в силу для програміста, щоб перевірити на наявність помилок синтаксису, а вийшло зовсім логічних помилок, ніж для компілятора зробити це. На мікрокомп’ютером з майже миттєвою поворот, часто буває більше часу, ефективно мати компілятор перевірити програму на наявність помилок синтаксису, неоголошені змінні і впорядкування аргументів викликів підпрограм, ніж перевірити ту ж інформацію вручну.

Інструменти на мікронів, як правило, використовуються по-різному. Debuggers використовуються, щоб знайти помилки так само, як вони знаходяться в середовищах мейнфреймів. Але оскільки вони є досить інтерактивним і дуже символічно, вони також широко використовуються в якості автоматизованих інструментів коду перевірки. Після того, як розробник компілює свій код, він крокує по коду рядка за рядком в відладчик, щоб переконатися, що він робить те, що він створив це робити. Якщо ви вважаєте, що ваші колеги можуть бути об’єктивними про помилку під час інспекції коду, спробуйте свій комп’ютер! У дальньому кутку мейнфреймів відносини, Харлан Міллс каже, що “інтерактивний відладчик є видатним прикладом того, що не потрібно” (Mills 1986). Він, здається, не знають про ефективність використання, як це. Я не маю на увазі, щоб виділити Міллс; його настрою були вторить багато з найвидатніших людей в програмної інженерії, і я як правило, один з його найбільших прихильників. Але це не зовсім ясно мені, що розробники програмного забезпечення, які критикують деякі аспекти мікрокомп’ютер практики розвинених дер тию в повній мірі усвідомлюють, що вони критикують.

Інший ефект збільшення обсягу апаратної підтримки даного мікрокомп’ютер програміст є те, що діяльність в області розвитку не настільки чітко розділити, як вони на багатьох проектах мейнфреймів. Наприклад, проекти в галузі розвитку мейнфреймів часто створюють відмінність між “кодування” та “модульного тестування.” Етапом кодування вважається завершеною, коли програміст закінчить введення коду в комп’ютер – перш ніж він буде навіть компіляції. Програміст в цій точці руки код для тестера для незалежної компіляції, тестування та інтеграції. У більшості магазинів мікро, ідея перетворити код знову для інтеграції без першої компіляції, занять спортом і ретельного тестування було б отримати дуже холодний прийом. Кожен програміст має більш широке коло обов’язків для коду, який він створює.

Основна різниця між цими двома середовищами полягає ступінь, в якій вони підтримують навчання програмуванню. Простий факт, що програміст може скласти програму, запустіть її, і побачити результати протягом декількох секунд, а не годинник робить велику різницю як в тому, як і в тому, як швидко програміст дізнається про програмування. Люди вчаться через зворотний зв’язок, і MICROS поліпшити якість і кількість зворотного зв’язку, що програмісти отримують про свої програми.

Різниця між запобіганням та виправленням помилок

Деякі з відмінностей між цими двома культурами виникають тому, що прихильники однієї культури уникнути помилок і інших захисників виправляючи їх. Багаторічний досвід навчив програмістів мейнфреймів, що краще витрачати час, щоб не допустити помилок, ніж витрачати час на виправлення їх пізніше. Харлан Міллс стверджує, що суворі підходи до розвитку необхідні, оскільки в іншому випадку програмісти можуть витратити 50 або більше відсотків свого часу на налагодження (Mills 1983). Міллс робить це чітке виклад традиційного заперечення проти Fix-It-пізніше підходу:

Налагодження не тільки показує відсутність концентрації і цілісності конструкції, але також великий перетягнути на продуктивність. Якщо хтось пише сотні рядків коду в один день, а потім займає два тижні, щоб отримати його налагоджена, вони дійсно тільки написав десять рядків в день (Mills 1983).

Типова мікрокомп’ютер точка зору відрізняється. Досвід роботи на тисячні навчив багатьох програмістів, що краще взяти час, щоб виправити помилки, ніж витрачати час на авансові накладні витрати, які часто не окупиться в довгостроковій перспективі. Бажання уникнути великих витрат часу на налагодження мейнфрейми виникає з дійсного міркування в цьому середовищі, але це залежить від наявності помилок, які зайняти кілька днів, щоб знайти. З сьогоднішніх високо інтерактивних отладчиков, це рідкісна помилка, яка вислизає досвідчений програміст для більш години. Уявлення про те, що покарання за погану роботу витрачає 50 відсотків налагодження проекту рідко застосовується до мікронів. Коли ви зрозуміли, що покарання ближче до 10 відсоткам, ваги наконечник від отримати це право вперше в сторону отримати це зробити з мінімальним фіксованим накладних витрат і помірною кількістю налагодження.

Це не означає, що вгору за течією діяльність аналізу вимог і архітектурного проектування менш важливі, ніж на тисячні на мейнфрейми. Це означає, що віддає від діяльності по забезпеченню якості низького рівня, такі як докладні огляди дизайну і огляди коду не так велика в мікрокомп’ютер, як в середовищі мейнфреймів.

Індивідуальне розширення прав і можливостей

Мікрокомп’ютери більш поширений, ніж мейнфрейми, і мікрокомп’ютер магазини більш схильні розподіляти повноваження щодо прийняття рішень теж. Вони штовхають його вниз до людей, які змушені жити і виконувати рішення. (Традиція порівняння організації комп’ютерної системи для організації управління повертається через кілька років – по крайней мере Structured Design Yourdon і Костянтина (1979) Цікаво зауважити, що об’єктно-орієнтоване програмування -., В яких контроль є відносно decentralized– Доросле в той же час, як децентралізованих комп’ютерів і децентралізованих структур управління людини.)

Мабуть, найкращою ілюстрацією різниці між мікро- і мейнфреймів розвитку підходів – з точки зору мікрокомп’ютера – походить від відносин між Microsoft і IBM. IBM представляє уособлювали підходу мейнфрейма, Microsoft мікро підходу. Обидві компанії мали значний зіткнення корпоративних особистостей в їх спільній розробці OS / 2. Після того, як компанії розійшлися, ця історія поширюється на Microsoft:

Microsoft і IBM були в гонці на човні з дев’яти чоловік в кожному човні. Microsoft була гребні вісім чоловік і одна людина рульове управління. IBM була одна людина, гребних і вісім чоловік рульового управління. Після програшу в гонці з великим відривом, IBM замовив три місяці, два мільйони доларів вивчають, щоб визначити, яким чином вони можуть виграти наступну гонку. Після розширення дослідження до шести місяців до п’яти мільйонів доларів, вони, нарешті, прийшли до висновку: одна людина робить греблю потрібно гребти сильніше.

Хоча IBM програмісти, ймовірно, не погодяться з тим, як вони це історія характеризує їх efforst розвитку, історія дає розуміння того, як мікрокомп’ютер програмісти сприймають практику розробки мейнфреймів. Моє власне припущення, що багато розробників програмного забезпечення для мейнфреймів виграють від задаватися питанням періодично чи медицина процедури-і-стандарти, які вони використовують може бути гірше, ніж хвороба він призначений для лікування.

Різниця в централізації відноситься і до клієнтів програмного забезпечення. Багато програм мейнфрейми написані відділ MIS для внутрішнього замовника. Відділ MIS намагається зберегти якомога більше контролю над системою, як це може: послуги програмування, вихідний код, призначені для користувача дані, та й самого обладнання. Відділ MIS є постачальником єдиного джерела для одного полоненого аудиторії. програми мікрокомп’ютера, як правило, написані для зовнішніх замовників. Замість того, щоб зберегти повний контроль над системою, мікрокомп’ютер магазин відмовляється контроль програмних послуг, призначених для користувача даних і самого обладнання. Якщо клієнт не любить мікрокомп’ютера продукт, він купує конкуруючий продукт замість цього. Результатом є те, що розробники мікрокомп’ютер змушені бути ближче до свого клієнта, ніж розробники мейнфреймів. В результаті того, щоб бути ближче до клієнта, що розвиток бере на себе інший набір пріоритетів, ніж часто передбачається в середовищі мейнфреймів.

Коректність і Своєчасність

Багато програм PC не життя критично, і багато користувачів вважали за краще б мати програмне забезпечення з помилками – скоро – чим немає програмного забезпечення на всіх. Таким чином, завдання початкового розвитку переходить від “Як розробити високонадійну програмне забезпечення в розумний проміжок часу” до “Як ми швидко розробляти програмне забезпечення, яке є досить надійним?”

Наскільки гарні практики мейнфреймів відповідаючи на друге питання? Ми можемо зробити грубу оцінку. Нижня межа для невеликого проекту програмного забезпечення, ймовірно, близько 16 000 рядків коду (LOC). Згідно з моделлю COCOMO Barry Boehm, в номінальному, 16 000 LOC проект органічного режиму може бути вироблено близько 350 LOC на програміста місяць (Boehm 1981). Кейперс Джонс повідомив, що в 1977 році за проектами, щонайменше 16000 рядків коду, продуктивність коливається від 125 до LOC на програміста місяць (Jones 1977). Кращий показник продуктивності мейнфреймів я бачив був для чистих приміщень проекту, який усередненої 740 LOC в місяць з 3,3 дефектів на KLOC під час сертифікаційних випробувань (затримуватися і Міллса 1988).

Успішні, своєчасні релізи продуктів в світі мікрокомп’ютер потрібна продуктивність не порядку від 125 до 740 ВХ в місяць, проте, але за наказом від 1000 до 2000 LOC в місяць. Традиційний підхід мейнфреймів немає відповіді на питання про швидкий розвиток на мікронів. методи підвищення продуктивності, які виробляють 1500 рядків коду в місяць є конкурентним необхідністю. Якщо рівень продуктивності передбачає також від 10 до 20 помилок на KLOC при тестуванні системи, так і буде. У світі мікрокомп’ютерів, що це невелика ціна, щоб заплатити, щоб задовольнити більш важливої мети надання клієнтам з функціональністю, необхідної в той час їм це необхідно.

Типові Програмісти

Типовий мікрокомп’ютер програміст має інший профіль, ніж його аналог мейнфрейма. Статистично, він молодший, має інше сімейний стан, і має менше років досвіду. У корпорації Microsoft, наприклад, близько половини програмістів у віці від 20 до 29 років, поодинокі, так і в середовищі роботи повний робочий день в перший раз. Кожен з цих факторів робить різницю між мікро- і мейнфреймів програмістів.

Розрив в поодинці віці може мати значний ефект. Франк О’Грейді написав чутливий статтю під назвою “гірке розчарування”, в якому він визначив різницю у віці, як один з трьох найбільших перешкод на шляху переходу від мейнфрейма до мікро роботу (О’Грейді 1990). Він каже,

Цей досвід досить принизливо, коли ви 22, будучи заляканими старих програмістів гарячої постріл. “Що ви маєте на увазі, ви до сих пір не отримати його? Скільки разів я повинен вам це пояснити?” Це зовсім інша справа, коли ти 42, і ви в даний час соромили і принижували 25-річного віку.

Різниця у віці і сімейний стан пов’язаний з високим, підприємницький дух багатьох мікрокомп’ютер магазинів. О’Грейді зазначає, що перше, що він помітив, після перемикання на мікрокомп’ютер магазину було те, що ніхто ніколи не пішов додому. Це легше зробити, якщо ви 25 і сингл, ніж якби ви 45 і в шлюбі з дітьми. Розробка програмного забезпечення для багатьох мікрокомп’ютер програмістів це місія і пригода. Для мейнфреймів програмістів це рідко більше, ніж робота, навіть якщо це хороша робота.

Стереотип мікрокомп’ютер програмістів, як хакери також містить більше, ніж зерно істини. Оскільки працівники молодше і підприємницький дух високий, програмісти менш зацікавлені в формальних процедур і більше зацікавлені в результатах. Це призводить до більш ризикованих, агресивнішою практики в галузі розвитку. Оскільки керівники таких компаній, як Microsoft, Borland, Aldus і (раніше) Ashton-Tate були самі програмісти, вони краще зрозуміти гострі відчуття від стільця штанів програмування; Таким чином, хакерство має підтримку на найвищому рівні мікрокомп’ютера промисловості.

Отримані уроки

Багато відмінності між ПК і розвитку мейнфреймів стилів є другорядними для двох платформ, а не фундаментальне значення для будь-якого з них. Через відмінності випадкові, програмісти в кожному середовищі є можливість вчитися у програмістів в інший.

Головний недолік програмістів, які працюють на мікронів є те, що вони повторюють всі помилки своїх попередників мейнфреймів. Мікрокомп’ютерні програмісти часто не знають практики, які успішно використовуються в середовищах мейнфреймів протягом 20 років. У 1988 році я був присутній на неформальній дискусії, яка включала програмістів, які працюють на третьому випуску Aldus PageMaker. Для третього випуску, вони найняли консультанта програмування-практик, який рекомендував підхід, який був новим для них: спробувати визначити свої вимоги до кодування і тестування. Програмісти були дуже раді цій новій ідеї.

Очевидно, що програмісти, які не знають про визначення вимог є щось дізнатися про розробку програмного забезпечення. Але такий недолік знань навряд чи незвичайним в світі мікрокомп’ютер, і багато великий проект мікрокомп’ютер був проведений без переваги контролю вихідного коду, хороший процес розробки стратегії, гарантії якості, або навіть офіційний графік. Але перш ніж звільнити більше випадковий підхід ALDUS, в розуміють, що це дійсно отримував їх до третього виходу в світ дуже успішний продукт, і це краще, ніж більшість компаній. Інше прийде з часом, у міру необхідності, так само, як це було в світі мейнфреймів.

Мейнфреймів програмісти можуть також дізнатися дещо про практику програмування. Вони можуть навчитися бути більш критично бюрократичного накладних витрат – іноді навмисні, формальні процедури не є найкращим способом для досягнення цілей проекту. Вони можуть дізнатися про нові методи програмування – за допомогою отладчиков і інших інструментів ефективно. Вони можуть наполягати на тому, що їх апаратного і програмного забезпечення забезпечують середовища розробки, які є настільки потужними, як ті, які доступні на мікрокомп’ютерів.

Найбільше, мейнфрейми програмісти можуть перегляне важку корочку припущень, які стають barnacled на свої звички і практики протягом останніх 20 років. Багато з припущень все ще законно, але багато хто з них були визнані недійсними за рахунок зміни технології і вдосконалених методів розвитку. Можливо, успіх неортодоксальних мікрокомп’ютер-programmming практики буде шпори, що тицяє таку повторну перевірку.

В кінцевому рахунку, це не важливо, хто попереду і хто за нині. Ступінь, в якій програмісти з обох середовищах вчитися один у одного визначатиме, хто рухається вперед з рівнем техніки в майбутньому і хто відсувається на тій же купі Scap як шаблонів блок-схеми, перфокарти, і кодування колодки.

Посилання

Бем 1981. Бем, Barry W. Software Engineering Економіка. Englewood Cliffs, Нью-Джерсі: Prentice-Hall, Inc., 1981.

DOL 1990. У. С. Департамент праці. “1990-91 Робота Перспективи Коротко,” Перспективи Професій Quarterly, Весна 1990, Вашингтон, США D.C.: Управління урядового друку.

Джонс, Т. Кейперс, 1977. “Програма якості та продуктивності програміста,” IBM Technical Report TR 02,764, січень 1977, стор. 42-78.

Кан 1989. Кан, Філліпп. “Програмне забезпечення в майстерність 90-х років,” Update програміста, вип. 7, немає. 4A (липень 1989), с. 39-44.

Затримайтеся і Міллс 1988. Linger, Річард У. і Харлан Д. Міллс. “Приклад в Cleanroom Software Engineering: Система IBM COBOL Структурування фонду,” Праці 12-ї щорічної комп’ютерного програмного забезпечення і додатків конференції, Лос-Alamitos, Каліфорнія: IEEE CS Press, 1988.

Міллс 1983. Міллс, Харлан D. Продуктивність програмного забезпечення. Бостон, Массачусетс: Little, Brown, 1983.

Міллс 1986. Міллс, Харлан Д. “Структурне програмування: Ретроспектива і Проспект”, IEEE Software, листопад 1986, стор 58-66 ..

О’Грейді 1990. О’Грейді, Френк. “Гірке розчарування: Покоління Програмісти хоче знати – Там Життя після COBOL,” американський програміст, т. 3, NOS. 7-8 (липень / серпень 1990), с. 44-49.

Йордан і Костянтина 1979. Йордан, Едвард і Ларрі Л. Костянтин. Структурний дизайн: Основи дисципліна комп’ютерної програми і системи проектування, Englewood Cliffs, Нью-Джерсі: Yourdon Press, 1979.

Про автора

Макконнелл є незалежним консультантом з програмного забезпечення, розробка та автор Досконалий код: Практичний посібник з будівництва програмного забезпечення, як очікується від Microsoft Press на початку 1993 року