Як оцінити якість коду, якщо ви не знайомі з мовою? [зачинено]

Як гіпотетично, якби я опитував когось на нову посаду розробника PHP, коли мій досвід роботи в .NET, як я можу визначити, чи зразок коду, який вони мені надали, ефективний та якісний?

Іншими словами, який найкращий спосіб оцінити код програміста, якщо ви не знайомі з мовою?

як я можу визначити, чи зразок коду, який вони мені надали, ефективний та якісний?

Те, що ви не зможете оцінити, - це правильне використання мовних ідіом та використання бібліотеки. Отже, це не речі, на які слід намагатися подивитися.

Що ви можете оцінити:

• Наскільки добре структурований код виглядає
• Добре названі змінні (чи можете ви зрозуміти щось)
• Добре складені функції / одиниці коду
• Послідовність у кодовій базі

Наведені вище пункти (хоча і не вичерпні) вказуватимуть на те, чи пахне кодом чи ні, і чи повинен щось досвідчений програміст визначити як хороший чи поганий.

Якщо коротко - шукайте речі, які повинні вказувати на хороший код незалежно від мови.

Запропонуйте їм блок-схему провести це або провести вас через нього в рамках інтерв'ю. У вас є ідеальне привід для запитання, і це говорить трохи, як вони думають, щоб побачити, як вони пояснюють.

Якщо вони збираються перейти на вашу бажану мову, то ви знаєте, що у вас настає багато наставницьких кадрів, тож ви, в першу чергу, повинні шукати хороші навички логіки / міркування.

Якщо вони продовжуватимуть працювати на своїй бажаній мові, вам доведеться погодитися, що вони мені трохи керуватимуть дрібнішими специфічними мовами деталями, поки хто-небудь ще не прискорить швидкість, тому все, що вам потрібно буде взаємодіяти з - це дизайн сторона також.

Убік кодового / очевидно неправильного коду, ефективність багато в чому залежатиме від компілятора / інтерпретатора мови, про яку йдеться, і ви справді не зможете окомплектувати це з зразка коду. Зразок коду може бути красиво написаний і елегантний, як тонкий Китай на серветках, але працювати повільно, якщо складено / інтерпретуватися погано.

Ви не зможете оцінити ідіоматичне використання мовних особливостей / синтаксичного цукру / умовностей без ознайомлення.

Ви повинні бути в змозі сказати, чи добре це написано в цілому на основі універсальних міркувань, таких як охайність, потік керування, називання змінних, порядок виконання операцій тощо.

Однак, більш практично, якщо ви знаєте, яка мова буде входити в процес, ви можете спробувати знайти один або кілька посібників зі стилю для цієї мови, перейти до книжкового магазину та перегорнути пару книжок для цієї мови та перегляньте приклади коду, шукаючи аналоги тому, що вам знайоме з вашої мови (мови), на яку вибираєте, ознайомтеся з одним або кількома проектами з відкритим кодом, які використовують цю мову тощо.

Якщо у вас є час, і якщо немає бар'єру витрат, ви можете навіть зайти так далеко, щоб створити середовище розробки для цієї мови і запустити додаток Hello World, зробити ката-код або іншим способом написати просту маленьку програму у цьому. Ви розробите рудиментарну систему відліку досить швидко, і це не тільки допоможе вам переконатися в конкретних цілях перегляду коду, про який йде мова, можливо, вас змусить мова та розгалужити трохи.

Незалежно від мови:

• Чи є чітке розмежування проблем, належне використання класів (для мов OO) або будь-які ознаки навмисних спроб розбити код на багаторазові, модульні «шматки»?
• Аналогічно, будь-які докази тестування - одиничне тестування чи іншим чином?
• Якщо це виробничий код, чи він містить рядки налагодження, які можуть запропонувати невеликий поділ між розробкою та розгортанням?
• Чи дотримується код будь-якої конвенції іменування (вам подобається ця конвенція чи ні, вона не має значення!)?
• Якщо у вас є файл, а не роздруківка, чи кожна функція / клас у файлі стосується (так, якщо це файл під назвою data_access_layer , докази функцій, які обробляють зображення, ймовірно, будуть поза місцем).
• Будь-які вказівки на відсутність довіри до вводу користувачів також є хорошими, особливо для веб-мов, таких як PHP. Тож такі структури, як input = escape (input), принаймні показують, що вони знають про проблему.
• Коментарі або коди, що самоописуються, завжди хороші. Існує кілька шкіл думки щодо кількості коментування, яка повинна бути присутнім, але повна відсутність коментарів
• Ціною цинічності я також хотів би гугл частину коду перед інтерв'ю. На жаль, це може бути сумно копіювальним і вставним завданням.

Не кажучи про те, що будь-який код, у якого немає всього цього, автоматично поганий, але я вважаю, що це показники того, хто задумався і розглядав свою практику.

Однак для всіх цих показників слід запитати, що таке обґрунтування коду. Можливо, для їх вибору може бути добра причина, яка залежить від мови ... і після цього Google є вашим другом, коли вони та інші кандидати відійдуть, оскільки ви можете перевірити, чи правдоподібно звучить те, що вони сказали ...!

Удачі, адже найм хороших людей - одна з найважливіших ролей у вашій організації;)

Ви повинні попросити когось, хто знає цю мову, щоб прийти на співбесіду або ознайомитись із зразком. Така людина набагато швидше знайде погані місця, якщо такі є.

Чи буде кандидат працювати в команді? Нехай члени команди зустрічаються з ним і задають питання про його вміння.

Запитайте їх про обмеження, на які вони стикалися під час використання мови. Попросіть їх показати простий запит SQL. Будь-який Php-розробник, котрий варто скачати, повинен мати можливість вивести базовий запит на вибір / оновлення / видалення без особливих зусиль.

дуг