Uncle Bob / Robert Martin - co-founder of cleancoders.com

Dmytro Mindra - Director of Technology at Opower Ukraine

Дмитрий: Вы впервые в Литве?

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

Дмитрий: Вы впервые выступали с речью на конференции Build Stuff?

Uncle Bob: Это вообще мое первое посещение конференции Build Stuff и я не знал, чего ждать. Когда я приехал, я увидел, что здесь собрались 800 человек - огромный поток энергии, и это было приятно наблюдать. Много программистов, страстно увлеченных своей работой, собрались вместе, чтобы обсудить довольно интересные вещи. Я участвовал во многих захватывающих дискуссиях. Вы могли слышать, как много Мелвин Конвей говорил о проектах потока данных в своем выступлении. Это все очень интересно.

Дмитрий: Вы очень популярны в Литве и Украине. В чем секрет вашего успеха?

Uncle Bob: Я занимаюсь этим бизнесом более 50 лет. Я прошел через многое. Я совершил много ошибок, меня увольняли из нескольких мест, мои проекты сворачивали, и так далее. И сейчас я могу рассказать людям, чего не стоит делать. Кстати, много моих статей основано на идее: "Не стоит этого делать, я уже однажды пробовал". Я не могу сказать, что мой успех - это тайна за семью замками. Это процесс совершения и исправления ошибок.

Дмитрий: Вы уже давно занимаетесь этой сферой деятельности. Чтобы вы могли порекомендовать другим?

Uncle Bob: Если бы я мог вернуться в прошлое, я бы сказал себе - тому юнцу: "Будь внимательным к делу, которым занимаешься, и не только в его технологическом аспекте, изучай бизнес, и вообще, постоянно учись." Это не было моей личной проблемой, это проблема общего значения. Люди думают, что вот они закончили институт, выучили Java, нашли работу и им больше не нужно учиться. Но в этой сфере просто нельзя перестать учиться. Технологии непрерывно меняются и поэтому нужно постоянно что-то изучать и пробовать новое. Как сказал Дейв Томас в своей книге "Прагматичный программист", каждый программист должен выучивать новый язык в год, и это прекрасный совет. Можно не использовать эти знания на работе, но практиковаться дома .И вот еще, что мне хотелось бы сказать людям, - вы работаете на вашего нанимателя 40-50 или - сколько-нибудь часов в неделю, но вы должны обязательно находить время и для себя, для карьерного роста, учась и практикуясь. Даже если вы полностью отданы своей работе, выделите 10-20 часов в неделю для саморазвития. Если вы работаете 40 часов в неделю и еще 20 тратите на самообразование, трудно найти еще время для жизни, для семьи. Но если вы хотите стать профессионал в области программного обеспечения, это цена вопроса. Это требует много усилий и времени, но если вы это любите, это того стоит.

Дмитрий: Вы являетесь одним из основателей движения "Искусство программирования". Каково будущее этого движения на ваш взгляд?

Uncle Bob: Я не помню наверняка, но, по-моему, это движение образовалось в 2010 году. Будущее этой организации для меня видится смутно, потому что предполагалось, что движение Agile будет как раз тем двигателем, который поведет Движение разработки программного обеспечения вперед. Но что-то случилось с Agile и это беспокоит меня долгое время. Оно попало в фокус с точки зрения бизнеса, но не с технической точки. Большинство сообществ Agile нацелено на управление проектами и бизнес, и технологии занимают в этом совсем маленькую часть. Основание движения "Искусство программирования" было реакцией на это с надеждой на воссоединение, но, к сожалению, этого не удалось реализовать, по крайней мере, пока. Поэтому, это меня тревожит, так как я вижу, что эти два движения идут отдельными путями, а я считаю, им нужно объедниться. Мы столкнемся с кризисом в сфере профессионализма, и я верю, что, объединившись, эти два движения помогут преодолеть этот кризис.

Дмитрий: Как вы считаете, когда нам ожидать этот кризис?

Мы должны предоставить правительству стандарты регулирования программного обеспечения.

Дмитрий: Вы видели так много перемен в разработке программного обеспечения. Можете ли вы предсказать, каким будет программирование через 10 лет?

С другой стороны, языки программирования совсем немного изменились. Сама по себе технология программного обеспечения представляет собой практически то же самое, что и 50 лет назад. Мы начинали с того, что получили компилятор, такой как Фортран, с его условными операторами, циклами, операторами присваивания, и то же самое мы имеем сегодня, и совсем немногое изменилось. Вы можете сказать, что объектность в програмировании это добавление, а я бы сказал, что это вычитание, это набор методов, которые позволят нам не использовать указатели функций. Структурное программирование - это набор методов, которые позволяют нам не использовать goto. А функциональное программирование - это набор методов, которые позволяют нам не использовать операторы присваивания. Эта парадигма - структурное, объектно-ориентированное, функциональное программирование - убирает ненужное, но не добавляет. Она забирает возможности, навязанные методами. Если бы я взял программиста из 1965 г. и провел его сквозь время (кстати, в 1965 г. это, скорее всего, была бы женщина, потому что в то время женщины больше занимались этим), и посадил бы его перед ноутбуком, на котором запущен Eclipse, и показал бы ему Java, этого человека поразили бы технологии, мощность аппарата, но в течении суток он смог бы писать код, потому что он, в сущности, не особы изменился. Этот человек увидел бы Java, я бы ему объяснил некоторые спецификации, и через день этот человек писал бы код без особых проблем. То есть, прыгнув в будущее на 50-60 лет, ему не пришлось бы много учить. А если бы я взял программиста из нашего времени и перенес бы его в 1965 г., он был бы, конечно, очень разочарован тем, что ему придется вносить код на бумажных перфокартах, но с другой стороны, он мог бы писать код, потому что он не слишком изменен. Итак, вы спрашиваете меня о будущем, и, рассмотрев обе этих тенденции, я считаю, что аппаратные технологии будут продолжать совершенствоваться, хотя, может, и не так быстро, как раньше. Желаемая скорость работы инструментов была достигнута, они будут становиться все более компактными, хотя процесс может идти немного медленней, чем сейчас. То есть, инструменты будут становиться все лучше и лучше. Но языки программирования останутся неизменными. Будут и условные операторы, и циклы, я думаю, какой-то большой революции, ведущей к переменам в программном обеспечении, не будет; будет так же много языков программирования, как и сейчас, будут возникать все новые языки, потому что нам все время хочется создавать что-то новое. Но новые языки - это обычно переделанные старые. Никакого действительно нового концепта в области языков программирования не возникало на протяжении, по-моему, 40 лет. Немного огорчительно, но это так и есть. Роль инструмента в этом, та, что мы ждем постоянного совершенствования в этом, но может случится, что мы зашли в угол в нашей технологии, то есть совершенствование будет продолжаться, но гораздо медленней. Я не уверен наверняка, но это возможно. Это то, что произошло с авиа сферой. Первые самолет был построен братьями Райт в 1903 г., через 40 лет появились первые реактивные самолеты, и, спустя 60 лет, мы все еще имеем все те же реактивные самолеты. Да, они немного улучшены, но, когда вы видите Боинг 747, классный самолет, вспомните, что он был построен в 60х годах. То есть, авиа технологии резко взмыли вверх, а потом свернули и плавно текут прямо без качественных изменений, и я боюсь, то же может произойти и в сфере программного обеспечения.

Дмитрий: Вы упомянули функциональные языки программирования. Какова их роль в будущем?

И нам, программистам, нужен путь, как работать с этой средой с множественными процессорами. И единственный путь как справиться с этим, как работать с множественными процессорами, это устранение трудностей, которые мы имеем с параллельным обновлением. Многие программисты имеют проблемы с потоками. Потоки сложны, и в то же время просты в сравнении с множественными процессорами. Поэтому можно рассматривать множественные процессоры как ужасающие потоки, и в трудность потоков в состоянии гонки проблемах параллельных обновлений. Если вы исключите назначение, уберете возможность изменения состояния переменной, значит вы будете играть в том же состоянии гонки, у вас не будет проблем с обновлением, потому что вам не придется ничего обновлять. И это то, что делают функциональные языки. Они ограничивают вас одним способом программирования, где вы не можете присваивать значение переменной. Вы можете объявлять переменную, вы можете изменить ее один раз после объявления и, если вы не можете изменять состояние переменной, вы не можете изменять состояние гонки. Поэтому, в теории, функциональные языки программирования будут очень полезными для многоядерных машин, если эти машины будут иметь 1024 или 4096 процессоров. Мне интересно, увидим ли мы это. Увидим ли мы портативные ноутбуки с более, чем 4мя ядрами, что есть стандартом на сегодняшний день. Будут ли ноутбуки в ближайшем будущем иметь 8 ядер? Несколько лет назад, я думал, случится переломный момент, сначала появятся компьютеры с 8, потом 16, потом 32 ядрами. Интересно, появятся ли они в будущем? Я думаю, могут и не появиться. Может быть, многоядерность вообще есть пугающей, и может вообще не развиваться по тому пути, как мы думали. Поэтому, будет интересно наблюдать за происходящим в будущем.

Дмитрий: Вы упомянули, что в 60х было множество женщин занятых в сфере компьютеров. Что происходит сейчас. Можно ли как-то изменить ситуацию?

Uncle Bob: Я не знаю. У меня нет ни малейшего представления, что происходит. Выглядит как случайность. Если вы посмотрите на кривую процентного соотношения женщин в информатике, эта кривая отслеживала число женщин и в других инженерных отраслях, как-то астрономия, химия, биология, другие виды инженерии, до приблизительно 1974-75 гг. И вдруг эта кривая стала падать вниз и очень резко, так что в течение 10 лет количество женщин в отрасли сократилось с приблизительно 20% до приблизительно 2%, и пока находится на этом уровне. Я точно не знаю причину этого, я много думал об этом. Когда я принимаю участие в конференции или мастерской по тематике программного обеспечения, когда люди приглашают меня посетить их компании, я наблюдаю группу молодых мужчин и иногда одну или две женщины. На нашей конференции я также вижу много молодых мужчин и только несколько девушек, и это вызывает беспокойство, я не совсем понимаю, почему так происходит. Неужели мы превратили сферу разработки программного обеспечения в сугубо мужскую отрасль? Неужели женскому полу стало совсем неуютно работать в этой области и присоединятся к нам из-за того, что мы, программисты, отдаем предпочтение специалистам мужчинам и ведем себя, как будто вокруг нас лишь мужское общество, закрытый мужской клуб, общаясь, пикантно шутя, используя разные словечки, допустимые в закрытом мужском клубе, и когда здесь появляются дамы и наблюдают все это, они предпочитают просто уйти. Я не знаю, возможно это и является ли это причиной происходящего. Я не знаю, что послужило причиной резкого обвала статистической кривой, но это также может быть связано с другой причиной - с тем что, число выпускников первых курсов по информатике в колледже, специалистов по информатике, закончивших школу и получивших работу совпало со стремительным сокращением числа женщин в их рядах. Это может быть как-то связано с отбором в колледжи, может быть в колледжи поступали больше парни, а не девушки, а может быть, девушки, поступившие в колледж, как-то вытеснялись парнями. Это очень интересный вопрос и это серьезная проблема. Наша отрасль практически единственная в которой настолько явно доминируют мужчины.

Дмитрий: Не думали ли вы адресовать этот вопрос Движению специалистов по программному обеспечению?

У нас, программистов, существует свой особый тип грамотности. Мы умеем читать и понимать особый язык и писать на нем, и большинство людей не понимают язык, на котором мы пишем и читаем на нашей работе, и это означает, что мы владеем особой формой грамотности. Мы владеем отдельным языком, которым не владеет остальной мир. Как же обучить других людей этому языку? Лучше всего начинать обучение с детства. Люди, достигшие определенного возраста, которых по какой-то причине начинают учить программированию, не могут овладеть этим навыком, это говорит о том, что их мозги заточены под что-то одно и не могут воспринимать концепцию, которая нами, программистами, воспринимается абсолютно естественно. И это подтверждалось очень много раз, когда я старался обучить людей, которые были старше, программированию на компьютере, они просто не могли воспринять информацию. И как бы я ни старался объяснить, ничего не получалось. И я не знал, что делать. Итак, я считаю, что лучше всего начинать обучение с юного возраста. Меня очень заинтересовала сегодняшняя лекция Мелвина Конвея, где он подает действительно прекрасное описание языка потока данных, над которым он работает уже 20лет, а я не знал об этой работе. Смысл в том, что он описывает образ женщины, как гончар делает вазу в гончарном круге, и он говорит, что, если мы хотим научить людей программировать, не нужно показывать им исходный код, не нужно рассказывать им о компиляторах, не нужно учить их алгоритмам и логическим операторам. Нужно дать им инструмент, похожий на глину, что-то, с чем они смогут поиграть, поманипулировать в реальном времени и увидеть немедленный результат, и смогут догадаться, что делать дальше – например лепить горлышко вазы уже или шире – то, что они могут видеть, чувствовать и ощущать. Мелвин показал на экране модели, например, принципиальные электрические схемы или сантехнические диаграммы, которые сразу работают, вам не нужно объявлять старт. Вы просто кладете эти предметы на экран, и они немедленно начинают взаимодействовать и создавать модели поведения, и автор сможет потом регулировать, управлять ими, имитировать и манипулировать ими. Он показал эти удивительные вещи и сказал, что это должно быть прозрачным, очевидным. Я точно не помню всех вещей, которые он назвал, но одна из них – это прозрачность, очевидность. Простому человеку не нужно знать, что происходят какие-то вычислительные действия под капотом, должно быть только то, с чем он сам может поработать, к чему может прикоснуться руками, и увидеть результат своих действий и немедленно, с ответной реакцией. И это поразило меня, я подумал, это хорошая мысль. Как мы можем научить детей программированию, если нужно вовлекать их в язык Джава, и кривая обучения для Джава выглядит смешно. Нужно просто предложить детям сделать что-то своими руками, то, что можно быстро сделать, играть, изменять. Думаю, это замечательная идея, которую можно применять для введения понятий, пробуждения интереса и восторга, а после этого уже можно углубляться в детали. Я надеюсь, учебный процесс будет происходить таким образом.

Дмитрий: Вы коллекционируете старые компьютеры. Когда вы начали это делать, и какая последняя машина в вашей коллекции?

Uncle Bob: Это началось довольно давно, когда я был очень молод и первый настоящий компьютер, на котором я учился программировать был PDP-8. Мне тогда было, наверное, лет 16. Мы с отцом проехали 30 миль до склада –магазина Цифровой Техники, где у них была напольная модель компьютера PDP-8 и менеджеры разрешили мне поиграть на этом компьютере. Мы с друзьями приходили туда в субботу. Вот как я проводил свои выходные во время учебного года и все каникулы – я приходил в этот магазин-склад и играл на компьютере PDP-8 и учился управлять этой машиной. Прошли долгие годы, с тех пора как я видел PDP-8 в последний раз, я работал в компании, у них в коридоре стояла какая-то старье, и однажды, проходя мимо мусорной корзины, я увидел в ней 3 передние панели от PDP-8, и я вытащил эти панели и унес домой. Несколько лет спустя, я поместил их в рамки и повесил в моем офисе. После этого я стал размышлять о том, что у меня теперь есть эти фронтальные панели, а теперь мне нужно раздобыть настоящий компьютер PDP-8, но где же его достать? А в прошлом году я написал симулятор для PDP-8 на моем планшете I-Pad, я сделал его внешний вид, как у PDP-8, со всеми светящимися лампочками, кнопками и бумажными лентами и тому подобным, который издавал те же звуки телетайпа, и звуки ридера перфоленты, что и PDP-8, я это сделал, чтобы вспомнить прошлое, поностальгировать. Я написал об этом в Твиттере и Фейсбуке, и мой знакомый написал мне, что у него есть два компьютера PDP-8 в подвале, и я ему ответил с просьбой продать мне один. И он так и сделал. Он продал мне компьютер PDP-8. Теперь в моем офисе стоит оригинальный компьютер PDP-8 1965 г выпуска. Он не работает, но включается, зажигаются лампочки, но что-то случилось с памятью, нужно разобраться в этом, но я собственноручно с осциллографом обещаю, что он возможно заработает к следующему году. Это просто мое хобби, это похожи на то, как человек в возрасте находит свою первую машину, на которой он учился водить. Он покупает ее, чинит, красит – для меня это тоже самое – мой первый компьютер.

Дмитрий: Что вы посоветуете в заключение участника конференции Build Stuff?

Uncle Bob: Я думаю, самая важная вещь для нас, тех, кто вовлечен в данную область, это установить общий подход, список правил, которому мы могли бы следовать. То, что больше всего меня беспокоит, это концепция тестирования. Я полностью поддерживаю разработку через тестирование, существующую долгие годы, и я считаю, что это один из правильных подходов, которому следуют разработчики программного обеспечения. Для меня это правильно, я спрашивал людей, как много они разрабатывают через тестирование, и на сегодняшний день это от 15 до 20%. А, например, 5 лет назад это было бы до 5%, а 10 лет назад этот подход мог вообще не использоваться. Я верю, что этот подход будет все более широко применяться, и я считаю, это правильные пусть. Если вы являетесь моими слушателями, я верю, что вы захотите изучить данный подход. Если вы не знаете принципов данного подхода, не старайтесь применять его на практике, потому что это испортит вашу работу. Практикуйтесь дома, учитесь дома, хорошенько потренируйтесь, потратьте время – 3 или 4 недели, практикую искусство написания тестов, сначала научитесь их писать, придерживаясь концептуального порядка, который описан во множественных блогах, их можно найти практически всюду, набейте руку дома, до того, как начнете использовать на работе. И когда вы овладеете этим навыком дома, вы убедитесь, что навык этот необходим. Когда вам удастся успешно реализовать его, вы поймете, как тяжело было не использовать данный подход и насколько бессмысленно.