개발자가 불필요하거나 유해한 기능에 반대해야합니까?

새로운 기능, 즉 중요하지 않은 / 질문이 아닌 기능을 논의 할 때 개발자의 좋은 태도는 무엇입니까?

언어와 같은 일종의 Java를 개발하고 있다고 상사가 말한다. "우리는 개발자가 객체 메모리를 직접 조작 할 수 있도록 포인터가 필요합니다!"

개발자가 상상할 수없는 복잡성과 보안 취약점을 추가하여 아이디어를 중단해야합니까? 아니면 요청을해야합니까?

이것은 좋은 예는 아니지만 워크 플로를 중단하거나 프로그램의 내부 구조에 영향을주는 버튼을 추가하는 등 회색 영역에 더 많은 것은 어떻습니까?

정규 프로그래머를위한 최적의 "할 수있는"배포와 "할 수없는"배포는 무엇입니까?

편집 : 문제는 나쁜 상사에 관한 것이 아닙니다. : D

나는 사람들이 눈에 띄는 양의 문제를 추가하면서도 소박하게 유용 할 수있는 새로운 문제에 어떻게 접근하는지에 더 관심이있었습니다.

일반적인 태도는 다음과 같습니다.

1. 그래 우리는 할거야, 복잡성을 망쳐
2. 아마도
3. 아니요, 일반적인 재 작업 및 시사점은 변화를 정당화하지 않습니다

좋은 개발자의 반응은 무엇입니까?

가장 좋은 점은 회의를 갖고 장단점 을 그룹으로 세우고 이를 바탕으로 최상의 해결책을 논의하는 것입니다. 팀이있는 경우 솔루션에 동의하도록하십시오. 팀이 무언가에 동의하면 관리자와 "보스"가 솔루션을 찾는 경향이 있습니다.

만약 당신의 상사가 여전히 동의하지 않는다면, 당신은 당신이 할 수있는 모든 일을 다 한 것입니다 : 당신은 당신의 팀과 매니저를 함께 가지고 장단점을 커버했고, 상사가 잠재적으로 열등한 해결책을 선택 했음에도 불구하고.

이것의 핵심은 그룹으로서의 장단점을 논의하는 것입니다. 그렇게함으로써 당신은 당신의 팀과 함께 최고의 솔루션이 무엇인지 논의하고 동시에 사람들이 당신의 상사 결정을 생각하는 이유를 사람들에게 말한 후 정치적 반발없이 상사의 결정을 지적합니다. 잘못되었습니다.

이것은 노동 정치와 관련된 부드러운 상황이지만, 우호적으로 다룰 수 있습니다.

만약 당신의 상사가 어리석은 일을하도록 지시한다면, 어리석은 이유를 (친절하게) 설명해야합니다.

그 사람이 요점을 얻지 못하면 어리석은 일을해야합니다. 그게 다야. 그는 보스입니다. 그러한 경우, 그 사람이하는 말을하거나 상사와 대화하거나 직업을 바꿀 수 있습니다.

사장에게 기술적으로는 가능하지만 분석, 디자인, 기존 코드 재 작성, 테스트, 회귀 테스트 등을 위해 노력하는 데 소요되는 X 시간과 비용이 소요될 것이라고 보스에게 알릴 수 있습니다. . 때때로 대답은 "그렇습니다! 우리는 이것을 가져야합니다!"가 될 것입니다. 때로는 "아니요, 그렇지 않습니다"가 될 것입니다.

요청한 기능이 응용 프로그램의 핵심 원칙 (예 : "파란색 버튼 추가!")을 고객의 요청에 따라 빨간색 버튼 만 갖도록 지정되고 설계된 UI에 위반하는 경우 정상이라고 생각합니다. 왜 "왜?" 미리 설정된 디자인에 반대한다고 언급합니다.

결국 거의 모든 것이 "할 수있는"것입니다 ( 기술적 인 관점에서 파란색 전용 UI에 빨간색 버튼을 추가하는 것이 어렵지 않을 수도 있음 ). "해야 할 일"이 더 중요합니다.

수정 된 질문에 답변하려면 추가 조사 및 분석이 진행되는 동안 답변이 # 2, "아마도"라고 생각합니다.

주어진 기간 내에 제공 할 수없는 무언가에 대한 약속을 고수 할 수 있기 때문에 # 1 "무조건적으로"라고 대답하고 싶지 않습니다.

당신은 비협조적이고 불필요하게 어려운 것처럼 보이기 때문에 # 3 "아니오, 너무 많은 일입니다"라고 대답하고 싶지 않습니다.

개발자의 관점에서 : 청구서를 지불하는 사람에게 자신이 원하는 것을 가질 수 없다고 말하지 마십시오. 대신, 당신은 그들이 그 가격으로 그것을 가질 수 없거나, 그들이 원래 생각했던 것과 정확히 그것을 가질 수 없다고 말할 수 있습니다.

"포인터"예; 관리 코드 환경 인 .NET에는 포인터가 있습니다. 관리되지 않는 코드와의 많은 상호 운용성을 위해서는 반드시 필요합니다. 그러나 "안전한"사용은 엄격하게 규제되며 "안전하지 않은"코드에서 사용되는 경우 해당 코드는 런타임에서 더 높은 보안 권한이 필요합니다. 포인터를 통한 직접 메모리 액세스가 필요한 관리되는 언어를 개발하는 경우 자동 마샬링 할 수없는 읽기 전용 관리 포인터를 사용하고 " true "는 코드베이스의 가장 신뢰할 수있는 영역에서만 포인터입니다.

GUI 예제 : 새로운 기능이 현재 코드 흐름을 "중단"한다는 것을 알고 있다면,이를 테스트하고 워크 플로우에서 수행 한 이전 작업을 롤백하기 위해 더욱 강력하게 개발할 수 있습니다. 당신의 클라이언트, 때로는 당신의 매니저조차도 대개 프로그램 구조에 대한 단서 나 관심이 없습니다. 프로그램을 구성하는 방식으로 인해 원하는 것이 어려운 경우, 정의에 따라 클라이언트가 원하는 것을 수행 할 수 없기 때문에 구조가 잘못되었습니다.

모든 경우에이 새로운 기능은 고객이 생각했던 것 이상으로 필요한 작업 범위를 증가시킬 수 있습니다. 그것은 일정 연장, 더 많은 돈, 및 / 또는 다른 계획된 작업의 감소를 요구할 것입니다.

그러나 더 쉽고 논리적으로 동일한 기본 결과를 얻는 방법을 알고 있다면 클라이언트에게 제안 할 수 있습니다. 분명히 존재하지만, 운 좋게도 개발자의 의견을 듣지 않기로 한 클라이언트를 보지 못했습니다. 특히 "제품 소유자"가있는 애자일 환경에서 다음과 같은 다양한 세부 사항에 대한 개발에 대한 책임이 있습니다. 이들.

수년 동안 대규모 응용 프로그램을 프로그래밍하는 데 시간을 투자하고 그에 따라 비판적으로 생각한다면 기능이 유용성을 능가하는 문제를 일으키는시기에 대한 미세 조정 된 감각을 개발하게됩니다. 이것에 대한 또 다른 단어는 지혜 이며, 다른 종류의 지혜와 마찬가지로 지혜가없는 사람들이 그 가치를 보지 못하게 만드는 것은 어려울 수 있습니다.

다른 포스터는 문제가있는 기능에 의해 도입 될 문제의 비용을 수량화하려고 노력해야한다고 주장했으며, 가능할 때는 좋은 생각이지만 일반적으로는 그렇지 않습니다. 일반적으로 즉각적인 구현 비용 만 추정 할 수 있습니다. 더 큰 기능의 경우에는 종종 어려움이 있습니다. 미래 비용에 관해서는, 당신은 어려운 위치에 있습니다. 어떤 다른 기능이 필요한지 또는 제품의 유지 보수 기간을 확실하게 알 수 없습니다. 비용은 일반적으로 어려운 사실에 근거한 추정치로 백업 할 수있는 것보다 훨씬 높습니다.

과거에 입증 된 역량이 많을수록 기능에 나쁜 아이디어를 선언해야 할 여지가 많습니다. 그것은 시간과 성공의 입증 된 기록과 함께 올 수 있습니다. 즉, 고객이 원하는 것이기 때문에 요청을 이행하기 위해 항상 열심을 표현해야합니다. 경험을 바탕으로 예약을 표시해야하며, 일단 문제가 발생하면 90 %의 사례에서 문제가되지 않습니다. 문제의 근본이되는 대화를 시작하기 때문입니다. 이 기능은 처음에? 이 시점에서 대안을 제공하거나 요청 된 기능에 문제가 발생하더라도 여전히 필요하다는 데 동의 할 수 있습니다.

물론 당신이 잘못되었을 수도 있습니다. 소프트웨어 엔지니어링이 재미 있지 않습니까?

질문이 꽤 모호하기 때문에 나는 내 대답으로 조금 일반화 할 것입니다.

항상 그들에게 질문하지만 그들의 추론에 귀를 기울이십시오. 때로는 사람들은 기능의 실용성 또는 프로그래밍 시간이 얼마나 오래 걸리는지 잊어 버립니다. 반면에, 우리는 때때로 효율적이거나 프릴이없는 등의 프로그래머 정신에 갇히게되고, 프로젝트에 필수적이지 않은 것으로 간주하는 것이 실제로는 클라이언트에게 해당되지 않는다는 것을 잊어 버립니다.

그들이 정당한 이유가 있다면, 프로그램을 작성하는 데 걸리는 시간과 구현하는 동안 발생할 수있는 모든 충돌을 알려주고 계속 진행할 것인지 확인하십시오. 그렇지 않다면, 그것이 좋은 생각이라고 생각하지 않는 이유를 설명하고 그들의 반응이 무엇인지보십시오. 헹구고 반복하십시오.

대부분은 이미 언급되었지만 현재 작업 환경에서 강조해야 할 것이 있습니다. 나는 다른 회사의 계약자 인 회사에서 일하고 있으며 응용 프로그램은 비즈니스 프로세스와 관련이 있습니다 (판매 및 고객 커뮤니케이션을 공정하게 유도합니다).

함께 제공되는 제품과 함께 비즈니스 프로세스는 (적어도 회사가 충분히 큰 경우) 매우 복잡 할 수 있습니다. 어느 정도 복잡한 것을 모델링하는 경우 결과 응용 프로그램에는 관련 복잡성이 있습니다. 대부분의 비즈니스 직원은 프로세스의 일부만 볼 수 있기 때문에 전체 응용 프로그램 / 프로세스는 한 명의 사용자 만 볼 수있는 것보다 훨씬 더 복잡합니다.

필자의 요점은 새로운 비즈니스 요구 사항이 발생하면 복잡성을 훨씬 높이 지 않지만 전체 시스템에 더 큰 영향을 줄 수 있기 때문에 비즈니스 사람들에게 효과적이라고 생각합니다. 제 생각에는 이것이 그 변화에 반대하는 이유는 아닙니다. 노력과 비용을 고객과 논의하는 것이 올바른 시점입니다. 고객이 해당 기능을 구축하는 것을 막을 수는 없지만 시간이지나면서 애플리케이션에 대한 느낌과 "어, 너무 비싸다!" 덜 까다로울 것입니다.

나는 당신이 비교 가능한 상황에 있는지 알지 못하지만 이해 관계자의 상황이 IT 시스템의 개발자와 건축가가 직면하는 상황과 똑같이 복잡성이 높아지는 것은 아니라는 것을 알게되었습니다. 그러한 상황에서 의사 소통은 양쪽에 도움이됩니다.

실례 합니다만,이 질문은 아버지의 조언을 요구하는 작은 것 같습니다. 이 경우에 좋은 개발자는 다음 계명을 받아 들여야합니다.

• 자신에게 충실하십시오. 장이 기능에 대해 불안하다고 느끼면 우려 사항을 청각 적으로 말하십시오. 팀이 개막을 기다리고있을 가능성이 높습니다.
• 경험의 경험 규칙으로 경험을 대체하려고 시도하지 마십시오. 모든 상황이 다르고 모든 기능이 새로운 것입니다. 이것은 당신의 연장자에게없는 플러스입니다.
• 소프트웨어 개발은 ​​정확한 과학이 아니며 결코 그렇지 않습니다. 그러므로 행동이 아니라 지혜를 축적하십시오.
• 패배를 받아들입니다. 팀이 달리 동의하면, 구역질 문제를 반복하지 마십시오.
• 긍정적으로 생각하십시오. 아이디어가 실제로 '해결하기'를 간청하고 있다면, 결함을 나열하기 전에 긍정적 인 측면을 찾아서 이름을 지정하십시오.
• 사람들과 교류하는 법을 배웁니다. 우리 개발자들은 종종 사회적 역량에 대한 기술 지식을 배치합니다. 기술 능력은 초기에 정점에 달하지만, 은퇴 할 때까지 사회적 역량은 계속 커질 수 있습니다.

나는 나쁜 요구 사항을 철회한다고 생각합니다. 그러나 나는 또한 그들이 왜 나쁜지 설명하고 그들이 여전히 원하는 것을 설명하는 데 최선의 기회를 주었을 때, 당신은 동의하고 일을한다고 믿습니다.

예를 들어, 응용 프로그램이 이미 수행 한 작업과 상호 배타적 인 요구 사항을 원하는 사람들이 있습니다. 내가 그렇게하면 100 % 보장 될 것입니다. 따라서 요구 사항을 다시 보내서 이미 적용한 다른 비즈니스 규칙을 위반할 것이므로이 규칙도 변경하고 싶습니까? 특정 요구 사항을 제시하는 소규모 그룹은 종종 나머지 응용 프로그램의 기능에 대한 더 큰 그림에 액세스하지 못합니다. 내가이 중 하나를 돌려 보낸 대부분의 시간에 고객은 초기 규칙이 더 중요하다는 것을 깨달았으며 원하는 변경이 그만한 가치가 없다고 결정했습니다. 그들이 변경하기로 결정했을 때, 그들은 초기 요구 사항을 추진 한 사람들과상의 한 후에 변경했습니다.

때로는 명확한 질문을하는 것만으로도 문제가 생각했던 것처럼 간단하지 않다는 것을 알게 될 것입니다. 때때로 당신은 왜 그들이 무언가를 원하는지 물어보고 변화를 이끌고있는 실제 필요에 이르게합니다. 일단 당신이 그것을 이해하면, 개발자로서 당신을 위해 작동하고 그들의 요구를 충족시키는 대체 솔루션을 더 쉽게 볼 수 있습니다. 원래 제안보다 요구 사항을 더 잘 충족시키는 방법으로 해당 솔루션을 제시 할 수 있다면 변경 승인 가능성이 크게 향상되었습니다.

때로는 변경 사항이 설계의 기본 수준에서 혼란을 초래할 때 변경에 걸리는 새로운 시간을 알려주는 것만으로는 충분하지 않습니다. 새로운 버그를 도입 할 수있는 중요한 기능을 지적하는 위험 평가와이를 3 명에 의한 6 주간의 헌신적 인 노력이 필요하다는 점을 지적하면 갑자기 더 이상 중요하지 않습니다.

그러나 때때로 당신은 그들에게 이것이 좋은 생각이 아니며 왜 "우리가 그것을 필요로하는지 너무 나쁘다"고 말합니다. 당신은 일부를 이기고 당신은 일부를 잃고 때로는 비즈니스 요구가 진정으로 변경되어 응용 프로그램이 그것을 수용해야합니다. 결정이 완료되면 더 이상 당신이하고있는 일에 의문을 제기 할 시간이 아니며 결정을 내릴 시간이 아닙니다. 이의 제기를 문서화 한 경우 예산이 초과되어 새롭고 흥미로운 버그가 발생할 때 개인적으로 여전히 좋은 위치에 있어야합니다. 그리고 다음에 이런 종류의 일에 옳은 일을 한 기록을 세웠을 때 그들은 더 기꺼이 당신의 말을 들어 줄 것입니다.

이 토론에서 많은 사람들이이기는 열쇠는 (아무도이기는 사람이 없음) 먼저 이야기하고있는 것을 아는 기록을 세우는 것입니다. 그런 다음 자신이 갖고있는 우려 사항을 설명하는 서면 문서를 보내십시오 (많은 관리자가 위험에 불리하며 나중에 누군가를 잘못 입증하는 문서를 갖고 싶어하지 않을 가능성이 높기 때문에 서면으로 작성한 것에 더주의를 기울이십시오). 변경에 소요되는 모든 비용 (시간뿐만 아니라 보안 위험, 새로운 버그 도입, 마감 기한 등)을 이해하도록합니다. 변화는 자유롭지 않으며이를 이해해야합니다. 다음 열쇠는 성인처럼 행동하고 호기심 많은 아이들은 좋아하지 않는 것입니다 ( "나는 그것을 좋아하지 않기 때문에 ... 그렇지 않으면 비즈니스 사례를 작성하면 나쁜 요구 사항을 더 많이 철회 할 수 있습니다.

내가 당신을 올바르게 읽으면 실제 질문은 알 수없는 복잡성에 관한 것입니다. 처음에 나는 "과도한 복잡성의 가능성이 매우 높지만 사장은 그렇지 않다"는 질문을 읽었지만, 사장님은 문제가 아니기 때문에 어떤 위험이 있는지 잘 모르겠습니다. 용납 할 수없는 복잡성을 추가하는 것입니다.

이 경우 일종의 위험 완화 전략을 추천합니다. WCF / 웹 서비스를 API에 추가하는 것을 고려중인 이미지. 보상 없이는 대단하거나 복잡 할 수 있습니다.

• 지점에 기능을 추가하십시오. 작동하면 병합하십시오. 쥐 둥지로 변하면 죽여라.
• 새로운 한 페이지 프로젝트를 시작하고 개념 증명을 수행하십시오. 짧은 시간 내에 개념 증명을 수행 할 수 없으면 삭제하십시오. 개념 증명이 작동하면 더 크게 만들어서
• 해당 기능이나 기술에 관심이있는 사람들을 위해 웹을 검색하십시오. 많은 어려움이있는 곳에서 기술은 지나치게 복잡한 위험을 초래할 수 있습니다. Java Beans와 COM +는 아마도 오래되었지만, 실제로 복잡성을 증가 시켰으며 방정식의 이점 측면에서 제공되거나 제공되지 않을 수있는 기능의 좋은 예일 것입니다.

아니에요 그렇습니다. 그러나 이는 사양에 추가 된 것으로 취급되어야하며 다른 기능에 우선 순위를 두어야합니다. 요청에 구현하기 위해 부당한 시간과 복잡성이 추가 될 것임을 알고 있다면이를 미리 설명하십시오. 요청을 수행하는 데 반대하는 것이 아니라 구현하는 데 필요한 것에 대한 설명과 같습니다.

요청에 크게 의존합니다. 포인터 구현은 전체 프로젝트에 영향을 줄만큼 충분히 크므로 선택시 장점을 평가해야합니다.

흐름을 방해하는 버튼을 구현합니다. 버튼이 선택적인 방식으로 양식을 배치 할 수 있다면 그렇게 큰 문제는 아닙니다. 나는 실제로이 일을했습니다. 버튼을 추가했지만 버튼이 선택 사항이되기 전에 충분한 정보를 수집했습니다. 거기에있을 것으로 예상 한 사용자와 그것을 중복으로 인식 한 사용자는 사용하지 않았습니다.

균형을 유지하고 언제 전투를 선택할지 아는 것이 중요합니다. 어쨌든 구현하지 않는 것의 사회적 측면을 다루는 것보다 구현하기가 더 쉽습니다.

내가 보는 문제는 당신이 단어를 사용하는 것입니다.

디자인 문제와 그에 대한 추론을 제기해야하지만 프로그래머는 자신이 취한 입장에 대해 방어적인 태도를 취하고 논쟁을 위해 포인트를 주장하는 경향이 있기 때문에 조심해야합니다 (때로는). 나는 꽤 많은 논쟁을하지 말아야한다. 항상 성공하는 것은 아니다. 또한 나이가 들어감에 따라 예전보다 더 자주 틀렸다는 것을 알게됩니다.

요구 사항을 명확하게 언급 한 경우 (언어는 안전해야하며 레거시 루틴에 액세스하려면 포인터가 필요합니다) 두 요구 사항이 어떻게 충돌하는지 제시하고 어느 것이 더 중요한지 물어볼 수 있습니다. 요구 사항과 그 이유가 있으면 두 가지 요구 사항 (JNI--kinda)을 모두 지원하는 완전히 다른 솔루션을 제안 할 수도 있습니다.

그렇지 않다면, 아마도 그것들을 체계화하기에 좋은 시간입니다!

1. 모든 것을 알지 못하고 모든 것을 할 수는 없다는 것을 깨달으십시오.

2. 그것이 나쁜 생각이라고 확신한다면, 나쁜 것을 말하십시오.

3. 그들이 당신을 강요하려한다면, 분석 시간이 더 필요하거나, 더 많은 시간이 필요하거나 우리가이 문제에 대한 좋은 해결책을 찾지 못했다고 말하십시오.

4. 그래도 잘못된 아이디어를 구현해야한다고 주장하는 경우 이유를 포함하여 이에 대해 조언했음을 알리십시오. 토론 내용을 요약 한 이메일을 관리자에게 사본으로 보낼 수도 있습니다. 이렇게하면 나중에 a **를 절약 할 수 있습니다.

이상적인 시나리오에서는 기술 측면에서 최종 결정을 내리는 수석 개발자와 비즈니스 측면에서 최종 결정을 내리는 비즈니스 리더가 있습니다. 이것은 두 가지 주요 질문에 대한 답변입니다.

1) 무엇? 고객이 원하는 것은 무엇입니까?

2) 어떻게? 기술적 인 관점에서 어떻게 이것을 달성 할 수 있습니까?

고객이 원하는 것은 청구서를 지불하는 사람이기 때문에 최고의 의사 결정자입니다.

개발자는 구현 요구 사항을 실제로 신경 쓰지 않아도됩니다.

그러나 어떤 것이 비현실적이고 더 나은 방법이 있는지 설명해야합니다.

때때로 실제 고객 요청 (고객 내부 정치에서 발생). 그런 다음 희망이없고 행해져 야합니다 (그러나 경영진은 그러한 프로젝트를 계속할 것인지 또는 가격을 재협상 할 것인지도 고려해야합니다).

이것은 거의 매일의 작업이며 실제로 기쁩니다.

특정 요구 사항이 응용 프로그램의 일부 여야하는지 여부에 대한 의견을 제공하기 위해 변경 한 경우, 기술이 아닌 사람은 기술 지식을 채워야합니다 (예 : "포인터를 사용하면 응용 프로그램이 불안정해질 수 있습니다"또는 "사용 중" X 목적을위한 GET 매개 변수는 보안 위험입니다 "). 기술 담당자는 생각하지 못한 특정 장점이나 단점에 대한 귀하의 의견에 감사드립니다.

물론 모든 사람들이 기능 X를 원하고 "좋지 않을 수 있습니다"라고 말하면 결국 가혹하지만 결국 모든 사람들이 안전하고 강력하며 안정적인 응용 프로그램 (유지 가능하고 유연한 등)을 만들려고합니다. ) 및 모든 음성을 계산해야합니다.

귀하의 질문에 답변하는 것은 개발자의 직무 (개발)의 일부가 아니지만 품질과 팀워크를 제공하는 "추가"입니다.

당신이 그것을하는 단점 (복잡성, 유용성 등)을 이해할 수있는 입장에 있다면, 당신이 그것을 최선을 다해 설명하는 것이 모든 사람의 최선의 이익입니다. 종종 개발자가 아닌 사람들은 새로운 기능을 추가하는 문제를 이해하지 못합니다. 그들은 아무것도하거나 생각할 필요가 없기 때문에 쉽습니다.

그러나 새 기능을 추가하기로 결정한 권한이 있으면 가능한 한 최선을 다해야합니다. 도전입니다.

그리고 새로운 기능이 너무 어리 석거나 작업 환경이 너무 까다로워지면 다른 직업을 찾을 때입니다.