Обзор

Я немного опоздал на вечеринку, но все же. Роберт С. Мартин, в просторечии известный как дядя Боб, в мае 2016 года выступил с увлекательной беседой о будущем программирования. Актуальность его слов по-прежнему актуальна, и это прекрасный урок истории разработки программного обеспечения, программирования как профессии с замечаниями об Agile и возможном будущем отрасли.

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

Объективная история C

В начале Роберт кратко упоминает свою версию Истории Objective C начала 90-х. С его точки зрения, Objective C должен был умереть в этот момент, потому что в целом C++ был лучшей эволюцией ANSI C, и оба языка конкурировали на одном поле. Но ряд обстоятельств спас Objective C. Стив Джобс был вытеснен из Apple в 1985 году и основал NeXT, Inc, чтобы конкурировать с Apple. На рынке было не так много программистов, но специалисты по Objective C испытывали некоторые проблемы с поиском новой работы. Как сказал Роберт:

На улице стояла кучка парней с табличками "Мы будем писать код на Objective C для еды".

– Роберт С. Мартин

Их наняла NeXT, и все эти программисты создали операционную систему NeXTSTEP. Через несколько лет Apple объявила, что купит NeXT за 427 миллионов долларов, что вернет Джобса в компанию. И Стив привел с собой всю команду NeXT, включая всех программистов на Objective C. NeXTSTEP OS также была частью сделки. Именно команда начала работать над прототипом iPod, и, как вы понимаете, основным языком был Objective C. Короче говоря, вот как Objective C воскрес из мертвых. Или спасли.

Алан Тьюринг

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

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

Если вы хотите узнать больше об этом парне, я настоятельно рекомендую книгу Аннотированный Тьюринг от Чарльза Петцольда (парень, стоящий за Microsoft Foundation Class Library (MFC) и бывший инженер-программист), которую Роберт упоминает в своем выступлении. также.

Роберт много говорит о дисциплине программирования и о том, почему она должна была опираться на плечи математиков. По его мнению, много проблем с наставничеством новых программистов и отсутствием фундаментальных знаний. Эта тема немного противоречива, но забавно то, что Алан Тьюринг предсказал проблему, написав «несколько сотен строк кода» более 70 лет назад:

"Одной из наших трудностей будет поддержание надлежащей дисциплины, чтобы мы не теряли из виду то, что делаем".

– Алан Тьюринг, Лекция в Лондонском математическом обществе 20 февраля 1947 г.

Небольшое примечание об операторе GOTO и о том, что не следует делать

На собрании перед ALGOL, состоявшемся в 1959 году, Хайнц Земанек прямо поставил под сомнение необходимость операторов GOTO; в то время на его замечание никто не обратил внимания, в том числе и Эдсгер В. Дейкстра, впоследствии ставший культовым противником GOTO. В 1970-х и 1980-х годах использование операторов GOTO сократилось в пользу парадигмы структурированного программирования, при этом goto критиковали за то, что он ведет к неуправляемому спагетти-коду.

– Википедия, ПЕРЕХОД

Так, в 1968 году Эдсгер В. Дейкстра написал свою довольно известную статью Перейти к заявлению, которое считается вредным. И это был один из первых примеров, когда программисты начали совершенствовать технологию и саму дисциплину. Я упомянул этот факт в качестве примера, потому что согласен с Робертом в его мыслях:

"С 70-х годов мы узнали больше о том, чего не делать, чем о том, что делать".

«Если мы и добились каких-либо успехов в программном обеспечении с 1945 года, то почти исключительно в том, чего делать нельзя. Структурированное программирование заключалось в том, чего делать нельзя — не использовать безудержный GOTO. Функциональное программирование — не используйте присваивание. Объектно-ориентированное программирование — не используйте указатели на функции. За последние 70 с лишним лет мы узнали больше о том, чего не делать, чем о том, что делать. Никаких радикальных достижений в программных технологиях не произошло. Мастерство написания программного обеспечения осталось примерно таким же, как и в 1945 году, — немного современнее, но существенно не изменилось».

– Роберт С. Мартин

Видеть? Почти все современные парадигмы были построены на принципах «не делать». С точки зрения Роберта, мы более или менее способны договориться о плохих вещах, но нам трудно договориться о чем-то новом и идти в том же направлении, и это одна из самых больших проблем, с которыми мы сталкиваемся в дисциплине:

"У нас проблема: мы не согласны с нашими техническими дисциплинами".

– Роберт С. Мартин

Мы много знаем о том, чего следует избегать, сотни плохих практик и антипаттернов. Но, с другой стороны, слишком мало общих принципов, которым нужно следовать. Мы изучаем и создаем новые языки для решения конкретных проблем, танцуем с дженериками поверх дженериков, копируем шаблоны и используем статьи о синтаксическом сахаре как о лучших методах разработки. Но, по сути, с 70-х годов в самом программном обеспечении мало что изменилось. В конце концов, ваша программа будет работать с операторами if, присваиваниями и циклами while.

«Вы бы узнали код, написанный Аланом Тьюрингом на машине ACE. Вам бы это не понравилось, но вы бы это узнали».

– Роберт С. Мартин

Что случилось с дисциплиной

Довольно интересно слушать парня, который за все эти годы испытал на себе все изменения в дисциплине. Например, Роберт заявил, что еще в 60–70-е годы ситуация с программистами выглядела так:

- До сих пор программисты были дисциплинированными профессионалами;

- Им не нужно много управления или процессов;

- умели распоряжаться своим временем, общаться и работать вместе;

- Они понимали сроки и обязательства. Что оставить, а что оставить.

– Роберт С. Мартин

В то время, используя упомянутые выше принципы, программисты создавали отличные программы. Или, как сказал Роберт: «Они знали, как делать большие дела»:

  • IBM 360 Virtual Memory OS — первое семейство компьютеров, предназначенное для покрытия всего спектра приложений, от малых до больших, как коммерческих, так и научных;
  • Проект НАСА Меркурий — первая в США программа человек в космосе;
  • Проект НАСА Джемини — вторая программа пилотируемых космических полетов;
  • Проект НАСА Аполлон — программа пилотируемых космических полетов, в рамках которой удалось высадить первых людей на Луну с 1969 по 1972 год;
  • Структурированная, функциональная, объектно-ориентированная парадигмы;
  • Фортран, Кобол, Алгол, Лисп, С, Unix;
  • И многое другое.

Я хочу упомянуть Маргарет Гамильтон — директора отдела разработки программного обеспечения Лаборатории приборостроения Массачусетского технологического института, которая разработала бортовое программное обеспечение для полета для программы НАСА Аполлон.

А пока давайте немного поговорим об Agile.

Agile-манифест

В 2001 году эти семнадцать разработчиков программного обеспечения встретились на курорте в Сноуберде, штат Юта, чтобы обсудить упрощенные методы разработки: Кент Бек, Уорд Каннингем, Дэйв Томас, Джефф Сазерленд, Кен Швабер, Джим Хайсмит, Алистер Кокберн, Роберт С. Мартин, Майк Бидл, Ари ван Беннекум, Мартин Фаулер, Джеймс Греннинг, Эндрю Хант, Рон Джеффрис, Джон Керн, Брайан Марик и Стив Меллор. Вместе они опубликовали Манифест гибкой разработки программного обеспечения.

– Википедия, Манифест гибкой разработки программного обеспечения

Примечание: под облегченными методами разработки предполагалась быстрая разработка приложений (RAD) с 1991 года; единый технологический (UP) и метод разработки динамических систем (DSDM), оба с 1994 г.; Scrum, с 1995 г.; Кристально чистое и экстремальное программирование (XP), оба с 1996 года; и Разработка, ориентированная на функции, с 1997 г.

Итак, Роберт был частью группы, стоящей за манифестом, и его объяснение хорошо согласуется с моим мнением. Программисты больше не были просто операторами, и им нужно было быть частью всего процесса создания. Agile — это все обещания, которые вы даете, а не список задач, которым вы следуете. В современном мире это восприятие исчезло, и Роберт предполагает, что это произошло, когда на пути встал бизнес. Бизнес полностью соответствовал тому, что предлагало Agile-движение, весь набор принципов имел для них смысл, и они понимали дисциплину. Однако бизнес начал брать под свой контроль некоторые инженерные практики, и Agile помог им. В худшем случае программистам приходится обсуждать с бизнесом технический долг, рефакторинг и технологии и запрашивать разрешения на управление простыми инженерными вещами. Дело в том, что бизнес не всегда понимает (и, честно говоря, не должен), что делают программисты. Итак, как только менеджеры проектов взяли под свой контроль Agile (например, с помощью Scrum), он стал менее техническим. По иронии судьбы, одной из целей Agile было устранение разрыва между бизнесом и программированием (Кент Бек).

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

Есть полезная статья от Martin Fowler — Flaccid Scrum примерно по тем же вопросам.

«Scrum-сообществу необходимо удвоить усилия, чтобы люди понимали важность надежных технических методов. … Если вы хотите внедрить Scrum, убедитесь, что вы уделяете должное внимание техническим приемам. Мы склонны применять многие из них из Extreme Programming, и они прекрасно подходят. Сторонники XP часто не без оснований шутят, что Scrum — это просто XP без технических приемов, которые заставляют его работать».

– Мартин Фаулер

Я могу распознать множество неудачных/проблемных проектов из своего опыта в том, как Роберт описывает явления:

«Вялый Scrum — эффективная бизнес-дисциплина в сочетании с недисциплинированной командой инженеров очень быстро приведет к беспорядку».

– Роберт С. Мартин

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

Исторические справки

Это ссылки на некоторые аппаратные средства, программное обеспечение и события, упомянутые в докладе.

  • Automatic Computing Engine (ACE) — британский ранний электронный компьютер с хранимой в памяти программой, разработанный Аланом Тьюрингом;
  • Delay Line Memory (линии задержки Меркурия) — форма компьютерной памяти, использовавшаяся на некоторых из первых цифровых компьютеров;
  • электронно-лучевые трубки — использовались в качестве запоминающих устройств, известных как трубки Вильямса;
  • Lisp — второй старейший язык программирования высокого уровня, широко используемый сегодня, который отказывается умирать;
  • Simula 67 — считается первым объектно-ориентированным языком программирования;

Нижняя линия

Профессионализм. Дисциплина. Внимание к деталям.

Это базовые принципы для лучших программистов. Звучит легко и очевидно. Почему бы не попробовать?

P.S.

К сожалению, этот разговор сильно предвосхищает ситуацию с Boeing 737 Max.

Первоначально опубликовано здесь.