Пока спрос на программистов в ИТ-индустрии и за ее пределами достаточно высокий. Но в любой отрасли «хороший» специалист ценится всегда, вне зависимости от ее популярности. Возникает вопрос, как стать таким специалистом? Какие критерии профессионализма высокого уровня можно выделить? Ответы на эти вопросы во многом зависят от конкретных работодателей.
В каждой компании, разрабатывающей программное обеспечение существуют свои требования к разработчикам. Современные программные проекты разрабатываются группами программистов, которые часто работают в разных кабинетах, зданиях, и даже городах и странах. Технологии удаленной работы позволяют использовать навыки лучших разработчиков, вне зависимости от места нахождения их работодателей. Такой подход к разработке предъявляет серьёзные требования к качеству кода, в частности, к его читабельности и прозрачности.
Для слабых разработчиков работа в изоляции может стать непреодолимым препятствием, так как они выпадают из-под опеки более опытных коллег, которые обычно тянут отстающих за собой.
Среди профессионалов всегда существуют какие-то договоренности. Это выражается, например, в том, что в свое время сформировались различные парадигмы и стили программирования. Однако, прежде всего, существуют некие базовые требования, которые предъявляются к профессиональным программистам независимо от направления и стиля разработки.
Если программист не соответствует базовым требованиям, то ему рано или поздно укажут на дверь.
Признаки плохого программиста
Распространенным и одним из главных признаков считается неспособность «выполнять программу в голове». Если перед вами человек с красивыми должностями в резюме, но он не может написать простой алгоритм на бумаге, лучше с ним не связываться.
На «Хабре» в свое время был пост, в котором обсуждались признаки плохого программиста:
• наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается;
• исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода;
• «йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали
• «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Он также выделяет еще две проблемы – с указателями и рекурсией. Если кто-то сам не пишет рекурсивные алгоритмы и не выполняет операции с указателями вручную, понимать, как это работает, необходимо.
Сложности с указателями
Если вы не понимаете указатели, то остаётся очень небольшой круг типов программ, которые вы можете написать, поскольку это понимание позволяет создавать сложные структуры данных и целесообразные API. Непонимание концепции указателей отразится в бедном проектировании структур данных и ошибках, причины которых кроются в разнице между передачей по значению и по ссылке.
Управляемые языки используют ссылки вместо указателей, которые похожи, но обеспечивают автоматическое разыменование и запрещают арифметические операции над указателями для устранения целого класса ошибок.
Сложности с рекурсией
Идею рекурсии достаточно легко понять, но у программистов часто возникают проблемы с тем, чтобы представить результат рекурсивной операции или насколько сложные вычисления могут быть произведены с простой функцией. Проблемы с представлением «где вы находитесь», когда вы начинаете писать условие продолжения рекурсии, или с формализацией параметров рекурсивной функции могут сделать разработку рекурсивной функции очень сложной для вас.
Следование договоренностям
Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня. Ведь это противоречит принципам всех парадигмам программирования – объектно-ориентированной, функциональной, декларативной и так далее. Такой подход затрудняет или делает практически невозможной коллективную разработку. Подобное отношение характеризует человека как ригидного, поверхностного, не желающего углублять свои знания и совершенствовать навыки.
@victorb, автор упомянутого выше поста указывает следующие «симптомы», связанные с неумением следовать парадигме разработки:
• использование любого необходимого синтаксиса для того, чтобы «вырваться» из предлагаемой языком модели, и написание оставшейся части программы в императивном/процедурном стиле;
• (ООП) Попытки вызова не статических функций или присвоения переменных в неинстанциированных классах, проблемы с пониманием, почему такие конструкции не компилируются;
• (Реляционное) Обращение с базой данных как с хранилищем объектов, исполнение всех JOIN'ов и проверки целостности на клиентской стороне;
• (Функциональное) Создание многих версий одного и того же алгоритма для обработки разных типов или операторов вместо передачи функций высшего порядка обобщенному алгоритму;
• (Декларативное) Установление индивидуальных значений в императивном коде вместо использования связывания данных (data binding).
Кроме однозначных минусов у разработчика могут быть такие качества, как перфекционизм, излишний педантизм, медлительность и так далее. Эти качества неспецифичны для какой-либо отрасли, но для кого-то они будут иметь решающее значение, а для кого-то – нет.
Мы пообщались с экспертами российской ИТ-индустрии и выяснили их мнение по поводу хороших и плохих программистов, а также попросили дать пару советов начинающим.
Максим Нальский, основатель сервиса Pyrus:
Какими качествами должен обладать хороший программист?
Хороший программист пишет качественный исходный код лучше и быстрее других. Если человек знает модные технологии, работал в крутых компаниях, окончил престижный ВУЗ, блещет рекомендациями, но не производит хороший исходный код за разумное время, вряд ли его можно называть сильным программистом.
Программирование — это способ , который не зависит от конкретного языка или платформы. Сильный разработчик осваивает новую технологию за неделю и уже может производить результат. Конечно, стать экспертом занимает большее время.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Умение написать легко читаемый, компилируемый, проходящий автотесты, работающий код — главный критерий.
Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.
Если хотите стать плохим программистом — идите на курсы, слушайте лекции, только ни в коем случае не программируйте сами. Некоторые так и делают — штудируют учебники, потом сдают экзамены, получают бумажки, сертификаты.
Когда я читаю резюме с длинным списком сертификатов, я вижу, как человек тратил время своей жизни, не совершенствуясь в навыках создания надежного софта, а получал оценки.
Руслан Фазлыев, СЕО Ecwid:
Какими качествами должен обладать хороший программист?
Хороший программист должен выпускать хороший код, быстро, результативно.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Отличить хорошего программиста – по тому, что он создал и насколько быстро решает простые задачи. Сложные задачи состоят из простых, и, если программист легко владеет атомарными кубиками, он будет результативен.
Может ли хороший программист быть перфекционистом? Почему?
Хороший программист может быть кем угодно – лентяем, перфекционистом, занудой. Использовать эти сильные стороны и митигировать слабые – задача хорошего инженерного менеджера.
Должны ли компании опасаться программистов-перфекционистов? Почему?
Их не нужно опасаться, ими нужно управлять. Частые промежуточные дедлайны – обязательно для перфекционистов, если у них не «рожается» код, нужно делать «кесарево».
Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?
Отлично, если это ускоряет результат.
Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?
Хорошему программисту нужно заниматься тем, чтобы сегодня же код работал у клиента. Игрок должен забивать голы, как он это делает – не важно. Опасайтесь слова «архитектура» от программистов. Говоря же о красоте кода – прекрасно, когда она есть естественно и по ходу дела, и да, море «if'ов» – не красиво и глюкоопасно. Но я не хочу это обсуждать с программистом: все, что я хочу знать – когда будет готов протестированный качественный релиз.
Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.
Все счастливые семьи счастливы одинаково, быть несчастным есть миллион способов. Первейший способ быть плохим программистом – лениться, гордиться, и искать сложных решений там, где есть простые.
Евгений Потапов, гендиректор «Сумма АйТи»:
Какими качествами должен обладать хороший программист?
В отличнейшей книге Coders at work (серии интервью с известными разработчиками) — один из главных вопросов «каким образом вы изучаете чужой код?».
Хороший программист это тот, кто может поддерживать чужой проект, тот кто может после запуска продолжать дописывать свой код, тот, чей код могут поддерживать другие люди.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Я считаю, что единственным нормальным способом оценки программиста непрограммистом является оценка того, как отзываются о тех проектах, где он работал, руководители этих проектов. Не бросил на полпути, выполнил в срок, продолжал доработки и ничего не упало — значит все хорошо; просят сказать, где его можно найти, чтобы убить — на работу лучше не брать.
Может ли хороший программист быть перфекционистом? Почему?
Может, если это не будет идти во вред производительности. К сожалению, почти наверняка идет, а в современном бизнесе время до деплоя куда важнее идеальности кода в большинстве случаев (пока вы не пишете медицинский софт и не запускаете людей в космос).
Должны ли компании опасаться программистов-перфекционистов? Почему?
Должны, но компании должны спрашивать отзывы с предыдущих мест работы, и если там все хорошо — сильно не бояться.
Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?
А как относиться к тому, что строители теперь сами не собирают глину и не пекут кирпичи? Знание алгоритмов — важный базис, однако основным навыком сейчас становится возможность склеить нужные решения надежно, поддерживаемо и в срок.
Позволительно ли хорошему программисту хронически не помнить некоторые алгоритмы и синтаксические конструкции языков, которыми он пользуется в работе? Почему?
Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать
Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?
Хороший программист это не тот, кто не пишет goto, делает return там, где это положено, и знает все паттерны ООП из Gang of Four на зубок.
Хороший программист — это тот, кто пишет код не только потому, что ему интересно, а потому, что ему нужно чтобы проект работал; ему хочется, чтобы пользователи были довольны, и он понимает что те, кто придут за ним, не должны испытывать боли.
Виктор Шабуров, технический директор Snapchat:
Какими качествами должен обладать хороший программист?
Smart and get things done.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Может ли хороший программист быть перфекционистом?
Да, это очень хорошо.
Должны ли компании опасаться программистов-перфекционистов? Почему?
Я не опасаюсь, наоборот люблю. Менеджер должен конечно ставить цели и контролировать их исполнение в срок. Но в целом это классное качество, если оно сочетается со скоростью программирования и целеустремленностью.
Должен ли хороший программист использовать выражения return true или return false в циклах?
Лет 10 назад, когда я еще кодировал, ответ был «нет».
Правда ли, что хороший программист обычно старается использовать меньше условных операторов?
Надо писать красивый код и использовать столько if, сколько нужно. В Java, например, пользоваться && и ||, чтобы сократить if.
Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?
Я использовал else, когда было нужно, но есть тонкости.
Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.
Лучше я дам хорошие советы — постоянно работать над собой, улучшать свои навыки программирования и по мере роста переходить в более крутые компании. Чем сильнее программисты на проекте — тем интереснее работать и большему научишься.
Так же смотреть не столько на зарплату, сколько на перспективу проекта и выделяемые акции компании. В успешном проекте с сильной командой, как Looksery или Machine Learning Works, на акциях можно в десятки раз больше заработать, чем получить зарплатой за это период.
Становление «хорошего» программиста сводится не только к исправлению чисто технических недостатков. Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами. Умение адекватно воспринимать обратную связь, критику считаются не менее важными качествами, чем способность к усвоению алгоритмов и технологий разработки ПО.
Автор: semen_grinshtein
