Як Ви визначаєте якість коду потенційного роботодавця, перш ніж зайняти посаду? [зачинено]

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

ОНОВЛЕННЯ:

Контрольний список: Запитайте;

• Що вони думають про кодову базу. А коли ви це зробите, приділіть пильну увагу міміці обличчя та часу, який потрібен їм для реагування. [Анон]
• Який рівень CMM компанії [DPD] (і якщо ви чуєте рівень 5, бігайте в інший бік [Doug T])
• Який життєвий цикл вони використовують [DPD] (І якщо ви чуєте "Agile", тоді ви починаєте задавати деякі проникливі питання, щоб спробувати зрозуміти, чи під "Agile" вони означають "Agile або" ковбойське кодування "[Carson63000])
• Які інструменти вони використовують для оцінки якості коду? [DPD]
• Які інструменти вони використовують для розробки? [DPD] (Шукайте інструменти рефакторингу та сервери безперервного збирання)
• Яку вихідний код (систему контролю над версіями) вони використовують, і корисне подальше запитання - це запитати, чому вони її використовують. [Захарій К].
• Які їхні процедури тестування? [Карл Білефельдт] (Особливо шукайте команди, які використовують глузуючі рамки та роблять акцент на ретельному автоматизованому тестуванні блоку через встановлені рамки, такі як NUnit / JUnit; не відкладайте команди, які не використовують тестові розробники TDD, але будьте будьте обережні, якщо вони не вважають тестування невід'ємною частиною та основою розробки надійного програмного забезпечення. Шукайте команди з спеціалізованими тестерами.)
• Які види завдань надаються новим розробникам? Досвідченим розробникам? [Карл Білефельдт]
• Скільки людей працюють над проектом? [Карл Білефельдт]
• Чи дозволено рефакторинг? Підбадьорений? [Карл Білефельдт]
• Які процеси, пов'язані з якістю чи архітектурою, розглядаються чи були внесені нещодавно? [Карл Білефельдт]
• Скільки автономії мають особи щодо своїх модулів? [Карл Білефельдт]
• Чи будете ви розробляти новіші проекти (розробка зеленого поля) або застарілі проекти (розробка коричневого поля)? (Розвиток Грінфілда, як правило, веселіше і має менше проблем, оскільки ти не прибираєшся до чужих помилок).
• Чи високий показник плинності працівників в організації чи колективі? (Це часто вказує на меншу якість коду) [M.Sameer]
• Деякі власні проблеми програмування; але уникай здаватися ривком. [Іскровий]
• Як розробники співпрацюють і як ділиться знаннями між командою? (Це має відповідати вашій особистості; я б сказав, що суміш сольної та парної роботи, мабуть, найкраща, співвідношення відповідає вашим соціальним потребам)
• Наскільки близька їх база даних до 3-ї нормальної форми (3NF), і якщо вона відхиляється, де і чому? (Якщо вони кажуть "3NF ???", піти. Якщо ні, і можуть бути вагомі причини цього, то дізнайтеся, що вони є).

ПРИМІТКА: Я прийняв відповідь Анона, тому що приблизно через тиждень громада вважає, що це найкраще - я думаю, це говорить про те, що це просто щось, для чого потрібно якось розвинути шосте почуття. Але, я думаю, кожен мав щось сказати.

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

Потім застосуйте свої знання про невербальні жести вашої культури, щоб інтерпретувати те, що вони насправді говорять. Для північноамериканської компанії слід бути точним:

• Невелика знизана плечима та швидка відповідь "це може бути краще": це, мабуть, досить добре.
• Довга пауза, затамування подиху, можливо, невеликий сміх: це не приємно, і люди, з якими ви берете інтерв'ю, не відчуваєте себе комфортно, що вам це говорять.
• Зірвані очі, швидка реакція "це смокче": це може бути добре, може бути погано, але трапляються політичні ігри. Якщо ви не готові грати в цю гру чи не бути тихим ніким, не тримайтеся подалі.
• Підняті або стиснуті брови: вони не розуміють питання, а кодова база майже напевно грізна.

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

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

Ось що ви можете попросити дізнатися.

• Який рівень ШМ компанії (в ідеалі 5)
• Який процес дотримується у вашому потенційному проекті (BTW, просити це добре, оскільки він показує, що ви зацікавлені в "цій" роботі, а не будь-якій роботі)
• Який життєвий цикл вони використовують (не будьте судженнями, якщо ви не чуєте "Agile". Вони можуть мати поважну причину для використання старих шкільних моделей)
• Запитайте, чи вони використовують якісь інструменти та показники, щоб перевірити якість коду. І якщо так, то який (якщо вони використовують хоча б один інструмент для метрики, а інший для якості - це хороший знак.)
• Також зверніть увагу, які інструменти вони використовують. Якщо це дорогий інструмент, такий як Resharper, а не якийсь безкоштовний інструмент, то вони ставляться до якості серйозно.

1. Запитайте їх, чи вони використовують джерело управління.
   • Немає джерела контролю? -> код, швидше за все, гадкий
2. Запитайте їх, як часто роблять огляди коду.
   • Немає огляду коду? -> код може бути підозрілим (але це не обов'язково, особливо якщо це невелика команда, що складається з гідних розробників.)
3. Запитайте їх, як вони тестують та розгортають перед тим, як перейти до виробництва?
   • Немає тестового середовища? Пряме розгортання у виробництві? -> код, швидше за все, гадкий.
4. Запитайте у них, чи роблять вони безперервну інтеграцію (наприклад, запускає збірки з Хадсоном)
   • Немає безперервної інтеграції? -> код може бути підозрілим, але це не обов'язково.
5. (Пов’язано з №3), запитайте їх, чи тестова середовище не відрізняється від вашого середовища розробки?
   • Тест розроблений? -> це не гарний знак, якщо тільки вони справді не мають грошових коштів, але наскільки дорогим буде додатковий ящик?
6. Запитайте їх, чи вони переглядають список дій перед тим, як розгорнути у виробництво.
   • Немає огляду дій перед розгортанням виробництва? -> Погане жужу.
7. Запитайте їх, скільки кроків потрібно для того, щоб зробити збірку.
   • Більше 3? -> типово поганий жужу.
8. Чи приймають вони (або здогадуються) кодові показники, такі як цикломатична складність або LCOM (міра згуртованості класу).
   • Так? -> ймовірно (але не точно) хороший знак щодо якості їх коду.
   • Ні, але вони розуміють поняття (принаймні, цикломатична складність)? -> важко сказати
   • Вони думають, що цикломатична складність - це екзотична страва чи афродизіак від Тімбукту (іншими словами, вони не знають, що це таке)? -> можливий поганий дзюджу.
   • Вони думають, що це нерелевантне лайно (чи якась інша поведінка подібного роду)? -> тікати.
9. Запитайте їх, як вони відстежують помилок.
   • Вони відстежують кількість помилок на певних показниках (. .Ie за проект, кількість змінених модулів або кількість запитів на вимогу / зміну, щось!)? -> хороший знак про їх код (та їх програмний процес).
   • Вони роблять вищезгадане та намагаються передбачити кількість можливих помилок, з якими вони можуть зіткнутися у майбутньому (або поточному) проекті на основі очікуваного показника (# запитів на зміни, розмір проекту тощо)? -> дуже хороший знак.
   • Вони відслідковують помилки лише для вирішення помилок? -> важко сказати
   • Немає послідовного відстеження? -> тікати.

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

З урахуванням сказаного, коли ви задаєте ці питання, будьте обережні. Вивчіть їх та виберіть декілька під час співбесіди.

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

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

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

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

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

Це те, що потрібно враховувати, коли / якщо ви вирішили попросити інтерв'ю про якість коду та програмних процесів.

Замість фактичної якості коду я б скоріше шукав компанію, де важливість якості коду добре зрозуміла.

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

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

Я знаю, де я хотів би працювати.

Є 99,9% шансів, що ви не зможете побачити код перед початком. (Якщо, звичайно, вони не виставили безкоштовний програмний продукт)

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

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

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

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

Тому питання, які я хотів би поставити для оцінки якості коду, є:

• Які ваші процедури тестування?
• Які види завдань надаються новим розробникам? Досвідченим розробникам?
• Скільки людей працюють над проектом?
• Чи дозволено рефакторинг? Підбадьорений?
• Які процеси, пов'язані з якістю чи архітектурою, розглядаються чи були внесені нещодавно?
• Скільки автономії мають особи щодо своїх модулів?

Як сказали @DPD і @Zachary, процес і SDLC є дуже важливими факторами, але я хочу додати ще деякі фактори, які, згідно з моїм досвідом, мають істотний вплив на якість коду:

• Запитайте, чи збираєтесь ви працювати над розробкою порівняно новішого проекту або підтримувати застаріле додаток. Спадкові програми, як правило, менш чисті, ніж новіші проекти.
• Спробуйте дізнатися, чи високий показник обороту працівника в організації чи колективі. Це, швидше за все, знизить і якість коду.

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

Моє ставлення таке: код - код, якщо це погано, ну це завдання зробити це краще. Якщо це добре, ну це ще складніше завдання зробити це краще!

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

Я трохи жартома кажу, інтерв'ю зі мною .

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

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

Чудова річ, що у вас може виникнути помірно складна проблема.

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

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

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

Звичайно, стандартна відповідь "це все є таємницею компанії" - загальний кінь-пукей.
Мій доказ: у мого попереднього роботодавця неконфіденційна частина військового продукту була зразком коду для запитання про співбесіду. [На щастя некласифікованого]

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

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

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

Є ряд речей, які мають тенденцію до підвищення якості коду (очевидно, гарантій немає).

• Статичний аналіз (у .NET це такі речі, як fxcop / stylecop)
• Підмножина (або повний набір) тестового набору - блок / інтеграція / регресія / керівництво тощо.
• Будді побудова (інший розробник команди розробляє зміни, щоб побачити, чи є якісь проблеми, пов'язані з машиною та користувачем - іноді також виконується швидкий розум)
• Перегляд коду

Вони можуть допомогти покращити не тільки міцність коду, але і якість коду.

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

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

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

На жаль, не можна. Жодна компанія не дозволить вам побачити їх код (але вони попросять побачити ВАШ код ...), і є шанси, якщо ви задасте їм питання про навколишнє середовище, на яке ви будете прямо брешені ("Контроль версій? Впевнений .." ми використовуємо .. е-е .. роздумуючи про суб-щось ")" або ввели в оману щодо якості ("ми використовуємо найновіший і найкращий .NET 4" лише для того, щоб дізнатись, що під час використання .NET 4 вони " переписувати це як. NET 1.1).

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