Здравствуйте, Eugenie, Вы писали:

E>Ситуация такова. Я — в данном проекте — программист серверной части, причем в таковом качестве больше никого нет.
E>Программист клиентской части считает себя вправе залезть в мои исходники (над которыми я работаю сейчас) и поправить их так, как нужно ему.
E>Причем это не объясняется ни срочной необходимостью — это было бы понятно, ни даже моим отсутствием на работе — иногда он правит их даже тогда, когда я сижу и правлю их тоже. Просто — ему так удобнее. Ему быстрее поправить самому, чем сказать об этом мне. А потом он ставит меня в известность.
E>На первую попытку ему мной было замечено — пожалуйста, больше так не делайте. После непродолжительного разговора он нажаловался начальнику. Начальник поговорил со мной, на мои аргументы, что мне это неудобно, он ответил, что коллеге так удобно и он так привык. Потом с начальником мы вроде бы пришли к такой технологии работы, что все исходники будут лежать на source safe и будут зачекаутены мной, то есть легально коллега не сможет поправить мои исходники, с которыми я работаю.
E>Тем не менее вчера коллега затер исходники в source safe , добавил свою процедуру и переформатировал ряд моих процедур. Видимо, это была демонстрация.

E>Еще надо сказать, что профессионализм коллеги в PL/SQL программировании оставляет желать много лучшего. Ему, например, неизвестно, что такое нарушение констрейнта.

E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?

Я согласен с aik, сказавшим, что это не вопрос этики. Если спросить немного иначе:

1. Этично или нет программисту править таблицы маршрутизации на рутере?
2. Этично или нет сисадмину править цены в прайс-листе, лежащем на сервере?
3. Этично или нет отделу продаж править схему базы данных?

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

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

Здравствуйте, Eugenie, Вы писали:

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

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


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

Здравствуйте, nobody2, Вы писали:

N>А чисто технически — если уж другому человеку приспичило что-то исправить, то пусть делает бранч и правит как хочет. А ты потом смерджишь это на основную ветку.

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

Вообще вся ситуация — к ПМ-у, такое ощущение, что он мышей не ловит, у программера клиентской части слишком много свободного времени, править не только свой код, но и чужой ))

Здравствуйте, Alxndr, Вы писали:

aik>>>>неа, это ненормально. правда, нам твоего кода не видно, вдруг все очень плохо
A>>>Даже и в этом случае это просто неэтично (если, повторюсь, методология не предполагает).

aik>>нет такого понятия — этично или нет править чужой код. это не твой код, и не коллеги, это код компании. если компания позволяет технически править код кому ни попадя — значит, так компании удобно. ты либо воздействуешь на компанию, либо молча страдаешь. причем, в этом есть свои плюсы — с тебя снимается половина ответственности по поводу найденных багов. если б коллега у тебя на столе порядок наводил или в твоей почте ковырялся — то да, тут вопрос этики имеется.
A>Не понятно в таком случае, что же такого ненормального в правке чужого кода?..

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

Alxndr wrote:
> Здравствуйте, Eugenie, Вы писали:
>
> E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
>
> Слыхал, что в методологии XP практикуется так называемое коллективное владение исходниками.
> Но в коллективном владении фишка в том, что это всем нравится, так что у тебя явно не тот случай

Не стоит забывать что в XP коллективное владение исходниками подкреплено парным
программированием, юнит-тестами, ранней интеграцией и стандартами кодирования. Т.е., например,
ситуации с переформатированием пары функции не может быть. Юнит-тесты ловят некоторые баги в
исправленной версии функции, а ранняя интеграция и частые релизы позволяют как можно раньше
определить, что внесенные изменения не нарушают контракты измененных функций.
Ну, и как заметили ниже, это подразумевает высокий профессиональный уровень разработчиков.

ЗЫ Как же вы работали без средства контроля версий...

У нас "своего кода" нет вообще.
Всё есть в svn и доступно для всех разрабочиков.
Это удобно тогда, например, когда автор кода в отпуске или вообще уволился.

На каждую часть проекта есть ChangeLog, в котором любые функциональные изменения должны быть понятно объяснены — что, где, зачем, кто виноват.
Мне кажется разумным.

Здравствуйте, Eugenie, Вы писали:

E>Ситуация такова...
Приходилось сталкиваться с подобным. Но было дополнительное условие: править надо было срочно (начальство подгоняло), а график работы владельца кода был смещен во времени назад относительно графика того программиста, которому требовались изменения. Считаю, что руководитель должен установить регламент разрешения подобных конфликтов (в письменном виде, как часть "процесса").

Здравствуйте, Eugenie, Вы писали:

G>>Не пора ли менять работу?
E>Неохота! все остальное нравится!

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

Здравствуйте, Eugenie, Вы писали:

E>...

такой удар по этике не должен оставаться безнаказанным. вызовите мерзавца на дуэль.

Здравствуйте, Eugenie, Вы писали:

E>Ситуация такова. Я — в данном проекте — программист серверной части, причем в таковом качестве больше никого нет.
E>Программист клиентской части считает себя вправе залезть в мои исходники (над которыми я работаю сейчас) и поправить их так, как нужно ему.
E>Причем это не объясняется ни срочной необходимостью — это было бы понятно, ни даже моим отсутствием на работе — иногда он правит их даже тогда, когда я сижу и правлю их тоже. Просто — ему так удобнее. Ему быстрее поправить самому, чем сказать об этом мне. А потом он ставит меня в известность.
E>На первую попытку ему мной было замечено — пожалуйста, больше так не делайте. После непродолжительного разговора он нажаловался начальнику. Начальник поговорил со мной, на мои аргументы, что мне это неудобно, он ответил, что коллеге так удобно и он так привык. Потом с начальником мы вроде бы пришли к такой технологии работы, что все исходники будут лежать на source safe и будут зачекаутены мной, то есть легально коллега не сможет поправить мои исходники, с которыми я работаю.
E>Тем не менее вчера коллега затер исходники в source safe , добавил свою процедуру и переформатировал ряд моих процедур. Видимо, это была демонстрация.

E>Еще надо сказать, что профессионализм коллеги в PL/SQL программировании оставляет желать много лучшего. Ему, например, неизвестно, что такое нарушение констрейнта.

E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?


Этично/неэтично — неважно. Вопрос больше относится к организации производства, чем к морали.

У нас в принципе работает система code owners, и если ты где-то нашел баг или хочешь расширить функциональность — должен сперва обсудить это с владельцем кода. (владелец кода — не обязательно человек, его написавший, т.к. он может уволиться или работать в другом проекте; скорее это тот, кто лучше всего знает этот модуль и/или занимается его поддержкой).

Кстати, когда он так смело кроит ваш код, его целостность не нарушается ? Ну в смысле, компилируется ли, не теряется ли функциональность? А то ведь в противном случае можно и лицо дать.



Кстати, VSS — говно. А в svn можно повесить на commit определенных файлов hook по нотификации их владельца. Считаю, очень полезная фича, жаль все никак руки не дойдут сделать

Здравствуйте, Eugenie, Вы писали:

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

Да бога ради. Может, что хорошее напишет.

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