답변:
이것이 "기본 디자인 결함"이라고 확신하더라도 외부인이라는 것을 기억하십시오. 좋은 이유가있을 수 있습니다. 또는 프로젝트의 나이에 따라 그 당시에 좋은 이유가 있었기 때문에 프로젝트에 넣을 수 있었으며 지금은 여전히 역사적인 이유로 남아 있습니다.
"메일 링리스트에서 이것을 폭파"하는 대신 질문을하십시오. 다음과 같은 것 :
"저는 방금 X에 부딪 쳤는데 말이되지 않습니다. 이것을 구현하는 올바른 방법은 Y 일 것 같지만 다시는 내가 여기 새로 왔음을 알고 싶지 않습니다. 어떤 결론으로 넘어 가세요. 이것은 설계 상 실수이거나 제가 빠뜨린 것이 있습니까? 누군가 누군가 나를 채울 수 있습니까? 감사합니다. "
공학은 겸손이 여전히 진정한 미덕으로 여겨지는 세계에서 몇 안되는 곳 중 하나이며, "분명한 문제"에 대한 질문을하는 것은 좋은 답변을 얻고 새로운 것을 배우는 정말 좋은 방법입니다.
48 가지 권력 법 중 하나 :
인수를 통해 결코 당신의 행동을 통해 승리
당신이 논쟁을 통해 얻은 순간의 승리는 실제로 Pyrrhic의 승리입니다. 한마디도하지 않고 다른 사람들이 당신의 행동을 통해 당신에게 동의하도록하는 것이 훨씬 더 강력합니다. 설명하고 설명하지 마십시오.
이것은 많은 무의미한 주장 후에 어려운 방법을 배웠습니다.
이 특별한 경우에는 디자인 결함으로 인해 작동하지 않지만 매우 간단하고 구체적인 코드 조각을 제안하는 것이 좋습니다. 이전의 말처럼 "컴파일러 / 통역사와 논쟁 할 수 없습니다".
다른 것은 그룹에 영향을 미치 려면 그룹의 구성원 으로 인식 되어야한다는 것 입니다. 회사에 가입했지만 사람들은 아직 그룹의 회원으로 인식하지 않습니다. 따라서, 당신을 그들 중 하나로 인식하는 법을 배울 때까지 설립 된 그룹과 함께가는 것이 더 나을 수 있습니다.
당신은 아마 이것을 좋아하지 않을 것입니다 ... 그러나 여기갑니다 ...
나는 "루프"에 들어가서 프로젝트에 대한 정기적 인 커미터가되는 방법으로 일부 버그를 수정하려고 노력하고 있습니다. 문제는 내가 작업중 인 버그 중 하나를 일으키는 근본적인 디자인 결함을 발견했다고 생각합니다.
아니, 아니야 그렇게한다면 주저하지 않을 것입니다. "기본 디자인 결함"에 대해 자신이 확실하지 않다는 것은 발견하지 못한 것을 의미합니다. 다른 사람의 실수를 지적하려고 할 때, 그것은 "기본"과 같은 최상급을 사용하는 친구를 사지 않습니다.
당신 이 발견 한 것은 당신 이 가지고있는 문제에 대해 약간 더 나은 디자인입니다. 그래도 철저히 테스트해야 할 것입니다. 프로젝트를 처음 사용하기 때문에 내가 무슨 말을하는지 전혀 모르는 것보다 낫습니다.
하지만 메일 링리스트에 이걸 터뜨리면 거만하게 될 것 같아
그것을 "기본 디자인 결함"이라고 부르는 것은 오만한 것입니다. 그 문제에 대해서는 버그 일지도 모른다 는 것이 최선의 아이디어는 아닙니다. 그것이 문제 라는 사실을 모른다 면 (그리고 그것을 뒷받침 할 수 있다면), 그것을 완전히 이해할 때까지 겸손히 질문하고 연구해야합니다 . 설득하려는 사람보다 낫습니다.
...이 문제에 관해 토론 한 내용 중 일부는 일부 사람들과 머리를 맞대고 있습니다. 어떻게해야합니까?
중지. 이것은 도덕적 인 문제가 아니며, 아무도 살해하지 않습니다. 프로젝트의 장기 회원이 되려면 질문하기 전에 먼저 신뢰를 얻어야합니다. 버그를 수정하고, 그룹 값에 관계없이 놀라운 작업을 수행하고, 몇 가지 기능을 디자인하고, 테이블에서 자리를 차지하십시오.
그런 다음 손가락을 가리 키거나 깨진 물건을 부르지 않고 겸손하게 그룹의 디자인을 향상시킬 수있는 제안을 제시하십시오. 그리고 그 결과에 대한 모든 결과와 해결책을 생각하는 것이 좋을 것입니다. 디자인이 더 나은 이유에 대한 논쟁을 준비하십시오. 잃을 준비를하고 우아하게 잃어 버리십시오.
아이디어가 진정으로 더 좋으면 결국 그룹에 의해 받아 들여질 것입니다 (아마도 원래 디자이너는 아닐 수도 있음). 후자의 경우, 왜 당신은 그룹의 일부가되고 싶습니까?
...
가능하다면, 코딩 방법에 놀라움을 느끼고 디자인의 우아함과 영원한 진실을 받아 들일 수밖에 없습니다. 개발자 는 역량을 존중하지만주의를 기울여야합니다. 무능 (또는 부당한 오만)에 대한 처벌은 다소 심각합니다. 당신 이이 질문을하고 있기 때문에, 나는 훌륭하고 당당한 오만 경로가 실제로 옵션이 아니라고 생각합니다. ;)
"안녕하세요. 당신의 집으로 오게 해주셔서 감사합니다. 문을 지나갈 때 가족의 모든 사람들에게 아기가 못 생겼으며 누군가가 그를 웃기게했다는 것을 알려 드리고 싶습니다."
버그는 버그이며이를 호출해도됩니다. "디자인 결함"이 원인이라고 말하는 것은 당신 앞에있는 사람을 손가락으로 가리키고 (대부분은 "아빠") 그가 바보라고 말하는 것입니다.
불필요하고 비생산적입니다. 나는 제안한다 :
"#blah 문제와 관련하여 XY와 Z를 수행하여 문제를 해결할 수 있다고 생각하지만 이것이 프로젝트의 나머지 부분에 어떤 영향을 줄지 잘 모르겠습니다. 괜찮을까요?"
XY와 Z가 문제를 해결하는 곳. 디자인 결함이라고 말해 보자. 다른 해결책이있을 수 있습니다. 또는 '결함'배후의 가정은 프로젝트 전체에서 너무 깊게 실행되어 버그를 수정하지만 다른 모든 것을 깨뜨릴 수 있습니다!