Тест Джоэла как инструмент собеседуемого

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

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

    Допустим, эта часть Вам понравилась и Вы задумались о том, чтобы перейти в этот проект. Потенциально Вам с этими людьми работать следующие несколько лет (ну минимум — месяцев). Поэтому имеет смысл пораспрашивать о проекте поподробнее. А заодно и будущих сокомандников прощупать — что они за перцы? ;)

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

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

    0. Сколько баллов набирает проект по тесту Джоэла?

    Если собеседники утверждают, что 6 или меньше — имхо можно сразу прощаться. Если 7 или больше — то можно посидеть подольше и повыяснять подробности. Особенно про те пункты, с которыми всё не очень хорошо. Если никто из собеседников не знает, что такое тест Джоэла и кто такой Джоэл — имеет смысл вежливо попрощаться и уйти ;)

    1. Пользуетесь ли вы системой контроля версий?

    Сейчас VCS — это правило, поэтому ответа «нет» Вы, скорее всего, не услышите. Поэтому следует спросить, какой системой контроля версий пользуются Ваши визави? Если выяснится, что это какая-нибудь старая и медленная система — вероятно, процессы в проекте (или во всей компании) идут медленно или народ не понимает преимуществ современных систем по сравнению со старыми. Имеет смысл спросить, есть ли в ближайших планах Git или Mercurial, и если есть — поинтересоваться, что мешало перейти на него раньше, какие бенефиты планируют получить при переходе.
    Ещё имеет смысл спрашивать, как построена работа с репозиториями — в каких ветках происходит разработка, в какие моменты и по каким правилам делаются мёрджи, насколько стабилен trunk, есть ли какие-то проверки при коммитах (что проект компилируется, что тесты проходят, что codestyle правильный) и т.п.

    И отличное дополнение из каментов — проверяется ли код перед интеграцией в хранилище людьми? Иными словами, есть ли на проекте Code Review?

    2. Можете ли вы собрать продукт за один шаг?

    Могут ли Ваши визави выполнить сборку/деплой/чоувастам своего продукта (или чо у вас там) за один шаг? За два шага? Иными словами, автоматизирована ли сборка. Если нет — имеет смысл спросить, почему она не автоматизирована. Что мешает её автоматизировать и тем самым сэкономить людские ресурсы (и нервы)? На этом этапе может выясниться много интересного про проект.

    3. Выполняете ли вы ежедневные билды?

    Как известно, стабильные найтли билды — признак некоторого минимального качества проекта и способ быстро находить критические ошибки. Выполняют ли Ваши визави ежедневную сборку проекта? Есть ли на проекте сервер Сontinuous Integration? Какой? Как он помогает инженерам? Какие выделены ресурсы на CI?

    4. Используете ли вы базу данных ошибок?

    Опять-таки, сейчас багтрекерами пользуются все. Поэтому интересно вот что: какой багтреккер используется? Какие процессы построены вокруг него? Кто, как и кому перекидывает тикеты? Это удобно? Что вас не нравится в текущем багтрекере или в процессах вокруг него? Какая деятельность регистрируется в трекере (баги, фичи, бэкпорты, регулярные таски), а какая — нет.

    5. Исправляете ли вы ошибки перед написанием нового кода?

    Исправляют ли Ваши визави имеющиеся ошибки прежде, чем писать новый код? Не все? Почему? Какие исправляют, а какие нет? Кто решает, исправлять ли данную ошибку или забить? Если в проекте много открытых багов (пусть даже только P4 и P5) — это верный признак не очень высокого качества продукта и недостатка ресурсов, разработчиков. Это может грозить авралами, оверхедами и потрёпанными нервами.

    Ну или просто всем всё пох на проекте и люди элементарно забивают. Вы хотите работать в таком проекте?

    6. Есть ли у вас актуальный план работ?

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

    7. Есть ли у вас спецификация?

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

    8. Предоставлены ли вашим программистам спокойные условия для работы?

    Созданы ли спокойные условия для работы инженеров? Сколько человек ещё человек сидит в комнате, где будете сидеть Вы? Разговаривают ли люди у себя рабочем месте по мобильникам? Едят ли прямо перед компом? Есть ли какие-то правила насчёт того, как должно выглядеть рабочее место? Обсуждают ли что-нибудь прямо в комнате, отвлекая других?

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

    9. Используете ли вы для работы лучшие из имеющихся инструментов?

    Дают ли инженерам для работы современные компы или заставляют пользоваться устарелым шлаком? Будет ли у Вас свобода в выборе ОС, IDE, текстового процессора, антивируса и т.д.? Всё ли ПО в конторе (проекте) — лицензионное? Винда? Ворд? Если Вам для работы понадобится софтина за 100 долларов — Вам купят на неё лицензию? А за $500? А за $1000?

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

    10. Есть ли у вас тестеры?

    Если нет — то надо бежать бегом, если это не Гугл. Сколько тестировщиков в проекте? Каково количественное отношение тестировщиков и разработчиков? Чем занимаются тестировщики — ручным тестированием или автоматическим? Пишут ли разработчики какие-нибудь тесты (юнит, регрессия). Тестировщики — члены команды или принадлежат соседнему подразделению? Второй случай означает невидимый барьер внутри команды, поэтому имеет смысл спросить, как в этом случае выстроено взаимодействие между тестировщиками и программистами.

    11. Пишут ли кандидаты на работу код во время собеседования?

    Думаю, ответ на этот вопрос вы и так узнаете)) Но тема — важная. Представьте, что Вас не попросили написать код на интервью. Значит, скорее всего, Ваших будущих коллег — тоже не просили. Значит, есть ненулевая вероятность, что они пишут код не очень хорошо. А может, они знают это и боятся облажаться перед Вами? В общем, если не просят писать код — имеет смысл насторожиться.

    12. Проводите ли вы коридорное тестирование удобства использования программ?

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

    Как-то так.

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

    А что бы спросили Вы?
    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

    Comments 80

      +2
      Думаю, что вы очень предвзято относитесь к некоторым пунктам в этом тесте.

      Не вижу, на пример, связи между использованием лучших инструментов и тем, что вам вздумается купить за счет фирмы софтину за $1000 и лицензионный виндовс с офисом. Зачем вообще программисту офис на компе?
      А для некоторых задач вообще будет лучшим использование линукс.
      Все же, работая в команде, вы должны придерживаться правил, которые приняты в команде, а не пороть горячку.

      Еще бы в дополнение ко всему перечисленному хотелось бы добавить, что не плохо взглянуть на ТЗ, которое выдается программистам для работы. Думаю, что грамотность ТЗ — это один из важнейших критерием проявления уважения (или не уважения) к программистам.
        +12
        > Не вижу, на пример, связи между использованием лучших инструментов и тем, что вам вздумается купить за счет фирмы софтину за $1000

        Например, я пишу на Java и считаю (небезосновательно) IntelliJ IDEA лучшей IDE для разработки на Java. Штука в том, что лицензия на неё стоит в районе 500$. Отсюда вопрос — есть ли в конторе лицензии, и если нет — купят ли мне её?

        > Зачем вообще программисту офис на компе?

        Документы писать и читать. Презентации делать. Инженерная работа не ограничивается написанием программного кода.

        > А для некоторых задач вообще будет лучшим использование линукс.

        Безусловно. Но в повседневной работе я юзаю и винду и юникс (в основном, солярку).

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

        Эти правила неплохо бы выяснить для начала! Пост — о том, как это можно сделать.

        > грамотность ТЗ — это один из важнейших критерием проявления уважения (или не уважения) к программистам.

        Оно не для всех моделей и проектов применимо. Но если есть — я бы взглянул, да. Тот же Джоэл рекомендует не ТЗ, а User Guide в качестве основной спецификации.
          –1
          Например, я пишу на Java и считаю (небезосновательно) IntelliJ IDEA лучшей IDE для разработки на Java. Штука в том, что лицензия на неё стоит в районе 500$. Отсюда вопрос — есть ли в конторе лицензии, и если нет — купят ли мне её?


          Расскажите, пожалуйста, что есть в Ultimate Edition для разработки на Java и при этом в Community Edition нельзя обойтись бесплатными плагинами.
          Чистое любопытство. Этот вопрос возник при обсуждении различных IDE среди .NET-программистов и я, как единственный пользовавшийся IDEA (для scala), не смог на него ответить.
            +2
            Поддержка Web ну и JavaEE вообще :)

            нормальная работа с JSON и XML

            саппорт, багфиксинг — по моему ощущению, JetBrains охотнее фиксит запросы от платных кастомеров.
              +1
              >различных IDE среди .NET-программистов
              А уже сделали что-то лучше VS? Чистое любопытство.
                0
                Я указал контекст обсуждения чтобы уточнить, что велось оно среди людей слабо разбирающихся в вопросе и ни коим образом не подразумевает призыв «зачем платить когда есть бесплатное!».
            –1
            Например вы пишете плагин для Word на Visual C++, а вам отказываются покупать Visual Assist. Купите за свои деньги?

              +5
              или Resharper за 300 баксов.
            +8
            Есть ли Code Review?
              0
              Безусловно! Добавлю-ка я этот пункт в раздел про контроль версий!
                0
                Думаю, описание пункта 1 такой вопрос подразумевает:
                есть ли какие-то проверки при коммитах (что проект компилируется, что тесты проходят, что codestyle правильный) и т.п.
                  0
                  Я изначально забыл про Code Review, но уже, конечно, поправил :)
                +1
                Больше спасибо за статью!
                Завтра как раз иду в побеседовать в компанию и попробую пройтись по этим вопросам. Напишу потом насколько успешно вышло и подготовились ли они, так как хабр там люди скорее всего читают.
                  +2
                  Более специфические, но важные для меня вопросы:
                  — используется ли Dependency Injection повсеместно
                  — утверждены ли стандарты форматирования кода
                  — является ли стандартом Resharper (или аналогичные инструменты, упрощающие жизнь)

                  Простите, случайно ответил не туда.
                    +2
                    С R# всегда так смешно получается в большинстве компаний куда приходил: многие используют только Ctrl+N и автодополнение более мощное, чем родное предоставляемое IntelliSense.
                      +1
                      надо признать, что и Студия не стоит на месте и сделала несколько шагов вперёд по сравнению с тем обморочным состоянием, в котором она была без решарпера году эдак в 2005ом.
                        +1
                        Да что там говорить, многие программисты не знают элементарных шорткатов не только в студии, но и в винде. Типа там Win-E, Win-Break, Win-R.

                        Я приложил некоторые усилия по внедрению R# в нашей команде, сделал презентацию, показал как всё работает, вбил coding style в настройки и расшарил их, но всё равно люди умудряются игнорировать даже очевидные ворнинги («Possible null reference exception» — вылез баг с ним, открываем код вместе — решарпер подчёркивает. Спрашивается — как такое вышло?).

                        Некоторые люди просто почему-то не хотят изучить свой инструмент и использовать его на полную.
                          0
                          К сожалению, не все люди, которые работают на должности разработчиков, любят эту профессию и стараются вникать в нее максимально.
                        –5
                        боюсь ваше тестирование мало кто пройдёт :) Лично я узнал про DI месяц назад. Сама идея вроде популярна около года (ну ладно, немного больше). А большинство проектов живут уже больше года. Так что вам — в стартап :)
                          +1
                          Сама идея вроде популярна около года (ну ладно, немного больше)

                          Что?
                          В PHP активно DIC используют больше 2-х лет, первые попытки аж в 2007-ых.
                          Вообще DIC еще в 90-ых обсуждали.
                            –5
                            я тогда джуниором был и не слышал об этом ничего
                            0
                            Принципы SOLID (D это и есть DI) описаны еще в начале 2000. Собственно IoC описан Фаулером в 1988. В 2008 Microsoft выпускает Unity и уже тогда они были не первыми.
                              +1
                              Автор книги Dependency Injection in .NET хорошо ответил на вопрос "В чем минусы DI?":

                              It can be dangerous for your career because it may increase your overall knowledge of good API design. Once you learn how proper loosely coupled code can look like, it may turn out that you will have to decline lots of job offers because you would otherwise have to work with tightly coupled legacy apps. Happens to me a lot :)

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

                              Я с этим согласен! Потому на собеседованиях буду уточнять. :)
                          +1
                          Напишу потом насколько успешно вышло

                          Будет очень любопытно узнать, что у вас получилось.
                            0
                            Не сошлись на начальном этапе сразу, так что спрашивать было бесполезно
                              +1
                              Ну вот, опять неизвестность… :)

                              Пожелаю вам удачи на новых собеседованиях.
                          +5
                          По мне так если интересный проект и хороший коллектив — то закрываешь глаза почти на все что угодно.
                            0
                            А как быстро выяснить — интересный ли проект и хороший ли коллектив? Мы ведь заранее, чаще всего, этого не знаем.

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

                            Вдруг проект кажется хорошим, а на самом деле там шлак в обёртке из-под конфеты. Или наоборот, проект поначалу кажется мутным, но по мере раскрытия деталей всё больше и больше хочется в нём работать :)
                            +2
                            13. Есть ли у вас печеньки? :)
                            Если серьёзно, имхо больше от адекватности людей зависит. Так по вопросам особо не угадаешь, понравится ли на предлагаемом месте работы, хотя косвенно судить тоже всегда полезно, особенно если человек выбирает из нескольких предложений.
                              0
                              Печеньки — это вопрос пары тысяч рублей в месяц. Просто русских в силу их ментальности ломает покупать печеньки самим. Хотя как бонус — приятно, не спорю.
                                0
                                Приятно, когда о вас заботятся :)
                                Это за ними ходить надо, если кончатся…
                              +2
                              Спасибо за материал, про тест Джоэла не знал. Интересно, что в какой-то момент при поиске работы и сам составил подобный список, так что сейчас добавил к нему ссылку на эту статью.

                              Из здешних пунктов у меня были те, с которым на тот момент пришлось столкнуться — насколько интересен проект и про уровень комфорта на рабочем месте. А в моём списке — пара специфических вопросов:

                              * стабильность работы — не свернётся ли проект через полгода (вопрос, конечно, актуален не для каждого работодателя);

                              * отсутствие требований к жёсткой посещаемости, ибо была компания, требующая быть в 7 утра как штык;

                              * возможность подключения и работы из дома.
                                +1
                                > ибо была компания, требующая быть в 7 утра как штык;
                                Девелоперская компания и 7 утра?!
                                  +1
                                  Нет, компания околофинансовая (алгоритмический трейдинг, если не ошибаюсь). И, как рассказал рекрутер, для них очень сложно найти людей. Кто ж в такой фирме захочет работать :) (работать, кстати, нужно было до 5 вечера, т.е. 10 часов в день)
                                +2
                                Интересный вопрос — как осуществляется управление проектом. Какие методики, техники, кто начальник, кто руководитель, принимают ли они участие в разработке или они лишь «на бумаге» вами руководят?
                                В моем случае руководителя нет. Он у меня условный. Т.е. следит за отработанным временем, напоминает про отчеты и т.п. В работе не помогает даже если просишь. Рееедко есть исключения.

                                От кого получать задачи? От руководителя или заказчика? Как построен принцип распределения задач? Agile, либо каждый раз приоритет может измениться? Есть ли разграничения задач по сотрудникам?

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

                                На деле:
                                дурю голову тим лиду на стороне заказчика «дай таск», получаю иногда ответ «на сегодня все, можешь идти домой», но идти не могу т.к. оплата почасовая.
                                git — базовое использование. Теги, 1 бранч master. Полное нежелание что-то менять на нашей стороне. Более полугода ушло на то, чтобы хотя бы немного приблизиться к git flow модели.
                                Тестирование есть. 1 тестировщик на другой фирме. На 80% бесполезный. Тестирование ручное. Документашку тестер читать не может. UML не знает. Увольнять его начальники не хотят. Видимо, дешево обходится. + feedback от пользователей.
                                Работу сложно назвать командной. Даже когда она таковая, в команде подобрались люди, которые не любят работать командно.
                                Рабочее место просто жесть. За год несколько переездов между комнатами, разными столами и освещенностью. В итоге сижу сгорбившись т.к. стол низкий. Регулярно пытаюсь на это обратить внимание руководства, но оно регулярно делает вид будто других проблем хватает. Скоро буду совсем злой. Кстати, может посоветуете, как конструктивно по этому поводу говорить?
                                Комп замечательный.
                                Ось лицензионная, софт — нет.

                                Ночных сборок нет, code review нет, спеки нет.

                                Почитал статью — хоть ты увольняйся :)
                                Но проект клевый :)
                                  0
                                  Ага, у меня тоже не все идеально, но очень нравятся задачи которые сейчас решаю и проект.
                                  Хотя мне вмешает ввести тестирование, продвинутое использование СКВ, интеграцию, баг-трекер, только отсутствие достаточного опыта, а скорее всего просто лень и не хочется заниматься такими вещами, потому что пока что итак все довольно эффективно :)
                                    0
                                    любое исключение лишь подчёркивает правило!
                                    0
                                    Вы только что ознакомились с сокращенной версией. Вот полная.
                                      0
                                      Это не сокращённая версия. В посте, на который Вы дали ссылку, я только поверхностно коснулся теста Джоэла, сфокусировавшись больше на кастомных вопросах.
                                    +1
                                    Интересный подход, что-то чувствуется интуитивно, когда спрашиваешь о будущей работе, но многое не знал, спасибо.

                                    Я бы еще добавил адекватность вашего визави. Как правило в качестве тех. спеца выступает непосредственный руководитель или будущий коллега и здесь многое становится понятно: с кем то сходу, налаживается отличный контакт, с кем то не идет. Много зависит от внешнего вида людей и от первых фраз визави, хоть IT и фрики, но все же в спортивном костюме на собеседование это не совсем к месту, я считаю (такое кстати было :). Еще интересный факт, как начинают общение на «вы», на «ты», спрашивают ли можно на «ты». Как правило, тактично начинают с «вы», потом по обоюдному согласию переходим на «ты», все же общаемся в деловой среде и фактические общение с незнакомым человек начинается, но бывали забавные случаи старта на «ты», типа друзья тысячу лет и все такое, но если честно отбивает желание дальше разговаривать такой подход.
                                      +2
                                      Я бы добавил вопрос под номером 0: «Сколько баллов вы набираете по тесту Джоэла?».
                                      Зачастую это позволит сэкономить время.

                                        0
                                        согласен! сейчас добавлю в пост!
                                          +5
                                          Гарантирую что большинство ответят «А что это?», хотя по пунктам могут и проходить.
                                            0
                                            ну если визави знают, что это такое — для меня это уже сразу плюс балл :)
                                            0
                                            По названию могут и не вспомнить, это не однозначный показатель. Зато, если знают, то уж точно маньяки :)
                                            +1
                                            честно говоря, за 2 года работы и 3 проекта нормальных тестировщиков не видел. Ни разу. То ПМ просматривает задание, то никто, то наймут какую-то барышню, которая и комп-то плохо знает. На последней работе такой вариант: тестировщица парт-тайм в другом офисе, тестирование ручное.
                                            Работал с украинцами, датчанами, англичанами.
                                            СВН по мнению автора устарешая система контроля версий? Или просто надо, чтобы собеседующий доказал её пользу?
                                            Лучшие из имеющихся инструментов? Мне никогда не покупали офис, да и PHPStorm тоже.
                                            В общем, все условия вряд ли будут выполнены хоть в одном проекте.
                                              0
                                              Видел один проект, в котором все условия не выполнялись. До этого я думал что это невозможно.
                                                0
                                                > СВН по мнению автора устарешая система контроля версий? Или просто надо, чтобы собеседующий доказал её пользу?

                                                SVN — годная система, но не более того. Для небольших проектов — рулит, для больших — имеет много проблем: performance, svnmerge.py, херовый резолвинг конфликтов и пр. Пожалуй, из бесплатных — сложно тягаться с гитом и меркуриалом.
                                                0
                                                А если почти ничего этого нет, и меня берут именно для того, чтобы это все в компании внедрить?
                                                  0
                                                  это — с одной стороны прекрасно, а с другой — может быть нудным геморроем. Ведь если всего этого нет — значит на это есть причины: люди сопротивляются, менеджмент не понимает профита, процессы негибкие, люди забронзовели. Вероятно, как следствие — качество продукта низкое и пр.

                                                  У меня был случай, когда мы ставили с нуля процесс разработки в неайтишной компании — они захотели писать некий свой софт для своих железок. Было очень круто. Во многом — потому что никто не вмешивался, не ставил палки в колёса, а наоборот — помогали всем, чем можно.

                                                  В общем, если у Вас карт-бланш — то флаг Вам в руки. Но боюсь, что Вы столкнётесь с неким сопротивлением, и преодолевать его будет, скорее всего, непросто.

                                                  Главное — чтобы было интересно!
                                                    0
                                                    1. Если Вы никогда не настраивали процесс разработки в (именно) команде «с нуля», то лучше попрактиковаться. Иначе возникнет ситуация:
                                                    — Здесь написано, что надо работать так — давайте все вместе настроимся и начнем работать так!
                                                    — Угу…
                                                    — Почему мы до сих пор так не работаем?
                                                    — Угу… эээ… угу
                                                    — Вы будете так работать?
                                                    — Угу
                                                    — Loop until @#$%!

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

                                                    3. Если Вы еще и на роль PM идете + внедрять систему разработки, то ахтунг удваивается троекратно.

                                                    4. Если в процессе стабилизации разработки реально(!) заинтересован какой-либо высокий манагер компании, то может и получится.

                                                    Лично мое мнение — это мегагеморроидальная задача в существующих проектах/командах, на неё я бы подписался только за очень большие деньги, т.к. реально знаю что это (кто мне вернет нервы? :) ).
                                                    +3
                                                    1. Хм. Задумался на первом же (нулевом по нумерации) вопросе.
                                                    Честно скажу, первый раз слышу про этот тест. Что, по вашему мнению, это значит?
                                                    Не считаю, что это хоть какой-то показатель, т.к. по остальным указанным пунктам может быть всё в порядке.

                                                    2. Почему вы считаете, что git и mercurial абсолютно лучше, скажем, svn?
                                                    Уверен, что многие с вами не согласятся, но не потому, что являются последователями черепашки, а просто потому, что в некоторых аспектах svn намного удобнее и лучше справляется с определёнными обязанностями. Поэтому опять же, считаю, что слишком предвзято относитесь к СКВ.
                                                      0
                                                      1. расширяйте кругозор, читайте хорошие статьи на Хабре! Ну и блог Джоэла, естественно!

                                                      2. Я в посте нигде не пишу про SVN. Потому что слишком многие на нём сидят и сразу начнут обижаться, прямо как Вы :) Судя по всему Git быстрее, чем Subversion, лучше справляется с мёрджами (svnmerge.py для нормального слияния веток — это вообще жесть) и конфликтами, умеет работать с локальным репозиторием. Ну и до версии 1.7 было много бесячего мусора в репозитории, который мешал, например, grep'у.
                                                      Приведите, пожалуйста, аргументы — чем лучше SVN?
                                                        +2
                                                        Приведите, пожалуйста, аргументы — чем лучше SVN?
                                                        При работе с центральным репозиторием в команде, лично мне удобнее работать с SVN. Потому что нет этого двух-фазного комита — сначала в локальный репо, потом пуш в центральный.

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

                                                        Во-первых, сейчас нет тулов, которые наглядно показывают незапушенные чейнджи (как в случае с dirty working copy в SVN), то получается что есть большой шанс, большой человеческий фактор, что пуш будет забыт. Ну и вообще, это надо самому ходить и проверять — есть ли че запушить. (Если вы мне хотите рассказать, что «забывать» это не удел хороших программистов, то это не о «забывчивости», а об удобстве. Такие же проблемы решают пункты 2,3,4,10 Теста Джоэла — там тоже можно все руками делать)

                                                        Ну, а в-третьих, с мерджем у меня больших проблем не возникало. Я и cherry-picking делаю, и сливаю между ветками. Проблема возникает тогда, когда объем комитов большой. Но в моем случае мне это не нравится по причине, что слишком много человек владеют одним кодом и решают в нем разные задачи.
                                                          +1
                                                          > Во-первых, сейчас нет тулов, которые наглядно показывают незапушенные чейнджи (как в случае с dirty working copy в SVN), то получается что есть большой шанс, большой человеческий фактор, что пуш будет забыт.

                                                          Тулов море — во-первых, все IDE под Java, например, по дефолту это делают. IDE сама за вас всё проверяет и подсказывает, что есть незапушенные changeset'ы.

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

                                                          В третьих, часть процесса. Тестировщики или роботы или кто-то ещё у вас не проверяют результат? Пример: разработчик отмечает в JIRA, что фикс интегрирован, но забывает сделать пушю Тестировщик видит изменение в статусе бага и проверяет фикс. Пуша нет, поэтому от выставляет в JIRA «fix failed». Вот Вам и вариант детектора.

                                                          Можно автоматически делать — указывать при закрытии бага номер changeset'а. JIRA, интегрированная с репозиторием, проверяет, что такой changeset есть в репозитории. Если нет — сообщает разработчику и не даёт закрыть баг.

                                                          В общем, способов море.

                                                          Про мёрдж — отдельная песня. SVN-овский не блещет. А в меркуриале, например, можно любой внешний тул подключить, если дефолтный не устраивает. Например, для мёрджа html и xml нужно применять специальные тулы. SVN в этом месте часто лажает, проверено. Потому что он чисто текст мёрджит. И пофиг, какой.
                                                            +1
                                                            Тулов море — во-первых, все IDE под Java, например, по дефолту это делают. IDE сама за вас всё проверяет и подсказывает, что есть незапушенные changeset'ы.

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

                                                            Если я правильно пользуюсь, там ставится тэг. Его можно увидеть только во вкладке log. Ни в changes ни в коде (dirty файлы там помечаются отличным цветом) dirty local repo никак не маркируется.

                                                            Короче, там есть всякие хаки, типа экстеншенов, dropdown-кнопок, по которой нужно попасть чтобы выбрать commit&push, алиасы комманд, скрипты, тестеры… Все это заплатки. Тул должен браться и работать, а там предлагают «паровоз и доработать напильником» уютно, под себя.

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

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

                                                            Когда-то давно, все понимали почему не CVS, а SVN. Сейчас это смхивает на hype, и SVN по-большому счету никто не мешает сосуществовать с GITом в мире разработки. Правда GIT часто лепят не туда, тыкая, что вообще панацея для всего.

                                                            Опять же про мердж. Если объем комитов большой, тут что git, что svn — попаболь еще та. Проблему в этом случае я описывал в коменте выше.

                                                            Остальные косяки с мерджем возникают тогда, когда не настроены code-style. В IDEA не очень хороший форматтер и рулы для формата XML-like синтаксиса. А также народ забывает настраивать импорты, например, одинаково для всех участников. И т.п.

                                                            Мердж окошко SVNа в IDEA вполне справляется со своими задачами при отсуствии факторов выше.
                                                              0
                                                              Плюсую и соглашаюсь! Вы очень классно написали, правда.

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

                                                              Ну и кстати, поддержка Меркуриала в Идее мне нравится!
                                                                0
                                                                Современная поддержка git в idea вполне неплоха. В idea 10, 10.5, 11 и 12 EAP.

                                                                Хотя лично я отдаю предпочтение консоли при работе и с git, и с hg, и с svn. И стараюсь на работе (используем git) прививать привычку использовать git в консоли + qgit/gitg/gitk для самоконтроля.

                                                                Незакомиченные файлы, лишние игноры и прочие признаки халатного отношения к VCS встречаются независимо от конкретной VCS/DVCS.
                                                            0
                                                            Согласен с вами. DCVS не панацея — когда много коммитов и много человек работает над одной частью, то что гит что свн — всё равно мержить ручками придётся и конфликтов не избежать.
                                                              0
                                                              если куча людей работают над одной частью — имхо это признак организационных проблем в проекте.
                                                                0
                                                                Всегда ведь есть файл констант, файл проекта и т.п., которые затрагивают практически все.
                                                                  0
                                                                  делите на куски, стройте дерево
                                                            0
                                                            Вы ошибаетесь, что я обижаюсь (:
                                                            В работе пользуюсь git'ом, но, тем не менее, не игнорирую некоторые достоинства SVN.

                                                            Полагаю, стоит отметить, что услышав в ответ ту или иную СКВ, не помешает осведомиться, почему именно эту систему выбрали. Если аргументы будут в духе «так исторически сложилось», «другого не пробовали», то это скажет больше о компании, чем сама СКВ.
                                                              0
                                                              абсолютно согласен с Вами!
                                                            +3
                                                            Отвечу как представитель организации, в которой недавно перешли с svn на git, а конкретно — на Github
                                                            1. Гораздо удобнее стала работа с ветками. Так как все ветки физически хранятся на локальном компьютере, switch очень быстрый.
                                                            В svn для работы параллельно с несколькими ветками нужно разворачивать каждую в отдельной папке — это долго и неудобно.

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

                                                            3. В github встроена довольно удобный (хотя и не идеальный) инструмент, позволяющий ревьюить пул-реквесты. Благодаря этому мы довольно быстро внедрили ревью в наш процесс. Непросмотренный код теперь вообще не попадает в репозиторий — это радость.

                                                            4. Будущее за git — все пацаны уже переходят. Надо идти в ногу со временем. :)

                                                            Кстати, черепашка под git тоже есть.
                                                            +1
                                                            10. Есть ли у вас тестеры?

                                                            Если нет — то надо бежать бегом, если это не Гугл.
                                                            ____________
                                                            А что, в Гугле нет тестеров?
                                                              +3
                                                              Судя по тому, что в андройде пропустили декабрь — да :)
                                                                0
                                                                На хабре был пост про многоуровневый процесс тестирования в Google. Видимо, не панацея. Либо не во всех проектах применяют.
                                                                  0
                                                                  Не тестеры, а тестировщики. ;-) По поводу процесса тестирования в Google есть такая книга.
                                                                  0
                                                                  в некоторых проектах. Там вообще местами демократично довольно, насколько я знаю. Но это не важно. Важно то, что если Вы делаете офигенную вещь, и она получается очень качественной — то мне совершенно пофиг, есть ли у вас отдельные тестеры, или процесс проверки устроен как-то нетрадиционно для индустрии :)
                                                                  +1
                                                                  Если в проекте много открытых багов (пусть даже только P4 и P5) — это верный признак не очень высокого качества продукта и недостатка ресурсов, разработчиков. Это может грозить авралами, оверхедами и потрёпанными нервами.

                                                                  Ну или просто всем всё пох на проекте и люди элементарно забивают. Вы хотите работать в таком проекте?

                                                                  Вот заглянул сейчас в багзиллу mozilla.org. Только в одном компоненте Core/JavaScript Engine 3170 открытых багов (из них 3 блокера и несколько сотен критичных). Ужасный, абсолютно негодный проект, где всё просто рассыпается в руках, а разработчики не спят ночами?
                                                                    0
                                                                    Я написал «это может грозить XXX», а не «в таких проектах обязательно XXX»
                                                                    0
                                                                    Я кроме технических моментов (правда, не столько детально) еще задаю два вопроса:
                                                                    1) Что вам больше всего нравится в работе в этой компании?
                                                                    2) Что вам больше всего не нравится в работе в этой компании?

                                                                    Много интересного для размышлений можно почерпнуть из ответов. На втором вопросе, например, многие просто виснут — плохой знак.
                                                                      +1
                                                                      Белусловно! Только задавать эти вопросы нужно в проивоположном порядке — чтобы у собеседников остался положительный фон после разговора с Вами.
                                                                        0
                                                                        Стереотип :). Тут как раз порядок нужный: про хорошее все взахлеб, а потом бамс. Вот тут и видно, как дела в компании, как человек относится и т.д. Ну и, конечно, это не последний мой вопрос, после него еще задаю другие вопросы.
                                                                      +1
                                                                      Я спросил бы обязательно, как устроено тестирование в компании.
                                                                      В том смысле, пишутся ли автоматические тесты, и кто их пишет.

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

                                                                        Первым и основным вопросом руководителю проекта, я бы задал вопрос:
                                                                        «Какую методологию управления проектами Вы используете?»
                                                                        Отсутствие ответа на этот вопрос нам какбэ намекнет…

                                                                        Еще вопрос, на который желательно получить ответ от PM:
                                                                        «Существует ли в Вашем проекте архитектор?»
                                                                        Ответ в стиле «у нас каждый участник архитектор своего участка» подскажет нам, что
                                                                        а) проект не имеет «стержня»
                                                                        б) в ответе явная тавтология…

                                                                        Следующий вопрос подскажет нам, как быстро мы поймем, что ребята всей командой делают:
                                                                        «У вас есть техническая и пользовательская документация, кто пишет?» — Документация должна быть. Должна Быть.
                                                                        Если документация есть, то нужно попросить с ней ознакомится ;)

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

                                                                        Я, по своей натуре, очень щепетильно отношусь к юзабилити решений, посему задал бы вопрос:
                                                                        «Проводите ли Вы юзабилити-тесты Вашего продукта?».
                                                                        На утвердительный ответ — попросите показать Вам пару форм/дизайнов/ещечего одного и того-же проекта и найдите 5 отличий:)

                                                                        Что я хотел сказать коментом помимо примеров вопросов — не верьте ответам! При любой возможности — просите подтверждение слов, иначе, в первый рабочий день, велика вероятность столкнуться с «когнитивным диссонансом» :)
                                                                          0
                                                                          Я вот не соглашусь ни с одним из пунктов!

                                                                          Какую методологию управления проектами Вы используете?
                                                                          Scrum? До свидания и удачи!

                                                                          Существует ли в Вашем проекте архитектор?
                                                                          Да? До свидания и удачи!

                                                                          У вас есть техническая и пользовательская документация, кто пишет?» — Документация должна быть. Должна Быть
                                                                          Голословное, вредное и абсолютно ни на чём не основанное утверждение. Проектов бывает миллион. Документация нужна там, где будет кто-то, кто будет её читать. Кому из пользователей сайта Аэрофлота нужна документация к нему? Спецификация как документация — должна быть. Чтобы заказчик мог сверить желаемое с действительным. Но вот User Guide — нет!

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

                                                                          Соглашусь лишь с последним Ваши утверждением:
                                                                          не верьте ответам!
                                                                          Люди врут.

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

                                                                        Only users with full accounts can post comments. Log in, please.