Так это значит, что первый вариант ушел в продакшн, а только потом его поменяли.
Не в продакшн, а в trunk. Проблема была замечена при QA trunk версии или даже при локальном тестировании самим разработчиком или кем-то еще из команды — уже не помню за давностью лет.
Я работал с SVN, поэтому могу сравнивать. Возможность поправить опечатки гораздо удобнее ее отсутствия.
Вы почему-то априорно полагаете, что условные опечатки надо исправлять, посему считаете систему с таким функционалом удобнее.
В вашем случае несколько изменений будет в одном коммите, в моем мире несколько изменений будут в одном таске. С разбиением их — тасков — на достаточную гранулярность для удобства восприятия. И искать информацию вы будете по коммитам (законченный этап, готовая фича-исправление и т.д.), а я — по задаче в тасклисте(багтрекере). Разный workflow, разные СКВ.
В Европе достаточно популярны т.н. мопедоавтомобили — ездят коробчонки с номерами, как у скутеров. В Китае и Индии их клепают, втч на экспорт в больших количествах. Я думаю, у нас это называлось бы как раз мотоколяской.
Формально-то может и так. Но по сути — отдельной велополосы нет, автобус едет солидно быстрее. Что он должен делать? Плестись за самокатом, график и интересы десятков и сотен людей — побоку из-за самокатчика?
Не готовы наши (постсоветские) дороги к самокатам. К велосипедам — и то с натяжкой.
Промежуточные же нестабильные снэпшоты часто не несут смысла отдельно от всей кучи (мало чинят, больше ломают).
А это не всегда очевидно — будет ли в будущем польза от такого коммита.
Выше другого человека просили привести пример, привожу из своей практики:
Есть ошибка, исправление занимает 1 строку. Скажем, было «строка1», я закоммичу «строка2». Однако мне кажется странным, почему применили именно «строка1», лезу в историю, нахожу, что изначально было «строка3», ее заменили на «строка2» (как я хочу сделать), а потом на «строка1».
Когда «мой» вариант был закинут, он решал какую-то проблему, но следующий коммит имел комментарий, указывающий на то, что «мое» решение («строка2») поломало то и то в другом месте, почему применили строка1 как компромиссный вариант. В самом таске было написано чуть подробнее, но я бы не полез это выискивать, если бы не видел, что «моё» «строка2» уже было отвергнуто.
В итоге я вернул «строка3», исправил пару ошибок в других местах, так что решение стало покрывать все случаи.
Когда работаешь с legacy кодом, любая мелочь помогает, и наперед я не могу сказать, какой коммит пригодится, какой нет. Тот человек вполне мог «исправить историю» и закинуть только работающий (на тот момент) вариант, и я бы не узнал, что мое решение — негодное, было уже опробовано, не узнал бы почему оно негодное.
michael_vostrikov это и вам ответ с примером. Также наши разногласия сильно зависят от используемой СКВ. Я размышляю в рамках централизованной системы, поэтому мне неведом ряд из указанных вами проблем и наоборот.
Ясно; в моей парадигме это тоже уже принято как стандарт в виде «узнал что-то новое — обсуди с товарищами, договоритесь о принятии».
Я критиковал не этот подход, а часто встречаемый в обсуждения о код-ревью «прессинг» вида «делай вот так, это best practise — аж Сам XYZ про это статью написал и пофиг, что это не стандарт команды, фиг ты у меня проскочишь».
Но в реальности, даже менее опытный девелопер, вполне может пройтись по чеклисту и найти «дыры» в коде более опытного товарища, особенно если товарищ по каким-то причинам был не собран или спешил.
В таком случае тем более стоит доверить более опытному решать — принимать эти замечания или нет (см. также выше об адекватности).
А когда один блок разделен на несколько частей (или наоборот, смешан с другими), то разбираться в причинах изменений сложнее, надо искать разные части и объединять их в уме.
Вовсе необязательно. У нас в команде эти коммиты будут привязаны к одному таску, можно сделать выборку истории по его номеру.
Почему бы тогда в СКВ не хранить движения мышки и нажатия клавиатуры, которые делал программист?
Потому что мы говорим об изменения кода в системе контроля версий (кода). Изменение — от одного символа и больше, способ ввода не дает никакой дополнительной информации. В отличие от последовательных коммитов в виде проб и ошибок.
Дак там только последнее изменение, которое было может вчера. А когда доберемся до нужного периода, там будет у одних изменений один хеш, у других другой, и тоже только конечный результат
Не знаю, как это устроено в git, в SVN я просто попрошу показать изменения не включая последний коммит по данной строке и получу предыдущие изменения, связанные пачкой. Опять же — привязка всех коммитов, втч промежуточных, к таску.
там будет у одних изменений один хеш, у других другой, и тоже только конечный результат.
Почему только конечный, если как раз политика «коммитить промежуточные этапы тоже»?
Информативности тоже 0, и появляются разные вопросы — почему сразу ту строчку не изменили, может причины какие-то есть, может этот лог парсится какой-то утилитой, и надо сначала ее перенастроить, надо лазить по истории, анализировать коммиты и сообщения к ним, спрашивать у кого-то а почему так.
Наоборот — это будет в случае, если закоммитили сразу готовые 10к строк и комментарий(и) вида «пофикисли багу». У нас пишут развернутые комментарии, даже если изменили всего один символ. Опять же… привязка коммита к таску, где при необходимости оставят еще более развернутые комментарии. Просто потому что через год-два сам человек не будет помнить «почему так».
То есть если он вместо переменной А возвращает переменную Б, то он может проигнорировать замечание ревьювера? Мне это кажется не логичным
Естественно, это вырожденный пример, доведение до абсурда: человек не проигнорирует указание на очевидную логическую ошибку.
Но да — он имеет право на это, потому что он отвечает за этот код, а не ревьювер и не команда в целом.
Если критика по делу
Так а кто это решит? Вы исходите все из того же неочевидного посыла, что ревьювер компетентнее (и это верно, если разработчик — новичок, за которым присматривают, или просто разработчик мало знаком с этой частью системы).
Мой посыл — ревьювер не в «потоке» у него не замылен глаз — пмсм, корректнее. Это чем-то похоже на программирование в паре, только второй участвует постфактум. Соответственно, он может заметить ошибку, которая пролетела у разрабатывающего «между глаз», как в вашем примере с переменной. Но принятие решения и ответственность все равно на разработчике: это его код, его зона ответственности.
Теоретически, ревьювер может пойти на конфликт, отследить таск, изменение этого участка и исправить такую ошибку самостоятельно, если он так переживает за качество кода, а разработчик глух и туп. Но я лишь один раз за долгие-долгие годы видел «войну коммитов», когда два человека телепали код туда-сюда пытаясь настоять на своей правоте (причем это касалось скорее холивора «как нам строить всё», а не явной ошибки). Это было лишь единожды и разрешилось административно.
В норме — ты пошлёшь код коллеге либо для поиска очевидных общих ошибок (здесь нужно просто быть не от мира сего, чтобы проигнорировать указание на ошибку «возвращаем А, а надо Б» — такого человека выкинут из команды. А раз не выкинули, то он, по мнению команды, компетентен и адекватен), либо для проверки решения в той области, где ревьювер компетентнее (это — в основном его участок работы/ответственности). Это означает, что ты уже считаешь его мнение значимым и готов к нему прислушиваться — ведь иначе ты вовсе не пошлешь код ему на проверку решения. Ты априори готов слушать его критику решения. Сообразно этой мотивации посылающий будет игнорировать только менее значимые, спорные вопросы. При этом нет элемента подспудного несогласия из-за обязательности и подчиненного положения разработчика как в «традиционной» системе.
В общем, в малой команде с малой текучкой своя специфика.
Так история — это два коммита один за одним, а не просто конечный результат. Строчку забыли изменить — так и вносим это в историю «этот corner case не был учтен, держите».
Как я уже писал выше — почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк. Ведь, как пишет mayorovp, «локальные изменения до PR никому не интересны».
В то же время, открытый PR ещё не является частью проекта, а потому его история изменений пока что никого не интересует.
Мне, как пользователю централизованной СКВ, не понять «а потому его история изменений пока что никого не интересует», простите. ПМСМ, это интересно, как минимум постфактум, потому что показывает ход разработки, косвенно указывает на причины принятых решений. А не просто на конечный результат.
Меня при работе с legacy кодом часто спасают как раз коммиты промежуточных этапов. Просто потому что комментарии к ним обычно содержат пояснения изменений, которые важны для понимания того или иного участка. Почему человек сделал так, а не иначе? А вот — пожалуйста — в истории видно, что это решение было опробовано и отвергнуто потому и потому. Граждане довольны, расходятся по домам (с).
По каким признакам вы выберете именно третий и девятнадцатый коммит именно в этом мерже для обучения на чужих ошибках?
Например, по blame'у. В одном случае будет видно, как менялся тот или иной блок, строка. В другом — просто «состояние 1- состояние 2». Информативности 0.
У нас в команде принят простой принцип: ревью — это всегда запрос со стороны разработчика к коллеге по принципу «одна голова хорошо, две — лучше».
Основная задача — посмотреть код со стороны, потому что из-за эффекта потока/контекста (замыливается глаз) разработчик может пропустить что-то.
Этот принцип сразу отметает проблему с придирками и спорами: запросивший ревью сам решает, принять замечания, или нет. Если это придирки или пролог к холивору — они просто отметаются.
Поскольку обе стороны находятся на одном уровне иерархии в команде, ввод искусственной иерархии на время ревью (обязательство учитывать замечания) недопустим. Эффект знаком, наверно, многим служившим в армии: бывает так, что сослуживцу, выдвинутому на самую младшую, но командную должность иногда срывает башню от микроскопической, но все же власти над сослуживцами. Никакого положительного эффекта для команды такое не несет.
Концептуальные споры должны быть вынесены на отдельную встречу, семинар, публичное обсуждение. Ты узнал что-то новое, нашел какую-то технику или технологию, которая сделает разработку более эффективной, уменьшит количество ошибок в коде и т.д. — обсуди с коллегами, объясни им преимущества, чтобы все этим пользовались. А не в стиле «надо делать так, так лучше потому что лучше, исправляй, а то не заапрувлю» на код-ревью.
Изучая исходники можно увидеть множество примеров использования гранулированных блокировок, использования грамотных алгоритмов вместо блокировок, а также использование специальных инструкций и более “легких” примитивов синхронизации, чем Monitor.
Было бы интересно узнать конкретику. Гранулированные блокировки — это блокировка части коллекции? Какие «специальные» инструкции и более легкие примитивы используются?
Но в большем количестве случаев, спустившись и обернувшись, обнаруживал что эскалатор загружен полностью.
И это не обязательно значит, что КПД стал выше.
Твой тезис о КПД некорректен, потому что принимает за максимальную пропускную способность «двое на ступеньку через одну». В зависимости от потока, длины эскалатора (количества желающих бежать вниз в конечно итоге), система «один справа, слева бегут» может пропустить больше людей за единицу времени, если поток бегущих плотный.
На него напирает толпа. Думаешь он не встанет слева? Встанет
Я не думаю, я вижу, что не всегда встают. Скажем, на коротких эскалаторах — (на переходе) встают всегда по двое. На длинных (на входе на станцию) — не всегда. Меня тоже интересовал этот вопрос и я тоже наблюдал такие ситуации. Разница в наблюдениях может быть вызвана разницей привычек в разных городах. Я свои наблюдения произвожу в СПБ.
Согласись что безопаснее не терять 5 минут в очереди, и спокойно спуститься стоя чем наоборот? Но менее интересно. Сам кстати раньше постоянно бегал.
Это вопрос «успел-не успел», а не безопасности. Бегущий человек «ставит» на ситуацию, когда поезд приходит между моментом, когда он сбежал по эскалатору и моментом, когда его стоящий сосед спустился.
Не мне с тобой спорить, в конце статьи даже фотографии затыкальщиков выложили, и цифры сходны с моими. Или ты будешь и их оспаривать?
3. Не мне с тобой спорить, в конце статьи даже фотографии затыкальщиков выложили, и цифры сходны с моими. Или ты будешь и их оспаривать?
См. выше. Самый высокий КПД — если люди будут бежать в два ряда. Система «слева бегут» может иметь КПД как ниже, так и выше или равный системе «2 на ступеньку», в зависимости от плотности потока слева. Плотность потока зависит от нескольких факторов; в час пик, когда напор на систему больше всего, множество людей пытается сэкономить время и бежит — плотность потока высока, и КПД такой системы будет запросто выше «двух на ступеньку».
Также, пмсм, стоит рассмотреть вопрос в разрезе общей эффективности системы — если мы говорим о максимальной подвозной эффективности эскалатора, хватит ли производительности самого рельсового транспорта, чтобы люди не скапливались на станции.
Опечатки, доработки по pull-реквесту, в Git не надо это делать отдельным коммитом.
А что в этом хорошего-то? По факту есть изменение, которое не зафиксировано. С таким же успехом можно всю разработку какого-то элемента вести, сохраняя файлы в локальной папке, ее же отослать на ревью, а потом итог закинуть в СКВ одним махом. Толку-то?
Если считать, что сам бег вниз по эскалатору не предполагает штрафной функции, то результат всегда либо нейтральный, либо выигрышный, и бежать вниз — всегда целесообразно.
В принципе, этот короткий абзац — и есть правильная статья на тему.
ledinhome
не уменьшается толпа. Точнее, это временный эффект. Я как-то проводил аналогчные наблюдения: получается. что непосредственно после «затыка» левой стороны эскалатор оказывается заполнен, но это мнимое повышение эффективности: он заполнен теми, кто иначе бежал бы вниз, а не дополнительными пассажирами. Если бы не было затыка, эти люди уже были бы давно внизу.
В верхнем вестибюле в тот момент, когда «затык» достигает верха, люди перестают вставать на левую сторону и очередь, которая разбивалась на стоящих справа и бегущих слева, превращается в очередь стоящих справа. Через некоторое время, когда хвост «затыка» уезхает вниз, на левую сторону опять начинают вставать люди. Но это по-прежнему те же люди, которые бежали бы и так и так.
Ну, а рассуждая о максимальном КПД, можно рассмотреть модель, когда люди встают в два ряда и оба ряда бегут вниз.
SVN + самописная централизованная система.
Команда маленькая, все имеют доступ ко всем веткам, code review всегда делается пост-фактум и пр. особенности workflow маленькой команды, поэтому никаких плюсов переход на git не дает.
Странно только что этот пост написан на капиталистическом компьютере и размещен в капиталистических интернетах
Нет.
Компьютеры, как и интернет, разработаны инженерами-пролетариями, собраны компьютеры также пролетариями. Капиталистического здесь — присвоение прибыли.
а не опубликован в газете «Труд» и вывешен на остановке в социалистической застекленной раме.
Странный вопрос — ведь в отсутствие «второго»(социалистического) мира мы не знаем, какие бы компьютеры и сети передачи данных были бы в соцлагере. Какой смысл брать способ распространения информации советского периода и сравнивать его с современным? Союза-то нет, его современной техники не существует.
Вообще-то «Остров дураков» именно как аллюзия на СССР и воспринимался.
По крайней мере — тогда. Когда государство очень плотно начало опекать своих граждан, делая их инфантильными домашними животными.
Забавно, впервые слышу такую трактовку. Ведь в книге четко описывается, пусть с детскими аллюзиями, опускание на социальное дно, примитивизация культуры, доступной бедному коротышке и т.д. (Т.е. описывается, что на Дурацкий остров попадает неплатежеспособный коротышка).
Ну это преувеличение, многие вещи существовали еще задолго до ссср, о многих вещах, таких как финансовые пирамиды можно прочитать в книгах, например, в занимательной математике Перельмана, ну вообще считать что подобного в ссср не было это несколько наивно.
Да и утверждать, будто в Союзе никто не знал ничего о жизни «там» — тоже глупо и наивно. Ведь было снято множество фильмов, написано множество книг, втч мемуарные книги о поездках в США. И здесь можно спорить о достоверности изображения западного мира, но выходит, что оно было достаточно достоверно, чтобы позволить советскому писателю написать такую повесть, неплохо высмеивающую капреальность.
Интересно, что в англоязычном мире (будь то википедия или отдельные статьи) про повесть Носова часто осторожно говорится, будто она показывает «гротескный коррумпированный капитализм».
Вот это и есть марксистская догма, опровергнутая практикой. Пролетариат в развитых странах был большинством до второй половины прошлого века включительно, сейчас это уже давно не так.
Да нет, это и сейчас так. Просто некоторыми по политэкономическому невежеству под пролетарием понимается какая-то сугубо узкая категория а-ля работяга с лопатой в ватнике. На деле любой офисный работник — пролетарий. И я — инженер-программист — тоже. Пролетарий — это любой наемный работник (п. — человек, единственным источником дохода которого является продажа своей рабочей силы).
С оговорками, конечно; здесь еще будет вопрос о совмещении ролей, о том как трактовать человека с опционом акций своего предпрития, о «пролетариате и капиталисте в узком (как человеке) и широком (как экономическая роль в момент времени t) смыслах слова», но это уже более длинная тема.
Разве? А чем это отличается от крестовых походов? Если действие в интересах христиан, то христиане его и исполняют…
Разделение по вере — субъективное, по отношению к созданию продукта и прибавочной стоимости — объективно.
Да вы ревизионист, батюшка…
Нет, я просто уточняю терминологию. Марксизм в СССР очень много проблем поимел из-за неверных терминов, некорректных переводов «которые пусть так и останутся, потому что мы так привыкли, устоялось же», потихоньку превращаясь в бессмыслицу. Так произошло и с ДП.
Пролетариат есть только при капитализме, нет и не могло быть никакой ДП после отмены НЭПа.
И если большевикам периода Ленина было простительно использование вульгаты и упрощения — во-первых, в их время упрощение достаточно точно апроксимировало имевшиеся категории людей, во-вторых, им приходилось работать с малообразованным населением, которое вряд ли было способно воспринять абстракции — то использование упрощений в последующие периоды вышло СССР боком.
На мой взгляд было бы более справедливо отправлять его обратно,
Эмм, что? Какой смысл?
Представьте в виде аналогии — вот кто-то перерабатывает мусор потому и только потому что из мусора можно извлечь, скажем, алюминиевую упаковку, бумагу и перереботать их. Остаток — не нужен НИКОМУ. При чем тут справедливость-то? В таком случае вы должны будете, отправив мусор обратно, доплатить за его прием, причем больше, чем получили выгоды от переработки.
Не в продакшн, а в trunk. Проблема была замечена при QA trunk версии или даже при локальном тестировании самим разработчиком или кем-то еще из команды — уже не помню за давностью лет.
Вы почему-то априорно полагаете, что условные опечатки надо исправлять, посему считаете систему с таким функционалом удобнее.
В вашем случае несколько изменений будет в одном коммите, в моем мире несколько изменений будут в одном таске. С разбиением их — тасков — на достаточную гранулярность для удобства восприятия. И искать информацию вы будете по коммитам (законченный этап, готовая фича-исправление и т.д.), а я — по задаче в тасклисте(багтрекере). Разный workflow, разные СКВ.
Не готовы наши (постсоветские) дороги к самокатам. К велосипедам — и то с натяжкой.
А это не всегда очевидно — будет ли в будущем польза от такого коммита.
Выше другого человека просили привести пример, привожу из своей практики:
Есть ошибка, исправление занимает 1 строку. Скажем, было «строка1», я закоммичу «строка2». Однако мне кажется странным, почему применили именно «строка1», лезу в историю, нахожу, что изначально было «строка3», ее заменили на «строка2» (как я хочу сделать), а потом на «строка1».
Когда «мой» вариант был закинут, он решал какую-то проблему, но следующий коммит имел комментарий, указывающий на то, что «мое» решение («строка2») поломало то и то в другом месте, почему применили строка1 как компромиссный вариант. В самом таске было написано чуть подробнее, но я бы не полез это выискивать, если бы не видел, что «моё» «строка2» уже было отвергнуто.
В итоге я вернул «строка3», исправил пару ошибок в других местах, так что решение стало покрывать все случаи.
Когда работаешь с legacy кодом, любая мелочь помогает, и наперед я не могу сказать, какой коммит пригодится, какой нет. Тот человек вполне мог «исправить историю» и закинуть только работающий (на тот момент) вариант, и я бы не узнал, что мое решение — негодное, было уже опробовано, не узнал бы почему оно негодное.
michael_vostrikov это и вам ответ с примером. Также наши разногласия сильно зависят от используемой СКВ. Я размышляю в рамках централизованной системы, поэтому мне неведом ряд из указанных вами проблем и наоборот.
Ясно; в моей парадигме это тоже уже принято как стандарт в виде «узнал что-то новое — обсуди с товарищами, договоритесь о принятии».
Я критиковал не этот подход, а часто встречаемый в обсуждения о код-ревью «прессинг» вида «делай вот так, это best practise — аж Сам XYZ про это статью написал и пофиг, что это не стандарт команды, фиг ты у меня проскочишь».
В таком случае тем более стоит доверить более опытному решать — принимать эти замечания или нет (см. также выше об адекватности).
В общем, мы поняли друг друга, я думаю.
Jef239
это только рывком — 60-100м дистанция.
Вовсе необязательно. У нас в команде эти коммиты будут привязаны к одному таску, можно сделать выборку истории по его номеру.
Потому что мы говорим об изменения кода в системе контроля версий (кода). Изменение — от одного символа и больше, способ ввода не дает никакой дополнительной информации. В отличие от последовательных коммитов в виде проб и ошибок.
Не знаю, как это устроено в git, в SVN я просто попрошу показать изменения не включая последний коммит по данной строке и получу предыдущие изменения, связанные пачкой. Опять же — привязка всех коммитов, втч промежуточных, к таску.
Почему только конечный, если как раз политика «коммитить промежуточные этапы тоже»?
Наоборот — это будет в случае, если закоммитили сразу готовые 10к строк и комментарий(и) вида «пофикисли багу». У нас пишут развернутые комментарии, даже если изменили всего один символ. Опять же… привязка коммита к таску, где при необходимости оставят еще более развернутые комментарии. Просто потому что через год-два сам человек не будет помнить «почему так».
Естественно, это вырожденный пример, доведение до абсурда: человек не проигнорирует указание на очевидную логическую ошибку.
Но да — он имеет право на это, потому что он отвечает за этот код, а не ревьювер и не команда в целом.
Так а кто это решит? Вы исходите все из того же неочевидного посыла, что ревьювер компетентнее (и это верно, если разработчик — новичок, за которым присматривают, или просто разработчик мало знаком с этой частью системы).
Мой посыл — ревьювер не в «потоке» у него не замылен глаз — пмсм, корректнее. Это чем-то похоже на программирование в паре, только второй участвует постфактум. Соответственно, он может заметить ошибку, которая пролетела у разрабатывающего «между глаз», как в вашем примере с переменной. Но принятие решения и ответственность все равно на разработчике: это его код, его зона ответственности.
Теоретически, ревьювер может пойти на конфликт, отследить таск, изменение этого участка и исправить такую ошибку самостоятельно, если он так переживает за качество кода, а разработчик глух и туп. Но я лишь один раз за долгие-долгие годы видел «войну коммитов», когда два человека телепали код туда-сюда пытаясь настоять на своей правоте (причем это касалось скорее холивора «как нам строить всё», а не явной ошибки). Это было лишь единожды и разрешилось административно.
В норме — ты пошлёшь код коллеге либо для поиска очевидных общих ошибок (здесь нужно просто быть не от мира сего, чтобы проигнорировать указание на ошибку «возвращаем А, а надо Б» — такого человека выкинут из команды. А раз не выкинули, то он, по мнению команды, компетентен и адекватен), либо для проверки решения в той области, где ревьювер компетентнее (это — в основном его участок работы/ответственности). Это означает, что ты уже считаешь его мнение значимым и готов к нему прислушиваться — ведь иначе ты вовсе не пошлешь код ему на проверку решения. Ты априори готов слушать его критику решения. Сообразно этой мотивации посылающий будет игнорировать только менее значимые, спорные вопросы. При этом нет элемента подспудного несогласия из-за обязательности и подчиненного положения разработчика как в «традиционной» системе.
В общем, в малой команде с малой текучкой своя специфика.
Lissov
То-есть, у вас есть человек-бутылочное горлышко, через которого проходят все коммиты? ЧуднО.
Как я уже писал выше — почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк. Ведь, как пишет mayorovp, «локальные изменения до PR никому не интересны».
mayorovp
Мне, как пользователю централизованной СКВ, не понять «а потому его история изменений пока что никого не интересует», простите. ПМСМ, это интересно, как минимум постфактум, потому что показывает ход разработки, косвенно указывает на причины принятых решений. А не просто на конечный результат.
Меня при работе с legacy кодом часто спасают как раз коммиты промежуточных этапов. Просто потому что комментарии к ним обычно содержат пояснения изменений, которые важны для понимания того или иного участка. Почему человек сделал так, а не иначе? А вот — пожалуйста — в истории видно, что это решение было опробовано и отвергнуто потому и потому. Граждане довольны, расходятся по домам (с).
michael_vostrikov
Например, по blame'у. В одном случае будет видно, как менялся тот или иной блок, строка. В другом — просто «состояние 1- состояние 2». Информативности 0.
johnfound
вот-вот:
«почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк.»
Основная задача — посмотреть код со стороны, потому что из-за эффекта потока/контекста (замыливается глаз) разработчик может пропустить что-то.
Этот принцип сразу отметает проблему с придирками и спорами: запросивший ревью сам решает, принять замечания, или нет. Если это придирки или пролог к холивору — они просто отметаются.
Поскольку обе стороны находятся на одном уровне иерархии в команде, ввод искусственной иерархии на время ревью (обязательство учитывать замечания) недопустим. Эффект знаком, наверно, многим служившим в армии: бывает так, что сослуживцу, выдвинутому на самую младшую, но командную должность иногда срывает башню от микроскопической, но все же власти над сослуживцами. Никакого положительного эффекта для команды такое не несет.
Концептуальные споры должны быть вынесены на отдельную встречу, семинар, публичное обсуждение. Ты узнал что-то новое, нашел какую-то технику или технологию, которая сделает разработку более эффективной, уменьшит количество ошибок в коде и т.д. — обсуди с коллегами, объясни им преимущества, чтобы все этим пользовались. А не в стиле «надо делать так, так лучше потому что лучше, исправляй, а то не заапрувлю» на код-ревью.
Было бы интересно узнать конкретику. Гранулированные блокировки — это блокировка части коллекции? Какие «специальные» инструкции и более легкие примитивы используются?
И это не обязательно значит, что КПД стал выше.
Твой тезис о КПД некорректен, потому что принимает за максимальную пропускную способность «двое на ступеньку через одну». В зависимости от потока, длины эскалатора (количества желающих бежать вниз в конечно итоге), система «один справа, слева бегут» может пропустить больше людей за единицу времени, если поток бегущих плотный.
Я не думаю, я вижу, что не всегда встают. Скажем, на коротких эскалаторах — (на переходе) встают всегда по двое. На длинных (на входе на станцию) — не всегда. Меня тоже интересовал этот вопрос и я тоже наблюдал такие ситуации. Разница в наблюдениях может быть вызвана разницей привычек в разных городах. Я свои наблюдения произвожу в СПБ.
Это вопрос «успел-не успел», а не безопасности. Бегущий человек «ставит» на ситуацию, когда поезд приходит между моментом, когда он сбежал по эскалатору и моментом, когда его стоящий сосед спустился.
См. выше. Самый высокий КПД — если люди будут бежать в два ряда. Система «слева бегут» может иметь КПД как ниже, так и выше или равный системе «2 на ступеньку», в зависимости от плотности потока слева. Плотность потока зависит от нескольких факторов; в час пик, когда напор на систему больше всего, множество людей пытается сэкономить время и бежит — плотность потока высока, и КПД такой системы будет запросто выше «двух на ступеньку».
Также, пмсм, стоит рассмотреть вопрос в разрезе общей эффективности системы — если мы говорим о максимальной подвозной эффективности эскалатора, хватит ли производительности самого рельсового транспорта, чтобы люди не скапливались на станции.
А что в этом хорошего-то? По факту есть изменение, которое не зафиксировано. С таким же успехом можно всю разработку какого-то элемента вести, сохраняя файлы в локальной папке, ее же отослать на ревью, а потом итог закинуть в СКВ одним махом. Толку-то?
В принципе, этот короткий абзац — и есть правильная статья на тему.
ledinhome
не уменьшается толпа. Точнее, это временный эффект. Я как-то проводил аналогчные наблюдения: получается. что непосредственно после «затыка» левой стороны эскалатор оказывается заполнен, но это мнимое повышение эффективности: он заполнен теми, кто иначе бежал бы вниз, а не дополнительными пассажирами. Если бы не было затыка, эти люди уже были бы давно внизу.
В верхнем вестибюле в тот момент, когда «затык» достигает верха, люди перестают вставать на левую сторону и очередь, которая разбивалась на стоящих справа и бегущих слева, превращается в очередь стоящих справа. Через некоторое время, когда хвост «затыка» уезхает вниз, на левую сторону опять начинают вставать люди. Но это по-прежнему те же люди, которые бежали бы и так и так.
Ну, а рассуждая о максимальном КПД, можно рассмотреть модель, когда люди встают в два ряда и оба ряда бегут вниз.
Команда маленькая, все имеют доступ ко всем веткам, code review всегда делается пост-фактум и пр. особенности workflow маленькой команды, поэтому никаких плюсов переход на git не дает.
Нет.
Компьютеры, как и интернет, разработаны инженерами-пролетариями, собраны компьютеры также пролетариями. Капиталистического здесь — присвоение прибыли.
Странный вопрос — ведь в отсутствие «второго»(социалистического) мира мы не знаем, какие бы компьютеры и сети передачи данных были бы в соцлагере. Какой смысл брать способ распространения информации советского периода и сравнивать его с современным? Союза-то нет, его современной техники не существует.
Exchan-ge
Забавно, впервые слышу такую трактовку. Ведь в книге четко описывается, пусть с детскими аллюзиями, опускание на социальное дно, примитивизация культуры, доступной бедному коротышке и т.д. (Т.е. описывается, что на Дурацкий остров попадает неплатежеспособный коротышка).
MechanicZelenyy
Да и утверждать, будто в Союзе никто не знал ничего о жизни «там» — тоже глупо и наивно. Ведь было снято множество фильмов, написано множество книг, втч мемуарные книги о поездках в США. И здесь можно спорить о достоверности изображения западного мира, но выходит, что оно было достаточно достоверно, чтобы позволить советскому писателю написать такую повесть, неплохо высмеивающую капреальность.
Интересно, что в англоязычном мире (будь то википедия или отдельные статьи) про повесть Носова часто осторожно говорится, будто она показывает «гротескный коррумпированный капитализм».
Да нет, это и сейчас так. Просто некоторыми по политэкономическому невежеству под пролетарием понимается какая-то сугубо узкая категория а-ля работяга с лопатой в ватнике. На деле любой офисный работник — пролетарий. И я — инженер-программист — тоже. Пролетарий — это любой наемный работник (п. — человек, единственным источником дохода которого является продажа своей рабочей силы).
С оговорками, конечно; здесь еще будет вопрос о совмещении ролей, о том как трактовать человека с опционом акций своего предпрития, о «пролетариате и капиталисте в узком (как человеке) и широком (как экономическая роль в момент времени t) смыслах слова», но это уже более длинная тема.
Разделение по вере — субъективное, по отношению к созданию продукта и прибавочной стоимости — объективно.
Нет, я просто уточняю терминологию. Марксизм в СССР очень много проблем поимел из-за неверных терминов, некорректных переводов «которые пусть так и останутся, потому что мы так привыкли, устоялось же», потихоньку превращаясь в бессмыслицу. Так произошло и с ДП.
Пролетариат есть только при капитализме, нет и не могло быть никакой ДП после отмены НЭПа.
И если большевикам периода Ленина было простительно использование вульгаты и упрощения — во-первых, в их время упрощение достаточно точно апроксимировало имевшиеся категории людей, во-вторых, им приходилось работать с малообразованным населением, которое вряд ли было способно воспринять абстракции — то использование упрощений в последующие периоды вышло СССР боком.
Эмм, что? Какой смысл?
Представьте в виде аналогии — вот кто-то перерабатывает мусор потому и только потому что из мусора можно извлечь, скажем, алюминиевую упаковку, бумагу и перереботать их. Остаток — не нужен НИКОМУ. При чем тут справедливость-то? В таком случае вы должны будете, отправив мусор обратно, доплатить за его прием, причем больше, чем получили выгоды от переработки.