Люди, занимающиеся написанием кода, условно делятся на две категории: первая – кодеры, вторая – программисты. Сооснователю компании Alef Development, Дмитрию Соколову, приходилось работать и с теми, и с другими. Теперь он может с помощью наглядных примеров из собственной практики рассказать, чем они отличаются и почему любовь к кодам, отказ от «грязных» методов решения задач и стремление к улучшению качества, а не скорости, играют важнейшую роль.
В чем разница?
Прежде всего, пройдемся по терминам. Кодер – это человек с уровнем IQ, достаточным для занятий интеллектуальной деятельностью. Справиться он может только с типовыми задачами, выстраивая решение по образцу, как это делают школьники на уроках математики.
Программист мыслит более масштабно. Его не вгоняют в ступор ранее неизвестные проблемы. В работе он стремится найти свои подходы и понять, из чего состоят алгоритмы, что скрыто внутри систем, по каким правилам они функционируют и т. д.
Ключевые отличия между кодером и настоящим программистом заключаются в следующем:
- любовь к своему делу (тот, кто никогда не писал код просто так, для себя, на волне вдохновения, вряд ли может стать хорошим программистом);
- отношение к программам как к виду искусства (когда архитектура приятна глазу, да и сам процесс поиска решений доставляет искреннее удовольствие).
Из этих главных различий следуют остальные:
- программист смотрит глубже, размышляя над деталями, тогда как кодер видит поверхностно, изредка выходя за рамки стандартных действий;
- цель программиста – найти лучшее решение, кодера – быстрое.
Рассмотрим пример: есть задача «создать программу с кнопкой, которая после клика будет выводить на экран соседнее простое число, стоящее после числа, записанного в специальное поле».
Тактика типичного кодера: в интернете найти любой алгоритм отбора чисел, дополнить его кнопкой с обработкой нажатия, протестировать несколько раз и все – дело сделано.
Вероятные действия программиста:
- найти несколько различных алгоритмов отбора чисел и после детального изучения выбрать самый подходящий;
- реализовать модель;
- предусмотреть проверку данных, после чего создать выскакивающее уведомление в случае ошибки при вводе (неверный формат);
- тщательно протестировать программу на различных примерах, выявить недостатки и исправить их;
- внедрить индикатор загрузки;
- поставить блокировку на кнопку для избежания повторного нажатия.
В качестве примера приведем реальный случай. Однажды сотрудники компании заметили закономерность в рабочей базе данных: первые пять цифр в начале ID объектов совпадали с датой создания этих объектов (например, ID 506108678548 значил, что файл был создан 10 июня 2005 года).
Эта особенность не подтверждалась документами, ее обнаружили только в ходе наблюдений. Гарантий, что идентификатор всегда будет показывать верную дату, не было. Узнать настоящие год, месяц и число создания объекта можно было другим, более надежным, но и более затратным по времени и приложенным усилиям способом – по связям между таблицами.
Однако человеку свойственно идти по пути наименьшего сопротивления. Поэтому много лет при составлении отчетов работники пользовались ненадежной закономерностью. И вот наступил момент, когда совпадения дали сбой: с первого месяца 2010 года даты начали отображаться неверно.
Ошибок можно было бы избежать, но для этого пришлось бы потратить время и заняться настройкой синхронизации данных. Так и поступил бы хороший программист, ведь он просто не смог бы успокоиться, пока решение задачи не начало бы базироваться на фактах, а не предположениях.
В данной ситуации сбой было легко заметить и исправить. А что если ошибка выявится только через много лет? Причем она может возникнуть очень внезапно, при сложном стечении обстоятельств, и тогда специалистам придется долго ломать голову над случившимся. И хорошо, если недочет обнаружится в программе менее ответственной, чем панель управления атомным реактором или системе пилотирования самолета, иначе цена расплаты окажется слишком высокой, а последствия – трагическими.
Справедливости ради заметим, что даже хороший программист время от времени использует «грязные» методы решения задач, но он обязательно предварительно оценивает все возможные риски.
Предположим, нужно разработать инструмент для разового использования, способный проанализировать большой объем нестандартных данных. На создание красивой архитектуры уйдет неделя работы, тогда как простой вариант можно реализовать и за полчаса. Да, результат будет не самым красивым, но задача решится быстрее, тем более что инструмент впредь никому не пригодится. Так что время от времени «красоту» нарушать можно, лишь бы цель оправдывала средства.
Признаки не программиста
Итак, возвратимся к заголовку статьи. Опыт показывает, что не получится стать программистом тому, кто:
- пишет код без удовольствия;
- в повседневных ситуациях не пользуется законами логики;
- увидев трудные вычисления и страницу длинного кода, испытывает панику или отчаяние;
- не способен уделять много времени анализу собственных ошибок, устранению недочетов и поиску более подходящих решений;
- не может самостоятельно изучать новое, не стремится развиваться;
- безразличен к устройству компьютера, работе процессора, свойствам оперативной памяти, тому, что происходит с программами по итогу компиляции;
- печатает медленно, обучаться «слепой» печати не планирует.