Coders at Work

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

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

Соблазнительно думать, что можно использовать одну программную парадигму для написания параллельных программ и затем реализовывать ее. Тогда для всех программ применялась бы одна парадигма.

Думаю, мы обманываем себя, когда говорим, что проверили программу и все в порядке. Лучше честно сказать, что мы повышаем свою уверенность в ней. Тут все может начинаться скромно — вы повышаете уверенность на 75%, прикладывая всего 5% от общего количества усилий. Это хороший показатель.

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

Чтобы работать над кодом, надо быть в нужном состоянии. А разве это возможно, если работаешь в паре? Из двоих всегда один не в настроении, хочет читать почту и все такое.

Сырые программы никому не нужны. «Делайте простейшую вещь из всех возможных» и «Беспощадный рефакторинг!» — эти два призыва совсем не означают, что надо писать сырой код, отказавшись от предварительного проектирования.

Основная аксиома проектирования API такова: «Сомневаешься — выкидывай». Простейшая вещь должна быть достаточно велика, чтобы соответствовать всем намеченным сценариям использования. Это вовсе не означает, что надо склеивать воедино сырые фрагменты кода. На этот счет есть куча афоризмов. Мой любимый — тот, что ошибочно приписывают Телониусу Монку: «Сделать просто — непросто».

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

Чем больше вы полагаетесь на свой API, тем больше вы к нему добавляете. Но основное правило вот какое: сначала напишите код, использующий API, а потом уже код его реализации. Иначе вы можете потратить впустую время, написав код, который не будет использоваться. На самом деле код, использующий API, надо писать даже до подробной разработки спецификации — иначе можно потратить время на детальную спецификацию чего-то в корне неработоспособного. Вот такой у меня подход к проектированию.

Для тех, кто создает библиотеки, компиляторы, фрейм-ворки, намного важнее математика. А для создания веб-приложений на базе фреймворков требуются навыки словесного и визуального общения.

А вообще, как только обнаруживаю, что занимаюсь копированием-вставкой, сразу думаю: «Что не так в моей архитектуре? Как это исправить?» Исправление требует некоторого времени. Я стал строже к себе, и это помогает мне писать качественные программы. Сам себя плохому не научишь.

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

Считается, что мы параноики и невротики, вечно озабоченные чем-то персонажи Вуди Аллена, но на самом деле параноику нечего делать в программировании.

Нетерпение и неприязнь к примитивным инструментам — вот из-за чего я старался совершенствоваться в программировании. Наш код сегодня испещрен проверками утверждений, и они фатальны.

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

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