Peter Wayner. 10 Hard Ttruths Developers Must Learn to Accept. www.infoworld.com
Чаще всего труд программиста вознаграждается полученным опытом, и нет задач, с которыми квалифицированный разработчик не справился бы.
Упорство, интуиция, правильно выбранный инструмент – все это помогает выдавать элегантный и красивый код.
Но небрежности, допущенные при внедрении, запросы на интеграцию дополнительных функций или слабо документированное обновление с нарушенными зависимостями способны легко разрушить эту красоту.
Конечно, хотелось бы, чтобы все наши усилия приводили к желаемому результату, чтобы сервисы, на которых базируются приложения, были устойчивы, как скала, чтобы программистам оказывалось уважение, которого они заслуживают, хотя бы со стороны тех, кому до профессиональных знаний еще очень далеко. Но холодная и жестокая реальность, окружающая романтический ореол программирования, довольно быстро спускает нас с небес на землю.
Вот десять горьких истин, который должен знать каждый разработчик.
.jpg)
1. Все крутится вокруг оператора if-then-else
Изобретатели языка ломают копья вокруг вложенных структур, типов и удивительных абстракций, но в итоге все эти изощренные конструкции сводятся к старому доброму условному оператору if-then-else.
Именно такую реализацию предоставляют нам аппаратные средства. Да, существуют инструкции, для того чтобы помещать данные в память и считывать их из нее, а также инструкции для выполнения различных арифметических операций, но в конце концов мы возвращаемся к ветвлению и выполнению определенного кода в зависимости от результатов сравнения.
Погружение в искусственный интеллект сопровождается упаковкой оператора if-then-else в различные таинственные покровы, но затем мудрый статистический механизм начинает выбирать из ряда чисел наибольшее или наименьшее значение. Он выполняет многочисленные вычисления, после чего открывает список, бормоча про себя: «Если первое значение больше, то… иначе… если первое значение больше, то… иначе… если первое значение больше, то…», -- так делает до тех пор, пока не доберется до окончательного ответа.
2. Большая часть веб-страниц – данные, хранящиеся в таблицах
За последние двадцать лет слово «Интернет» стало ассоциироваться с обещаниями прекрасной погоды, удачных знакомств, дешевых товаров, быстрой связи и много чего еще, за исключением, быть может, исцеления от рака. Но, по сути, большая часть Сети – это набор данных, хранящихся в виде таблиц.
Match.com? Таблица потенциальных знакомств, с колонками, заполненными цветом волос, исповедуемой религией и любимым десертом. eBay? Таблица сделок с колонкой, в которую записывается самая высокая предлагаемая цена. Блоги? Таблица с отдельной строкой для комментария очередного капризного нытика. Назовем ресурс своим именем – это таблица.
Автоматический учетчик файлов, а вовсе не электронный вариант Гэндальфа или Дамблдора.
Все это хорошо прослеживается в языках программирования. Ruby on Rails – одна из самых ярких комет, прочертивших небосклон Web, на поверку оказалась красивым тонким шпоном, наклеенным поверх базы данных. Определите глобальную переменную, и Rails создаст для вас колонку, потому что все здесь строится в виде таблиц базы данных.
3. У пользователей всегда есть собственное мнение
Вы-то, наверное, думали, что участник события, созданный вами в программе под именем «сохранить», выполняет некие действия, записывая на диск копию состояния программы. А между тем пользователи видят перед собой совсем иное – волшебную кнопку, которая обещает исправить все ошибки в их рухнувшем документе или добавить к их стандартному пенсионному плану нечто раскрывающее небеса и указывающее дорогу к вечной жизни.
Бывают моменты, когда пользователи излучают очарование, но в большинстве случаев они изворотливы и непредсказуемы. А еще они могут быть и очень требовательны. Программисты пытаются угадать, какие неприятности могут возникнуть, когда пользователи начнут издеваться над окончательной версией их кода, но, как правило, все усилия пропадают даром. Большинство пользователей не являются программистами, а просить разработчика думать, как средний пользователь, – все равно что просить кошку думать, как собака.
Это выходит за рамки обычной бестолковости пользователей. И не слишком важно, насколько грандиозным было ваше изобретение и элегантным код – в любом случае, он обречен.
4. Большая часть вашего кода никогда не используется
Гордитесь тем, что ваша новая программа умеет говорить на XML, CSV и арамейском? Простите, но нам было бы куда приятнее, если бы она умела расшифровывать иероглифы индейцев майя. Конец 2012 г.... Конечно, если такая функция не предусмотрена, ничего не случится, но если бы она присутствовала, нам было бы гораздо проще подписывать новые заказы на покупку.
Конечно, рядовым пользователям нужно гораздо меньше. Они хотят видеть перед собой всего одну кнопку, но порой даже она способна привести их в замешательство. Чудесный код, который вы написали для поддержки других кнопок N-1, возможно, и оказался затронут группой, занимающейся тестированием, но вполне вероятно, что ваши трудовые подвиги и ночные бдения всего лишь принесены в жертву обычной бюрократии и что их итоги никогда не будут востребованы.
Художники всегда получают очередной импульс для вдохновения, продав несколько своих работ родителям или родственникам. Программистам такой путь заказан. Наши родители никогда не придут и не выполнят код функции, которая, как показалось кому-то в ходе очередного мозгового штурма, способна в корне изменить характер игры.
5. Расширение масштабов проекта неизбежно
Один менеджер как-то раз поведал свой секрет. Он всегда улыбается и хвалит подчиненных за то, что они делают, даже если это совершенно ужасно. И только подойдя к двери, добавляет: «Да, и еще одно…» Таким хитрым способом он очень часто переворачивает весь проект с ног на голову, отправляя всех его участников переписывать приложение.
Расширение масштабов практически всегда вытекает из структуры проекта. Всю тяжелую работу с электронными таблицами руководители проделывают до его начала. Они вынашивают амбициозные планы и выстраивают экономические модели, чтобы оправдать инвестиции.
Менеджеры любят бросать фразы вроде «пока вы тут слонялись без дела» или «когда вы натянули на глаза свой капюшон». В конце концов, от расширения масштабов страдал даже аналитический механизм Ады Лавлейс, который многие называют первой компьютерной программой. Он был завершен почти на год позже намеченных сроков и оброс множеством дополнений и замечаний.
.jpg)
6. Никто вас не понимает – особенно начальник
Существуют два типа программистов: те, кто работает на начальников, которые не умеют программировать и не знают, как тяжело компилировать код, и те, кто работает на бывших программистов, уже забывших, как тяжело компилировать код.
Начальник никогда не поймет ни вас, ни вашу работу. Когда убежденный гуманитарий, специалист в области развития бизнеса выдвигает идею, которую можно осмыслить лишь при наличии ясновидящего компьютерного чипа, все понятно. По-другому он просто не может.
А что же с начальником, который все забыл? Здесь тоже все ясно. Через месяц-другой даже самый лучший программист забывает API для библиотеки. А теперь представьте, что человек не читал программный код уже на протяжении двух-трех лет. И во время учебы проходил Java, а не JavaScript. А между тем даже Ruby – уже вчерашний день.
У этой истины есть одна положительная черта: если начальник понял, как решить задачу, он задержится вечером и решит ее. А вот на поиск программиста и общение с ним у него уйдет гораздо больше времени.
7. Конфиденциальность – это всегда головная боль
Мы желаем, чтобы наши продукты защищали пользователей и их информацию. Но вместе с тем нам хочется, чтобы сайты были простыми в эксплуатации. Глубина операций (количество действий, которые нужно совершить, чтобы добраться до цели) должна быть минимальной.
Но дело в том, что конфиденциальность требует ответов на ряд вопросов, и их непременно нужно получить, прежде чем двигаться дальше.
Предоставление людям контроля над распространением информации предполагает добавление еще нескольких кнопок для описания происходящего.
Конфиденциальность влечет за собой дополнительную ответственность. Если пользователь не хочет, чтобы на сервере оставались какие-то следы, он тем самым должен взять ответственность на себя, потому что сервер не может прочитать его мысли. Ответственность порождает дополнительные препятствия, а следовательно, конфиденциальность также связана с дополнительными препятствиями.
Конфиденциальность может привести нас к взаимоисключающим логическим связям. Существуют два противоположных желания: чтобы никто вас не трогал и чтобы можно было отправить кому-нибудь совершенно потрясающее сообщение. Одно желание связано с пребыванием в состоянии блаженного покоя, а другое предполагает последующее получение любовного письма, предложения о работе, приглашения встретиться пообедать вместе или посетить распродажу в вашем любимом магазине.
Увы, одно невозможно без другого. Если вы боретесь с внешними раздражителями, придется отказаться от приглашения на вечеринку. Даже если вы скрываете свой адрес электронной почты, наверняка найдется кто-то, кто приложит все силы, для того чтобы найти способ связаться с вами. И, скорее всего, у него это получится.
8. Доверие стоит недешево
Обещания Web 2.0 звучали потрясающе. Просто вставьте в свой код ссылку на чужой код, и случится настоящее чудо. Ваш код сможет обращаться к коду других, другие смогут обращаться к вашему, а инструкции начнут плясать вместе, как Фред и Джинджер.
О, если бы все было так просто. Ведь прежде чем вам позволят использовать чужой код, нужно заполнить множество специальных форм. Вашему адвокату это наверняка не понравится, потому что в формах везде придется поставить свою подпись с отказом от всех прав. А что вы получите взамен?
Моральное удовлетворение от того, что ваш код будет время от времени получать ответы от чужого кода. Просто доверьтесь нам.
И кого потом винить? Быть может, вы, сами о том не подозревая, связались со спамерами, мошенниками и ворами, которые хотят использовать возможности Web 2.0, для того чтобы проворачивать свои делишки. И им вы тоже должны доверять. А пользователь вынужден доверять и вам, и им.
Конфиденциальность? Конечно. Все обещают использовать при обмене информацией самые передовые технологии и самые мощные средства шифрования. Не беспокойтесь. В итоге же зачастую вам придется проделать гораздо больше работы, чем было обещано.
9. Битовая деградация
Приступая к работе, вы обращаетесь к самым последним версиям библиотек, и в течение недели или двух все работает без каких-либо сбоев. Затем выпускается версия библиотеки A за номером 1.0.2, но она оказывается не совместимой с новейшим вариантом библиотеки B, потому что программисты A в процессе разработки имели дело с предыдущей версией. После этого разработчики библиотеки C также выпускают новую версию, включая в нее ряд функций, которые желает видеть ваш начальник. Естественно, она будет работать только с версией 1.0.2.
Когда здания и корабли стареют, одновременно стареют и все их элементы. Когда устаревает код, он распадается на куски очень странным и непонятным образом. Если вы хотите получить C, вам следует отказаться от B. А если вы выбрали B, придется сообщить начальнику, что C ему не светит.
В этом примере у нас было только три библиотеки. В реальных проектах таких библиотек оказывается с десяток и даже больше, и потому проблемы растут как снежный ком. Еще хуже, что подобная деградация не всегда выявляется сразу. Иногда трудности возникают лишь в каких-то несущественных моментах, которые можно обойти. Но крошечные проявления несовместимости нарастают, и мало-помалу термиты доводят свое дело до конца, вплоть до полного коллапса.
Появление битовой деградации тем удивительнее, что компьютерный код не подлежит износу. Здесь нет движущихся частей, нет трения и окисления, нет углеродных цепочек, вызывающих гибель микробов.
Казалось бы, программный код – это памятник вечности, который и через сто лет будет так же хорош, как и в тот день, когда он был написан. Увы, все не так.
Единственным светлым пятном здесь являются эмуляторы, помогающие снова и снова запускать старый код, написанный для Commodore 64 или Atari. Чудесные музеи, позволяющие хранить и выполнять код вечно – до тех пор, пока битовая деградация не доберется до самих эмуляторов.
10. Обнесенный стеною сад будет цвести
При всех разговорах о том, как важна открытость, мы видим все больше и больше свидетельств того, что в этом нуждается лишь весьма небольшая часть рынка. Причем зачастую игроки не хотят платить за дополнительные привилегии. Защитники бесплатного программного обеспечения желают не только свободы его распространения, но и свободы внесения любых изменений в программный код. И лишь очень немногие готовы отчислять за это дополнительные денежные средства.
Вот почему наиболее мощные сторонники Linux и BSD окружают свободное программное обеспечение проприетарным кодом. Устройства наподобие TiVo построены на базе Linux, но интерфейс, который и делает подобные решения по-настоящему интересными, не является открытым. То же самое относится и к семейству Mac.
Компаниям, поставляющим компьютеры на платформе Linux, сложно конкурировать с производителями систем Windows. Зачем платить ту же цену за Linux, если можно купить машину Windows и установить на нее Linux в качестве второй операционной системы?
Обнесенные стеной сады зацветут, когда люди начнут платить больше за то, что находится у них внутри. этих стен. И сейчас мы видим все больше примеров того, что люди готовы вносить плату за вход. Портативные компьютеры Macintosh стоят в 2--3 раза дороже обычных ПК, а между тем магазины забиты ими под завязку.
Стены становятся все толще. В начале продаж третьей версии iPad компания Apple хвасталась отгрузками миллионов и миллионов устройств, приходящих на смену ПК. Глубоко внутри у iPhone находится операционная система с открытым кодом, но лишь очень небольшому проценту клиентов известно об этом. Пока люди пребывают в неведении и их не слишком беспокоит подобное положение дел, «огороженные сады будут процветать».