Кто такой хороший программист? Как это понятие изменились, скажем, за последние 50 лет?
В 60-е, 70-е и частично в 80-е, компьютеры были дорогими, редкими, слабыми. Хорошим программистом называли того, кто может решить задачу наиболее оптимальным образом. Сэкономил десяток тактов процессора? Молодец! Программа потребляет на 100 байтов меньше ОЗУ? Вообще здорово! Ценились неординарно мыслящие специалисты, которые могли найти нетривиальное решение, позволяющее потратить наименьшее количество ресурсов компьютера. В каком-то смысле, программисты напоминали математиков, а написание программы – доказательство теоремы.
Годы идут. Сейчас компьютеры, напротив, весьма производительные, дешёвые, используются везде. Бюджетный телефон мощнее суперкомпьютера 70х! А цена компьютеров настолько низкая, что их не забирают даже воры. Сложность программ же выросла экспоненциально.
Очевидно, такие фундаментальные изменения не могли не повлиять на подход к разработке программ, а соответственно и тех, кто их пишет. Сейчас хороший программист – полная противоположность хорошему программисту из прошлого.
Итак, современный хороший программист должен мыслить максимально прямолинейно. Не надо никаких выкрутасов, оригинальности и программной эквилибристики. Код должен быть тривиальным, понятным и стандартным. Для решения задач должно использоваться максимальное число готовых библиотек и компонентов.
Если какую-то вещь можно сделать просто, но решение будет жрать много ресурсов компьютера, или как-то ухитриться и сделать оригинально и экономично – нужно выбрать первый способ. Тоже самое касается и скорости разработки – из двух вариантов следует выбрать менее трудоёмкий, не обращая внимания на то, сколько ему требуется ОЗУ/процессора.
Естественно, хороший программист должен придерживаться корпоративного стиля оформления кода, соблюдать регламенты и правила работы.
Оптимизациями же должен заниматься компилятор. Либо человек, но только после выявления проблем с производительностью и только в местах, выявленных при профилировании. Большинство оптимизаций, которые может сделать программист, никто из пользователей никогда не заметит за весь период эксплуатации продукта. А вот сорванный срок разработки – компания почувствует.
Если обобщить – хороший программист, это тот, кого можно в любой момент уволить и заменить другим - но на сроках проекта это никак не скажется. Бизнес не может зависеть от отдельных людей.
Если у вас в компании есть гений-программист, который пишет код, который никто кроме него понять не может – ему нужно объяснить в каком году он живёт, а если это не поможет - избавиться. Как бы он не был лоялен компании – он всё равно может заболеть или с ним может что-то случиться. А ведь проекты, которые существуют, развиваются и поддерживаются более 10-20 лет – не такая уж и редкость. Но что бы такое было возможно, код должен быть таким, чтобы в нём могли разобраться новые люди на проекте. Причём, желательно за минимальное время.
Так же нужно жёстко пресекать попытки программистов тратить своё время (а значит и деньги компании) на переписывание рабочего кода. Помню у нас был программист, который, по недосмотру своего руководителя, 3 дня потратил на оптимизацию работы со списком (stl его не устроил). Причём в том списке могло быть максимально 10 элементов и обращения к нему были не часты!
У многих молодых программистов есть проблема, что они слишком увлекаются процессом программирования, забывая о конечном результате и то, для чего программа вообще разрабатывается. Они начинают воспринимать работу, как школьную олимпиаду по программированию. Задачи же воспринимают, как учебные упражнения – и подходят к ним соответствующие. Таких тоже нужно возвращать в реальность.
Коллеги! Подписывайтесь на канал, ставьте лайки. Я собираюсь продолжить писать интересный материал о работе руководителя, IT-индустрии, бизнесе, ну и просто о жизни офисного планктона.