ИЗ АРХИВА ЖУРНАЛА PRAGPUB АПРЕЛЬ 2010 ГОДА
Запутались в инструментах: что не так с библиотеками и что с этим делать
Майк Тейлор
Неужели «Просто изучите эти 57 классов» — это не повторное использование, которое нам обещали?
Что бы ни случилось?
Несколько недель назад в своем блоге The Reinvigorated Programmer я написал статью под названием Что случилось с программированием?, которая, судя по многочисленным комментариям, вызвала глубокий отклик у многих людей. Вместо того, чтобы отвечать индивидуально на первоначальный пакет комментариев, я написал дополняющую статью, которая, в свою очередь, породила гораздо больше комментариев — на Hacker News, Reddit и Slashdot, а также в самом блоге. Эти комментарии породили еще много вопросов, и мне нужно время, чтобы их все переварить. Я думаю, что я нащупываю какой-то вывод, хотя. В этой статье я кратко рассмотрю суть этих двух статей и поразмышляю о возможных путях продвижения вперед.
Первоначальная статья родилась из-за разочарования в том, как, похоже, продвигается современная работа по программированию — тенденция отходить от реального создания вещей и просто склеивать вместе то, что уже сделали другие люди. Некоторое время я смутно чувствовал это, но это чувство кристаллизовалось наблюдениями Дона Кнута в длинном интервью для книги Питера Сибеля Кодеры за работой. Кнут сказал:
То, как многие программируют сегодня, не представляет никакого удовольствия, потому что это просто подключение магических заклинаний — объединить чье-то программное обеспечение и запустить его. В нем не так много творчества. Я беспокоюсь, что это становится слишком скучным, потому что у тебя нет возможности сделать что-то особенное новое. Ваш кайф приходит, когда вы видите забавные результаты, выходящие из машины, но не тот кайф, который я всегда получал, создавая что-то новое. Удар сейчас в том, что после того, как вы сделали свою скучную работу, вы внезапно получаете отличное изображение. Но работа не была скучной. (стр. 594)
Видно, что многие люди думают так же. Дело не в том, что мы хотим писать собственные процедуры сортировки и поиска каждый раз, когда нам нужно это сделать — все признают, что это было бы пустой тратой времени, которое лучше потратить на решение задач более высокого уровня. Но когда я работаю над современным веб-приложением, я хочу привнести тот же вид творчества, в котором я нуждался раньше, когда мы писали собственные средства быстрой сортировки, планировщики, мелкие... языковые парсеры и так далее. Я не хочу, чтобы моя работа заключалась в простосоединении компонентов, которые уже написали другие люди (особенно, когда процесс соединения столь неуклюж и подвержен ошибкам, как это часто бывает). Я хочу сделать что-нибудь.
Ученые против инженеров
Ответы на вопрос «Что случилось?» статьи, казалось, были разделены примерно 50–50 между учеными и инженерами. Ученые сказали: «Да-да, я точно понимаю, что вы имеете в виду!»; Инженеры сказали: «Это повторное использование, которого мы все пытались достичь в течение последних сорока лет». Часть меня знает, что инженеры правы или, по крайней мере, частично правы; но часть меня чувствует, что это точно не то блестящее цифровое будущее, которого мы все с нетерпением ждали. Неужели повторное использование должно быть таким, скажем так, неприглядным? Неужели «Просто изучите эти 57 классов» — это не повторное использование, которое нам обещали?
Но правда в том, что, как и большинство из нас, я в разное время ношу шляпы ученых и инженеров. То, что я хочу с одной шляпой, может не совпадать с тем, что я хочу с другой шляпой. Обе стороны сходятся во многих вещах — желательность простоты, ясности и общности, например, три волшебных слова на обложке книги Кернигана и Пайка Практика программирования. Но шляпы имеют разные представления о том, как туда добраться. Шляпа науки глубоко заботится о понимании. Нет, это нечто большее: оно заботится о глубоком понимании. Инженерная шляпа заботится о том, чтобы все было сделано. Что я все еще пытаюсь выяснить, так это: быстрее ли просто сделать все, не утруждая себя пониманием, или время, потраченное на понимание, стоит того, даже если его измерять чисто утилитарным способом? Я честно не знаю.
Это было тогда, это сейчас
Раньше такого не было. Я программирую компьютеры с 1980 года: Commodore BASIC, затем C, затем Perl и совсем недавно Ruby. По пути я использовал много других языков, но это были четыре, которые в то или иное время были моими любимыми языками. Несколько лет назад, в глубине веков, все мои мысли имели номера строк. В 1990-х каждый раз, когда я хотел написать программу, мои пальцы автоматически печатали int main(int argc, char *argv[]), как только мой задний мозг обнаруживал свежий буфер emacs. Я провел десятилетие своей жизни, полагая, что различие между скалярным и списковым контекстом имеет смысл и что wantarray() может включать в себя рациональный язык. Сейчас мне лучше, но иногда мне кажется странным, что физические объекты в мясном пространстве не знают, как реагировать на каждое сообщение с прикрепленным замыканием.
За последние 30 лет я видел много изменений в том, как делается программирование, но, возможно, ключевым из них является подъем инженерии. На Commodore 64 вам нужно было быть ученым, чтобы что-то сделать. Нужно было глубоко познать машину, нужно было вкопаться в ее самое сокровенное ядро, стать единым целым с ее рабочими параметрами, резонировать с тонкими частотами ее самых глубоких глубин — или, по крайней мере, знать, в какое место ТКАТЬ, чтобы повернуть границу. фиолетовый.
Почти то же самое было верно и при программировании на C в Unix: вам все еще нужно было знать машину, даже если теперь это была немного более абстрактная машина. Но произошло важное изменение — в ретроспективе, даже более важное, чем переход от неструктурированного спагетти-кода к блочно-структурированному или от интерпретируемого к компилируемому: появилась библиотека. Да, библиотека — только одна. (Ну, примерно один; я немного упрощаю, потому что были также curses, termcap и несколько других маленьких.) Библиотека предоставляла простые способы делать сложные вещи, такие как сортировка и форматирование вывода, а также операции на системном уровне, такие как настройка пайпов и процессов разветвления. Вряд ли стоит говорить, что все согласились с тем, что библиотека — это хорошая вещь, позволяющая значительно сэкономить время. Итак, мы все изучили библиотеку: хорошие программисты на C знали все, включая такие вещи, как разница в порядке аргументов между write() и fwrite(), сигнатура функции сравнения sort() и когда использовать strcpy() против memcpy(). Это дало нам совершенно новую палитру для рисования.
А потом, вау, Перл. Perl не предлагает библиотеку. Perl имеет, вероятно, самый большой каталог библиотек для любого языка в мире: CPAN (Комплексная сеть архивов Perl. На момент написания статьи CPAN предлагает для скачивания 19941 дистрибутив, из которых 500 относятся только к XML. Это ошеломляет). . За последние десять лет было написано как минимум три биографии под названием Последний человек, который знал все (об Афанасии Кирхере, Томасе Янге и Джозефе Лейди). когда один человек мог освоить все накопленные человечеством знания, сейчас невозможно освоить все библиотеки с открытым исходным кодом для Perl, там так чертовски много всего.
Библиотечная слепота
Так что же делать мальчику? Тщательно выбирайте библиотеки, изучайте только несколько и надейтесь, что вы выбрали правильные. По историческим причинам я обрабатываю XML в Perl, используя неуклюже названную библиотеку XML::LibXML, и я понятия не имею, является ли она лучшей для этой работы. Мне его проще всего использовать, потому что все, что мне нужно сделать, это найти какой-нибудь код, где я использовал его раньше, вырезать и вставить экземпляр/вызов и настроить его в соответствии с текущим случаем. Но в то время как моя шляпа инженера довольна этим, моя шляпа ученого глубоко недовольна тем, что я понимаю, что делаю. Не совсем.
Конечно, проблему XML-in-Perl решить не так сложно — мне просто нужно немного времени, чтобы немного побродить вокруг, посмотреть, какие XML-библиотеки используют другие люди и что они говорят о них, выяснить, как «живой» код (есть ли последние релизы и как часто они выходят?), скачайте и установите их, попробуйте и посмотрите, что мне больше нравится. Если бы XML был единственной областью, где библиотечная слепота была бы проблемой, я бы, наверное, просто заткнулся и занялся этим. Но то же самое происходит и в сотне других областей, и я слишком занят рубкой деревьев, чтобы остановиться и наточить свой топор.
Я говорю, что для Perl не должно быть никаких библиотек? Черт возьми, нет, я не хочу заниматься разбором XML самостоятельно! Что тогда? Что должна быть Единая Настоящая Библиотека, как это было для C в 1980-х, и кто-то заслуживающий доверия должен решать, что входит, а что нет? Нет, это никогда не сработает. По правде говоря, я не уверен, что говорю: я не знаю решения. Я даже не могу предложить одну, если не считать очевидного наблюдения, что лучшие механизмы управления репутацией сделают выбор одной библиотеки из множества конкурирующих в одном пространстве менее пугающим. Нам нужны библиотеки, и их много, по той простой причине, что сейчас от нас ожидают гораздо большего, чем когда у нас были Commodore 64 (или, да поможет нам Бог, VIC-20). Небольшие автономные программы, которые мы тогда писали, не нуждались в библиотеках, потому что они не вызывали REST к веб-службам, не отображали объекты в реляционные базы данных и не преобразовывали XML-документы. (Возможно, мы могли бы использовать графические библиотеки, но поскольку аппаратное обеспечение на самом деле не поддерживало произвольную прорисовку, большая часть графики была сделана с помощью определяемых пользователем символов и, если вам повезет, спрайтов.)
Так что библиотеки нужны. Являются ли они необходимым злом? Только если вы думаете, что зло является необходимостью. я так не думаю; но экспериментальные доказательства против меня.
Библиотечная ложь
Комментатор под ником Silversmith в обсуждении моей оригинальной статьи на Reddit идеализировал представление о библиотеках: «У вас есть проблема X, состоящая из подзадач X1, X2, X3. Существуют легкодоступные решения для X1 и X3. Если вам не хочется быть каменщиком, используйте код X. Я выбираю код X2, подключаю решения X1 и X3 и провожу остаток дня, исследуя и, возможно, решая проблему Y». Это то, что я называю библиотечной ложью, и я думаю, что Сильверсмит проглотил ее. Негласное предположение заключается в том, что «подключить решения X1 и X3» тривиально — что это требует небольших усилий и практически не требует времени, а результатом является хороший, чистый, интегрированный X. Но мы знаем из опыта, что это не так. истинный. XML, который создает X1, предположительно имеет тот же формат, что и X3, но он таинственным образом отклоняется, когда вы передаете его X3 (и, конечно же, нет полезного сообщения об ошибке — просто «Ошибка XML»). Вы предоставляете две функции-ловушки для обратного вызова X3, но одна никогда не вызывается, а другая, кажется, вызывается дважды… иногда при неясных условиях. И так оно и есть, и вы обнаружите, что пишете не только X2, но и слои-оболочки X1’ и X3’, которые должны сделать X1 и X3 такими, как вы хотите. И даже когда вы закончите, вы не совсем понимаете, почему агрегат работает для протестированных вами случаев; и у вас нет уверенности, что что-то не пойдет таинственным образом не так, когда вы начнете использовать его в других случаях.
Я не говорю, что создание X1 и X3 и преодоление всей боли в целом не быстрее, чем написание собственных X1 и X3. Но я говорю, что нам нужно, по крайней мере, быть честными с самими собой в отношении того, сколько времени займет «просто подключите решения X1 и X3»; и мы должны признать, что конечный результат может быть не таким послушным или надежным, как если бы мы построили все решение целиком.
Библиотеки — это победа. Но это не такая большая победа, как они хотят, чтобы вы думали, и иногда это такая победа, от которой вы жалеете, что не проиграли.
Я увижу вашу библиотечную слепоту и подниму вам рамочную лихорадку
Если и есть что-то более пугающее, чем прокладывание пути через лабиринт извилистых маленьких библиотек, все они разные, так это то, что он увязает в болоте фреймворка. «Фреймворк» — это слово, которое стало популярным в последние несколько лет — вы редко слышали его до рубежа тысячелетий, по крайней мере, за пределами кругов Java, но теперь это горячая игра, в которую нужно играть. Иногда это слово кажется просто модным синонимом библиотеки, но сама структура — это более крупный и волосатый зверь.
Фреймворк можно определить как набор библиотек, которые говорят: «Не звоните нам, мы позвоним вам». Когда вы вызываете традиционную библиотеку, вы по-прежнему контролируете ситуацию: вы делаете вызовы библиотеки, которые хотите сделать, и имеете дело с последствиями. Фреймворк инвертирует поток управления: вы передаете ему управление и ждете, пока он вызовет различные функции обратного вызова, которые вы предоставляете. Вы отдаете жизнь своей программы в ее руки. Это имеет последствия: одним из наиболее важных является то, что, хотя ваша программа может использовать столько библиотек, сколько ей нужно, она может использовать — или, скорее, использоваться — только одним фреймворком. Фреймворки завидуют. Они не делятся.
Стоит ли передавать управление фреймворку? Ну, иногда. Мой опыт подсказывает, что пока вы делаете что-то в соответствии с фреймворком и вам не нужно выходить за пределы того, что представлял себе автор, у вас все будет хорошо — все будет работать быстро и просто, и солнце будет светить, и птицы будут петь до тех пор, пока вдруг — о-о! — вам нужно сделать что-то чуть-чуть по-другому и бух! все разваливается. Тонкие зависимости, которые были скрыты от вас, когда все шло как надо, вдруг выпрыгивают из кустов и кричат на вас. Монстры, которые были прикованы цепями в подвале, все сразу освобождаются, и вдруг вы добавляете этустроку в свой обратный вызов, и это приводит к тому, что этана первый взгляд никак не связанная вещь работает неправильно. Итак, вы исправляете это, и что-то совершенно отдельное идет не так на другом конце вашего приложения, и лог-файл не сообщает вам ничего полезного. Итак, вы пытаетесь найти проблемную область в документации, но когда вы находите запись для функции newRecordAddedHook, она просто говорит: «Этот хук вызывается при добавлении новой записи».
В книге по Rails есть пугающий пример отказа фреймворка, Agile Web Разработка с помощью Rails (третье издание). Учебное пособие занимает 187 страниц, обучая вас, как делать такие вещи, как добавление has_many :line_items в класс модели продукта: минимум кода, все говорит само за себя. Затем внезапно из ниоткуда глава Интернационализация предлагает вам просто добавить форму в макет магазина:
<% form_tag '', method => 'GET', :class => 'locale' do &>
<%= select_tag 'locale', options_for_select(LANGUAGES,
I18n_locale),
:onchange => 'this.form.submit()' %>
<%= submit_tag 'submit' %>
<%= javascript_tag "$$('.locale input').each(Element.hide)" %>
Я хочу сказать, что?
Тег формы, тег выбора и тег отправки имеют смысл в свете того, что было раньше, но этот кусок JavaScript появляется в тексте полностью сформированным, прямо из разума Зевса. Здорово, что это появляется прямо в туториале, но я бы никогда не пришел к этому сам.
Когда я сталкиваюсь с подобными вещами, мне кажется, что я снова играю в приключенческие игры 1980-х годов. Вы помните: ОТКРЫТЬ ДВЕРЬ / Дверь заперта / РАЗБЛОКИРОВАТЬ ДВЕРЬ / Отпереть дверь чем? / ОТКРОЙТЕ ДВЕРЬ КЛЮЧОМ / Вы имеете в виду железный ключ или медный ключ? / ОТКРОЙТЕ ДВЕРЬ МЕДНЫМ КЛЮЧОМ / Латунный ключ не подходит. Это догадки. Хуже того, он угадывает неинтересные детали, такие как словарный запас, а не догадывается о реальной проблеме. Когда я играл в Lurking Horror, у меня были ужасные проблемы с головоломкой в самом конце, когда было очевидно, что что-то находится в луже воды, и мне нужно было это вытащить. Я не мог ВХОДИТЬ В БАССЕЙН или ПЛАВАТЬ В БАССЕЙНЕ, и все попытки ПОЛУЧИТЬ РУКУ В БАССЕЙНЕ или ЧУВСТВОВАТЬ БАССЕЙН или ЧУВСТВОВАТЬ В БАССЕЙНЕ были бесплодны. В конце концов я наткнулся на ответ: ДОСТАТЬ В БАССЕЙН. Такого рода игра «угадай, что имел в виду автор» достаточно уныла, когда вы пытаетесь победить готический ужас вне времени и спасти мир от злого владычества культовых зверей; но это просто глупо, когда все, что вы пытаетесь сделать, это отобразить раскрывающийся список.
Вы теперь низший класс
У меня вчера кровь похолодела, когда я прочитал эти комментарии в интервью Gang Of Four на тему Паттерны проектирования 15 лет спустя:
Ричард Хелм: я думаю, что уровень сложности изменился. Программное обеспечение многократного использования перекочевало в базовую систему/язык в виде наборов инструментов или фреймворков — и в основном это должно быть оставлено на усмотрение экспертов.
Ральф Джонсон: Большинство программистов нанимают не для того, чтобы писать повторно используемое программное обеспечение […] Возможно, сейчас было бы лучше нацелить книгу на людей, использующих шаблоны, выбранные другими, а не на людей, пытающихся выяснить, какие шаблон для использования.
Вот оно, ребята, черным по белому: по мнению экспертов, все мы, работающие Джо, должны просто использовать фреймворки… которые будут написаны: экспертами.
Знаешь что? Я не доверяю им, чтобы понять это правильно. Я имею в виду, зачем им начинать сейчас?
Проблема не в библиотеках. Проблема в плохих библиотеках
Я нарисовал черную картину. Я осознаю необходимость в наши дни писать программы, которые делают гораздо больше, чем в 1980-х; Я признал, что мы не можем сделать это без библиотек; Возможно, я не сразу сказал, что фреймворки тоже необходимы, но в глубине души я знаю, что это правда (иначе зачем мне читать книгу о Rails?) Забавно вспоминать своих лекторов, в конце 1980-х, когда я учился на факультете математики и информатики, говоря о «кризисе программного обеспечения» — они действительно не представляли, насколько все будет плохо. Слова Дейкстры из книги The Humble Programmer кажутся пророческими: «пока не было машин, программирование вообще не было проблемой […] теперь у нас есть гигантские компьютеры, программирование стало такой же гигантской проблемой». Трудно поверить, что это было написано в 1972 году.
Так что я, кажется, ною довольно много. Есть ли у меня конструктивные предложения? Почему да! Да. У меня есть двойной манифест.
Вариант 1: проще, понятнее, короче документация
Самое простое, что мы можем сделать прямо сейчас, — это переосмыслить то, как мы документируем библиотеки. Инструменты автоматического документирования, такие как Javadoc и Rdoc, хороши для создания толстых стопок бумаги, но не так уж хороши для фактического информирования пользователей библиотек о том, что им нужно знать. Они являются источником большей части мировой документации «newRecordAddedHook вызывается при добавлении новой записи».
Они могут быть полезны, но они не заменят собственно написания о библиотеке: одностраничные сводки, которые отвечают на три ключевых вопроса: что делает библиотека, почему вы должны использовать его и как это сделать. Чтобы получить бонусные баллы, в одностраничном резюме не следует использовать слова «предприятие» (если только это не библиотека кораблей из Звездного пути) и «инновационный».
Вот пример того, от чего нам нужно отказаться: я дословно цитирую первый абзац контента на первой странице основного веб-сайта о JavaServer Faces:
Технология JavaServer Faces, разработанная в рамках процесса сообщества Java в соответствии с JSR-314, устанавливает стандарт для создания пользовательских интерфейсов на стороне сервера. Благодаря вкладу группы экспертов API-интерфейсы JavaServer Faces разрабатываются таким образом, чтобы их можно было использовать с инструментами, которые сделают разработку веб-приложений еще проще. Несколько уважаемых поставщиков инструментов были членами экспертной группы JSR-314, которая разработала спецификацию JavaServer Faces 1.0. Эти поставщики привержены поддержке технологии JavaServer Faces в своих инструментах, тем самым способствуя принятию стандарта технологии JavaServer Faces.
Это модель запутывания; вещь по-своему красивая. В почти сотне слов он почти ничего не говорит. Он ухитряется использовать название «JavaServer Faces» не менее пяти раз, ни разу не дав более чем смутного намека на то, что это на самом деле — что-то связанное с пользовательскими интерфейсами, по-видимому, хотя в Интернете, на рабочем столе или в другом месте я не мог сказать. Он действительно сообщает вам целую кучу вещей, которыми вы можете простозаинтересоваться после года или двух фактической работы с технологией, но которые не могут быть интересны ни одному разумному существу, знакомящемуся с ней в первый раз. . То, что несколько уважаемых поставщиков инструментов были членами экспертной группы JSR-314, не было в моем списке вещей, которые нужно узнать о JSF.
(Позвольте мне сказать, что моя цель здесь не в том, чтобы придраться конкретно к JSF. Это всего лишь один из сотен одинаково плотных примеров, которые я мог бы выбрать — и это, на самом деле, как раз моя точка зрения.)
Я полагаю, что любая библиотека, основные функции которой не могут быть изложены на одной странице формата A4 (или US Letter, если вы настаиваете), слишком сложна и нуждается в переработке. Под «слишком сложным» здесь я подразумеваю не просто то, что он делает слишком много, но то, что он делает, недостаточно сфокусирован. На самом деле вы должны быть в состоянии кратко описать, что делает библиотека, в одном предложении. И если предложение начинается «Это основа для построения абстракций, которые можно использовать для получения моделей, которые…», то вы проиграли.
Довод 2: Минимизируйте радиус понимания
«Радиус понимания» — это новый термин, который я ввожу здесь, потому что он описывает важную концепцию, для которой, как мне кажется, нет названия. Это свойство кодовой базы, определяемое следующим образом: если вы смотрите на данный фрагмент кода, насколько далеко от этого фрагмента кода вам нужно иметь в виду в это время, чтобы понять имеющийся фрагмент. ? Это своего рода измерение того, насколько хороша инкапсуляция во всей кодовой базе, хотя, когда я говорю «инкапсуляция» здесь, я использую этот термин в широком смысле, который означает больше, чем просто технические вопросы, такие как какая доля элементов данных помечен как частный. Я говорю здесь о человеческой проблеме (и, следовательно, к сожалению, почти невозможной для измерения, хотя мы знаем это, когда видим).
Так, например: когда я читаю кодовую базу, с которой я еще не знаком, если я сталкиваюсь с объектом, класс которого называется Employee, или HashTable, или CharacterEncoding, я могу быть достаточно уверен, что понимаю, для чего предназначен этот класс. делаю, и я могу догадаться о значении вызываемых в нем методов — радиус понимания приятно низок. Если я столкнусь с объектами класса EmployeeFactory, я, вероятно, сделаю хорошее предположение и, вероятно, буду прав. Если я найду CharacterEncodingMediatorFrobnicationDecorator, у меня не будет четкого представления о том, что это такое, если я не пойду и не прочитаю код сам, поэтому радиус понимания увеличивается. Именование классов — лишь один из многих факторов, влияющих на радиус понимания: другие включают неизменность объектов, функции, которые гарантированно не имеют побочных эффектов, и — что труднее всего определить количественно — концептуальное единство различных модулей.
Значимость радиуса очевидна: когда он мал, нам нужно сразу загрузить лишь небольшую часть кода, чтобы понять ту часть, которую мы пытаемся прочитать, отладить или улучшить. Когда радиус велик, ценное пространство разума должно быть отдано вопросам, которые не имеют прямого отношения к проблеме, которую мы пытаемся решить; и чем о большем количестве вещей мы должны думать одновременно, тем меньше внимания мы можем уделить основной проблеме.
Радиус понимания зависит от того, сколько вы должны удержать в голове, прежде чем сможете начать продуктивно работать. Джоэл Спольски написал о проблеме прерываний — как они выбивают программистов из зоны, так что нам приходится заново перезагружать все свое психическое состояние, прежде чем мы сможем вернуться к полезной работе (см. спокойные условия работы?») Раз так, то нам нужно строить наше программное обеспечение таким образом, чтобы у программистов было минимальное количество для перезагрузки после каждого перерыва. И это особенно важно для разработчиков библиотек и (где возможно) фреймворков.
Как можно уменьшить радиус? В общих чертах это просто бритва Оккама: не умножайте сущности без надобности. Каждая библиотека должна предоставлять наименьшее возможное количество классов API, и каждая должна поддерживать минимальное количество методов. Это многое очевидно. Но можем ли мы выйти за рамки этих общих положений и предложить некоторые предварительные рекомендации по уменьшению радиуса? Мы могли бы попробовать следующее, с подобающим смирением, в надежде, что критика их приведет к лучшим правилам:
- Каждый вид вещей должен иметь только одно представление. Это кажется настолько очевидным, что едва ли нуждается в уточнении, но ошибочное различие Java между
ArrayиArrayListделает его достойным упоминания. - Насколько это возможно, объекты должны представлять реальные вещи. Иногда шаблоны проектирования вводят классы для представления абстракций, таких как итерации, стратегии и декораторы: это может быть необходимым злом, но тем не менее это зло. Каждый такой класс увеличивает радиус.
- гарантированно неизменным, то вероятность того, что мне нужно будет прочитать его исходный код, чтобы понять его, значительно снижается.
- Точно так же легче думать о функциях без побочных эффектов, чем о тех, которые изменяют состояние одного или нескольких объектов.
Когда языки имеют синтаксис, который позволяет нам помечать объекты как неизменяемые или функции как свободные от побочных эффектов, мы должны использовать их: такая нотация является документацией, которую компилятор может проверить за нас. Отсутствие таких возможностей в чрезвычайно динамичных языках, таких как Ruby, является слабостью.
Наконец, как отметил Бьерн Страуструп в Языке программирования C++ (2-е издание), «дизайн и программирование — это деятельность человека; забудь об этом, и все потеряно… Нет методов из «поваренной книги», которые могли бы заменить интеллект, опыт и хороший вкус». Я думаю, что радиус понимания — полезная концепция, но она послужит нам лучше всего, если мы будем просто помнить об этом при разработке API, а не слепо следовать правилам, которые предназначены для его уменьшения.
В начале своей карьеры я провел десять лет, работая над частной базой данных текста и объектов, полностью написанной на C, которая должна была строить свою объектную ориентацию из запасных частей. По всем стандартным ожиданиям, это должно было быть кошмарно. Но на самом деле у кода был очень низкий радиус понимания просто потому, что он был разработан с заботой, вниманием и вкусом очень талантливого и старательного архитектора. Чтобы работать с этой очень большой системой, мне нужно было одновременно иметь в уме только очень маленькую ее часть. Я могу только надеяться, что через десять лет люди, которые работали со мной, смогут сказать то же самое о моем коде.
об авторе
Майк Тейлор начал программировать на PET 2001 в 1980 году и продал свои первые коммерческие программы для VIC-20 два года спустя, в возрасте 14 лет. Интернет. Он работает в Index Data, самой маленькой транснациональной корпорации в мире, для которой его выпуски бесплатного программного обеспечения включают синтаксические анализаторы запросов, преобразователь OpenURL и наборы инструментов для опроса удаленных IR-серверов. В свободное время он занимается палеонтологией динозавров: в 2007 году он описал и назвал зауропода Xenoposeidon, а в 2009 году пересмотрел Brachiosaurus. Его новый блог по программированию The Reinvigorated Programmer , присоединяется к многолетнему фавориту Картинка недели с изображением позвонка зауропода или SV-POW! для краткости. Майк написал много программ на Perl, но недавно стал лучше и теперь пишет в основном на Ruby. Однажды он действительно выучит Лисп.
Майк любит суши. Все изображения суши под лицензией Creative Commons By-2.0 и загружены и изменены из: Прямоугольная тарелка с диагональным нигири сверху (TedsBlog), Лосось нигири (adactio), Круглая тарелка (mdid), Одинарная внутри -сегмент наружного ролла лежа (без зевка), Квадратная тарелка в косой проекции (Geoff Peters 604), и Четыре лосося наизнанку роллы (Хорхе-11).
