Термин «информатика» меня уже давно немного раздражает. Это стандартный термин для обучения программированию в колледже, но, на мой взгляд, это своего рода ложь, потому что программирование по большей части не является наукой в формальном смысле.
Есть много терминов, которые я могу применять к программированию:
- Прежде всего, программирование - это инженерия. Вы берете установленный набор процедур, руководящих принципов и правил и применяете их к новым проблемам. Часто это довольно недисциплинированная отрасль инженерии (я, конечно, знаю инженеров, которые в результате насмехаются над ней), но все сделано хорошо, я думаю, что этот термин применим, поэтому я предпочитаю «программную инженерию» «информатике».
- Об этом стоит думать также как о ремесле. Это положительная сторона этой довольно слабой дисциплины: поскольку каждая проблема немного отличается, программирование, как правило, не сводится к правилам, но тогда забота серьезного мастера становится действительно важной. Дело не только в знании деталей - требуется много практики, чтобы научиться правильно соединять их во множестве различных конфигураций. (Иногда я говорю, что научился программировать в лучшем средневековом стиле, обучаясь у своего отца в его ремесле, когда мне было 14 лет).
- Мне даже удобно называть программирование искусством. Конечно, это верно не для всех, и это действительно искусство, которое говорит только другим программистам, но когда я смотрю на код, он полностью задействует эстетическую часть моего мозга. Когда я использую такие слова, как «красивый», «элегантный» или «уродливый» для описания блока кода, я не говорю метафорически: для меня это так же верно, как когда я смотрю на картину или скульптуру.
Но «наука»? Да, люди лениво часто используют это слово как синоним слова «технология», но, ИМО, это вводит в заблуждение. Наука - это не о технологиях. Наука - это довольно специфическая техника для исследования мира и его понимания.
Есть несколько вариантов того, как люди описывают научный метод (здесь я в основном следую за Поппером - вы можете изменить следующее на основе других версий), но, грубо говоря, это выглядит так:
- Начните с вопроса или проблемы, которые вы пытаетесь понять.
- Соберите данные по этому вопросу.
- На основе полученных данных сформулируйте гипотезы о том, что может происходить.
- Придумывайте опровергающие эксперименты, которые либо подтверждают, либо опровергают вашу гипотезу.
- Проведите эти эксперименты.
- Проанализируйте результаты и на их основе решите, находитесь ли вы вне базы или стоит следовать этой линии мысли.
Это действительно не похоже на программирование, не так ли? В основном нет, но есть одно большое исключение:
Правильная отладка - это в точности наука.
Это нюанс, который большинство старших программистов знают интуитивно, но младшие иногда испытывают трудности, потому что многие образовательные программы уделяют мало внимания процессу отладки или вообще не уделяют ему никакого внимания. Что жаль, потому что это одно из самых распространенных занятий, которые выполняют все программисты, и оно заслуживает понимания.
Столкнувшись с ошибкой, люди иногда просто борются с ней - волей-неволей пытаются что-то изменить, делают предположения, иногда она просто начинает работать, и они объявляют победу, несмотря на то, что на самом деле не понимают, что было не так или почему сейчас правильно.
Вместо этого я рекомендую вам научный метод, когда вы сталкиваетесь с ошибкой. В этом случае потребуется немного другой объектив, но, надеюсь, вы сможете увидеть сходство с приведенным выше:
- Для начала у вас есть проблема, которую нужно решить: рассматриваемая ошибка.
- Начните со сбора данных. Столько данных. Все данные. Именно здесь молодые инженеры часто спотыкаются, потому что кажется, что вы наверняка тратите время на сбор всех этих данных, но часто приходится делать довольно много. Посмотрите на ошибки. Поговорите с пользователями о том, что они видят. Добавьте операторы печати. (Да, они старомодны, но часто все еще нет ничего более полезного, чем куча
println.) - Собирая данные, продолжайте искать в них закономерности. (При необходимости привлекайте других программистов, которые будут действовать как резиновые утки в ваших поисках шаблонов.) Начните пытаться выдвигать гипотезы о том, что может происходить, но продолжайте сравнивать их с данными, чтобы увидеть, подходят ли они. Если нет, продолжайте собирать данные. Как долго это займет? Нет однозначного ответа - у меня были ошибки, когда я обнаруживал закономерность за пять минут, и другие, где на это уходило пять месяцев. Но ничего не остается, как продолжать собирать новые и разные данные и видеть то, что вы в них видите.
- Когда у вас появится гипотеза, подумайте, как ее проверить. Да, вы можете просто погрузиться и исправить это, но в идеале говорите об этом более формально. Лучший подход, если у вас есть такая роскошь, - это начать с написания неудачного регрессионного теста, который иллюстрирует проблему и который, если ваша гипотеза верна, будет работать после того, как вы ее исправите.
- Затем вы исправляете ошибку после того, как проведете хорошо опровергнутый эксперимент. Если тест заработает - отлично! У вас есть веские доказательства того, что вы не только исправили ошибку, но и понимаете, что вы только что сделали и почему это работает. А если нет, значит, вы опровергли свою гипотезу, так что пора сделать шаг назад и предложить другую.
Этот последний бит очень важен и заслуживает внимания. Когда что-то давало сбой, а теперь работает, и вы не знаете почему, уместны смешанные эмоции: здорово, что на вас не пялился жук, но очень неудобно, что вы не можете быть уверены, что он победил не вернусь. Научный подход к отладке дает вам понимание того, в чем была проблема, что помогает избежать ее и связанных с ней ошибок в будущем.
Наконец, существует распространенное заблуждение относительно научного метода, которое полностью применимо и к отладке: «доказательство» редко бывает абсолютным. Чем больше тестов вы пройдете, тем больше у вас будет уверенности в том, что вы знаете, что делаете, но не впадайте в высокомерие, полагая, что вы полностью понимаете все возможности. Иногда это возможно в программировании (в большей степени, с современными, более строгими подходами к FP), но обычно цель должна состоять в том, чтобы углубить ваше понимание и получить больше уверенности в нем. Однако не позволяйте этому взбрыкнуть - в следующий раз, когда что-то пойдет не так и вы получите данные, которые противоречат вашему пониманию, вам следует начать с веры в эти данные и провести больше экспериментов, чтобы определить реальность ситуации. Никогда не предполагайте, что вы лучше, чем эмпирические данные, знаете, что на самом деле происходит при запуске программы.
Если вы не делали этого раньше, я рекомендую попробовать этот подход в следующий раз, когда вы столкнетесь с ошибкой. Это может показаться немного медленным и трудоемким, но эта формальность часто может сэкономить много времени в долгосрочной перспективе, потому что часто приводит к лучшему исправлению ошибок и лучшему пониманию вашего кода.
