Как отличить новичка от профессионального разработчика

Специалисты разделились на два лагеря. Первые считают, что новичка видно за версту. Другие, что IDE сгладил неровности и вышло что-то вроде правильного 65537-угольника, который неотличим от окружности, при разрешении в 1000 пикселей. Кто прав?

Почему отличить начинающего программиста просто

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

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

А почему сложно?

Современные среды разработки настолько хороши, что исправляют те самые ошибки в названиях переменных, расставляют отступы, где это необходимо, дают знать, когда вы пропустили ветвь или проигнорировали ошибку. Многим непрограммистам может показаться, что IDE делает всю работу вместо специалистов, но это совсем не так. Наоборот, начинающим и опытным разработчикам она помогает избежать мелких ошибок.

По использованию инструментария можно понять на каком этапе развития находится программист

Вначале он пытается решить задачу любыми способами, используя то, что есть у него в голове на данный момент. Код получается запутанным и примитивным — зачастую, работает, но о каком-либо изяществе говорить не имеет смысла. Часто на данном этапе не соблюдается что-то вроде «общепринятого стиля кода», который сформирован компанией или здравым смыслом.

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

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

Хороший программист — ленивый

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

Забота о коллегах-программистах

Профессионал понимает, что его код много раз прочтут — возможно, через год ему придется вернуться к проекту, а там черт ногу сломит. И вот, чтобы человек мог без боли-страданий вносить правки или дополнять в материал, создатель оставляет комментарии-заметки к участкам, которые могут вызвать затруднения.

Также он предусматривает, чтобы методы помещались на экран. Автор не набросал все в кучу, а разделил одну объемную задачу на несколько простых, для того, чтобы не переусложнять функции. А названия классов станут лаконичными и четко отражать суть того, что в них положили.

Стандарты

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

Но стандарты могут быть не только в рамках команды, но и в сообществе вцелом. Так, существуют жесткие ограничения на использования конструкции goto — она создает спагетти-код, который невозможно читать, к тому же он нестабилен. Разумеется, код, построенный на goto, считается откровенно плохим. Подобные вещи называются анти-паттернами.

От общего, к частному

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

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

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

Возможность тестирования

Доступность проведения тестов — это очень важно. Жесткая привязка компонентов может не лучшим образом повлиять как на качество, так и на стоимость тестирования. Профи также обращают внимание на возможность ввода некорректных данных: если не предусмотреть этот момент, приложение может закончить работу ошибкой.

Поддержка — это важно, если вы понимаете о чем я

Код, написанный профессионалом, легко оптимизировать, поддерживать и масштабировать. Новичок же, в основном, не думает о будущем своего продукта, поэтому часто может возникать ситуация: «как-то работает, но я не знаю как — не трогать». Очевидно, что качества продукту это не добавляет, зато добавляет к сложности и цене поддержки.

У профессионалов скучный код

Потому что предсказуемый. Вы не найдете за шубами Нарнию, и не будете искать «Magic numbers», чтобы код начал работать правильно. Никакого веселья, только стабильная работа с предсказуемыми результатами.

Последовательность

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

Будь Малевичем

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

Или… не будь Малевичем?

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

Повторение — мать учения?

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

Не все то золото, что с нуля

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

Подводя итоги

Код, написанный профессионалом, лучше структурирован, более читабелен и стабилен. Если без сложных участков не обойтись, для них написаны лаконичные комментарии, в которых раскрыта причина действий. Профи не допускает ситуации, когда в коде остаются неиспользуемые фрагменты или части «на будущее». Новичков тянет в неуместные абстракции, написание «велосипедов», решение проблем «костылями», создание god object и magic numbers.

18.11.2018
165
Автор: Ася Яскер