> artiom -> debian-russian@lists.debian.org @ Mon, 26 Mar 2018 20:53:38 +0300: > > >> >> В идеале пишутся тесты. Часть заранее, часть по мере наступания на > >> >> грабли :) Код на Haskell и Scala даже и не тестируется автомагически, > >> >> настолько мало там багов, что написание тестов не окупается. > >> >> > >> > Ну это две параллельные задачи. Часто тесты нельзя написать. > >> > >> Если тесты нельзя написать, то код негодный. Другое дело, что на > >> написание тестов не всегда хватает ресурса. > >> > > Ну почему сразу "код"? А взаимодействие с аппаратурой? Моки каждый раз > > делать? > > Не каждый. Для unit-тестирования да, а для acceptance подключать > аппаратуру, ага. > А она бажная. Как факт. Потому что тоже разрабатывается.
> > А работа при загрузке ОС? > > И это тоже надо тестировать. Ну да, придется контейнер тюнить. > > >> > Плюс, на ревью проверяется читабельность кода и его логическая > >> > корректность (и тесты, и код возможно написать некорректно). Плюс, в > >> > два раза больше работы. В общем, одно другое не заменяет. > >> > >> Я не утверждал, что тестирование заменяет ревью. Я утверждал, что в > >> процессах, которые применяются там, где я работал, ревью отсутствует. > >> > > Понял вас. Хотя, всё-равно не могу представить. У меня опыт поменьше, но > > всё-таки, в трёх достаточно известных конторах, где я работал, ревью > > имеется, причём через WEB GUI. > > Известная контора - еще далеко не гарантия качества результата :) > Ну, я точно в курсе. > >> Если более тысячи программистов отвечают за одно место в коде, код > >> работать не будет. В больших конторах за каждое место в коде отвечает > >> очень небольшое количество людей, а протоколы взаимодействия между кодом > >> разных отделов компактны. > >> > >> >> За коммитами джуниоров просто присматривают вручную. Недолго, человек > >> >> либо обучается, либо идет искать работу в другом месте. > >> >> > >> > Да тут вопрос не о джуниорах. Всё сложнее. Но, в любом случае, код > >> > сложный, хотелось бы видеть, что уйдёт в репозиторий. > >> > >> В одной из контор у нас были любители почитать код, уходящий в > >> репозиторий. Ну, репозиторий был настроен так, чтобы рассылать коммиты > >> желающим. По почте. Тем же способом присматривали за джуниорами. > >> > > Примерно так и есть, но почта заменяется ccollab (или, в общем случае, > > любым web интерфейсом), и код не проходит в репозиторий без одобрения. > > Тут важный момент - не веб или почта "код не проходит в репозиторий без > одобрения". У нас проходил. Мой point в том, что проблем от этого не > происходит. > Возможно. Надо подумать над этим. Раньше я даже не предполагал такой практики. > >> Практика показывает, что читать код _до_ попадания в репозиторий - не > >> очень хорошая идея. Благо репозиторий позволяет, если что, откатить. > >> > > Но сборки уже будут собраны и отправлены на тестирование, так не лучше > > ли - не допустить? > > Какая практика? > > В чём нехорошесть данной идеи? > > Тормозной путь. Между моментом изменения кода и моментом, когда код > будет изменен, проходит время. Как минус, так и плюс. > Либо это очень большое время, либо > ревьюер работает с частыми прерываниями. Если у него содержательная > работа не обезьянья, то частые прерывания очень сильно снижают его > продуктивность. Так и так изрядно падает КПД. > Ну, допустим, пара дней на ревью - это большое время? Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и ждать ответов автора (который в этом время уже над другим работает), к тому же, ревьюверов бывает несколько. > >> Это вот понятное употребление ревью. Очень громоздкое, но цена ошибки > >> там такова, что оно окупается. > >> > > В случае того, что есть сейчас, коммиты тоже обосновываются: к ним > > привязана задача, после чего проверяются (перед репозиторием). > > А "в случае того, что есть сейчас" непонятно, окупается ли этот > тормозной путь. > Продукт окупается. "Тормозной путь", скорее всего, да. Не от хорошей жизни, а из-за некоторых разработчиков и сжатых сроков. > >> >> >> В общем, даже модель pull request не использовали, не говоря уже > о code > >> >> >> review. А вот работу в паре как раз использовали. > >> >> >> > >> >> > А подробнее? Это из области "экстремального программирования"? > >> >> > >> >> Да. Просто садятся двое. Один за клавиатурой, он код пишет. Второй > >> >> рядом, он смотрит, что пишет первый. Его задача - взгляд уровнем > >> >> абстракции выше, чем у писателя. Чтобы прямо по ходу иметь возможность > >> >> сказать "ты решаешь не ту задачу" или "ты сейчас подложил вот сюда вот > >> >> такие грабли". > >> >> > >> >> Результаты различного качества, в зависимости в основном от дисциплины > >> >> написания тестов. Но так, чтобы было неработоспособно - нет. Чаще > >> >> вылетает аппаратура, чем вылезают не дающие работать баги. > >> >> > >> > Только читал об этом, не думал, что в РФ используется. > >> > >> Это парадигма, ей чихать на государственные границы. > >> > > Границы не при чём, имеет значение "менталитет", в общем и, в частности: > > культура разработки и стоимость такого подхода. > > Менталитет программиста тоже интернационален. С менталитетом "кодера по > обезьяньей работе" хуже, но extreme programming - технология для > программистов. > Ну что-то мне подсказывает, что русским и китайцам ужиться будет несколько сложно, и не для всех эта техника подходит. > >> > В любом случае, если я такое (чисто теоретически) предложу менеджеру, > >> > он только у виска покрутит. Это же получается, что каждый программист > >> > работает, условно половину времени, а половину сидит "и что-то там > >> > смотрит". > > >> А если тебе не результат а имитацию бурной деятельности для менеджера, > >> то да, подход ровно обратный. > > В конкретном случае мне нужно сделать для себя: имитировать там не для > кого. > > Над своими проектами я не за деньги работаю. > > И те, кто со мной работает, понимают, что если ты не сделаешь, ничего не > > будет сделано. > > А если для себя, то предлагать вы будете не менеджеру, а себе. > Совершенно другая задача. > У меня так-то оба варианта сейчас есть. > >> Берем софт для совместной работы, > >> выбираем его по критерию "наиболее красочная презентация", закупаем под > >> него сервер, месяц инсталлируем, три месяца настраиваем. Менеджер от > >> презентации в экстазе, и всё согласовывае. Если бизнес-процесс > >> позволяет, покупаем платный саппорт, чтобы жопу прикрыть. Потом > >> заставляем всех им пользоваться. Все дружно заняты все 8 часов, а то и > >> 12... > >> > > Как ни печально, наблюдаю подвижки в этом направлении. > > Я с натуры это писал :) > Ну а я "в натуре" это вижу (хотя и не настолько всё плохо). > >> И кстати, code review более чем подходит под определение "что-то там > >> смотрит". Как ты будешь объяснять тому менеджеру, чем ты занят во время > >> code review? > >> > > А у нас на ревью время специально выделяется (похоже, что были > > менеджеры, которые не понимали, что это "за ревью такое", и в правила > > записали официально). > > На парное программирование же времени не выделяют. > > Код пишут не вместе, хотя иногда вместе раздирают. > > А у нас выделяют время на работу, а не процедуры определенного > вида. Надо поработать в паре - попросил коллегу, сели, поработали в > паре. Надо попросить коллегу посмотреть код - попросил коллегу > посмотреть код. И т.д. > Так тоже возможно, но постоянную "работу в паре" не одобрят точно. > >> P.S. жалоба листмастеру на оффтопик ушла. > >> > > На тот офтопик, который вы поддерживаете сами? :-) > > У вас, прямо таки сейчас духовность зашкалила. > > Нет, на политический. Который я как раз не поддерживаю. > А причём здесь эта тема?
