프로젝트에서 Java 개발자의 일반적인 작업

Java 개발자의 일반적인 책임은 무엇입니까? 결국, 당신은 당신이 무엇을 하려고 하는지, 그리고 결국 무엇을 하게 될 것인지 이해해야 합니다. 그렇죠? 오늘 저는 Java 개발자가 수행하는 10가지 주요 작업에 대해 이야기하고 싶습니다. 하지만 먼저 Jira와 같은 도구에 대해 알아봅시다. 아니면 이미 익숙하다면 기억을 새롭게 해보자. Jira 는 사용자 상호 작용 도구이지만 경우에 따라 프로젝트 관리에도 사용됩니다. 즉, 프로젝트 개발은 이 도구에 설명된 작은 작업으로 분류됩니다. 이러한 작업은 구현을 담당할 개발자에게 할당(할당)됩니다. 작업이란 예를 들어 일부 기능을 추가하는 것을 의미합니다. 진행이 진행됨에 따라 개발자와 기타 전문가는 누가 무엇을 했는지, 얼마나 많은 시간을 소비했는지에 대한 설명을 추가하고 시간을 추적합니다. 이는 소비된 시간을 추적하기 위해 수행됩니다. 즉, 소비된 금액과 내용을 추적합니다. 이상적으로는 하루에 한 번 수행됩니다. 떠나기 전 저녁에 8시간 동안 수행한 작업을 추적합니다. Jira의 기능은 위에서 설명한 것보다 훨씬 광범위하지만 초기 이해에는 이것만으로도 충분합니다. 그렇다면 Java 개발자의 책임은 무엇입니까?

1. 새로운 솔루션 개발

뭔가를 만들고 구현하기 전에 먼저 생각해내야겠죠? 앞서 말했듯이 이는 단지 Jira 작업 이 귀하에게 할당될 수 있으며, 귀하는 Jira에서 얼마나 많은 시간을, 무엇에 소비했는지 기록하면서 새로운 솔루션을 개발하기 위해 노력하게 될 것입니다. 이는 그룹 팀 통화에 대한 토론일 수도 있습니다. 모든 사람이 자신의 의견을 표현하고 가장 좋다고 생각하는 접근 방식을 제안할 수 있습니다. 그리고 여기에서 몇 가지 사항을 언급하고 싶습니다. 첫째, 개발자 직업은 표준 도구를 사용하여 문제를 해결하는 독특한 방법을 고안해야 하기 때문에 매우 창의적인 분야입니다. 종종 하나의 문제는 다양한 해결책을 가질 수 있습니다. 따라서 모든 것은 개발자의 "창의력", 축적된 지식 기반 및 경험에 달려 있습니다. 여기에서 모든 창의성과 천재성을 보여줄 수 있지만 가장 중요한 것은 그것을 과도하게 사용하지 않는 것입니다. 이 경우 코드가 너무 복잡하고 읽을 수 없게 되어 결과적으로 떠난 후에는 코드가 무엇인지 완전히 이해하지 못할 것입니다. 그것이 어떻게 작동하는지. 그리고 모든 것을 처음부터 다시 작성해야 합니다. 그리고 그들은 당신을 기억할 수도 있습니다. 그리고 한 번 이상. 그리고 이것은 따뜻하고 친절한 말이 아닐 것입니다. 당신은 그것을 필요로합니까? 둘째, 개발자는 하나의 솔루션에 갇히거나 다른 솔루션에 폐쇄되어서는 안 된다는 점에서 유연성이 있어야 합니다. 예를 들어, 이 방법으로만 수행하면 되고 다른 방법은 필요하지 않습니다. 이는 여러 가지 이유로 발생할 수 있습니다. 예를 들어, 자신의 관점을 증명하고 싶거나 이미 솔루션을 개발하고 구현했지만 애착을 갖고 있으며 물론 그것이 자신의 관점이 아니라는 점을 인정하고 싶지 않은 경우 등이 있습니다. 최상의. 이것은 당신을 거의 눈 멀게 할 수 있습니다. 실제로, 몇 주 동안 작성해 왔고 매우 자랑스러워하는 기능을 제거해야 하더라도 실수를 인정하고 항상 새로운 것에 열려 있어야 합니다(“개방적”). Jira에서 누군가의 시간 추적을 통해 하루 종일 기분이 결정된 적이 있는 것을 기억합니다. “사산 기능을 삭제했습니다. 나는 울었다”

2. 새로운 기능 작성

이는 이전 단계, 즉 새로운 기능 구현을 따르는 논리적 단계입니다. 프로젝트의 모든 작업은 개발자가 작업하면서 받는 Jira의 작업으로 나누어집니다. 이 문제에 대한 다양한 접근 방식이 있습니다. "방법론"에 대한 자세한 내용은 JavaRush의 이 기사에서 읽을 수 있습니다 . 일반적으로 작업에는 완료에 소요되는 예상 시간인 "추정" 이 있습니다. 작업을 수행할 때 직접 설정하거나 팀 리더가 설정하거나 계획 중에 개발자가 함께 추정합니다. 다양한 요인이 발달에 영향을 미치기 때문에 이번에는 정확하게 추측하는 경우가 거의 없습니다. 예를 들어, 프로그래머가 이 기술에 익숙한지 또는 익숙하지 않은지, 그의 일반적인 경험은 무엇인지, 개발 중에 이미 눈에 띄게 나타날 수 있는 다양한 함정 등이 있습니다. 따라서 기능을 개발할 때 이 기한을 지키지 않으면 나쁜 일은 일어나지 않을 것입니다. 이는 단지 일반적인 추정치일 뿐입니다. 그러나 다시 말하지만 모든 프로젝트에 작업 견적이 있는 것은 아니며 저에게는 그것 없이 사는 것이 훨씬 더 쉽습니다. 특히 PM이 하루에 두 번씩 "예산은 어디에 있습니까? "라는 질문으로 당신을 옆으로 찌르지 않을 때 더욱 그렇습니다. ” 따라서 작업을 수행하고, 필요한 기능을 개발하고, 이를 GIT 의 공통 브랜치에 업로드 하고, Jira에서 작업 상태를 "검토 준비 완료" 로 변경합니다 . 즉, 보기(확인) 준비가 되었다고 기도합니다. 개정에 대한 의견과 함께 귀하에게 반환되지 않습니다.

3. 기능 테스트 작성

귀하의 코드를 검사하는 사람(검토자)은 귀하가 개발한 기능을 좋아했지만 질문이 있습니다. 이에 대한 테스트는 어디에 있습니까? 그리고 그는 수정을 위해 작업을 귀하에게 반환합니다. 테스트는 모든 Java 애플리케이션의 중요한 부분입니다. 이를 실행하면 애플리케이션이 잘못 작동하는 위치를 즉시 파악할 수 있습니다. 예를 들어, 개발자가 시스템의 한 부분을 일부 변경하여 다른 부분의 동작이 변경되었지만 개발 중에 이를 알아차리지 못했습니다. 테스트를 실행하면 실패한(올바르게 작동하지 않은 테스트) 테스트를 볼 수 있습니다. 이는 시스템의 다른 부분에서 문제가 발생했음을 알려줍니다. 따라서 그는 서버에 주요 변경 사항을 업로드하지 않고 계속해서 솔루션을 개선할 것입니다. 물론 테스트를 좋아하는 개발자는 거의 없지만 테스트가 애플리케이션에 가져오는 이점은 부정할 수 없습니다. 종종 클라이언트는 준수할 테스트 적용 범위 수준(예: 80%)을 지정합니다. 따라서 다양한 유형의 테스트를 알고 작성할 수 있어야 합니다. Java 개발자는 주로 단위 테스트와 통합 테스트를 작성하는 반면 AQA(자동화 테스터)는 보다 광범위한(종단 간) 테스트를 처리합니다. 내 리뷰에서 그들과 IT 전문가의 다른 대표자에 대해 자세히 읽을 수 있습니다 .

4. 버그 발견 및 수정

이는 Java 개발자에게 매우 일반적이고 빈번한 작업이기도 합니다. QA와 AQA의 주요 임무는 버그를 잡는 것입니다. 즉, 프로그램이 잘못 작동하는 곳을 찾아 Jira에서 문제를 만들고 누군가를 비난합니다. 예를 들어 팀장은 시스템의 이 부분에 대한 부하와 친숙도에 따라 이를 할당할 개발자를 결정합니다. 그 후 개발자는 버그를 검색하고 디버거 에서 몇 시간을 보내고 QA 전문가의 문제 설명을 사용하여 버그가 발생한 상황을 반복합니다. 다음으로 개발자는 버그를 찾아 수정한 후 검토를 위해 보냅니다. 글쎄, 개발자가 버그를 재현하지 못했을 가능성이 있으며 이에 대한 설명과 함께 작업을 QA 전문가에게 반환합니다. 버그를 찾아서 고치는 데는 그리 오랜 시간이 걸리지 않을 것 같지만, 약간의 뉘앙스가 있습니다. 모든 것은 주로 이 코드 섹션에 대한 개발자의 친숙함, 이론적 문제에 대한 경험 및 지식에 달려 있습니다. 버그를 발견하고 수정하는 데 20분 밖에 걸리지 않는 경우도 있고, 3일이 걸리는 경우도 있습니다. 따라서 이러한 유형의 작업은 개발자가 설명을 읽은 후 무엇이, 어디서, 무엇이 잘못되었는지 즉시 이해하지 않는 한 사전에 평가하기가 특히 어렵습니다. 이 경우 그는 시간을 다소 정확하게 추측할 수 있습니다.

5. 코드 검토

위에서 언급했듯이 작업을 완료하자마자 검토를 위해 보내야 하며, 통과하면 일반 스레드로 이동하고, 그렇지 않으면 필요한 사항에 대한 설명과 함께 개발자에게 반환됩니다. 수정. 이 모든 것은 더 높은 권한이 아니라 다른 개발자가 확인한다는 것이 분명합니다. 그러나 모든 개발자가 리뷰어가 될 수 있는 것은 아니며, 경험이 풍부하고 좋은 코드와 나쁜 코드를 구별할 수 있는 경험이 풍부한 개발자만이 리뷰어가 될 수 있습니다. 코드 검토는 일반적으로 Crucible과 같은 보조 도구를 사용하여 수행됩니다 . 검토자는 코드를 검토하고 필요한 경우 일부 줄 아래에 주석을 남깁니다. 댓글의 유형도 다양할 수 있습니다. 예를 들어 수정 없이 검토자가 코드를 통과하지 못하는 중요한 항목과 개발자가 듣고, 기록하거나 무시할 수 있는 선택한 접근 방식에 대한 설명일 가능성이 더 높은 항목도 있습니다. 팀은 검토 수행을 위한 자체 절차와 규칙을 만들고, 주의할 가치가 있는 것과 그렇지 않은 것에 동의할 수 있으며, 코드 검토를 수행해야 하는 기간 등에 대해 동의할 수 있습니다. 리뷰를 수행하려면 경험만으로는 충분하지 않습니다. 기술적인 방향으로 많은 것을 개발해야 하고, 다양한 책(예: "클린 코드" )을 읽어야 합니다. Google에 따른 코드 검토 수행의 미묘한 차이에 관심이 있다면 이 기사를 읽어 보시기 바랍니다 .

6. 코드 분석

프로젝트는 서로 다르게 생각하는 여러 사람이 동시에 작성하므로 코드와 접근 방식도 다를 것입니다. 그리고 시간이 지남에 따라 모든 것이 점차 흐려질 것입니다. 코드를 개선하기 위해 때로는 특정 모듈이나 전체 애플리케이션을 분석하여 결함을 찾아 플래그를 지정하고 나중에 이러한 설명을 기반으로 리팩터링 작업을 생성하는 작업을 생성합니다. 분석은 개발 초기에는 보이지 않았지만 지금은 볼 수 있는 더 간단한 지름길이 있는 상황에서도 도움이 됩니다. 예를 들어 일부 메서드에서는 동일한 논리가 반복되는 경우가 많으므로 별도의 메서드로 옮겨 여러 번 재사용할 수 있습니다. 글쎄요, 일부 클래스가 고통스러울 정도로 비대해졌거나, 일부 코드가 유지 관리하기 어렵거나 구식이 되었거나... 분석 작업은 코드와 애플리케이션의 품질을 향상시키는 데 도움이 됩니다. 내 생각에는 많은 양의 코드를 분석하는 것은 지루한 작업일 수 있습니다.

7. 코드 리팩토링

분석의 다음 부분은 코드 리팩토링입니다. 오래되었거나, 더 이상 필요하지 않거나, 제대로 작성되지 않았거나, 읽기 어려울 수 있습니다. 항상 완벽함(존재하지 않더라도)과 최신 코드를 위해 노력해야 하며 불필요한 모든 것을 제거해야 합니다. 이는 기능의 본질을 혼란스럽게 하고 볼 수 없게 하기 때문입니다. 프로젝트 초기에는 이러한 작업을 볼 가능성이 거의 없다는 것은 말할 필요도 없습니다. 이러한 작업은 애플리케이션이 다듬어지고 완벽해졌을 때 개발의 후반 단계에서만 발생합니다. 여기에서는 동료들과 어떻게 이를 수행할 것인지, 어떤 함정이 있는지에 대해 상의하는 것이 적절할 수 있습니다. 이러한 작업의 본질은 새로운 기능의 개발과 유사합니다. 예를 들어 동작을 변경하지 않고 일부 기능을 편집하는 작업을 받습니다. 이렇게 하려면 이전 항목을 삭제하고 직접 작성한 다음 테스트를 확인하세요. 모든 작업을 올바르게 수행했다면 테스트를 변경하지 않고도 이전처럼 작동할 것입니다. 모든 것이 코드에 정착되면 검토를 위해 보내고 커피를 마시러 갑니다.))

8. 문서 작성

당신이 오랫동안 개발되어 온 일부 프로젝트의 새로운 개발자라고 상상해 보십시오. 이에 익숙해지거나 버그 잡기와 같은 특정 작업을 수행해야 합니다. 프로젝트를 어떻게 탐색할 것인가? 5분마다 팀원을 끌어당기나요? 바쁘거나 주말이면 어떻게 되나요? 이것이 문서가 존재하는 이유입니다. 기능에 익숙하지 않은 사람이 들어가서 올바른 페이지를 찾고 관심 있는 애플리케이션 부분이 무엇인지 빠르게 이해할 수 있도록 하기 위한 것입니다. 하지만 누군가는 문서를 작성해야 합니다 ^^ 프로젝트에 개발자가 지원해야 하는 문서가 있는 경우 새로운 기능을 구현할 때 이를 설명하고 다양한 변경 및 리팩토링을 통해 문서를 업데이트합니다. 문서 작성, 지원 및 제어를 위해 별도의 전문가, 즉 기술 문서 작성자를 고용하는 경우도 가능합니다. 이런 전문가가 존재한다면 일반 개발자의 삶이 조금은 편해집니다.

9. 각종 집회 참여

개발자들은 다양한 회의와 협상, 기획에 많은 시간을 소비합니다. 가장 간단한 예는 어제 무엇을 했고, 오늘 무엇을 할 것인지를 말해야 하는 '일일 회의'(매일 회의)입니다. 또한 예를 들어 QA 전문가와 일대일 통화를 해야 버그 재현의 뉘앙스를 보여/설명하거나 비즈니스 분석가 또는 조직과 뉘앙스와 요구 사항에 대해 논의할 수 있습니다. PM과 관련된 문제. 그러므로 개발자는 고독을 선호하는 내성적인 사람일지라도 여전히 다른 사람들과 공통 언어를 찾을 수 있어야 합니다(글쎄, 적어도 조금은). 개발자의 순위가 높을수록 의사소통에 더 많은 시간이 필요하고 코드 작성에 소요되는 시간은 줄어듭니다. 개발자 팀 리더는 작업 시간의 절반 이상을 대화와 회의에 소비하고 코드 작성 빈도를 줄일 수도 있습니다(이로 인해 약간의 이해력이 상실될 수 있음). 하지만 당신도 대화를 좋아하는 사람이라면 팀장에서 관리직으로 쉽게 발전할 수 있고 코드에 대해 완전히 잊어버리고 다양한 팀, 고객, 다른 관리자들과 하루 종일 소통할 수 있습니다.

10. 면접 실시/합격

아웃소싱이나 아웃스태프 회사에 근무하는 경우 고객에게 "판매"되어야 하는 경우에는 외부 인터뷰를 자주 거쳐야 하며(그러면 고객 측 담당자와 인터뷰를 할 수도 있음) 내부 인터뷰를 거쳐야 합니다. 회사 내에서 순위를 높이십시오. 잦은 인터뷰로 인해 지식이 항상 모양을 갖춰야하기 때문에 이것이 개발을위한 좋은 요소라고 부르고 싶습니다. IT에서 휴식을 취하면 현장에서 완전히 날아갈 수 있기 때문에 녹슬거나 긴장을 풀지 않을 것입니다. 좀 더 경험이 많은 개발자가 되면 합격이 아닌 인터뷰를 진행하는 반대편을 방문할 수 있게 됩니다. 저를 믿으세요. 이런 관점에서 보면 매우 놀랄 것입니다. 왜냐하면 인터뷰를 하는 것이 합격보다 더 무서울 수 있기 때문입니다. 자신만의 면접 전략과 질문 목록이 있어야 하며, 필요한 모든 주제에 대해 한 시간 안에 질문할 수 있는 시간이 필요합니다. 그 후에는 피드백에 대한 책임이 있습니다. 피드백에 의존하면 오랫동안 기다려온 제안이나 프로모션을 받을 수도 있고 받지 못할 수도 있기 때문입니다. 글쎄요, 그 반대도 마찬가지입니다. 그가 해당하지 않는 직위에 대해 솔직히 약한 후보자를 놓칠 수 있으며 그런 다음 질문을 받을 수 있습니다. 어떻게 그런 수준의 지식으로 그를 그리워 했습니까? 그러므로 면접을 볼 때, 상대방도 힘든 시간을 보내고 있고, 그 사람도 스트레스를 받고 있을 수 있다는 점을 염두에 두시기 바랍니다. 모든 면접은 지원자와 면접관 모두에게 스트레스가 됩니다. 아마도 우리는 여기서 끝날 것입니다. 읽어주신 모든 분들께 감사드립니다. Java를 좋아하고 배우세요 ^^