Есть ли какие-то «улики», свидетельствующие о том, что человек, писавший код, находится в самом начале своей карьеры разработчика? На этот вопрос отвечали посетители сайта Quora.
Теодоракопоулос Никос, главный менеджер/технический директор в Vision Solutions
«Улики», касающиеся написания кода
- Дублирование кода.
- Непонятный и сложный код.
- Неадекватное комментирование, особенно сложных алгоритмов и операций.
- Неэффективный нейминг (например, наличие многих переменных с названиями «data», «records», «variable», «item», «object», которые не несут смысловой нагрузки).
- Длинные методы.
- Отсутствие решения нужной задачи (частичное ее решение или решение не той задачи).
- Ресурсоемкие операции в циклах (файл I/O, запросы к базе данных, вызовы веб-сервиса).
- Попытки разрабатывать все с нуля без предварительной проверки, нет ли уже готовых решений проблемы или ее части в кодовой базе. Попытки изобрести колесо.
«Улики», касающиеся тестирования
- Обращение в отдельному массиву или списку без проверки их существования.
- Деление на число без проверки, не является ли оно нулем.
- Отсутствие проверок на null (в литературе указывается, что с этим связано 40-60% багов).
- Отсутствие модульных тестов.
«Улики», касающиеся структуры/архитектуры
- Полное игнорирование существующей архитектуры и норм.
- Зацепление базы данных и GUI, да и вообще зацепления.
- Божественные объекты (объекты с очень большим числом свойств и методов, часто не имеющих отношения друг к другу).
- Огромное количество не относящегося к делу кода в одном файле.
- Отсутствие связности, добавление метода к классу, к которому он не относится. Например, добавление метода, который относится к манипулированию строками в классе DAL (уровень доступа к данным), к классу, относящемуся к данным клиента.
Энди Бойд, учился в Zend Certified Engineer
Вот несколько вещей, которые даже при беглом просмотре кода выдают, что его автор — джуниор.
Оговорка: приведенные примеры в основном касаются LAMP stack, потому что я провожу собеседования с людьми именно по этим темам. Но общие идеи применимы и в других языках. Так что любители .NET могут расслабиться.
Окончания строк
*nix и Windows имеют разные последовательности символов для окончания строк (\n vs \r\n). Допустим, есть код,который будет запускаться на Linux, но в котором используются окончания строк для Windows. Это говорит мне о том, что человек разрабатывает ПО для Linux на WAMPP или еще каком-то стеке на базе Windows, но на уровне джуниора. Учитесь строить VM.
Табы и пробелы
Стандартный отступ в большинстве языков это четыре пробела, а для shell-скриптов – два. В голову не приходит ни одного языка, где стандартный отступ указан в табах. Поэтому, если я вижу код, где использованы табы, я предполагаю, что:
- человек не знает лучших вариантов;
- он не пользуется IDE, которая обычно выполняет замену на пробелы вместо вас.
Любой из этих вариантов указывает на джуниора.
Другие стилевые отклонения
Каждый язык имеет стандарты стиля. Могут допускаться некоторые вариации, но в целом есть очевидные вещи, указывающие на то, что это код джуниора: неправильный выбор строчных и заглавных букв для имен переменных, неправильный стиль написания констант классов, использование подчеркиваний в именах переменных (вместо CamelCase), использование CamelCase для названий столбцов в базе данных (вместо подчеркиваний) и т.п.
Непоследовательное форматирование
Любая IDE отформатирует ваш код, от вас потребуется лишь пара нажатий клавиш. Если отступы не на месте и фигурные скобки не выровнены, я знаю, что человек, наверное, не пользуется правильной IDE. Вероятно, у него также нет возможности отладить код или взглянуть на стек вызовов в режиме реального времени. Джуниор.
Цикломатическая сложность и N-Path, или чертовы реально длинные функции
Цикломатическая сложность и N-Path это пара умно звучащих выражений для определения функций длиной больше 30 строк.
Незрелые решения в проектировании или изобретение колеса
Однажды я унаследовал кодовую базу на PHP с функциями в 2000+ строк, которые объединяли одну гигантскую строку XML вместо использования массива или библиотеки XML объекта. Зачастую джуниор будет пытаться решать проблему, для которой уже есть стандартное решение, о котором он попросту не знает.
Эндрю Эванс, технический директор и ETL-разработчик
Все очень зависит от ситуации. Например, вы можете программировать на Java и не иметь понятия о Pep8. Но среди «говорящих» признаков можно перечислить:
- недостаток модульности и абстракции;
- постоянное изобретение велосипеда;
- стабильно более длинные функции;
- строгое следование изученному в вузе, а не лучшим практикам.
Также нужно быть осторожным с идеями по решению проблем. Меня однажды назвали джуниором за то что я закрыл 15 тикетов одной программой, которая решала то, что было, в общем, одной-единственной проблемой. Порой вы можете зрить в корень и видеть настоящую проблему, но это приведет к неприятностям, потому что вы работаете с ленивыми му***ми.
Флавьен Волкен, учился в École Polytechnique Fédérale de Lausanne
Несколько пунктов, на которые стоит обращать внимание (и которые первыми приходят на ум):
- Нейминг переменных / функций. Вроде использования «i» вместо «index».
- Бесполезные комментарии вместо подходящих имен.
- Длина методов (обычно чем короче, тем лучше).
- Последовательность кода (в отношении имен, структуры, дизайна).
- Соблюдение принципов S.O.L.I.D.
- Один метод – одно назначение.
- Размер классов.
- Управление ошибками (если есть).
- Изобретение колеса или использование шаблонов проектирования?
- Используются ли новейшие свойства языка в правильном контексте?
- Наличие тестов (модульных или сквозных).
- Правильно ли используется система контроля версий.
- Есть ли автоматизация развертывания.
Ион Каспельхорн
Между разработчиком-джуниором и разработчиком-мидлом нет четкой линии разграничения, это скорее градиент. Так что я думаю, любые показатели для сравнения должны быть гибкими. Также следует учитывать, что многие «симптомы» джуниорства очень привязаны к языку. Плохое управление памятью? А может, это не джуниор, а кто-то, проработавший пять лет с языком программирования, с которым ему не надо было беспокоиться об этой проблеме? Незнание экосистемы и соглашений? Джуниор это или кто-то, работающий с новым для себя языком?
И насколько этот джуниор «джуниористый»? Человек, программирующий полгода, сильно отличается от человека, программирующего на протяжении трех лет. Но оба они потенциально являются джуниорами. Или мидлами!
Есть определенные вещи, на которые я обращаю внимание, но вряд ли их можно считать «неопровержимыми уликами».
1. Количество кода, которое нужно прочесть, прежде чем станет ясно, что делает модуль. Это водораздел между императивным и декларативным программированием. Если вы можете определить назначение программы, пробежавшись по именам функций и переменных, это хороший знак.
Если же вам нужно отследить, какие значения содержатся в каких переменных, если вам приходится разбираться в реализации прежде, чем вы поймете функцию, значит, вы смотрите на код джуниора. Чем больше кода вам нужно прочесть, чтобы понять его работу, тем «джуниористее» этот джуниор.
2. Если вы хотите заменить dependency (например, заменить модуль, стороннюю библиотеку или сервис-провайдера), сколько кода вам нужно будет изменить? Чем больше зацеплены модули, тем неопытнее разработчик.
Со старшим разработчиком вы можете быть уверены, что поменять код нужно будет всего в паре мест. Вы, скорее всего, даже не глядя на код догадаетесь, где именно искать эти места в кодовой базе.
3. Этот пункт более спорный, но я нахожу его полезным. Если вы спрашиваете разработчика (без указания контекста), что бы он хотел улучшить в вашем приложении, то о чем он скажет?
Кинется улучшать реализации – переименовывать члены класса, использовать другую структуру данных для некоторых внутренних состояний класса, заменять циклы for на map – разработчик может быть джуниором, хотя, конечно, возможны и исключения.
Если же он говорит о более общих идеях – улучшении usability класса или API, расцеплении классов или модулей или даже об изменении архитектуры отдельного слоя в приложении, то в таком случае разработчик может быть более опытным.
В общем (подчеркну – в общем), чем крупнее картина, которую разработчик видит, тем он старше. Возможно, это потому, что более опытный разработчик так часто выполняет тактические задачи, что уже не считает интересным говорить о них. Конечно, разработчики-сеньоры тоже видят плохие реализации и хотят их исправить. Но это им не кажется срочным.
Имеет значение, зачем проверяется уровень разработчика
Когда речь заходит о разделении на джуниоров, мидлов и сеньоров, я думаю, имеет значение, почему вы хотите это знать. Если это связано с уровнем оплаты, вы будете обращать внимание совсем на другие вещи, чем если вопрос будет связан с тем, какого рода задачи может решать этот человек.
Но в общем (еще раз подчеркну – в общем), начинающие разработчики полностью сфокусированы на написании рабочего кода без багов. Чем разработчик старше, тем больше он начинает думать о долгосрочной перспективе – поддержке, масштабируемости, когнитивной нагрузке.
Брайан МакКлайн, директор в Code Immersives
Если вы даете разработчику массив и просите написать цикл for, который будет его перебирать, и он выдает что-то вроде:
[code]four(let i == 0; j > array.len; k++) [
council.blog(some(item))
][/code]
Это шутка, но для начала вполне можно обратить внимание на то, как человек управляется с функциями более высокого уровня и асинхронными данными.
Также следует определиться, что мы имеем в виду, говоря о разработчиках-сеньорах. Означает ли этот тайтл наличие некоторых руководящих способностей, возможно, опыт в менеджменте проектов, или сеньор просто должен уметь писать код немного лучше, чем джуниор?
Стоит отметить, что языки и платформы, которые выбирают сеньоры, могут быть не самыми передовыми. Так что быть джуниором не так уж плохо. Вы начинаете с точки, где можете просто игнорировать множество вещей, которые более старшие разработчики учили годами (поскольку эти вещи уже устарели или их можно заменить более современными). Сообразительный, трудолюбивый и быстро обучаемый разработчик-джуниор довольно скоро станет сеньором.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
Что-то не густо с комментариями )
ахах, утешил в последних строчках))
Поспорил бы с каждым пунктом, но вот это говорит о непрофессионализме людей отвечающих на вопросы:
неправильный стиль написания констант классов, использование подчеркиваний в именах переменных (вместо CamelCase), использование CamelCase для названий столбцов в базе данных (вместо подчеркиваний) и т.п.
1) Кто называет ПОЛЯ в БД столбцами?
2) Хорошо жить начали, например в БД Firebird до 4 версии (еще в бете) название ПОЛЯ может состоять максимум из 32 символов, исходя из этого написание в CamelCase сохраняет прилично места.
И по всей статье так, люди возомнили себя профессионалами и пытаются учить других