전혀 수행하지 않은 프로그래밍 작업에 직면했을 때 어떻게해야합니까?

저는 3 개월 전에 .NET 개발자로 경력을 시작했으며 다양한 기술, 패턴 및 개념에 대한 오랜 교육 계획을 수립 한 후 저를 감독하고있는 개발자가 회사가 처리하는 많은 프로젝트 중 하나에 참여할 준비가되었다고 결정했습니다.

마침내 코딩을 시작할 수있게되어 매우 기쁩니다. 내가 참여한 팀은 현재 새 프로젝트를 시작했기 때문에 규모가 작습니다. 프로젝트의 전체 수명주기에 참여하기 때문에 좋습니다. ASP.NET MVC / ASP.NET 웹 API를 사용하고 Durandal 프레임 워크 및 관련 라이브러리를 프론트 엔드로 지원하는 웹 기반 SPA 프로젝트입니다.

내 문제는 동료들과 회의를 갖고 다음 달에 과제와 추정을 정한 후에 나는 어떤 과제를 수행 할 수 있는지 알 수없는 입장에 있다는 것이다.

생성 된 작업을 수행 한 적이 없으며 진행 방법을 모르겠습니다.

예를 들어 생성 된 작업 중 하나는 전체 응용 프로그램에 대한 일반적인 오류 처리 메커니즘을 만드는 것입니다.

자신이 한 번도 해보지 못한 일에 직면했을 때 일반적으로 어떻게 진행됩니까?

작업을 준비하기 위해 할 수 있고해야 할 일이 몇 가지 있습니다.

• 문제에 대해 생각하고 다이어그램을 그리십시오. 해결하려는 문제가 무엇인지 알고 있어야합니다.
• 당신이하려는 일에 대해 조사하십시오. 인터넷은 유용한 정보원입니다. 나는 스택 오버플로 요청을 말하는 것이 아니라 다른 사람들이 이미 당신과 같은 문제를 해결하거나 접근 한 방법에 대해 조사한다고 말하고 있습니다. 구글이 생각 해낸 것 : "시스템 전반에 대한 예외 처리 예외" . 개인적으로 나는 항상 다른 사람들로부터 배우려고 노력합니다.
• 마지막으로, 이것이 가장 중요 할 수 있으며, 팀의 다른 사람들과 대화하여해야 할 일에 대한 설명과 지시를 더 많이 얻으십시오. 저는 항상 새로운 엔지니어들이 프로젝트에 대한 안내를 요청하기를 원합니다.

무언가를하는 방법을 모른다면 결코 끝나지 않을 것입니다. 나는 매일 한 번도 해본 적이없는 문제에 부딪칩니다. 새로운 문제를 해결하는 방법을 알아내는 능력이 매우 중요합니다. 오래된 문제조차도 완전히 오래된 것은 아닙니다. 프로그래밍에서 거의 항상 새로운 왜곡이나 솔루션이 새롭거나 다른 방식으로 작동하도록 요구합니다.

이것이 제가 엔지니어 인 이유입니다. 나는 새로운 것을 알아내는 것을 좋아합니다.

새로운 것을 배우지 마십시오. 학습은 당신을 더 나아지게합니다.

완벽한 해결책은 없지만 도움이 될만한 것들이 있습니다.

• 작업을 가능한 가장 작은 단위로 나누십시오. 할 수있는 일이 생길 때까지 나누십시오.

• 즉각적인 작업이나 문제를 다시 설명하여 실제로 이해하도록하십시오. 그런 다음 몇 가지 분석을 수행하고 반복하십시오.

• 운동량을 얻기 에는 너무 단순한 것처럼 보이지만 가장 간단한 작업을 먼저 선택하십시오 . 어떤 사람들은 가장 어려운 일을 선호하기 때문에 '열심히 일하는 것'이 방해가됩니다. 나는 '가장 간단한 작업'이 일반적으로 당신이 약간의 추진력을 얻으려고 노력할 때 더 잘 작동한다는 것을 알았고 나는 실제 모멘텀을 얻기 전에 '가장 어려운 것'이 프로젝트가 멈추는 것을 보았습니다.

• 올바른 작업을 선택하고 시작하는 방법에 대한 도움을 요청하십시오.

• 일주일 또는 2 주 동안 지속적으로 (이상적으로 매일) 피드백을 줄 수있는 멘토를 찾으십시오.

• 많은 질문을하지만 팀원에게 예의를 지키는 데 집중하십시오. 항상 시간이 있는지 물어보고, 시간이없는 일반적인 구두 및 비 언어 표시에주의하십시오.

• 발생하는 문제의 목록을 유지 한 다음 매일 스크럼 또는 정기적으로 원하는 시간에 다른 사람들과 함께 진행하십시오.

• 가장 기본적인 질문을 두려워하지 마십시오. 다른 사람들의 가정은 도전하기 어려울 수 있지만 주어진 것을 진행할 수 없다면 다시 질문해야합니다.

• 목표를 알고 있다면 멈출 때까지 최대한 많이 노력한 다음 진행률과 질문을 스택 오버플로에 게시하십시오.

물론 "일반 오류 메커니즘"을 작성하는 방법을 모릅니다. 어떤 요구 사항이 정의 될 때까지 아무도 "일반 오류 메커니즘"을 작성하는 방법을 모른다. 이 프로젝트를 시작하려면 "일반적인 오류 메커니즘"이 필요하다는 누군가의 생각 만있는 것 같습니다.

개인적으로, 나는이 개념을 철회 할 것입니다. 실제 사용자 요구 사항을 구현하기 전에 "일반적인"내용을 작성하는 것은 거의 항상 시간 낭비입니다. 그리고 그것은 일반적 이기 때문에 정의에 따라 회사 나 응용 프로그램에만 국한되지 않으므로 아마도 귀하의 요구의 약 95 %를 충족시킬 수있는 무언가가 이미있을 것입니다.

그러나 당신이 주니어 멤버이기 때문에, 뒤로 밀기는 좋은 생각이 아닐 수도 있습니다. 따라서 "일반적인 오류 메커니즘"이 필요하다고 생각하는 사람들과 이야기하고이 메커니즘이 어떤 서비스를 제공해야하는지 알아 내야합니다. 그런 다음 그물을 검색하여 이미 작성된 것이 충분할 수 있는지 확인하십시오. 무언가를 찾으면 간단히 사용하십시오. "일반적인 오류 메커니즘"을 요구하는 사람은 아마도 여기서 발명되지 않은 나쁜 경우로 고통 받고 있기 때문에 아마도 동의하지 않을 것입니다.

만약 실패한다면, 다음 단계는 오류 메커니즘에 대한 인터페이스를 정의하고 이해 당사자들의 승인을받는 것입니다. 그 후에는 구현이 쉽지 않을 것입니다.

=================

PS 어떤 프로젝트를 시작하는 방법은 "플랫폼"을 작성하여 애플리케이션 모듈에 필요한 모든 공통 서비스를 제공하는 것이라고 생각하는 프로그래머가 있습니다. 이것은 보통 무료로 쉽게 구할 수있는 물건을 재창조하는 몇 개월의 사소한 작업으로 나뉩니다. 사용 가능한 솔루션의 성능 한계에 도달 할 때까지 "플랫폼"서비스를 작성할 이유가 없습니다. 기존 API를 래퍼로 작성해야하는 이유도 없습니다. 계속 리팩토링하면 응용 프로그램에 필요한 정확한 래퍼가 마술처럼 나타납니다.

나는 당신이 기술력 부족보다 불안으로 더 고통 받고 있다고 생각합니다. 언젠가 모든 것이 새로운 것이 아니 었습니까? 당신은 작업을 받았으며 어느 정도까지 해결할 수 없었습니까? 당신은 물건을 알아 내야합니다.

팀 활용 -좋은 팀에 속해 있다면 도움을 요청할 수 있습니다. 가장 나이가 많은 사람조차 알지 못하는 것들이 있습니다. 도움을 요청하는 것은 약점의 징후가 아닙니다 (질문 사이트를 방문하는 것 이상).

검색 -일반적인 오류 처리에 대한 웹 검색에 아무것도 없었습니까? 전체 솔루션을 찾지 못할 수도 있습니다. 당신은 그것에 대해 작업하고 어쨌든 앱에 맞게 만들어야합니다.

프로토 타입 -프로덕션에서 프로토 타입으로 작업에 대한 관점을 변경하십시오. 거기에서 무언가를 만들고 구축하십시오. 당신이 그것을 사용할 수있는 시점에 도달하면 그것을 생산으로 생각하기 시작하십시오. 이제 작업을 시작 위치를 모르는 것으로 볼 수 없습니다.

극복하기 -자신이하는 일만하는 것은 지루할 것입니다. 또한 동일한 것을 반복해서 반복하여 일부 솔루션을 강제 실행하는 함정에 빠지게합니다 (반복하는 것을 좋아한다면 조립 라인에서 작업하십시오). 실수 할 준비를하십시오. 그들이 모든 것을 알고, 도움을 요청하거나 검색을하지 않는다고 말하는 사람들은 단지 거짓말입니다.

의사가 여전히 약을 "연습"하는 것에 대한 오래된 농담입니다. 그들은 모든 대답을 가지고 있지 않습니다.

백 번 전에 한 일을하지 않았다는 점에 기뻐하십시오. 당신은 소프트웨어 개발의 기쁨을 발견했습니다 (어쨌든, YMMV)-당신이 특별한 속도로 고속도로를 아프게하는 동안 운전하는 법을 배우십시오. 이것은 훌륭한 개발자가 선호하고 능가하는 것입니다.

내 개인적인 과정은 다음과 같습니다.

• 연구. 이 문제 또는 유사한 문제가 전에 어떻게 해결되었는지 알아보십시오. 다른 언어 나 플랫폼에 대한 솔루션에 대한 정보 만 찾을 수 있더라도 여전히 매우 유익 할 수 있습니다.
• 원형. 올바른 일을하는 가장 좋은 방법은 먼저 잘못하는 것입니다. 연구 결과에 따라 원하는대로 솔루션을 구축하십시오. 보조 요구 사항을 고려하여 주요 요구 사항을 준수하도록하십시오. 예쁘거나 완벽하거나 확장 가능하거나 유연하거나 성능을 향상시키는 데 신경 쓰지 말고 작동하십시오. 학습 한 내용, 작동 한 것, 그렇지 않은 것, 잠재적 장애물 등을 기록한 다음 코드를 버립니다. 너무 오래 걸리는 바보를 찾는 것이 걱정된다면 혼자서하십시오. 지식 측면에서 개인적으로 도움이됩니다.
• 디자인. 외부 지식 (연구)과 개인 지식 (배운 프로토 타입 학습)을 결합하고 올바른 방법이라고 생각하는 디자인을 공식화하십시오.
• 협력. 선임 팀원을 찾아 제안 된 디자인을 보여주고 피드백을받습니다. 다른 사람에게 보여주고 피드백을 받으세요. 디자인을 개선하십시오.
• 반복합니다. 여전히 솔루션을 잘 모를 경우 피어 리뷰가 반복주기의 일부인지 확인하십시오. 피드백을 위해 정기적으로 선임 팀원에게 구현을 가져 오십시오.
• 행복하십시오-당신은 당신의 지식과 경력을 발전 시켰으며 오래 전에 지루하고 지루한 일 대신에 새롭고 흥미로운 일을해야했습니다. 다음 프로젝트를 더 큰 도전으로 삼으십시오.

마지막으로 외모에 대해 너무 걱정하지 마십시오. 개발자 팀 관리자로서, 우리가 지금하고있는 한 가지 일을 이미 알고 있음을 증명할 수있는 사람보다 필요할 때 배울 내용을 배울 수 있다는 것을 증명할 수있는 사람이 필요합니다. 전자는 우리가 내일, 다음 달 또는 내년에하는 일에 더 유용 할 것입니다.