Людей, которые пишут код, можно разделить на два типа: кодеры и программисты. Дмитрий Соколов, сооснователь Alef Development, на примерах из рабочей практики объясняет, как отличить их друг от друга, и рассказывает, почему любить код, стараться не использовать "грязные" методы программирования и решать задачу не быстро, а качественно – крайне важно.

В чем отличие?

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

Программист – это образ мышления. Он не впадает в ступор, столкнувшись с задачей, решение которой не знает с ходу. Программист придумывает свои подходы к работе и стремится разобраться, как все системы и алгоритмы устроены изнутри.

Фундаментальными отличиями программиста от кодера являются:

• влюбленность в дело (если человек в жизни не написал ни единой строчки кода для себя, потому чтонравится, – вряд ли он является программистом);
• подход к программированию как к искусству (стремление к построению архитектуры, которая радует глаз, и поиску красивых решений задач, а, главное, получение от этого неподдельного удовольствия).

Все остальное – уже следствия из этих базовых различий:

• программист смотрит на любую задачу шире, продумывая и предусматривая все особенности, а кодер решает задачу поверхностно и очень редко заглядывает за рамки формулировки;
• программист заинтересован в том, чтобы его решение работало как можно лучше – кодер хочет сдать задачу побыстрее.

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

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

Возможный подход программиста:

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

Программист постарается избежать решения задачи «грязными» способами, если есть другой выход.

Вот пример из реальной жизни. В базе данных одной системы была негласная закономерность: идентификаторы объектов начинались с цифр, соответствующих дате их создания (908157567437 – обозначало, что объект создан в 2009 году, 15 августа).

Это не было задокументированной особенностью, такой вывод можно было сделать только на основе наблюдений. Никакой гарантии, что так будет работать всегда, не было. Вместе с этим существовала надежная возможность узнать дату создания объекта, обратившись по связке к другой таблице, – такой способ требовал больше времени и усилий.

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

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

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

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

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

Признаки непрограммиста

Вернусь к заголовку статьи. Итак, программистом никогда не станет человек, который:

1. не получает удовольствия от написания кода;
2. не использует законы логики в повседневной жизни;
3. при виде сложных вычислений или страницы кода впадает в уныние и хочет, чтобы это поскорее убрали с его глаз долой;
4. не готов проводить много часов, анализируя свои ошибки и занимаясь поиском лучших решений;
5. не умеет самостоятельно обучаться новому;
6. не интересуется фундаментальным устройством компьютера: что такое процессор и его команды, как устроена оперативная память, во что превращаются программы после компиляции;
7. печатает двумя пальцами и не планирует переучиваться.

ИСТОЧНИК