Ситуация такова. Я — в данном проекте — программист серверной части, причем в таковом качестве больше никого нет.
Программист клиентской части считает себя вправе залезть в мои исходники (над которыми я работаю сейчас) и поправить их так, как нужно ему.
Причем это не объясняется ни срочной необходимостью — это было бы понятно, ни даже моим отсутствием на работе — иногда он правит их даже тогда, когда я сижу и правлю их тоже. Просто — ему так удобнее. Ему быстрее поправить самому, чем сказать об этом мне. А потом он ставит меня в известность.
На первую попытку ему мной было замечено — пожалуйста, больше так не делайте. После непродолжительного разговора он нажаловался начальнику. Начальник поговорил со мной, на мои аргументы, что мне это неудобно, он ответил, что коллеге так удобно и он так привык. Потом с начальником мы вроде бы пришли к такой технологии работы, что все исходники будут лежать на source safe и будут зачекаутены мной, то есть легально коллега не сможет поправить мои исходники, с которыми я работаю.
Тем не менее вчера коллега затер исходники в source safe , добавил свою процедуру и переформатировал ряд моих процедур. Видимо, это была демонстрация.
Еще надо сказать, что профессионализм коллеги в PL/SQL программировании оставляет желать много лучшего. Ему, например, неизвестно, что такое нарушение констрейнта.
Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
Здравствуйте, Eugenie, Вы писали:
E>Ситуация такова. Я — в данном проекте — программист серверной части, причем в таковом качестве больше никого нет. E>Программист клиентской части считает себя вправе залезть в мои исходники (над которыми я работаю сейчас) и поправить их так, как нужно ему. E>Причем это не объясняется ни срочной необходимостью — это было бы понятно, ни даже моим отсутствием на работе — иногда он правит их даже тогда, когда я сижу и правлю их тоже. Просто — ему так удобнее. Ему быстрее поправить самому, чем сказать об этом мне. А потом он ставит меня в известность. E>Еще надо сказать, что профессионализм коллеги в PL/SQL программировании оставляет желать много лучшего. Ему, например, неизвестно, что такое нарушение констрейнта. E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
неа, это ненормально. правда, нам твоего кода не видно, вдруг все очень плохо
Здравствуйте, Eugenie, Вы писали:
E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
Слыхал, что в методологии XP практикуется так называемое коллективное владение исходниками.
Но в коллективном владении фишка в том, что это всем нравится, так что у тебя явно не тот случай
Этично/не этично — это вообще не в тему. Все зависит от организации процесса. Если ваш начальник считает возможным, что в написанный вами код кто-то вносит изменения (а судя по вашему посту так оно и есть), то значит так тому и быть. Только он (начальник) должен понимать (а вам желательно это до него донести), что с момента первого такого изменения понятие "ваш" код пропадает, это теперь "общий" код со всеми вытекающими последствиями — в частности, степень вашей ответственности за его неработоспособность существенно уменьшается.
IMHO, должна быть некая золотая середина. А именно — за каждый участок кода (компонент) должен быть один конкретный ответственный человек. При этом другие люди могут (при необходимости) вносить в эту часть кода изменения, но они должны быть согласованы с "хозяином" кода.
Здравствуйте, Eugenie, Вы писали:
E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
Смотри его изменения. Если все сделано правильно оставляй, если что-то не так откатывай изменения назад и уведомляй коллегу.
У нас принято спрашивать разрешения на правку исходников у их хозяина, если он есть конечно. Или просить его править лично.
Здравствуйте, Eugenie, Вы писали:
E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
Тому могут быть объективные причины. Может быть вы тугодум, и добиться от вас изменения кода сложно. Среди специалистов по базам данных такое встречается. Может быть вы загружены работой и физически не способны оперативно править код, а коллеге нужно работать.
Если вас там всего двое, в чем вообще может быть проблема? Пусть правит. введите систему контроля версий и порядок работы с ней. За нарушение порядка (коммит без комментария, правка физический файлов на сервере cvs и т.п.) больно бить с применением начальства. Если есть сомнения в квалификации коллеги, устраивайте code review перед/после коммита. По результатмам review показывайте коллеге где он не прав. Если он не клинический идиот, это только повысит его уровень, заодно и вы будете иметь в виду, что он там наменял. В любом случае никаих этических препятствий такому сценарию я не вижу.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Eugenie, Вы писали:
E>>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают? M>Тому могут быть объективные причины. Может быть вы тугодум, и добиться от вас изменения кода сложно. Среди специалистов по базам данных такое встречается. Может быть вы загружены работой и физически не способны оперативно править код, а коллеге нужно работать.
Указанные объективные причины отсутствуют. Моя реакция на просьбу доделать-переделать в среднем составляет 3-5 минут от момента получения письма — если я считаю нужным доделать-переделать! Если не считаю нужным, тут же прошу аргументировать просьбу, и иногда, если соглашаюсь с доводами, ее выполняю.
Описываемый коллега — не единственный, с остальными у меня проблем нет. Мои исходники лежат в открытом виде и видны всем, и всеми просматриваются. Иногда поступают дельные предложение улучшить — улучшаю. Такого, чтобы меня упрекнули в непрофессионализме — пока не было. By the way, я — Oracle 8i certified DBA.
Спасибо всем за отзывы. Кажется, удалось убедить начальника
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, Eugenie, Вы писали:
E>>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
A>Слыхал, что в методологии XP практикуется так называемое коллективное владение исходниками. A>Но в коллективном владении фишка в том, что это всем нравится, так что у тебя явно не тот случай
Ваш слух, вас не обманывает
Во всяком случае мне это кажеться очень удобным. Коллективное владение исходниками убыстряет разработку (не надо ждать, когда владелец кода освободиться и добавит нужный вам метод) и делает людей более взаимозаменяемыми, т.к. больше количество людей разбираеться в конкретных участках кода. Хотя есть минус, иногда ни кто не представляет как все это работает в целом, т.к. каждый правит что ему нужно, иногда не задумываясь о влияние этого на других участников процесса, но тут автотесты вам в помощь
В общем можно долго продолжать.
Здравствуйте, Eugenie, Вы писали:
E>Честно говоря, мне это не нравится Но, может, я придираюсь и теперь все так работают?
Ревью и рефакторинг кода вам в помощь, а так радуйтесь, за вас делают вашу работу
Главное договоритесь об общих стандартах оформления кода и кто главный (тоесть чтоб после вашего рефакторинга кода, у него не возникло желание все вернуть назад), иначе может начаться "война скобок"
Здравствуйте, Alxndr, Вы писали:
aik>>неа, это ненормально. правда, нам твоего кода не видно, вдруг все очень плохо A>Даже и в этом случае это просто неэтично (если, повторюсь, методология не предполагает).
нет такого понятия — этично или нет править чужой код. это не твой код, и не коллеги, это код компании. если компания позволяет технически править код кому ни попадя — значит, так компании удобно. ты либо воздействуешь на компанию, либо молча страдаешь. причем, в этом есть свои плюсы — с тебя снимается половина ответственности по поводу найденных багов. если б коллега у тебя на столе порядок наводил или в твоей почте ковырялся — то да, тут вопрос этики имеется.
Здравствуйте, aik, Вы писали:
A>>Даже и в этом случае это просто неэтично (если, повторюсь, методология не предполагает).
aik>нет такого понятия — этично или нет править чужой код.
Ну что ж, спорить дальше бессмысленно — для меня такое понятие существует
aik>если б коллега у тебя на столе порядок наводил или в твоей почте ковырялся — то да, тут вопрос этики имеется.
Если коллега ковыряется в моей корпоративной почте — это, понятно, резко становится этичным.
Добавлю, что мой рабочий стол с бумагами, которые лежат на нем и в ящике стола, также принадлежат компании.
Так что и тут все этично с определенной точки зрения.
Здравствуйте, aik, Вы писали:
aik>Здравствуйте, Alxndr, Вы писали:
aik>>>неа, это ненормально. правда, нам твоего кода не видно, вдруг все очень плохо A>>Даже и в этом случае это просто неэтично (если, повторюсь, методология не предполагает).
aik>нет такого понятия — этично или нет править чужой код. это не твой код, и не коллеги, это код компании. если компания позволяет технически править код кому ни попадя — значит, так компании удобно. ты либо воздействуешь на компанию, либо молча страдаешь. причем, в этом есть свои плюсы — с тебя снимается половина ответственности по поводу найденных багов. если б коллега у тебя на столе порядок наводил или в твоей почте ковырялся — то да, тут вопрос этики имеется.
Не понятно в таком случае, что же такого ненормального в правке чужого кода?..
Здравствуйте, Tourist, Вы писали:
T>Во всяком случае мне это кажеться очень удобным. Коллективное владение исходниками убыстряет разработку (не надо ждать, когда владелец кода освободиться и добавит нужный вам метод) и делает людей более взаимозаменяемыми, т.к. больше количество людей разбираеться в конкретных участках кода. Хотя есть минус, иногда ни кто не представляет как все это работает в целом, т.к. каждый правит что ему нужно, иногда не задумываясь о влияние этого на других участников процесса, но тут автотесты вам в помощь T>В общем можно долго продолжать.
Мне тоже это кажется удобным, но минусы тоже имеются, как минимум:
— разработчики должны быть высокого профессионального уровня;
— этот подход не масштабируется на случай больших команд;
— вероятно, непросто применить коллективное владение не в test-driven development.
Здравствуйте, Eugenie, Вы писали:
E>Ситуация такова[...]
Как вариант. Пишешь для всего кода избыточные unit-тесты. И пусть правит. Самое главное, чтобы все unit-тесты после этого выполнялись. Если вдруг после очередного исправления твоих исходников тесты не выполняются, так и пишешь начальнику. После внесения изменений перестали работать N тестов. В такой обстановке работать не могу. Прошу принять соответствующие меры.
Здравствуйте, Eugenie, Вы писали:
E>Программист клиентской части считает себя вправе залезть в мои исходники (над которыми я работаю сейчас) и поправить их так, как нужно ему.
Но, может, я придираюсь и теперь все так работают?
