День 135. Размышления о работе программиста (II)

2. Брэд Фицпатрик, создатель livejournal


Я прошел через множество стилей: сначала объектно-ориентированный, потом функциональный, а затем непонятная смесь того и другого. Вот почему я люблю Perl. С его уродливым синтаксисом, с накопившимся за много лет багажом и изъянами, он никогда не парит мне мозги, задавая стандарт оформления кода. Любой стиль, который вам нравится, хорош. Можно сделать свой код красивым и последовательным, но нет никакого стандарта, определяемого самим языком.

Мне начали предлагать проекты, и те, что мне не нравились, я передавал приятелю из другого города, с которым познакомился в сети. И вот однажды нам достался такой крупный проект (впоследствии это стало Живым Журналом), что ни один из нас самостоятельно его бы не потянул, и мы сказали заказчику: «Для этого проекта нужны двое». И он отправил нас в Пенсильванию. Он был очень общительный. Пошел в туалет в моем номере и даже не закрыл дверь, хотя я стоял рядом. Я сказал что-то вроде: «Отлично, будь как дома». Казалось, будто мы знаем друг друга лет пять, хотя на самом деле никогда не встречались. И мы начали работать над проектом вместе. Мы просыпались в 10-11 утра, работали до полудня, сидя в трусах, потом немного смотрели телевизор, после чего трудились в непрерывном режиме до 3-4 часов ночи.

Я определенно пытался найти повод применить или изучить что-то новое. Никогда не изучишь что-либо, не написав для этого программу и не начав жить и дышать этим. Одно дело выучить язык ради удовольствия, но нельзя говорить о том, что знаешь его, пока не напишешь на нем большую сложную систему.

На практике никогда ничего не работает нормально. За прекрасными абстракциями скрывается всякая дрянь. Библиотеки могут выглядеть прекрасно, но работают отвратительно. И если именно вы отвечаете за покупку серверов или за поддержку, то очень полезно знать, что же на самом деле происходит внутри, не доверяя чужим библиотекам, коду и интерфейсам.

Я начинаю с самых сложных кусков или с тех частей, в которых не уверен, и пытаюсь реализовать их в первую очередь. Я стараюсь не оставлять ничего сложного или потенциально неожиданного под конец: я предпочитаю с самого начала решить наиболее трудные вещи. Причина, по которой я так и не завершил ряд своих проектов (друзья говорят, что их целая куча), связана с тем, что я начинал с наиболее сложной части проекта, изучал то, что хотел изучить, и не возвращался к оставшейся неинтересной части.

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

Думаю, постепенно я научился лучше оценивать время, но, слава богу, меня не просят об этом слишком часто. И сейчас, когда на носу дедлайн, я думаю: «Ура! Дедлайн!», — меня это так заводит, что адреналин так и хлещет, и я работаю и заканчиваю эту чертову работу. На самом деле, в Google дедлайнов нет. А бывает примерно так: «Как насчет того, чтобы это запустить? Есть такое ощущение?» Реальные сроки сдачи проектов ставятся редко и главным образом в такой форме: «Хорошо бы запустить это к такому-то числу», — и все прилагают для этого максимум усилий. Большинство же проектов, над которыми я работаю, реализуются по принципу «Когда сделаем, тогда и сделаем».

Я понял, что есть те, кто делает только то, что поручено, без какого-либо стремления к совершенству. Они работают по принципу: «Сделано. Следующее задание?» — или ничего не говорят, а просто шарят по Интернету.

Обычно я ищу тех, кто много чего написал по собственной инициативе, а не потому, что ему сказали это сделать. Я не имею в виду учебные задания и проекты от предыдущего работодателя. Я о тех, кто чем-то увлечен, кто выполнял сторонние проекты. Как он их сопровождал и насколько серьезно к ним подходил?

Моя кривая обучения выглядит так: я быстро изучаю что-нибудь, пока не смогу работать с этим достаточно быстро и качественно. Обычно это где-то 80-90%, тогда я работаю весьма продуктивно, мне не приходится постоянно что-то искать, вот и отлично. После этого я продвигаюсь уже медленнее. И только если мне что-то очень уж приглянулось, говорю себе: «Пора поглубже изучить документацию этого языка — мануалы — и обшарить все потайные углы и щели».

Самый важный навык для программиста — мыслить как ученый; за один раз изменять только что-то одно. Терпение и стремление понять коренную сущность вещей.

3. Дуглас Крокфорд, старший архитектор JavaScript в Yahoo!, создатель формата передачи данных json

Я всегда настаиваю на необходимости чтения кода. Думаю, чтение кода — самое полезное, что программисты могут сделать друг для друга: постоянно уделять часть своего времени чтению кода коллег. При управлении проектами программистов часто предоставляют самим себе, затем всю их работу объединяют, и если результат удается скомпилировать, то полученный продукт выпускают на рынок и забывают о нем.

Это приводит к тому, что если у вас в команде есть слабые или неуверенные в себе программисты, то это обнаруживается слишком поздно. В результате возникает риск того, что в проекте будет множество низкокачественных компонентов, которые приведут к срыву сроков, что неприемлемо. Кроме того, у вас могут быть блестящие программисты, которые оказываются недостаточно хорошими руководителями для других членов команды. Чтение кода решает обе эти проблемы.

Мы выводим код на экран и комментируем его по ходу чтения. Кто-то говорит: «Я не понимаю этот комментарий» или «По-моему, этот комментарий не описывает этот код». Это очень важно, поскольку как программист вы перестаете читать свои комментарии, не сознавая, что другому что-то может быть непонятно. Прекрасно, когда коллеги по проекту помогают поддерживать ваш код в чистоте — вы находите ошибки, которые никогда бы не нашли самостоятельно.

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

Я управлял проектами, в которых незадолго до срока сдачи люди говорили: «Все практически готово», — а затем я смотрел их код, но там еще ничего не было или была полная ерунда, или он был очень далек от завершения. Жуткое испытание для руководителя проекта, и я думаю, что чтение кода как раз помогает избежать подобных ловушек.

Одна из главных трудностей программирования в том, что мы обычно занимаемся тем, чем никогда прежде не занимались. Если мы имеем дело с чем-то, что уже делали, то используем это повторно. Но в основном мы делаем то, чего никогда раньше не делали. А создавать что-то, чего никогда не делал, сложно. Заниматься этим очень интересно, но весьма непросто.

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья