LINUX.ORG.RU
ФорумTalks

По поводу изменения общего кода


0

1

Недавно «в реале» и скайпике разгорелась жаркая дискуссия по поводу правки общего кода.

Сценарий:

1) A написал код
2) Б пошел, и независимо изменил его, руководствуясь самыми благими побуждениями
3) Б видит, что код после изменения не работает
4) Б идет к изначальному автору кода А и требует починить его чтобы всё работало


Ситуация встает особо остро, когда Б бросается исправлять любую замеченную несправедливость/неправильность кода, даже если на него не назначено подобных задач.
Всё это как правило вызывает некислую ненависть со стороны А, у которого всё ВНЕЗАПНО начинает ломаться в самых странных местах как раз тогда, когда нужно сдавать работу.

Одна популярная точка зрения: «код общий, А работает в одной команде с Б и должен принимать близко к сердцу его мнение, поэтому А должен немедленно броситься и поправить свой код в соответствии с желаниями Б».
Другая популярная точка зрения: «послать Б нафиг, „твои изменения - твои проблемы“, а еще коммитить нерабочий код в репозиторий - грех и мракобесие».


На какой стороне вы? Есть еще варианты?

★★★★☆

А что, контролировать совсем некому, что принимается, а что нет? Тогда бить по рукам и изгонять с позором.

Deleted ()

Как в методологии XP: если сломал что-то — почини сам.

undertaker ★★ ()
Ответ на: комментарий от Deleted

> А что, контролировать совсем некому

есть кому. Но обращение к архитекторам решить тёрки обычных разработчиков по поводу стандартной задачи - воспринимаются крайне негативно. Нельзя постоянно отвлекать такой чепухой.

плюс, всё зависит от точки зрения. Если первый к контролятору пойдет А, он может сказать, что борется с кривыми правками (пусть и созданными с самыми благими намерениями). Если первый к контролятору пойдет Б, он может сказать, что борется с быдлокодом, который приведет проект к краху, один-одинешенек в окружении мерзких быдлокодеров.

stevejobs ★★★★☆ ()
Ответ на: комментарий от drull

> А откатить до предыдущей версии религия не позволяет?

откат до предыдущей версии — это в интересах товарища А. Но не в интересах товарища Б, которому не нужен откат, ему нужно чтобы А пофиксал код.

stevejobs ★★★★☆ ()

Да, а можно в git или другой scm поставить на файл флаг «Не трогать! Другой разраб сейчас пилит этот файл.» От 1 проблемы это должно спасти.

different_thing ()

>а еще коммитить нерабочий код в репозиторий - грех и мракобесие"

Они еще и бранчи ниасилили?

redgremlin ★★★★★ ()
Ответ на: комментарий от different_thing

> а можно в git или другой scm поставить на файл флаг «Не трогать!

неа, не спасает ;) Допустим, чел B решил, что сигнатура функции func(type1 x,type2 y, type3 z) - фигня и быдлокод. Тогда он клацает правой кнопкой по функции, говорит „изменить сигнатуру“ и меняет type3 на type4. При этом он меняет ее в интересах текущей задачи. Но реально-то меняются 100500 файлов, в которых та функция используется.

stevejobs ★★★★☆ ()
Ответ на: комментарий от Deleted

Так он может чинить как хочет, но только что б потом работало :3

так вопрос в том, кто чинить будет, А или Б.

я-то явно на стороне А. НО оказалось, что всё не так очевидно: нашлось множество человек, вступившихся за Б. Типа, каждый имеет право фиксать код каждого, и если кто-то написал фигню, то он и должен отдуваться.

stevejobs ★★★★☆ ()
Ответ на: комментарий от redgremlin

> А если товарищ Б прав и у А быдлокод с побочными эффектами?

Тогда получается что Б сделал из рабочего быдлокода нерабочий, и он все равно не прав.

drull ★☆☆☆ ()
Ответ на: комментарий от drull

А если бы он сделал правильно и свой коммит оформил отдельным бранчем, чтобы А разгреб свой быдлокод, не трогая пока работающий master?

redgremlin ★★★★★ ()
Ответ на: комментарий от redgremlin

Это уже другая ситуация, отличная от той которую описал ТС.

drull ★☆☆☆ ()
Ответ на: комментарий от stevejobs

> и если кто-то написал фигню, то он и должен отдуваться.

Ну дык Б написал фигню в результате которой другая фигня перестала работать ---> Б должен отдуваться.

drull ★☆☆☆ ()

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

CrossFire ★★★★★ ()

Моё мнение: «Б - мудак. Гнать из проекта ссаными тряпками за наплевательское отношение к принципам написания кода и идее проекта».

Quasar ★★★★★ ()
Ответ на: комментарий от stevejobs

Если товарищ Б это не осознаёт, значит быдлокодером является именно он.

Quasar ★★★★★ ()
Ответ на: комментарий от stevejobs

stevejobs> нашлось множество человек, вступившихся за Б. Типа, каждый имеет право фиксать код каждого, и если кто-то написал фигню, то он и должен отдуваться.

Вот пусть Б и фиксит, раз взялся. Если он поломал программу своим «мупер некривым кодом», значит он именно сломал всё, а не «пофиксил код так, чтобы было правильно». Раз он так начал фиксить - пусть фиксит до конца. Иначе получается двоемыслие.

Quasar ★★★★★ ()

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

Terrens ()

> На какой стороне вы?

Чума на оба ихних дома.

Есть еще варианты?


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

atrus ★★★★★ ()

Имхо, если А написал полную фигню, то Б должен так ему это и сказать, а не ломать код.

Yareg ★★★ ()

1. нефиг 2-м человекам работать над 1-м куском, тем более если они не могут договориться
2. чуваку Б - пистонов прописать, при выявлении косяков, появившихся из-за его вмешательства
3. надо поплотнее использовать бранчи
4. неужели чувак Б сделал всю свою работу, что лезет чужой код править?
5. введите уже code review

shty ★★★★★ ()
Ответ на: комментарий от shty

и да, до кучи надо добавить: модульное тестирование и документ по code style

shty ★★★★★ ()

> 2) Б пошел, и независимо изменил его, руководствуясь самыми благими побуждениями

3) Б видит, что код после изменения не работает

4) Б идет к изначальному автору кода А и требует починить его чтобы всё работало



У нас такое ресолвилось следующим образом: коммитить неработающий код было строго запрещено. Автор неработающего коммита накрывал поляну на всю команду. Раз покормил, два покормил, и знаете, побуждения как рукой...

shimon ★★★★★ ()

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

А от разборок с коллективным «пиджаком Райкина», иногда, может и репа съехать ))
Все от конкретики. Например: ffmpeg - тоже что-то непонятное. Лан, не будем судить.

elipse ★★★ ()

Тут еще такой вопрос: если Б что-то исправлял после А, и какое-то решение показалось Б бредом собачьим, то почему бы не спросить у А: товарищ, вот тут твое решение мне кажется собачьим бредом, соизволь объяснить, почему ты сделал вот так?

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

shimon ★★★★★ ()
Ответ на: комментарий от thrall

> Б - идиот.

Необязательно, просто в одиночку Б может быть богом работающего кода, и при этом не уметь работать в команде. Работать в команде научиться можно и нужно.

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

shimon ★★★★★ ()
Ответ на: комментарий от stevejobs

>При этом он меняет ее в интересах текущей задачи.

Тут нужна просто жесткая политика в отношении сохранения API. Не нравится Б сигнатура - ОК, пусть добавит новую версию функции, используя реализацию старой, и использует в файлах, относящихся к его задаче

annulen ★★★★★ ()

Б пошел лесом. Если ему не нравится код А то пуст поправит, но не изгадит как обезъяна. Выглядит как Б не понравился код А и он молотил как идиот по клавиатуре пока компилятор вообще перестал его воспринимать? И что А идиот? Да фиг там. Б баран

demmsnt ()

Б — идиот. Если тебе кажется, что ты видишь неминорную проблему, сначала надо обсудить с автором кода, потому что сам можешь понимать что-то неправильно.

Одна популярная точка зрения: «код общий, А работает в одной команде с Б и должен принимать близко к сердцу его мнение, поэтому А должен немедленно броситься и поправить свой код в соответствии с желаниями Б».


Выносить на обсуждение

Другая популярная точка зрения: «послать Б нафиг, „твои изменения - твои проблемы“, а еще коммитить нерабочий код в репозиторий - грех и мракобесие».


Всё верно, и неплохо бы руководству прописать Б хороших мормальных 3.14здюлей. Если не дойдёт — уволить.

fang ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.