Как вы определяете качество кода потенциального работодателя, прежде чем занять должность? [закрыто]

По моему опыту, прежде чем вы начнете работать в компании, у вас нет возможности взглянуть на кодовую базу (я спрашивал, и из соображений конфиденциальности все всегда говорили «нет», я думаю, что это справедливо), поэтому во время собеседования Как вы думаете, самые важные вопросы, которые нужно задать, чтобы выяснить, в каком состоянии находится код (в конце концов, если это собака, то вы окажетесь среди бедных несчастных, которым приходится каждый день выгуливать его)?

ОБНОВИТЬ:

Контрольный список: Спросите;

• Что они думают о кодовой базе. И когда вы это сделаете, обратите пристальное внимание на выражения лица и время, которое требуется им, чтобы ответить. [Анон]
• Каков уровень CMM компании [DPD] (и если вы слышите, как Уровень 5 работает в другом направлении [Doug T])
• Какой жизненный цикл они используют [DPD] (И если вы слышите «Agile», тогда вы начинаете задавать некоторые проницательные вопросы, чтобы попытаться выяснить, означают ли «Agile» «Agile» или «ковбойское кодирование» [Carson63000])
• Какие инструменты они используют для оценки качества кода? [DPD]
• Какие инструменты они используют для разработки? [DPD] (ищите инструменты рефакторинга и серверы непрерывной сборки)
• Какую систему исходного кода (контроля версий) они используют, и хорошее продолжение - спросить, почему они ее используют. [Захари К].
• Каковы их процедуры тестирования? [Карл Билефельдт] (Особенно обратите внимание на команды, которые используют фальшивые фреймворки и делают упор на тщательном автоматизированном модульном тестировании с помощью установленных фреймворков, таких как NUnit / JUnit; не откладывайтесь на команды, которые не используют TDD для разработки через тестирование, но Осторожно, если они не считают, что тестирование является неотъемлемой частью и краеугольным камнем надежной разработки программного обеспечения. Ищите команды с преданными тестерами.)
• Какие виды заданий даются новым разработчикам? Для опытных разработчиков? [Карл Билефельдт]
• Сколько людей работает над проектом? [Карл Билефельдт]
• Разрешен ли рефакторинг? Воодушевленный? [Карл Билефельдт]
• Какие изменения в процессе или архитектуре, связанные с качеством, рассматриваются или были сделаны недавно? [Карл Билефельдт]
• Сколько автономии имеют люди над своими модулями? [Карл Билефельдт]
• Будете ли вы разрабатывать новые проекты (разработка новых месторождений) или унаследованные проекты (разработка новых месторождений)? (Разработка с нуля, как правило, более увлекательна и имеет меньше проблем, поскольку вы не исправляете чужие ошибки).
• Высока ли текучесть кадров в организации или команде? (Это часто указывает на более низкое качество кода) [M.Sameer]
• Некоторые собственные проблемы программирования; но старайтесь не казаться придурком. [Спарки]
• Как сотрудничают разработчики и как знания распространяются среди команды? (Это должно соответствовать вашей индивидуальности; я бы сказал, что сочетание одиночной и парной работы, вероятно, лучше всего, с соотношением, соответствующим вашим социальным потребностям)
• Насколько близка их база данных к 3-й нормальной форме (3NF), и если она отклоняется, где и почему? (Если они говорят «3NF ???», уходите. Если нет, и для этого могут быть веские причины, то выясните, что они собой представляют).

ПРИМЕЧАНИЕ: я принял ответ Анона, потому что примерно через неделю сообщество считает его лучшим - думаю, это говорит о том, что для этого нужно как-то развить шестое чувство. Но я думаю, что у каждого было что-то ценное, чтобы сказать.

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

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

• Небольшое пожатие плечами и быстрый ответ «могло бы быть и лучше»: это, вероятно, довольно хорошо.
• Длинная пауза, вдох, возможно, небольшой смех: это не приятно, и люди, с которыми вы беседуете, не чувствуют себя комфортно, рассказывая вам это.
• Закатанные глаза, быстрый ответ «это отстой»: может быть хорошо, может быть плохо, но происходят политические игры. Если вы не готовы играть в эту игру или быть тихим, оставайтесь в стороне.
• Поднятые или сжатые брови: они не понимают вопроса, а кодовая база почти наверняка гнилостная.

Конечно, если у вас есть проблемы с межличностным общением, это может не сработать для вас.

Я удивлен, что ты даже спросил. Ни одна компания не покажет вам код, прежде чем вы присоединились. Даже к консультантам, вызванным для процесса, если они не подписали соглашение о конфиденциальности.

Вот что вы можете попросить выяснить.

• Каков уровень CMM компании (в идеале 5)
• Каков процесс, который используется в вашем предполагаемом проекте (кстати, спросить, это хорошо, потому что это показывает, что вы заинтересованы в «этой» работе, а не просто в любой работе)
• Какой жизненный цикл они используют (не осуждайте, если вы не слышите «Agile». У них может быть веская причина для использования моделей старой школы)
• Спросите, используют ли они какие-либо инструменты и метрики для проверки качества кода. И если да, то какой (если они используют хотя бы один инструмент для метрик, а другой для качества, это хороший знак).
• Также обратите внимание, какие инструменты они используют. Если это дорогостоящий инструмент, такой как Resharper, а не какой-либо бесплатный инструмент, то он серьезно относится к качеству.

1. Спросите их, если они используют систему контроля версий.
   • Нет управления источником? -> код скорее всего хреновый
2. Спросите их, как часто делают обзоры кода.
   • Нет проверки кода? -> код может быть подозрительным (но не обязательно, особенно если это небольшая команда, состоящая из достойных разработчиков.)
3. Спросите их, как они тестируют и разворачивают перед началом производства?
   • Нет тестовой среды? Прямое развертывание в производство? -> код, скорее всего, дерьмовый.
4. Спросите их, выполняют ли они непрерывную интеграцию (.ie. Запуск сборок с Hudson)
   • Нет непрерывной интеграции? -> Код может быть подозрительным, но не обязательно так.
5. (Относится к # 3), спросите их, является ли их тестовая среда отдельной от вашей среды разработки?
   • Тест это дев? -> не очень хороший знак, если только они действительно не нуждаются в деньгах, но насколько дорогой будет дополнительная коробка?
6. Спросите их, проверяют ли они список действий перед развертыванием в производство.
   • Нет обзора действий до развертывания производства? -> Плохо жужу.
7. Спросите их, сколько шагов нужно для того, чтобы сделать сборку.
   • Более 3? -> Как правило, плохо жужу.
8. Используют ли они (или предполагают) метрики кода, такие как цикломатическая сложность или LCOM (мера связности классов).
   • Да? -> возможно (но не обязательно) хороший знак в отношении качества их кода.
   • Нет, но они понимают понятия (хотя бы цикломатическая сложность)? -> Трудно сказать
   • Они думают, что цикломатическая сложность - это экзотическое блюдо или афродизиак из Тимбукту (другими словами, они не знают, что это такое)? -> Возможна плохая дзюю.
   • Они думают, что это неуместное дерьмо (или что-то подобное)? -> убежать.
9. Спросите их, как они отслеживают ошибки.
   • Они отслеживают количество ошибок по некоторым показателям (например, по каждому проекту, количеству измененных модулей или количеству требований / запросов на изменение, что-то!)? -> хороший знак об их коде (и их программном процессе).
   • Они делают вышеуказанное и пытаются предсказать количество возможных ошибок, с которыми они могут столкнуться в будущем (или продолжающемся) проекте, основываясь на ожидаемом показателе (количество запросов на изменение, размер проекта и т. Д.)? -> очень хороший знак.
   • Они отслеживают ошибки только для устранения ошибок? -> Трудно сказать
   • Нет последовательного отслеживания? -> убежать.

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

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

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

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

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

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

Когда это происходит, тогда вы должны спросить себя, нужна ли вам эта работа так сильно. Иногда вы делаете, и вы должны окунуться в кучу спагетти дерьмо. Иногда нет (имеется в виду, что вы можете себе этого не позволить)

Это то, что вы должны принять во внимание, когда / если вы решили спросить интервьюера о качестве их кода и процессов программного обеспечения.

Вместо реального качества кода я бы предпочел поискать компанию, в которой важность качества кода хорошо понятна.

Например, скажем, в компании А есть менеджеры, которые считают, что «планирование - это пустая трата времени» и «мы можем исправить проблемы проектирования позже (например, когда ад замерзнет. У нас будет время)». Даже если бы у этой компании сейчас была хорошая кодовая база, она долго не будет. И вы будете тем, кто будет (будет вынужден) сделать это хуже.

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

Я знаю, где я хотел бы работать.

С вероятностью 99,9% вы не сможете увидеть код перед началом работы. (Если, конечно, они не выпустили бесплатный программный продукт)

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

Место, где я работал с очень качественным кодом, практически не позволяло двум третям разработчиков касаться кода. Другие вместо этого написали сценарии автоматического тестирования черного ящика. Если вы доказали, что достойны изменить реальный код, требования были настолько чрезмерно завышены, что это была не более чем транскрипция в исходный код. Тестовые сценарии на самом деле было веселее писать.

Места, где я видел код самого низкого качества, были совершенно противоположными: только относительно неопытные или неученые программисты когда-либо касались кода, обычно потому, что это был инструмент, не имеющий прямого отношения к продукту компании или считающийся экспериментальным.

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

Поэтому вопросы, которые я хотел бы задать для оценки качества кода:

• Каковы ваши процедуры тестирования?
• Какие виды заданий даются новым разработчикам? Для опытных разработчиков?
• Сколько людей работает над проектом?
• Разрешен ли рефакторинг? Воодушевленный?
• Какие изменения в процессе или архитектуре, связанные с качеством, рассматриваются или были сделаны недавно?
• Сколько автономии имеют люди над своими модулями?

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

• Спросите, собираетесь ли вы работать над разработкой в ​​относительно новом проекте или поддерживать устаревшее приложение. Устаревшие приложения, как правило, менее чисты, чем новые проекты.
• Постарайтесь узнать, высока ли текучесть кадров в организации или команде. Это, скорее всего, также снизит качество кода.

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

Мое отношение таково: код есть код, если он плохой, ну, это задача сделать его лучше. Если это хорошо, ну, это еще сложнее сделать его лучше!

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

Слегка в шутку говорю, интервью со мной .

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

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

Самое замечательное в том, что у тебя могут быть измеримо трудные проблемы.

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

Актуальность вопроса ОП заключается в том, что каждый, кто придет на физическое собеседование, увидит какой-то код. (Не с конфиденциальным контентом компании)

Если вы не можете использовать эту технику, скажем, ненормативную лексику в кодовой базе, тогда тест работает, поскольку потенциальные сотрудники спросят «могу ли я увидеть код», и ответ будет «о, вы не можете полный ненормативной лексики ".

Конечно, стандартный ответ «все дело в секрете компании» - полный хоккей.
Мое доказательство: у моего предыдущего работодателя неконфиденциальная часть военной продукции была образцом кода для вопроса об интервью. [К счастью, не классифицировано]

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

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

Спросите, что требуется для кода, чтобы сделать его в производственной сборке. Если вы получите «эээ ... разработчик совершает это ...», то это почти наверняка мусор.

Есть ряд вещей, которые имеют тенденцию повышать качество кода (очевидно, нет никаких гарантий).

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

Это может помочь улучшить не только прочность кода, но и качество кода.

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

Если это магазин Java, спросите их, какую библиотеку ORM они используют. Если они свернули свои собственные, то это могло бы пойти в любую сторону - это могло бы отстой, или это могло бы быть хорошо. Если они не используют, бегите к двери прямо сейчас.

Это трудная задача, потому что существует так много разных плохих методов кодирования, что вы никогда не сможете предсказать их все.

Вы не можете, к сожалению. Ни одна компания не позволит вам увидеть их код (но они попросят увидеть ВАШ код ...), и есть вероятность, что вы зададите им вопросы об окружении, в котором вы либо будете полностью обмануты («Контроль версий? Конечно ... мы используем ... э-э ... думая Sub .. Sub-что-то ") или заблуждаемся по поводу качества (" Мы используем новейшую и самую лучшую версию .NET 4 "только для того, чтобы узнать, что при использовании .NET 4 они ' переписываешь как .NET 1.1).

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