Отдел новостей 27 февраля 2018, 12:30

Винтик в системе. Чем плохой разработчик отличается от хорошего

В колонке для dev.by iOS-разработчик Андрей Малыгин рассуждает о том, чем плохой (пассивный) программист отличается от хорошего (активного).

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

Stackoverflow-ориентированное программирование хоть и может помочь, но рано или поздно непонимание вам аукнется.

Попробуем выделить шортлист смертных грехов программиста:

Лень
Нетерпеливость
Высокомерие

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

Активный программист всё ставит под вопрос. Он пытается написать код, который будет выделятся из общей массы. Для этого не обязательно написать оптимизацию, ускоряющую работу системы на 400%. Иногда достаточно вынести в константы разбросанные по коду числовые значения. Это облегчит жизнь следующему разработчику, пытающемуся понять скрытый смысл числа 42.

Подумайте, если вам нечего ответить на вопрос: «А что такого серьёзного написали именно вы в предыдущем проекте?». Может, пора начать проявлять активность, а не кодить на автомате?

Выработать свой стиль

Великого композитора можно узнать по первым звукам его произведения, поэта — по паре строф, то же самое должно быть и с вашим кодом.

Если ваш код просто теряется после мержа и уже через несколько недель вам самим нужно заглядывать в blame, чтобы понять, кто это написал — пора начать работать над собой. Уникальный почерк вовсе не означает, что вы должны писать код, который будут обсуждать на курилке или видеть в страшных снах. Напротив, дядя Боб советует писать в том же стиле и с теми же соглашениями, что уже есть в этом файле или модуле.

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

Быть проще

Любой дурак может написать код, который может понять компьютер. Но только хороший разработчик способен написать код, который поймёт человек. Возможно, вы стараетесь забетонировать должность за собой и поэтому пишете код, на который нельзя взглянуть, не перекрестившись. Не мне вас судить, но если вы задумываетесь о том, как сделать level up своей карьере, пора научиться писать простой, понятный код. Чем меньше сложности и неопределённости в коде — тем лучше.

Не торопиться

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

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

Быть рок-звёздой

Настоящие рок-звёзды в программировании — это не миф, но нужно уметь отличить настоящую от фальшивой. Запомните, хороший программист решает проблемы, а не ноет о них. Если процесс заливки приложения в AppStore занимает у вас полчаса, конечно, можно принять это как данность и сходить заварить себе чайку. Можно пожаловаться об этом на курилке и решить, что «можа, так і трэба». А можно постараться автоматизировать это и попутно прокачать свою карьеру. Берите пример с Феликса.

Не стоит думать, что такой программист будет работать за десятерых. Это из разряда бородатого анекдота про то, что 9 женщин способны выносить ребенка за месяц. Но эффект от его работы будет заметен. Что-то перестанет ломаться, участки кода, на которые до этого нельзя было смотреть без противогаза, начнуть разгребаться. Необязательно рок-звезда должна вести свой блог или выступать на конференциях. Это может быть вполне себе тихий спокойный профиль на github или множество толковых ответов на stackoverflow. Но вы его точно не пропустите.

Помнить о тестировщиках

Даже если ваш код прошёл код ревью, это ещё не означает, что в нём нет проблем. Иногда получается так, что именно ваш код привлекает всё больше и больше внимания тестировщика. Оттуда сыпятся баги, бэклог раздувается, бизнес негодует. Это минус в разработчицкую карму.

Прежде чем отдать свой код в руки другим людям, посмотрите на него внимательно ещё разок. Постарайтесь найти слабые моменты. Откуда могут появиться баги? Не бойтесь потратить лишних полчаса. Том Каргил отлично заметил: «Первые 90% кода пишутся в первые 90% времени. Остальные 10% кода пишутся во вторые 90% времени».

Избавляйтесь от переработок и ночей, проведённых в молитвах после релиза.

Вывод

Возможно, не каждому дано стать суперспециалистом, настоящим маэстро. Однако почти каждый человек «с головой» — при наличии желания, усердия и чуточки терпения — может стать действительно хорошим разработчиком. Если ты не хочешь этого, то никто и никак тебе не поможет.