Роберт Мартин: "Будущее программирования" / Robert Martin: "The Future of Programming"

C++, Objective-C и история чудесного возрождения

Что с нами не так?

В прошлое, чтобы понять настоящее

Новая эра : вниз по водопаду и попытка вернуться к Agile

Инженеры и бизнес. Риски и ответственность.

Выбор будущего

Роберт Мартин — автор книг "Чистый код", "Чистая архитектура", ряда других книг по разработке ПО, один из авторов Agile-манифеста. YouTube подбросил мне в список рекомендаций его интереснейшее выступление "Будущее программирования".

После поисков в сети не нашел перевода и даже транскрибации на английском. Наткнулся только на просьбы сделать перевод на нескольких форумах и решил, что выступление этого действительно достойно. Это интересный экскурс в историю от зарождения индустрии до наших дней. И да, оно больше про историю и настоящее, чем про будущее. Название обманывает ))  Перевод не дословный, поэтому рекомендую по возможности посмотреть и само выступление: https://www.youtube.com/watch?v=ecIWPzGEbFc.

Небольшой дисклеймер. Выступление является агитационным и местами идеалистичным. Мнение переводчика не обязано совпадать и не всегда совпадает с мнением Роберта Мартина. Например в отношении причины подавляющего числа мужчин среди программистов (наверное у каждого на этот счёт своё мнение), консерватизма в отношении языков программирования или неизбежности жесткого регулирования всей отрасли.

Ряд вопросов покажется чуждым для разработки на платформе 1С, но есть и те, что имеют к нам непосредственное отношение.

В общем читайте или слушайте и делайте выводы сами.

C++, Objective-C и история чудесного возрождения

Среди вас наверняка есть люди, знакомые с языком Objective-C. Он был создан больше 36 лет назад в 1980 году Брэдом Коксом. Зачем он это сделал? Он просто хотел улучшить язык C. Точно также как Бьёрн Страуструп, который создал C++ в том же самом 1980 году.  

Брэд Кокс был программистом на Smalltalk , но он был вынужден программировать на C. Ему это не нравилось. Поэтому он написал небольшой препроцессор для C, который делал его хоть немного похожим на Smalltalk, и назвал это Objective-C. Бьёрн Страуструп был программистом на Simula, но он был вынужден программировать на C. Ему это не нравилось. Поэтому он написал небольшой препроцессор для C, который делал его хоть немного похожим на Simula, и назвал это "C with Classes".  Потом какой-то парень пришел к нему и сказал, что это неподходящее имя, и тогда язык был переименован в C++. Оба языка были созданы с одной целью, в одно время и развивались параллельно.

Objective-C стал широко известен задолго до C++. В ранних 80-ых, будучи молодым программистом на C, я искал для себя новые возможности. И именно Objective-C  был тогда тем, о чем говорили все вокруг. Он казался хорошим языком, подходящим для многих компаний. Это очень впечатляло.  

Но потом произошло кое-что странное… Бьёрн Страуструп написал книгу…

Большинство программистов на C и на производных от него языках знают книгу Кернигана и Ритчи "Язык программирования Си". Если вы программист на C, то у вас должна быть эта красивая белая книга с бумажным переплетом и большой голубой буквой "C" на обложке. В ней около 150 страниц и если вы ее откроете, то увидите очень приятный шрифт, хорошо структурированный текст. Нумерация глав у нее начинается с нуля, а не единицы. Нумерация с нуля была хорошим маркетинговым ходом. В итоге каждый гик знает об этом факте и этой книге.  

Так вот, в 1986 Бьёрн Страуструп опубликовал книгу "Язык программирования С++". Она была не белой, а бордовой. Вместо голубой буквы "С" на обложке у нее на обложке была золотая буква "С". И рядом с ней еще два плюса. Но у нее был точно такой же бумажный переплет и тот же самый форм-фактор. Вы открывали её и видели тот же самый шрифт, такую же разметку и таким же образом структурированный текст. Она была написана похожим языком. А главное, нумерация глав в ней также начиналась с нуля вместо единицы. И все программисты сказали : "О!  Это же новый Си!". И они все бросили Objective-C и ушли в C++. Компания Брэда Кокса, пытавшаяся продавать Objective-C, была слита в канализацию.

И это должен был быть конец. Objective-C должен был умереть в этот момент. Если бы не один поворот судьбы.  Этим поворотом стал успех компании Apple в начале двухтысячных. Apple продавала компьютеры Макинтош в 1983 году, а до этого компьютеры Apple 2. У нее были миллиарды долларов и один молодой человек по имени Стив Джобс тогда решил, что его компании нужен хороший управляющий. Он немного поискал вокруг и нашел худшую кандидатуру для этого — человека по имени Джон Скалли. Скалли до этого был вице-президентом Пепси Колы. Вам наверное кажется странной идея позвать такого человека для управления Хай-Тек компанией, но аналогичная мысль не пришла тогда в голову Стива Джобса. Выбор Скалли оказался фатальным, этот человек утянул компанию вниз. Но Скалли был достаточно грамотен как политик, чтобы перед этим уволить Стива Джобса из его же собственной компании.

И Стив Джобс уйдя из Apple с несколькими миллиардами долларов в своём кармане сказал "Я ещё покажу этим парням". Он основал новую компанию Next и стал производить железо, намереваясь конкурировать и уделать этих гадов из Apple. А в это время на улице ходила толпа никому не нужных парней с плакатами "Буду программировать на Objective-C за еду". И Джобс нанял этих парней для создания операционной системы для Next.

Компьютеры от Next не снискали популярности. Я знаю только одну компанию, которая купила один из них и это компания, которой я сейчас владею. Но дальше снова был крутой поворот. Спустя несколько лет компания Apple избавилась от Скалли и обратилась к Стиву с просьбой : "пожалуйста, вернись к нам, похоже, что теперь мы не обойдемся без тебя". И Джобс сказал: "Хорошо, я вернусь, но тогда я прихвачу с собой всю мою команду". Так в Apple появилась целая куча программистов на Objective-C и написанная на нём операционная система для Next. Затем они стали работать над iPad.

Так язык полностью возродился. К сожалению.

Что с нами не так?

Теперь собственно вопрос. Почему мы, программисты, никогда не довольны нашими языками? Никогда!  Сколько сейчас языков? Сотни и сотни и завтра появятся еще сотни. Сколько языков появилось за последние пять лет?  Swift, Golang, Dart… и еще целая куча. И сколько еще нам будет нужно ближайшие годы?

Что с нами не так? Почему мы постоянно ищем этот "лучший язык". И что мы находим в процессе этого поиска? Вот выходит на свет новый язык, и что? Он чем-то лучше? Ну да, у него есть пара фич из одного языка, пара фич из другого, один с немного более безопасной типизацией, другой вдруг наоборот с менее безопасной типизацией. Один с большей долей динамической типизации, другой наоборот с меньшей долей динамической типизации….. Может быть мы как индустрия должны наконец остановиться в этой легкомысленной гонке за золотым молотком. Может быть нам нужно в какой-то момент стать взрослыми и сказать "Было бы хорошо, если бы мы говорили на одном языке хотя бы следующие 20 лет, без того чтобы постоянно выбрасывать и рвать на клочки всё что мы имеем".

—  Босс, у меня есть новый язык программирования, он намного лучше!

—  Почему?

—  Потому что он новый!

—  Ох, не знаю куплюсь ли я на это в этот раз…

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

—  Ну хорошо, работай на нём.

—  Босс, у меня есть новый язык программирования, он намного лучше!

—  ……

Но это разговор о будущем программирования. И прежде чем продолжить мне бы хотелось провести небольшой эксперимент. Я прошу встать всех программистов, находящихся в аудитории :

А теперь я прошу сесть всех мужчин. Только мужчин. Дамы, пожалуйста стойте :

Что не так в этих картинках?  

Как так получилось, что в нашей индустрии настолько доминируют мужчины? Ведь так было не всегда. На заре программирования доля женщин в индустрии составляла примерно половину. Не ровно 50%, но около 50%. И даже когда я рос, когда я был молодым программистом, в первой компании, где я работал примерно треть программистов составляли женщины. И это были не юные 20-летки. Им было по 30, 40, 45 лет. Это были зрелые люди. Почти все программисты были зрелыми людьми. Тогда, будучи 18-летним ребенком мне казалось, что я окружен старцами. И значительная их часть была женщинами.

Через десять лет после этого (я уже работал на другую компанию) у нас было намного больше программистов и почти всем из нас было от 20 до 29 лет. Нас было около 50 программистов и среди нас было всего 2 или 3 женщины.

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

В прошлое, чтобы понять настоящее

Мы начнем с изучения истории, с 1936 года. А вот здесь я, нарисованный синей стрелкой. Я родился в 1952, всего несколько лет от точки отсчета.

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

Есть ещё такой парень, Чарльз Петцольд  (Charles Petzolde). Он известен как автор целой кучи книг для Microsoft. Но он также написал книгу "Читаем Тьюринга"(The Annotated Turing). Он взял публикацию Тьюринга , разобрал её на маленькие кусочки и затем заботливо окружил каждый из этих кусочков историей, объяснениями и шаг за шагом прошел по исходной публикации, рассказывая, о чем именно говорил Тьюринг и почему. Прекрасная работа, она настолько хороша, что я читал её дважды.  Рекомендую вам прочитать обе эти публикации — и Тьюринга и книгу Петцольда.

Итак, Тьюринг, представил в 1936 году концепцию, в которой мы с вами можем узнать "компьютер". Он также изобрел другие вещи — подпрограммы,  макросы, переменные, бинарный код.

К 1939 году Тьюринг работал над дешифраторами и несколько машин, которые он использовал для взлома шифров, использовали реле. Они выглядели вот так :

Реле это просто катушка провода. Прохождение тока через эту катушку порождает магнитное поле, которое притягивает маленькую металлическую пластину на конце реле, называемую якорем. Другой конец якоря замыкает контакт и по внешней металлической части реле начинает проходить электрический ток. Это было изобретение для телеграфов, сигнал которых мог идти всего около 20 миль, а затем его необходимо было усиливать, чтобы он не угас. Угасающий сигнал доходил до реле, его хватало чтобы замкнуть якорь и новый генератор с новой силой отправлял сигнал дальше на следующие 20 миль. Вот почему это устройство называется "реле", что в переводе означает "эстафета", оно передает сигнал дальше как эстафетную палочку. Устройство подобное этому может надежно выполнять переключение около 10 раз в секунду. Таким образом Тьюрингу в то время была доступна только эта небольшая частота.

Вакуумные лампы тогда уже существовали, но они были ужасно ненадежны. Многие из них не могли удерживать вакуум достаточно долгое время и их спирали быстро выгорали. Они не могли массово производиться в нужных количествах. Они были быстрыми, гораздо быстрее реле. Но они были настолько ненадежными, что вместо одной лампы приходилось объединять их в платы платы по 20 штук и более, что часто делало их использование невозможным. В середине Второй Мировой был построен колоссальный комплекс из этих ламп и результаты всё еще получались ненадежными. Поэтому в большинстве случаев вычислительная техника полагалась на реле.

1945 год. После окончания войны была создана машина ACE  (Automatic Computing Engine)   — один из первых компьютеров в мире.

На фотографии за компьютером сидит не Алан Тьюринг, а настоящая женщина, обратите на это внимание. ACE — это машина, которую помог спроектировать Тьюринг. Он разработал набор инструкций, ширину слова, саму концепцию этой машины.  

ACE могла складывать, но не вычитать. Чтобы выполнить операцию вычитания необходимо было инвертировать биты, выполнить побитовый сдвиг и затем сложить. На самом деле Тьюринг даже не хотел вводить операцию сложения. Он считал, что достаточно побитовых операций И, ИЛИ, НЕ, с помощью них уже можно было выполнять сложение. Но разработчики оборудования посчитали, что это замедлит вычисления и добавили операцию сложения.

Посчитайте сколько гигабайт сейчас в вашем смартфоне. Сколько гигабайт сейчас в комнате, где вы находитесь. Сравните это с тем, что было доступно в 1945 году.

Компьютер ACE использовал в качестве памяти "линии задержки" на основе ртути. Только представьте себе это. Трубка с жидкой ртутью, с одной стороны находится динамик, а с другой специальный микрофон. Звук с высокой частотой отправлялся из динамика в трубу со ртутью, принимался на другой стороне микрофоном и отправлялся обратно на динамик.  Это была циклическая, замкнутая память, позволяющая хранить 1024 бит в каждой ртутной трубке.  В распоряжении у ACE было 22 таких трубки. Порцией данных было вращающееся в трубках слово длинной 22 бита, по биту в каждой трубке. Это всё, что было у них в распоряжении.

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

Но уже это позволило Тьюрингу сделать большой шаг вперед. Зеленый квадрат на рисунке ниже — это устройство вывода, которое он использовал. Он мог читать вывод компьютера глядя прямо на саму физическую память компьютера как на экран. Он видел нули и единицы, наборы битов, проводил с ними операции. Представлял ими символы используя base32, биты при этом были переставлены в обратном порядке по сравнению с современным представлением base32.

1945 был также тем годом когда были изобретены программный стек и подпрограммы. Тьюринг предложил использовать стек для хранения адреса возврата из подпрограммы, что было действительно новаторской идеей для того времени. Были изобретены числа с плавающей точкой, умещавшиеся в слово из 22-ух бит.  Для этого пришлось написать библиотеку подпрограмм для работы с такими числами.

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

В том же году Алан Тьюринг пишет отчет о проделанной работе, в котором есть примечательные слова: "Нам потребуется большое количество способных математиков, потому что в будущем, вероятно, будет очень много подобной работы".  И далее в этом тексте есть слова: "Одной из сложностей, с которой нам предстоит столкнуться, будет поддержание должной дисциплины, чтобы не сбиться с пути и не потерять то, что мы делаем".

Эти примечательные слова были сказаны им буквально после того как он написал первые несколько тысяч строк программного кода. Уже тогда он понимал проблему, с которой нам предстоит столкнуться на протяжении следующих 60-ти лет. Интересно, как он смог догадаться об этом? )))  Способные математики. Большое их число. И должная дисциплина.

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

В 1945 году количество компьютеров было порядка O(1). Возможно больше одного, например около четырех, но не больше. Количество программистов было того же порядка — их были единицы. Это было 74 года назад. 

1950-ые года. Память на электронно-лучевых трубках, которая могла хранить тысячу бит стоила тысячи долларов. Стоимость памяти была больше 10 долларов за 1 бит. И тогда был изобретен другой тип памяти — память на магнитных сердечниках (core memory). Посмотрите на эти круглые металлические кольца на картинке. Мы намагничивали их пропуская электический ток через проходящие сквозь них провода. После намагничивания кольца, можно было определить факт того, что оно намагничено путем пропускания тока через провод в противоположном направлении. Если кольцо содержало заряд, то оно вызывало ток в другом проводе и этот ток можно было считать. Как и в случае электнонно-лучевых трубок бит данных, хранимый кольцом, при считывании также уничтожался и его требовалось перезаписать.

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

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

Компьютеры перестали производиться в единичных экземплярах. Их становилось больше и к 1953 году компьютеров было уже достаточно, чтобы люди стали задумываться над языками программирования. В 1953 году Джон Бэкус представил язык Фортран. Вы видите пример кода на нем на картинке ниже. В нем был условный оператор и в нем указывались номера  строк для перехода. Нумерация строк была необязательной, она заменяла метки-теги для перехода к ним.

Например условный оператор в строке 703 говорит, что если (IA + IB + IC) отрицательно, то переход выполняется к строке с меткой 777, если результат равен нулю то переход выполняется также на 777, а если положительно, то переход выполняется к строке 704.

Обратите внимание на отсутствие отступов в коде. Мы тогда еще не придумали отступы. Код пробивался на перфокартах — выбивались квадраты на месте заглавных букв и цифр.

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

Затем вы брали пачку перфокарт, относили их к компьютерному залу, где складывали их в корзину. Затем вам нужно было отойти, потому что сами программисты не прикасались к компьютеру. Им даже не позволялось входить в эту комнату. Компьютерные залы управлялись особой разновидностью людей, называемых "операторами компьютеров".  И этим операторам не нравились программисты. Потому что иногда программисты просачивались в компьютерный зал и их приходилось выметать метлой ))

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

Наконец приходили вы, забирали результаты, разворачивали их изучали и…. обнаруживали, что забыли запятую. И начинался отсчет следующих 24 часов. Такова была жизнь программиста в то время. И чтобы хоть как-то справиться с этим мы писали по 5-6 программ за раз. У программистов всегда была такая очередь из программ.

1956 год. Появился LISP.  Он был создан Джоном Маккарти для работ по искусственному интеллекту. И этот язык до сих пор отказывается умирать. Мы пытаемся убить его раз за разом, он он возвращается.  Я бьюсь об заклад, мы все закончим тем, что будем программировать на LISP ))  Потому что остальные языки умирают, а LISP всё время выживает.

И к слову сказать это первый язык для функционального программирования. А ведь мы только недавно начали понимать всю важность функционального программирования.  Много лет спустя.

Между 1954 и 1960 годом IBM продала 140 компьютеров с Фортраном и Лиспом внутри.  

Таким образом количество компьютеров в 1960 году стало порядка 100. От 100 до 900, но порядок был таким. А что можно сказать о программистах? Их из было порядка 1000. Потому что в то время на один компьютер приходилось 10-15 программистов.

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

Кто же становился программистами в то время? Программистов набирали из инженеров, ученых и математиков. У них были ученые степени. Они имели опыт в своей области и они редко были молоды. Обычно их возраст был 30, 40 , 50 лет. Это были зрелые люди. Они понимали что такое проект, что такое расписание и сроки, они не нуждались в куче менеджмента над собой. Это были люди, которым компании доверяли.

А потом появился транзистор. Он был меньше ламп, потреблял меньше энергии, был надежнее и проще в производстве. За короткое время транзисторы завоевали рынок, к 1965 году было произведено 10 000 компьютеров модели 1401.

Это была очень интересная модель компьютера — это была десятичная машина. В IBM приняли решение что всё следует привести к "десятичному" виду. На нижнем уровне операции по прежнему выполнялись в двоичном виде но имели десятичное представление. Разработчики IBM довели эту идею до того, что покупая модель 1401 с памятью 4K вы получали ровно 4000 байт. Не 4096, а ровно 4000. Адресное пространство было "десятичное".

Они сдавали эту машину в аренду по цене 2500 $ в месяц, что сегодня равнялось бы 20 000$. Высокая цена на аренду заставила многие компании задуматься над их покупкой вместо аренды.

И к 1965 году количество компьютеров было уже порядка 10 000 , а количество программистов порядка 100 000. Скорее всего их было 200 000 или 300 000. А ведь прошло меньше 20 лет с тех пор, как Тьюринг написал первую строчку кода.  

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

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

1966 год. IBM производит по 1 000 машин модели 360 каждый месяц. Я работал на одной из таких машин. Я работал на 360 Model 30 и на 360 Model 40. Первая имела 16 KB внутренней памяти, вторая 64 KB. Это был огромный объем памяти. Я помню когда у нас появился первый Мегабайт. Видите вон там синий ящик размером примерно с холодильник? Так выглядел Мегабайт. Он сдавался в аренду за десятки тысяч долларов в месяц. Если бы вы захотели купить его, он бы стоил десятки миллионов долларов. Это было дорогущее оборудование.

Тысячи и тысячи этих машин были выпущены из IBM , это возможно был самый успешный продукт IBM, который принёс им миллиарды долларов.

Это также был год, когда был создан первый объектно-ориентированный язык Simula-67. Он был создан Оле-Йоханом Далем и Кристеном Нюгором в городе Осло. Мы уже имели функциональное программирование и теперь получили объектно ориентированное программирование.

А в 1968 году Дейкстра написал свою знаменитую публикацию, где была обозначена вредоносность оператора GoTo и это было начало революции структурного программирования.

За эти 10 лет мы сделали три главных шага в нашей индустрии — функциональное, структурное и объектно-ориентированное программирование. Они все были сделаны в это время, этими профессионалами.  

А вот и Кен Томпсон и Деннис Ритчи. Тот же самый 1968 год. Мы всё ещё в 22 годах от появления первых строк кода. Эти ребята сидят в подвале AT&T и создают язык С и Unix. И это были дисциплинированные математики.

1970 год. Компания DEC (Digital Equipment Corporation) создает компьютер PDP8 и это был не единственный мини-компьютер того времени. Это была эра, когда все выпускали мини-компьютеры. 50 000 этих PDP8 было лишь вершиной айсберга.

Количество компьютеров было порядка 100 000 , а количество программистов порядка 1 000 000. Миллионы программистов спустя 25 лет с первых строк кода. Снова произошло десятикратное увеличение количества программистов за 5 лет.

Кто были все эти люди?

Новая эра : вниз по водопаду и попытка вернуться к Agile

Вот один из них. Это я. Мне 19 лет и это был возраст, когда я получил свою первую работу как программист. Бог мой, я уже был нанят, чтобы писать на COBOL.

К 1970 году десятки тысяч выпускников CS и EE  (Сomputer Science и Electrical Engineering) начали заканчивать школы. Компьютерные курсы можно было пройти в колледжах. В среде выпускников попасть в индустрию ИТ считалось престижным. Конечно в этом они были правы. И эти десятки тысяч выпускников, устремившиеся в ИТ имели кое-что общее. Мы все были юными. И почти все мы были мужчинами. Именно здесь произошел сдвиг. Доминирование мужчин в ИТ началось здесь. Я помню себя в ВУЗе, как я прикасался к компьютеру, телетайпу, подключенному к компьютеру в Технологическом Институте. Почти все кто был рядом были парнями, всего одна или две девчонки.  

Когда я пришел на свою первую работу у нас было около 24 программистов и половина из них были женщинами. Это было то место, где я программировал на Коболе. А 10 лет спустя у моего работодателя было 50 программистов. И всего три женщины. Я даже помню их имена, чего не скажешь о всех мужчинах из тех пяти десятков. Подавляющее большинство из нас было мужчинами. Точнее говоря мальчиками.

Чтобы не быть голословным, вот графики, которые впоследствии стали известными. Это количество женщин в различных областях науки. Оранжевая линия — это количество женщин в компьютерных науках. Что-то странное произошло, не так ли? Заметьте этот пик и резкое падение в начале 80-ых.

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

Моя первая работа как программиста давала всего лишь 6 900 долларов в год, 570 в месяц.  Но для возраста 19 лет это была куча денег. Я даже мог купить машину. Я даже мог съехать от родителей. Это было круто.

Ещё раз. До этого времени программисты нанимались из опытных сотрудников из других областей. Они не нуждались в куче менеджеров или выстраивании процессов . Они сами знали как управлять своим временем, коммуницировать, понимали что такое договорённости, они знали всё это. Они делали волшебные вещи — виртуальную память операционной системы, покорили Луну, создали ООП, структурное и функциональное программирование, Юникс, язык Си и остальное.  Они определенно знали как добиваться больших результатов.

Какой подход к разработке они использовали? 

Если бы мы отправились назад и понаблюдали за ними, то узнали бы в их процессе некую разновидность "Agile". Как говорят, Agile — это то, что дисциплинированные профессионалы используют в дикой природе ))

Мы знаем что разработчики программ для Шаттла работали итерациями длинной в 6 недель. Да, по нынешним меркам это долго, но всё же это интересный факт. Они закрывали каждый цикл разработки каждые 6 недель. Мы знаем что программисты для марсианской капсулы писали юнит-тесты на разработанные модули с утра и добивались их прохождения к вечеру. Это было чем-то похоже на TDD.

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

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

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

Посмотрите на график — экспоненциальный рост. Количество программистов удваивается каждые 5 лет. Мы начинали всего с нескольких, а сейчас их сотни миллионов. И важное следствие из этого — половина программистов имеет менее 5 лет опыта.

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

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

Что еще поменялось помимо “демографической картины” в отрасли? Поменялось железо. Подумайте о разнице между ACE и моим ноутбуком. Даже нет, подумайте о разнице между PDP 8 и моим ноутбуком. PDP 8 мог исполнять полмиллиона инструкций в секунду. Мой ноутбук сейчас в 10 000 раз быстрее!  PDP 8 имел  4 KБ внутренней памяти. Мой ноутбук — 16 Гигабайт и это кажется немного по сегодняшним меркам. PDP 8 имел диск 32 KБ , а ноутбук сейчас 1 Терабайт SSD.  Триллион транзисторов в моем смартфоне… Что если бы он работал на триллионе вакуумных ламп? Какого размера небоскреб мог бы вместить триллион ламп? Это было бы самое большое здание в мире. На него бы работала бы сеть ядерных реакторов и стоил бы он 50 триллионов долларов. Вся экономика того мира лежит в моей руке ))  А мы сейчас производим их миллионными тиражами чтобы можно было расписаться в Инстаграме. Почувствуйте масштаб изменений в течение жизни одного человека.

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

Что НЕ изменилось? Вам это не понравится.

Не изменились программы. Вы бы смогли узнать код, который Тьюринг написал для компьютера ACE. Да, он бы вам не понравился, но вы бы смогли его понять. Вы бы смогли разобрать код на Fortran. Вам бы он тоже не понравился. Но вы бы смогли прочитать его и даже написать его. 

Я мог бы взять человека из 1968 года, например программиста для PDP, перенести его в будущее, посадить перед моим ноутбуком и показать ему Intellij IDEA. Ему бы потребовалось около 24 часов чтобы оправиться от шока, но потом  он смог бы начать писать код. Я бы показал ему Java и он немного помявшись сказал бы:  "Нуу ладно, Джава так Джава, интересно. Intellij IDEA хороший инструмент, хотя язык Java так себе. ООП? Это та штука с которой я работал в 1967 году, верно?". Никакой революции не произошло.  

Я мог бы взять вас и перенести в 1968 год.  Посадить перед PDP8 с телетайпом и показать как редактировать код на бумажной ленте. И вам бы потребовалось 24 часа чтобы оправиться от разочарования. Но вы смогли бы писать код. Потому что код — это присваивание, условные операторы и циклы. Ничего более. Так было и так будет — это и есть суть кода, как бы мы им не жонглировали.

Если мы и сделали какие-то подвижки в разработке программного обеспечения с 1945 года — это в понимании того, что не следует делать.

• Структурное программирование  — это о том, что не следует делать. Не использовать опасный GoTo.
• Функциональное программирование : не используйте присваивание.
• Объектно ориентированное программирование : не используйте указатели на функции.

Что мы узнали за последние 74 года — это больше о том, что не следует делать, чем о том что нужно делать. Искусство написания программ остается в грубом приближении тем же самым, каким оно было в 1945 году, хотя и с налётом современности.

Что же мы должны были поменять? Уровень профессионализма, который мы потеряли из-за потока юных программистов. И уровень дисциплины, большой недостаток которой мы до сих пор испытываем. Старой гвардии, поддерживавшей дисциплину, больше не было в отрасли. Даже первая волна программистов-карьеристов уже шагнула за свои 40 лет. В 1995 году мы уже видели необходимость изменений.

И тогда Джеймс Греннинг, присутствующий здесь, я, Кен Швабер, Майк Бидл, Кэнт Бэк, Вард Канингем, создатель Crystal Алистер Клокберн и еще несколько человек стали осознавать, что эта эра водопада, в которой мы жили, должна измениться. И мы встретились в месте под названием Сноубёрд, чтобы создать Agile-манифест.

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

А вот эта картинка под текстам — это работа Варда Канингема. Вы можете рассмотреть на ней Мартина Фаулера с безумной бородой, вон там стою я и точно где-то там стоит Джеймс .

Мы написали строки, которые привлекли внимание всего мира. Гораздо больше внимания, чем мы предполагали. Мы же просто пришли на эту встречу, написали этот текст и разошлись по домам )) Эти люди больше никогда не собирались вместе… и я даже не хочу этого. За исключением Джеймса, присутствующего здесь  ))

Инженеры и бизнес. Риски и ответственность.

Agile требует дисциплины. Он часто рассматривается как процесс, но это не процесс. Agile требует не только дисциплины, но и внимания к деталям. Вы должны работать в фиксированных отрезках времени, вы не можете удлинять эти отрезки. Вы должны оценивать задачи в условных единицах. Вы должны поддерживать коммуникации с заказчиком. Вы не можете обойтись без непрерывной интеграции. Вы должны работать в команде. И это всё то, что относится дисциплине, а не просто к процессу.  Это не просто список задач по которому нужно пройтись.

Экстремальное программирование — это то направление Agile, которое больше всего воплощает дисциплину. Оно включает в себя TDD, рефакторинг, приемочное тестирование, подход Simple Design.

Дисциплина гарантирует, что вы будете следовать этическим принципам и принципам морали.  Например "Я буду писать тесты" — это принцип.

Многие из нас чувствовали, что техническая дисциплина — это тот самый клей, который позволял Agile-разработке работать правильно. Agile становится пустым без технических дисциплин. Создаваемый код вырастет во что-то такое, с чем будет всё сложнее и сложнее работать. Вспомните Тьюринга: "сбиться с пути и потерять то, что мы делаем". Еще раз, Agile — это о дисциплине, мастерстве и профессионализме.

Бизнес понимает что такое дисциплина. Любой бизнес понимает что это такое и вы не можете вести бизнес без этого. И поэтому бизнесу действительно понравился Scrum за его простоту, очевидность и дисциплину, которую он предлагает. У вас есть спринты, события, планирование. Это важно для бизнеса. И бизнес подумал: да, это круто нам нужны люди, сертифицированные в этом направлении.

Но бизнес не понимает нас как программистов. Он не понимает парное программирование, он не понимает Test Driven Development, не понимает рефакторинг. Это просто выходит за рамки его экспертизы. И не должно входить! Эти практики принадлежат нам, нашей отрасли.

Поэтому бизнес не может утвердить или отвергнуть эти практики. А вы не можете прийти к бизнесу и спросить "как вы смотрите на то, что мы будем писать тесты?". Потому что делая так вы просто пытаетесь переложить свои риски на бизнес. А бизнес не может оценить это и не может оценить риски отсутствия этих практик. Конечно же бизнес от них откажется!

Вы не можете прийти к бизнесу и спросить "нормально будет, если мы займемся рефакторингом"?  Так вы просто перекладываете на менеджеров риски, которые должны быть нашими. Это мы — те, кто знает, что код должен быть протестирован. Это мы — те, кто знает, что код должен подвергаться рефакторингу. Это мы знаем как делать программное обеспечение. И мы должны нести риски за это.

Это часть наших профессиональных обязанностей. Профессионал — это тот кто принимает на себя риск за то, в чем он специализируется.

Выбор будущего

К сожалению, не все из нас с этим согласны. Часть "программистов" считают, что нам не нужны эти практики и недавно мы увидели публикации типа "TDD умерло" , "TDD, я сдаюсь", "Парное программирование? Нет!"

У нас большая проблема, потому что мы сами не достигли согласия на счет наших практик. В то же время без технической дисциплины Скрам превращается в то, что Мартин Фаулер назвал "увядший Скрам". Скрам у которого нет тела, характера и который не может обеспечить регулярные поставки. Техническое качество начисто пропадает.

Скрам превращается в эффективную бизнес-дисциплину, но в паре с разболтанной инженерной командой ведет лишь к бардаку.

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

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

Где все программисты? Вы отправляетесь на Agile конференцию, а там совсем немного программистов, там не поднимают технических вопросов. Бывают попытки сделать это, но они тонут в менеджерах от бизнеса и проджект-менеджерах. Техническое мастерство превратилось в маргинальное сопротивление. Была группа людей, говорившая "подождите, у нас тут тоже право голоса, мы должны поговорить с этими людьми из нового Agile и как то объединиться". Но этого не случилось.

Здесь есть доля иронии. Ведь слова Кента Бэка, сказанные им в Сноубёрде, о целях движения были такими :  "Agile — это лекарство от разделения бизнеса и программирования". И с точки зрения движения эта цель провалена. За исключением отдельных личностей и отдельных офисов, где эту цель удается достичь. Но само движение разделилось.

Что же нам нужно изменить в этот раз, спустя 15 лет?

Превое. Мы, как Agile-сообщество, должны повзрослеть. Мы, как программисты, должны определить нашу профессию. Мы должны выбирать наши практики и дисциплины. Быть ли TDD, применять ли парное программирование, непрерывную интеграцию, непрерывное развертывание? Ведь это наши практики! Давайте их применять. Давайте решим, что значит быть программистом.  Мы должны вновь объединить мастерство и Agile. И начать вести за собой.

Кому то в любом случае придется быть первыми. Потому что есть большая проблема.

Цивилизация зависит от нас, хотя не вполне это понимает. Мы сами это не вполне это понимаем. Я хочу чтобы вы хорошо подумали. Сколько раз в день ваша бабушка вступает в контакт с программным обеспечением? Вы можете подумать  "ох, она вообще не вступает в такой контакт". Но она в любом случае что-то покупает в магазинах, а вы не можете купить что-либо в магазине и избежать контакта с софтом. Вы не можете получить страховку не вступив в контакт с софтом, вы не можете сделать звонок со своего смартфона, посмотреть телевизор, сесть в автомобиль, выбрать режим микроволновки, постирать вещи. Всё, что вы делаете так или иначе связано с программным обеспечением.

Кто нибудь знает сколько строк кода в современной машине? 10 миллионов строк кода. Зная, как создаются программы, это вас не пугает? Конечно не все они управляют двигателем, большая часть сидит в GPS и развлекательных устройствах. Но в современной машине дроссель управляется программным обеспечением. Есть софт, управляющий тормозами и акселераторами. Машина моей жены корректирует поворот руля, если она неправильно паркуется. Сколько людей убивает ПО в автомобилях? Тысячи. Много примеров когда машина таким образом теряла управляемость и разбивалась. Мы убиваем людей. Мы пришли в этот бизнес не для того, чтобы убивать людей, но так получается. И будет только хуже. Наша цивилизация всё больше полагается на нас. Хотя она пока этого не понимает, да и мы тоже.

Сколько из вас видели как СEO североамериканской Volkswagen давал показания перед конгрессом, обвиняя пару разработчиков программного обеспечения в том, что они подделали результаты тестов? "Ооо, это была пара  программистов, которые с чего-то накосячили".

А знаете в чем дело? Это действительно была пара программистов. Может быть даже больше. Это они написали тот код, обманывающий тесты. Некоторые программисты так делают :

Если РежимТестирования Тогда

Сообщить("Все хорошо"); // никакого намека на модули форм в типовых конфигурациях, все совпадения случайны
Возврат;

КонецЕсли;

Я даже думаю, что они осознавали, что делают. И в этом проблема. И будет день, когда кто-то из нас напишет программу, которая приведет к интересным газетным заголовкам. Что это может быть за программа? Да что угодно, от софта управляющего самолетом, до софта управляющего футбольным стадионом. Это просто вопрос времени.

Тогда политики начнут делать то, что должны. Они укажут своими пальцами прямо на нас и зададут вопрос "как вы это допустили?" Они не укажут на менеджеров, потому что менеджеры скажут:  “Это не мы, это разработчики написали такой софт, мы не знаем почему они так поступили”. И тоже укажут пальцами на нас.  И наш ответ "О, мой начальник заставил меня написать такой алгоритм" не прокатит. "О, начальник поставил мне дедлайн". Простите, но нет. Это не сработает.

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

Возможно мы можем этого избежать? Как? Сделав это первыми. Первыми начав регулировать нашу индустрию, как это давно сделали другие отрасли. Создав принципы и этику. Установить базовый уровень морали и дисциплины и отказываться опускаться ниже. Иногда это значит сказать вашему боссу "нет", как это может например сделать врач, давший профессиональную клятву.

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

И это конец моей речи.