디자인 선택이 좋은 이유를 설명하는 방법? [닫은]

더 나은 개발자가되자 내 디자인 기술의 대부분은 기계적 분석보다 직관에서 비롯된 것입니다. 대단하다. 코드를 읽고 더 빨리 느낄 수 있습니다. 언어와 추상화 사이에서 디자인을 훨씬 쉽게 번역 할 수 있습니다. 그리고 더 빨리 일을 처리 할 수 ​​있습니다.

단점은 특정 디자인이 유리한 이유를 팀원 (및 더 나쁜 경영진)에게 설명하기가 어렵다는 것입니다. 특히 모범 사례에 뒤쳐져있는 팀원. "이 디자인은 더 테스트 가능합니다!" 또는 "상속보다 구성을 선호해야합니다." 머릿속으로 가서 지난 10 년간의 소프트웨어 엔지니어링 발전에 대한 모든 사람들의 실마리를 찾기 위해 노력하고 있습니다.

물론 연습으로 더 나아질 것입니다. 그러나 그 동안 많은 시간과 / 또는 나쁜 디자인이 필요합니다 (나중에 시간을 낭비하게 될 것입니다). 이점이 잠재 고객에게 완전히 분명하지 않은 경우 특정 디자인이 왜 우수한지 더 잘 설명 할 수 있습니까?

이것은 귀하의 질문에 직접 대답하지는 않지만 흥미로운 방향으로 이끌 수 있습니다.

나는 당신이해야 할 일은 아이디어를 설명 하는 것보다 아이디어 를 판매 하는 것과 관련이 있다고 생각 합니다. 영업은 고객의 문제가 무엇인지 이해 한 다음 제품 (또는 개발 방법 등)이 어떤 이점을 얻을 수 있는지 보여 줍니다. 사람마다 요구 사항이 다르므로 한 사람에게 도움이되고 흥분되는 것들이 다른 사람을 식 히게 할 수 있습니다.

CEO의 경우 시장 출시 시간이 핵심 일 수 있으며, 관리자에게는 예측 가능한 일정이 될 수 있고, 프로그래밍 동료에게는 코딩 속도가 빨라지거나 (테스트 / 문서화 / 디버깅 등) 회사 고객에게 더 빠를 수 있습니다. 아마도 ... ?

판매는 자동으로 이루어지지 않습니다. 상대방의 관점 을 이해하고 아이디어를 Happy Place ™에 매핑하는 방법을 찾기 위해 공동 노력을 기울여야합니다 . 그들은 방법을 알고 나면 그들이 개인적으로이 새로운 것은 도움이됩니다, 그들은 종종 "얼마나 그것은 비용과 우리가 그것을 얼마나 빨리 할 수 있습니까?"질문 당신이 그 마술 단어를 듣고 나면 당신은 당신의 판매 업무를 잘 수행 한 것을 알고 있습니다.

나는 당신의 질문에 대한 해결책을 실제로 가지고 있지 않지만 얼마 전에 나는 똑같은 딜레마에 직면했으며 정확히 똑같은 질문에 대답하려고했습니다.

나는 논쟁의 한쪽과 다른 쪽의 누군가를 찾을 것이고 내 몸의 모든 섬유가 나에게 올바른 디자인은 X라고 말했지만 단어를 사용하여 뒷받침 할 수는 없었습니다.

더 나쁜 점은 때로는 포인트를 인정하지 않고 상대방이 내 얼굴에 디자인을 불어 넣을 수있는 방법으로 만 구현할 수 있다는 점입니다. "그렇습니다. "만약이 코드를 보여줄 수 있다면."

글쎄, 실제로 답을 찾지 못했지만 며칠 전에 Lean Software Development : An Agile Toolkit을 살펴 보았습니다., 나는 대답이 실제로 존재하지 않는다는 것을 암시하는 흥미로운 것을 발견했습니다. 이 책의 한 부분은 다른 분야의 지도자, 특히 비상 대응 부서와 지도자가 결정을 내리는 방법에 대해 이야기하고있었습니다. 화재가 발생하거나 누군가가 당신을 쏘고있을 ​​때, 그 지도자들은 결코 앉아서 동료와 찬반 양론을 주장하지 않습니다. 대신 그들은 훈련과 경험을 통해 개발 된 직관을 사용하여 의사 결정을 돕습니다. 우리의 직업에도 동일하게 적용됩니다. 소프트웨어 개발에서 흔히 볼 수있는 수많은 미지의 변수와 가변성에 직면했을 때 어떻게 완전히 논리적으로 결정할 수 있습니까? 저자는 모든 결정을 정당화하려고 시도하는 대신, 개발자는 본능을 훈련하고 개선하여 결국 무엇을 해야할지 "알고"장려해야한다고 주장한다.

내가이 논쟁에서 벗어나는 유일한 길은 내 작업에 대한 입증 된 실적을 쌓는 것입니다. 내 코드에서 디자인 결정을 내렸다는 사실을 관리 및 팀원들에게 보여주기 위해 유지 관리, 확장 및 안정성이 더 높은 코드가 만들어집니다. 이 작업을 반복하면 사람들이 당신을 알아 차릴 것입니다. 이 시점에서 본능에 기초한 의견은 오늘날보다 훨씬 더 중요합니다. 이 전략은 상사를 포함하여 내 팀의 90 % 이상과 협력했습니다. 불행히도, 당신은 완전히 고집이 세고 당신의 길을보기를 거부하는 한두 명의 남자를 찾을 수 있습니다. 이때 몇 가지 옵션이 있습니다.

1. 당신은 계급을 뽑으려고 노력할 수 있습니다 (나는 막강한 논쟁에 지쳐서 상사에게 가서 계급을 요구하게되었습니다)
2. 대부분의 팀이 귀하를 지원하기 위해 로비를 시도 할 수 있습니다.
3. 프로젝트가 생산력을 잃지 않을 수 있다면 (즉, 생산성 손실이 너무 크지 않다면) 다른 사람이 잘못된 결정을 내린다고 생각하면 상대방이 논쟁에서 이기게하십시오. 다음 두 가지 중 하나가 발생합니다.
   • 어떤 경우에는 (소망 적으로 아주 작은 부분) 직관이 잘못되어 결국 무언가를 배우게됩니다. 잘 됐네요.
   • 대부분의 경우 (다시 ... 희망적으로), 당신과 "나쁜"디자인을 옹호했던 사람은 그것이 왜 나쁜지 정확히 알 것입니다. 모든 후시는 항상 20/20입니다. 바라건대, 이것은 당신이 당신이 무슨 말을하고 있는지 알 수 있고 다음에 그들이 그들의 주장을 두 번 주장 할 것이라고 생각하는 그 사람에게 교훈이 될 것입니다.

글쎄,이 대답은 당신이 생각하는 것만 큼 프로그래밍에만 국한된 것은 아닙니다. 당신은 그들이 이해하는 것들로 다시 가져와야합니다.

상속에 대한 구성과 같은 것이라면 현재 개발자의 90 %가 모범 사례 (부분적으로 개발자의 100 %가 거의 아무것도 동의하지 않는다는 사실에 근거한 야생 추측)를 고려할 것이라고 말할 수 있습니다. 그 이유에 동의하고 기뻐할 것입니다.

논란의 여지가 무엇인지, 개발자의 몇 퍼센트가 저에게 동의하는지에 대해 가능한 한 정직하게 노력합니다.

이것은 일반적으로 개발자보다 관리에서 더 잘 작동합니다. 개발자는 실제로 좋은 디자인을 옹호하는지 여부와 그것을 어떻게 알 수 있는지 설명하는 토끼 구멍을 밟을 것입니다. 이것에는 칭찬할만한 것이 있지만, 그것은 당신이 많은 시간을 투자해야한다는 것을 의미합니다. 그들이 그런 말에 대해 적어도 잠정적으로 당신의 말을 받아 들일만큼 충분히 당신을 신뢰하지 않는 한. 좋은면에서, 그들은 당신이 틀렸다는 것을 설득 할 수 있습니다.

더 테스트 가능한 디자인과 같은 것들에 대해 더 테스트 가능하다는 것에 동의하지 않으면 첫 번째 예제와 거의 동일합니다. 그들이 더 시험적인 것이 바람직하다는 것에 동의하지 않는다면, 그것을 이해하는 것으로 가져와야합니다. 이것은 아마도 관리 일 가능성이 높으며 장기적인 개발 비용 절감, QA 감소, 더 예측 가능한 프로세스 (반복되는 QA 사이클의 길이를 예측하기 어렵 기 때문에) 등에 대해 이야기 할 수 있습니다.

문제의 일부는 당신이 옳은 일이더라도 (그리고 물론 당신이 아닐 수도 있음) 팀이 논쟁의 여지가있는 것에 대해 당신과 동의하는 것이 얼마나 어려운지를 과소 평가한다는 것입니다. 프로그래밍은 부분적으로 사회학적인 연습이므로 아무도 이해하거나 뒤지지 않는 훌륭한 디자인이 실제로는 훌륭한 디자인이 아니기 때문에 토끼 구멍의 일부를 실제로 내려 가려면 시간을 예약해야 할 수도 있습니다. 따라서 그 시간을 낭비로 생각하지 말고 프로젝트 성공의 필수 부분으로 생각하십시오. 어떻게 든 건너 뛸 수 있다면 훨씬 쉬울 것입니다.

변화의 유일한 목소리가되는 것은 결코 쉬운 일이 아닙니다. 첫 번째 도전은 일반적으로 다른 사람들을 당신과 함께하는 것입니다. (희망에는 다른 사람들보다 더 열린 마음을 가진 사람들이 있습니다.) 다른 선임 개발자 / 관리자의 관심을 사로 잡아 십자군에 합류 할 수 있다면, 그 합병 된 목소리는 나머지 사람들이 무시하기 훨씬 어려울 것입니다.

사람들에게 설명 할 수있는 좋은 방법은 그들이 적극적으로 참여한 프로젝트에서 과거의 실수에 대한 구체적인 예를 제공하는 것입니다. 고치세요. "). 더 나은 방법으로, 이러한 '새로운'디자인 아이디어와 원칙을 소규모 / 시행 프로젝트에 적용하고 그것이 얼마나 성공적 이었는지 보여줄 수 있습니다.

회사 내 다른 사람들의 태도에 따라 변화가 빨리 올 수도 있고 기적을 헤엄 치려고하는 것과 같을 수도 있습니다. 일부 관리자는 확실한 통계 / 증거가없는 한 완전히 움직일 수 없습니다. 다른 관리자는 최신 사고에 대처하고 싶어합니다.

상대하는 사람에 따라 다른 전술을 시도해야 할 수도 있습니다. 비 기술적 인 관리자의 관심을 끌기 위해서는 돈 / 시간 / 노력이 절약되고 품질이 향상 될 수 있다고 제안하는 것이 좋습니다. 쉬운 자동 테스트의 약속은 동일한 테스트 스프레드 시트를 반복적으로 실행하는 데 며칠을 소비 할 수없는 많은 개발자들에게 어필합니다.

청중에 따라 다릅니다! 개발자로서 우리는 좋고 나쁜 코드에 대한 직감을 개발했으며 "코드 냄새", "못생긴 코드", "아름다운 솔루션"과 같은 모호한 감정적 용어를 사용합니다. 이는 동일한 사고 방식으로 다른 개발자와 통신 할 때만 작동합니다. 기술이 아닌 CEO에게 일부 코드를 "더 아름답게"만들기 위해 x-man-hours를 투자해야한다고 설명해보십시오.

주어진 디자인 개선은 다음 중 하나에 해당 할 수 있어야합니다.

• 회사를 위해 돈을 저축하다
• 회사를 위해 돈을 벌다

예를 들어, 단일 책임 원칙을 준수하는 경우는 무엇입니까? 각 클래스에 단일 책임이 있으면 버그를 쉽게 찾아 수정하고 기능과 개선 사항을 쉽게 추가 할 수 있습니다. 버그 수정 및 기능 추가 = 시간 절약.