> >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на > >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически, > >> настолько мало там багов, что написание тестов не окупается. > >> > > Ну это две параллельные задачи. Часто тесты нельзя написать. > > Если тесты нельзя написать, то код негодный. Другое дело, что на > написание тестов не всегда хватает ресурса. > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз делать? А работа при загрузке ОС?
> > Плюс, на ревью проверяется читабельность кода и его логическая > > корректность (и тесты, и код возможно написать некорректно). Плюс, в > > два раза больше работы. В общем, одно другое не заменяет. > > Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в > процессах, которые применяются там, где я работал, ревью отсутствует. > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но всё-таки, в трёх достаточно известных конторах, где я работал, ревью имеется, причём через WEB GUI. > Если более тысячи программистов отвечают за одно место в коде, код > работать не будет. В больших конторах за каждое место в коде отвечает > очень небольшое количество людей, а протоколы взаимодействия между кодом > разных отделов компактны. > > >> За коммитами джуниоров просто присматривают вручную. Недолго, человек > >> либо обучается, либо идет искать работу в другом месте. > >> > > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код > > сложный, хотелось бы видеть, что уйдёт в репозиторий. > > В одной из контор у нас были любители почитать код, уходящий в > репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты > желающим. По почте. Тем же способом присматривали за джуниорами. > Примерно так и есть, но почта заменяется ccollab (или, в общем случае, любым web интерфейсом), и код не проходит в репозиторий без одобрения. > Практика показывает, что читать код _до_ попадания в репозиторий - не > очень хорошая идея. Благо репозиторий позволяет, если что, откатить. > Но сборки уже будут собраны и отправлены на тестирование, так не лучше ли - не допустить? Какая практика? В чём нехорошесть данной идеи? > Не, мне рассказывали байку о техпроцессе в Боинге с кодом, который идет > в авионику. Там ревью есть, но начинается оно не с would-be коммита, а с > обоснования, почему надо менять именно это место в коде, и как его > менять. Только там питона, баша и луа быть не может - их интерпретаторы > не удовлетворяют требованиям к тому техпроцессу. > Согласен. > Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки > там такова, что оно окупается. > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним привязана задача, после чего проверяются (перед репозиторием). > >> >> В общем, даже модель pull request не использовали, не говоря уже о > code > >> >> review. А вот работу в паре как раз использовали. > >> >> > >> > А подробнее? Это из области "экстремального программирования"? > >> > >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй > >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем > >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность > >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот > >> такие грабли". > >> > >> Результаты различного качества, в зависимости в основном от дисциплины > >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще > >> вылетает аппаратура, чем вылезают не дающие работать баги. > >> > > Только читал об этом, не думал, что в РФ используется. > > Это парадигма, ей чихать на государственные границы. > Границы не при чём, имеет значение "менталитет", в общем и, в частности: культура разработки и стоимость такого подхода. > > В любом случае, если я такое (чисто теоретически) предложу менеджеру, > > он только у виска покрутит. Это же получается, что каждый программист > > работает, условно половину времени, а половину сидит "и что-то там > > смотрит". > А если тебе не результат а имитацию бурной деятельности для менеджера, > то да, подход ровно обратный. В конкретном случае мне нужно сделать для себя: имитировать там не для кого. Над своими проектами я не за деньги работаю. И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не будет сделано. > Берем софт для совместной работы, > выбираем его по критерию "наиболее красочная презентация", закупаем под > него сервер, месяц инсталлируем, три месяца настраиваем. Менеджер от > презентации в экстазе, и всё согласовывае. Если бизнес-процесс > позволяет, покупаем платный саппорт, чтобы жопу прикрыть. Потом > заставляем всех им пользоваться. Все дружно заняты все 8 часов, а то и > 12... > Как ни печально, наблюдаю подвижки в этом направлении. > И кстати, code review более чем подходит под определение "что-то там > смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время > code review? > А у нас на ревью время специально выделяется (похоже, что были менеджеры, которые не понимали, что это "за ревью такое", и в правила записали официально). На парное программирование же времени не выделяют. Код пишут не вместе, хотя иногда вместе раздирают. > P.S. жалоба листмастеру на оффтопик ушла. > На тот офтопик, который вы поддерживаете сами? :-) У вас, прямо таки сейчас духовность зашкалила.
