Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО
Печатающая головка перемещалась на каретке. С каждым символом каретка сдвигалась на одну позицию вправо, вместе с ней смещалась и печатающая головка. Когда каретка доходила до конца 72-символьной строки, каретку приходилось возвращать в начало строки, отправляя символ возврата каретки (r = 0x0D); без этого печатающая головка продолжала бы печатать символы в 72 столбце, и от многократной печати там появился бы черный прямоугольник.
Конечно, этого было недостаточно. Возврат каретки не приводил к смещению бумаги к следующей строке. Если бы после возврата каретки не передавался символ перевода строки (n = 0x0A), то новая строка была бы напечатана поверх старой.
Итак, для телетайпа ASR33 строки должны были завершаться последовательностью «rn». Однако и здесь была необходима осторожность, потому что возврат каретки мог занять более 100 миллисекунд. Если ограничиться отправкой «nr», то следующий символ мог оказаться напечатанным во время обратного хода каретки, а в середине строки появился бы смазанный символ. Для надежности символы конца строки часто дополнялись одним или двумя символами «забой» (0xFF).[56]
В 1970-е годы, когда телетайпы стали постепенно выходить из употребления, в операционных системах UNIX последовательность конца строки сократилась до n. Однако другие операционные системы – например DOS – продолжали использовать обозначение rn.
Когда вам в последний раз попался текстовый файл, использующий «неправильное» обозначение? Я сталкиваюсь с этой проблемой не реже раза в год. Два идентичных файла с исходным кодом не сравниваются, а их контрольные суммы различаются, потому что в них используются разные завершители строк. Текстовые редакторы некорректно переносят слова или разделяют строки двойным интервалом, потому что они интерпретируют rn как две строки. Некоторые программы понимают rn, но не распознают nr… И так далее.
Вот что я имею в виду под детализацией. Попробуйте-ка закодировать логику обработки завершителей строк на UML!
Без изменений и надежд
Движение MDA обещало, что использование диаграмм вместо кода позволит исключить из программирования большое количество второстепенных подробностей. До настоящего момента эти обещания не оправдались. Как оказалось, в коде не так уж много лишних подробностей, которые можно было бы исключить при помощи диаграмм. Более того, диаграммы тоже содержат свои второстепенные подробности. Они обладают своей грамматикой, синтаксисом, правилами и ограничениями. В конечном счете различия в уровне детализации оказываются незначительными.
Движение MDA обещало, что работа с диаграммами будет осуществляться на более высоком уровне абстракции, чем работа с кодом – подобно тому, как Java находится на более высоком уровне абстракции по сравнению с ассемблером. Но и эти обещания тоже не оправдались. Различия в уровне абстракции в лучшем случае незначительны.
В завершение представьте, что в один прекрасный день будет изобретен действительно полезный диаграммный язык. Но ведь рисовать диаграммы будут не архитекторы, а программисты. Диаграммы попросту станут новым кодом, и программистам придется «рисовать» этот код – ведь в конечном итоге все сводится к подробностям, а управлять ими приходится именно программистам.
Заключение
С тех времен, как я занялся программированием, появилось великое множество новых и чрезвычайно мощных инструментов. Мой текущий инструментарий ограничивается небольшим подмножеством этого арсенала. Я использую git для управления исходным кодом, Tracker для отслеживания текущих задач, Jenkins для непрерывной сборки, интегрированную среду IntelliJ, XUnit для тестирования и FitNesse для компонентного тестирования.
Я работаю на компьютере Macbook Pro с процессором 2.8Ггц Intel Core i7, с 17-дюймовым монитором, 8 Гбайт памяти, 512Гбайт SSD и двумя дополнительными экранами.
Примечания
1
Без паники!
2
Технический термин неизвестного происхождения.
3
Ассемблер для компьютера Honeywell H200, аналог Autocoder для компьютера IBM 1401.
4
Если, конечно, он правильно понимает профессиональную ответственность.
5
Robert C. Martin, Principles, Patterns, and Practices of Agile Software Development, Upper Saddle River, NJ: Prentice Hall, 2002.
6
Также называемой «бережливой». – Примеч. перев.
7
Американский профсоюзный лидер, исчезнувший при загадочных обстоятельствах. – Примеч. пер.
8
http://raptureinvenice.com/?p=63
9
День массовых распродаж в США; приходится на период с 22 по 29 ноября. – Примеч. перев.
10
Возможно, за исключением непосредственного работодателя Джона, хотя я готов поспорить, что он тоже оказался в проигрыше.
11
Правда, никаких денег я на этом не потерял. Я продал свой патент Teradyne за 1 доллар согласно условиям контракта (хотя и этот доллар я не получил).
12
Мартин Р. Чистый код. Создание, анализ и рефакторинг. СПб.: Питер, 2010.
13
Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Upper Saddle River, NJ: Prentice Hall, 2003.
14
Я не знаю ни одной методологии, которая бы сравнилась по эффективности с TDD, – но вдруг она известна вам?
15
Эта тема гораздо подробнее рассматривается в главе 10.
16
См. главу 7.
17
К мужчинам это относится в гораздо большей степени, чем к женщинам. У меня была замечательная беседа с @desi (Дези Макадам, основательница DevChix) о мотивации женщин-программистов. Я сказал ей, что для меня заставить программу работать – примерно то же самое, что на охоте убить огромного зверя. Она сказала, что для нее и для других женщин, с которыми она общалась, написание кода является созидательным актом.
18
С высоты своего возраста я считаю ребенком всех, кому меньше 35 лет. Когда мне было за 20, я тратил довольно много времени на написание глупых игр на интерпретируемых языках. Я программировал космические «стрелялки», приключенческие игры, имитаторы скачек, «змейки», азартные игры… и т. п.
19
http://fitnesse.org
20
90 % – минимальная оценка. На самом деле значение намного выше. Точную величину покрытия трудно рассчитать, потому что программные инструменты «не видят» код, выполняемый во внешних процессах или блоках catch.
21
http://www.objectmentor.com/omSolutions/agile_customers.html
22
E. Michael Maximilien, Laurie Williams, “Assessing Test-Driven Development at IBM,“ http://collaboration.csc.ncsu.edu/laurie/Papers/MAXIMILIEN_WILLIAMS.PDF
23
Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language, Upper Saddle River, NJ: Prentice Hall, 1975.
24
А если некоторые программисты и ждут, то это трагическая случайность, которая свидетельствует об их неаккуратности. В современном мире время сборки должно измеряться секундами, а не минутами – и уж конечно, не часами.
25
Рик Хики называет этот метод «разработкой через лежание в гамаке».
26
Эта ката стала очень популярной; Google выдает информацию о многих ее разновидностях. Описание оригинала находится по адресу http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata
27
Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Upper Saddle River, NJ: Prentice Hall, 2003.
28
http://codekata.pragprog.com
29
Мы используем префикс «Прагматик», чтобы отличить его от «Большого» Дэйва Томаса из OTI.
30
http://codingdojo.org/
31
http://katas.softwarecraftsmanship.org/?p=71
32
http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
33
XP Immersion 3, May, 2000. http://c2.com/cgi/wiki?TomsTalkAtXpImmersionThree
34
Исходное условие: команда LogFileDirectoryStartupCommand
Исходное условие: до выполнения команды каталог old_inactive_logs существует
И содержит файл с именем x
После выполнения команды каталог old_inactive_logs должен существовать и должен содержать файл с именем x. – Примеч. пер.
35
Выполнить 15 операций отправки данных и просуммировать время. Убедиться в том, что z-показатель для двух секунд не менее 2,57. – Примеч. пер.
36
Выполнить 15 операций отправки данных и просуммировать время. Убедиться, что вероятность того, что операция займет не более двух секунд, составляет не менее 99,5 %. – Примеч. пер.
37
http://www.satisfice.com/articles/what_is_et.shtml
38
Mike Cohn, Succeeding with Agile, Boston, MA: Addison-Wesley, 2009.
39
Мана – стандартный ресурс в фэнтезийных и ролевых играх типа «Dungeons &Dragons». Каждый игрок обладает определенным количеством маны – магической субстанции, которая расходуется на применение магических заклинаний. Чем мощнее заклинание, тем больше на него расходуется маны. Восстановление маны происходит медленно, с фиксированным ежедневным приращением. Неопытные игроки способны легко израсходовать всю ману за несколько применений.
