동료가 내 쿼리 이름을 모두 바꿨습니다. [닫기]

내가 매우 자극을 받아야하는지 또는 무엇을해야하는지 모르겠습니다. 대규모 데이터베이스에 대해 300 개가 넘는 쿼리를 직접 작성하고 명명 규칙을 개발하여 나중에 찾을 수 있도록했습니다. 내 사무실의 어느 누구도 쿼리를 작성하는 방법을 모르지만 어제 들어 와서 모두 이름이 바뀌 었다는 것을 알았습니다. 나는 지금 물건을 찾는 데 매우 어려움을 겪고 있으며, 무엇을해야하는지 파악하려고 노력하고 있습니다.

나는 책임을 맡은 사람과 이야기를 나누었고, 그녀는 방금 모든 것을 다운 플레이했습니다. 그녀는 이름을 더 쉽게 찾을 수 있도록 이름을 변경했다고 말했습니다. 불행히도, 나는 그것들을 구축, 편집 및 유지 관리하는 방법을 알고있는 유일한 사람이며, 그녀가 그들을 찾는 데 필요한 유일한 이유는 쿼리를 테스트하는 것이 었습니다. 새로운 명명 규칙은 전혀 의미가 없으며 개발 과정에서 거꾸로 한 걸음이 된 것 같습니다.

내가 알아 내려고하는 것은 다음과 같습니다.

1) 과민 반응입니까?

2) 이것을 처리하는 가장 좋은 방법은 무엇입니까? 나는 이것을 상사에게 언급하는 것을 싫어하지만 어제 동료와 대화를 한 후, 그녀가 아무 잘못이 없다고 느끼는 것을 이미 말할 수 있습니다.

1. 실제로는 아닙니다-그것은 엄청나게 무례한 일입니다.

2. 당신은 그녀에게 이야기했지만 우리는하지 않았지만 백업에서 이전 명명 규칙을 복원하거나 소스 제어에있는 경우 되돌릴 수있는 권리가있는 것처럼 보입니다. 이렇게하면 상사와 동료에게 알리고 이유를 알려주십시오 (자신의 작업을 유지할 수는 없습니다).

마지막으로 원하는 것은 이것을 앞뒤로 돌리는 것이지만 상황이 문제가되는 것처럼 처리하지만 적어도 무례한 패턴의 일부가되는 경우에는 문서화해야합니다.

왜 어른처럼 취급하지 않습니까? 앉아서 대립하지 않고 이름 지정 체계에 대한 장단점 목록을 작성하고 이에 동의하고 그것을 설명하는 간단한 문서를 작성하여 공식화하십시오. 그녀의 의견에 진심으로 관심을 가져서 그녀가 참여하고 있다고 느끼도록한다.

그것이 대부분 맛의 문제이고 그녀가 절대적으로 자신의 길을 가져야하는 종류의 사람이라면, 당신이 더 큰 사람이라는 것을 기쁘게 생각하십시오. 인생은 너무 짧아 명명 체계에 대한 오줌 싸기 대회가 없습니다.

문제가 이름 지정 체계입니까, 아니면 존중받지 못한다고 생각하십니까? 그렇다면 아마도 당신은 당신의 작업 관계에서 일할 수 있습니다. 당신이 가치가 없다고 생각한다면 왜 그녀가 생각하는 것에 관심이 있습니까? :) 또 다른 옵션은 그녀가 정말로 큰 일이라고 느끼지 않을 수도 있고 물건을 찾는 데 문제가 있다고 설명하면 다시 바꿀 수 있습니다.

1. 데이터베이스 디자인에는 권한 (GRANT 및 REVOKE)이 포함됩니다.
2. 테스트에는 테스트 권한이 포함됩니다.
3. 데이터베이스 개체의 이름을 바꿀 권한이있는 사람은 거의 없습니다.
4. 당신의 동료는 소수의 사람이 아닙니다.

"새로운 명명 규칙은 전혀 의미가 없습니다"라는 소리는 다음 중 하나 일 수 있습니다.

1. 그녀는 그들에게 회사 규범을 적용했습니다. 이것들은 종종 코드의 일관성을 유지하기 위해 사용되며, 최상의 경우에는 작은 사용자 정의 스크립트와 같은 주변 장치가 코드를 쉽게 찾을 수 있도록 도와줍니다. 이 경우 표준을 이해하고 왜 상황에 "이해가되지 않는지 " 이해해야합니다 . 그래도 모든 개발자 가 그대로 두는 것이 더 낫다고 생각한다면 , 왜 당신의 방법이 우월한 지 설명하고 규범을 바꿀 수 있는지 (아마도 그들이 동의하면 괜찮을지) 물어보십시오. (장기적으로는 어리 석고 지저분합니다).
2. 그녀는 그 자리에서 자신의 표준을 발명하고 적용했습니다. 새로 온 사람 일 가능성이 더 높으며 이론적 근거를 설명해야합니다. 당신은 무언가를 배울 수 있고 그리고 / 또는 당신이 이론적 근거를 설명하면 그녀는 무언가를 배울 수 있습니다.

중요한 점은 코드가 (단일) 코드 가 아니며 전체 그룹에 속하고 수정 될 것이라면 그렇지 않다는 것 입니다. 코드에 대한 비판은 코드를 작성한 사람을 중심으로해서는 안됩니다.

나는 책임을 맡은 사람과 이야기를 나누었고, 그녀는 방금 모든 것을 다운 플레이했습니다.

그리고 나는 당신에게 말할 것입니다.

변경 사항을 롤백하십시오.

이 전쟁에 임하십시오. 관리자는 귀하를 후원하고 권한을 강화해야합니다.

1) 아니오 당신은 너무 반응하지 않습니다. 누군가가 말하지 않고 작업을 변경하고 이유를 물었을 때 솔질했습니다. 그것은 무례하고 무례한 imho입니다.

2) 귀하는 공식 DBA입니까, 아니면 최소한 DB를 유지 한 사람입니까? 그렇다면 이름을 변경하고 작업 방법에 대한 규칙 문서를 작성하십시오. 또한 'Users Guide'스타일 문서를 작성하여 누군가가 DB에 들어가서 할 수있는 것을 찾도록해야합니다.

나는 손가락을 가리 키지 않고 그룹에 이것을 보내려고한다.

그렇지 않은 경우 팀으로 컨벤션을 작성하고 팀으로 컨벤션을 따르십시오.

참고로 300 + 쿼리의 이름을 변경하기 위해 무언가를 테스트 해야하는 사람에게는 유치한 것처럼 보입니다. 이 일을하는 데 시간이 얼마나 걸렸으며 물건을 찾을 수있을 정도로 시간이 많이 걸렸습니까? 누군가에게 도움을 요청하는 대신 그녀는 시간과 시간, 회사 시간을 낭비했습니다. 이 작업을 수행 할 때 코드가 손상되었을 수 있으므로 다른 팀원의 시간도 낭비됩니다.

내가 너라면 조금 식을 때까지 기다렸다가 다시 대화 해보세요. 그래도 문제가 해결되지 않으면 상사와상의하십시오. 그런 카우보이 정신은 팀 전체를 결속시킬 것입니다.

데이터베이스에서 임의로 이름을 바꾸면 프로덕션 환경이 쉽게 다운 될 수 있습니다. 이러한 절차가 코드 어딘가에서 참조되는 경우 심각한 결과를 초래할 수 있습니다. 롤백을 수행 할 수 있지만 이와 같은 테스터가 실제로 수행중인 작업을 알 수없는 경우 테스터가 프로덕션 환경을 변경하는 단계는 아닙니다. 이는 비즈니스 손실을 의미 할 수 있으므로 개발자와 테스터를 위해 별도의 사용자 역할을 구현해야합니다. 우리는 테스터와 함께하고 훌륭하게 작동합니다. 테스터는 라이브 데이터를 망칠 염려에 살 필요가 없기 때문에 종종 감사합니다.

다른 곳에서는 다루지 않는 것 같지만 공공 장소에 배치 된 모든 소스 (예 : 쿼리)는 버전 관리 시스템 아래에 있어야합니다.

그런 다음 동료가 이름 지정 체계를 변경하면 작업 체계로 쉽게 되돌릴 수 있습니다 (변경 사항을보고 필요한 경우 되돌릴 수 있음). 또한 변경 사항을 특정 사용자와 연결하여 누가 엉망이되었는지 확인할 수 있습니다.

입안에 선물용 말을 보지 마십시오.

첫째, 집단 코드 소유권- '귀하의'가되어서는 안됩니다.

둘째, 이름을 바꾼 경우 새 이름 지정 체계에 대한 추론을 요청하십시오. 그들은 쿼리를 사용하고 있습니다-어떤 경우에는 그들의 호출입니다; 또는이를 유지하는 데 도움을주기 시작한 첫 번째 단계입니다.

모든 사람이 자신이 '귀하의 것'이라고 생각하면 절대 제거하지 않고 새로운 것으로 넘어갑니다.

이것이 요청되었는지는 모르겠지만 공식 버전은 어떤 명명 규칙입니까? 귀하의 버전이 공식적인 경우 관점에서 문제를 해결한다고 말씀 드리겠습니다. 따라서 "Person X가 내 모든 변경 사항을 롤백했습니다"라고 말하는 대신 "Person X가 공식 명명 규칙에 위배되는 변경을했습니다"라고 말합니다. 공식적인 협약이 없다면 먼저 상담없이 변경 사항에 대해 감사하지 않음을 알려주십시오.

어느 쪽이든, "전쟁"을하는 것이 답이 아니라고 생각합니다. 이기더라도진다

그것은 끔찍한 행동입니다. 그녀는 후회가없는 것처럼 들리므로 상사에게 가져 가서 엉망이되지 않도록 확신 할 수있을 때까지 액세스 권한을 취소하도록 사례를 만듭니다.

당신의 상사가 기술적이지 않다면, 그들이 이해하는 용어로 설명하십시오. 포스트가 배달 준비가 된 비둘기 구멍으로 분류되는 포스트 룸에서 작업을 시작한다고 상상해보십시오. 당신은 일방적으로 비둘기 구멍을 현재 부서 시스템의 바닥 대신 바닥에서 성으로 분류하기로 결정합니다. 단기간에 인생을 편하게 해줄 수도 있지만 다른 포스트 룸 직원들에 의해 살해 될 것입니다.

무례합니다. 나는 분노 할 것이다.

임의의 사람들이 변경을 막을 수있는 권한을 설정하는 것 외에, 기능을 테스트하는 것이 그녀의 일이므로 설명해야합니다. 임의의 사람들이 코드를 변경하는 경우 신뢰성을 보장 할 수 없습니다.

모든 사람들이 말했듯이, 그녀는 이러한 쿼리의 작성자 관리자이기 때문에 당신을 존중하지 않으면이 작업을 수행해서는 안됩니다.

말했지만, 그녀가 처음에 검색어 이름을 바꾸면 이름 지정 규칙을 이해할 수 없기 때문에 언급 한 사람은 없습니다.
따라서 명명 규칙을 문서화하고 동료가 문서에 액세스하고 필요한 것을 찾을 수 있도록하여 문제를 쉽게 해결할 수 있습니다.

또한 다른 사람들이 쿼리를 찾아서 사용하는 방법을주의해서 고려해야합니다. 명명 규칙에 따라 작업을 효율적으로 수행 할 수없는 경우에는 아마도 태그 및 합의 된 키워드를 통해 다른 사람들이 원하는 것을 찾을 수 있습니다.

여기서 핵심은 누구도 고립 된 방식으로 일하지 않으며 서로의 발가락을 밟는 것을 피하는 가장 좋은 방법은 일반적인 기본 규칙에 대해 의사 소통하고 동의하는 것입니다.

나는 모든 것을 되돌 리겠다는 당신의 결정을 무시하고 같은 방식으로 응답 할 것입니다. 변경 사항을 되돌리고 동료에게 간단한 이메일을 보내십시오.

"이름 변경 규칙을 이해하지 못했기 때문에 현재 rXXXX 변경 사항을 되돌 렸습니다. 시도해 주셔서 감사합니다. :)"

그렇습니다.

버전 관리라는 것이 있는데, 무엇보다도 동료들이 당신의 물건을 엉망으로 만들 때 $ #! 7을 이길 필요가 없습니다. 이전 버전으로 롤백하고 파일을 잠그면 분노를 처리 할 수 ​​있습니다. 그것은 확실한 이유없이 그리고 먼저 묻지 않고 다른 사람의 물건에 의존하는 코드에서 급격한 변화를 수행하는 것이 단지 잘못되고, 매우 비현실적이며 실질적으로 죄가 아니라는 것을 설명 할 기회를 열어 줄 것입니다.

물론 이것은 명명 규칙이 그녀의 것보다 낫다는 것을 가정하고 변경 사항을 처리 할 수있는 한 빨리 코드 변경을 시작하는 것이 가장 현명한 경우가 아니라면 객관적인 인수 로이 결정을 실제로 백업 할 수 있다고 가정합니다 다음에 더 나은 명명 규칙을 생각해보십시오.

그것을 상사에게 가져 가지 마십시오. 그것을 해결하는 성숙한 방법은 동료와 직접적입니다. 그 후에는 그녀와 함께 일해야하므로 쉽게 해결할 수있는 싸움의 관계를 손상시킬 수 있습니다.