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

Java 개발자의 일반적인 책임은 무엇입니까? 결국, 당신은 당신이 무엇을 하고 있는지, 그리고 당신이 무엇을 하게 될 것인지를 이해해야 합니다, 그렇죠? 오늘 저는 Java 개발자가 수행하는 10가지 필수 작업에 대해 이야기하고자 합니다. 하지만 먼저 Jira라는 도구에 대해 알아봅시다. 또는 이미 익숙하다면 기억을 되살리십시오. 지라는 인간 상호 작용을 구성하는 도구이지만 경우에 따라 프로젝트 관리에도 사용됩니다. 즉, 프로젝트는 이 도구에서 설명하는 작은 작업으로 나뉩니다. 이러한 작업은 구현을 담당하는 개발자에게 할당됩니다. 예를 들어 작업은 일부 기능을 추가하는 것일 수 있습니다. 작업이 수행되면 개발자와 다른 전문가는 누가 무엇을 했고 얼마나 많은 시간을 소비했는지에 대한 설명을 추가합니다. 이것은 어떤 작업에 얼마나 많은 시간이 소요되었는지 알기 위해 시간 추적 목적으로 수행됩니다. 이상적으로는 하루에 한 번 수행됩니다. 저녁에 책상을 떠나기 전에 8시간 중 다양한 작업에 소비한 시간을 표시합니다. 위에서 설명한 것보다 Jira의 기능에 훨씬 더 많은 기능이 있지만 초기 이해에는 이 정도면 충분합니다.

1. 새로운 솔루션 설계

무언가를 만들고 구현하기 전에 개념화를 해야겠죠? 이전에 말했듯이 이것은 단순히 Jira에서 할당된 작업일 수 있으므로 새로운 솔루션을 설계하기 위해 작업하고 소요 시간과 시간을 Jira에 기록합니다. 이 작업은 팀 전화 회의에서 토론하는 동안에도 발생할 수 있습니다. 모든 사람이 자신의 의견을 표현하고 가장 좋다고 생각하는 접근 방식을 제안할 수 있습니다. 그리고 여기서 몇 가지 사항에 주목하고 싶습니다. 첫째, 소프트웨어 개발은 ​​매우 창의적인 직업입니다. 표준 도구를 사용하여 새로운 문제 해결 방법을 찾아야 하기 때문입니다. 하나의 작업에 여러 솔루션이 있을 수 있습니다. 따라서 모든 것은 개발자의 창의성에 달려 있으며, 이는 축적된 지식과 경험의 영향을 많이 받습니다. 여기에서 모든 창의력과 천재성을 과시할 수 있습니다. 그러나 중요한 것은 과용하지 않는 것입니다. 그렇게 하면 코드가 너무 복잡해지고 읽을 수 없게 됩니다. 결과적으로 당신이 떠난 후에는 아무도 당신이 코딩한 것과 그것이 어떻게 작동하는지 완전히 이해하지 못할 것입니다. 그리고 그들은 모든 것을 처음부터 다시 작성해야 할 것입니다. 그리고 그들은 당신에 대해 기억할 수 있습니다. 한 번 이상. 그리고 따뜻하고 친절한 말이 나올 것 같지 않습니다. 그게 필요하세요? 둘째, 개발자는 하나의 솔루션에 집착하여 다른 사람에게 폐쇄적인 태도를 취해서는 안 된다는 점에서 심리적 유연성을 유지해야 합니다. 마치 한 가지 방법으로만 무언가를 해야 하고 다른 옵션이 없는 것처럼. 여러 가지 이유로 이 함정에 빠질 수 있습니다. 예를 들어, 당신의 관점이 옳다는 것을 증명하고 싶다고 가정해 봅시다. 또는 이미 친숙한 솔루션을 설계하고 구현했을 수도 있습니다. 물론, 당신은 그것이 최고가 아니라는 것을 인정하고 싶지 않을 것입니다. 이러한 상황은 상당히 눈이 멀게 만들 수 있습니다. 실제로 자신의 실수를 인정하고 항상 열린 마음을 가질 수 있어야 합니다. 자랑스러워하고 일주일 이상 코딩한 기능을 제거해야 하는 경우에도 마찬가지입니다. 한 동료가 Jira에 다음과 같은 시간 추적 댓글을 남겨 모든 사람의 하루를 밝게 해주었던 일이 기억납니다. "사산된 부분을 제거했습니다. 그리고 애도했습니다."

2. 새로운 기능 작성

새로운 기능을 구현하는 이 단계는 논리적으로 이전 단계 다음에 따릅니다. 프로젝트에 관련된 모든 작업은 Jira에서 작업으로 나뉘며 작업량에 따라 개발자에게 할당됩니다. 이 프로세스에는 "방법론"이라고 하는 다양한 접근 방식이 있으며 CodeGym에 대한 이 기사 에서 자세히 읽을 수 있습니다 . 일반적으로 작업에는 추정치가 있습니다., 완료하는 데 필요한 예상 시간입니다. 작업을 받을 때 개발자가 설정하거나 팀장이 설정하거나 계획 중에 개발팀에서 집합적으로 설정합니다. 소프트웨어 개발에 영향을 미치는 다양한 요소가 너무 많기 때문에 이번에는 추측이 정확하지 않은 경우가 매우 드뭅니다. 예를 들어, 프로그래머가 관련 기술에 익숙하거나 익숙하지 않거나, 전반적인 경험, 예측할 수 없는 다양한 함정 등. 이는 일반적인 추정치일 뿐입니다. 즉, 모든 프로젝트에 시간 추정이 필요한 것은 아닙니다. 개인적으로 나는 그것 없이 사는 것이 훨씬 더 쉽다는 것을 알게 되었습니다. 특히 PM이 "당신의 시간 추정치는 어디에 있습니까?" 그래서 임무를 받고,Jira에서 " 검토 준비 "를 수행하고 코드 변경 사항이 주석과 함께 수정을 위해 반환되지 않도록 기도하십시오.

3. 테스트 작성

검토자, 즉 코드를 확인하는 사람은 구현한 기능이 마음에 들지만 질문이 있습니다. 관련 테스트는 어디에 있습니까? 그래서 그녀는 수정을 위해 작업을 다시 보냅니다. 테스트는 모든 Java 애플리케이션의 필수 부분입니다. 테스트를 실행하면 애플리케이션이 올바르게 작동하지 않는 위치를 즉시 식별할 수 있습니다. 예를 들어 개발자가 시스템의 한 부분을 변경하면 다른 부분의 동작이 변경되지만 코딩하는 동안 이를 알아차리지 못했습니다. 테스트를 실행하면 특정 테스트가 실패했음을 알 수 있습니다. 즉, 예상한 결과를 얻지 못했다는 의미입니다. 이것은 그에게 시스템의 다른 곳에서 무언가가 손상되었음을 알려줍니다. 이를 알면 그는 서버에 주요 변경 사항을 커밋하지 않고 대신 코드 디버깅 작업을 계속할 것입니다. 예, 테스트 작성을 좋아하는 개발자는 거의 없지만 소프트웨어 개발에 가져오는 이점을 부인할 수는 없습니다. 클라이언트는 종종 유지하려는 테스트 범위 수준(예: 80%)을 나타냅니다. 즉, 당신이 알아야 할다양한 유형의 테스트를 작성하고 작성할 수 있습니다. Java 개발자는 주로 단위 테스트 및 통합 테스트를 작성하는 반면 보다 광범위한(종단 간) 테스트는 QA 및 테스트 자동화 전문가가 처리합니다.

4. 버그 찾기 및 수정

이는 Java 개발자에게 매우 일반적이고 빈번한 작업이기도 합니다. QA 및 테스트 자동화 전문가의 주요 업무는 버그를 잡는 것입니다. 즉, 프로그램이 잘못 작동하는 위치를 찾은 다음 Jira에서 작업을 생성하고 다른 사람에게 할당합니다. 예를 들어 팀 리더는 업무량과 시스템의 관련 부분에 대한 친숙도에 따라 개발자를 할당할 개발자를 결정합니다. 그 후 할당된 개발자는 디버거 에서 몇 시간을 보내면서 버그의 근본 원인을 찾아냅니다., QA 전문가가 제공한 버그 설명을 사용하여 버그가 발생하는 조건을 재현합니다. 개발자가 버그를 찾아 수정하면 검토를 위해 수정 사항을 보냅니다. 개발자가 버그를 재현할 수 없는 경우가 있으므로 설명과 함께 작업을 QA 전문가에게 다시 보냅니다. 버그를 찾아 수정하는 데 그리 오래 걸리지 않을 것 같지만 약간의 뉘앙스가 있습니다. 그것은 주로 개발자가 코드의 이 섹션에 대해 얼마나 잘 알고 있는지와 그의 경험 및 이론적 지식에 달려 있습니다. 때로는 버그를 찾아 20분 안에 수정할 수도 있고 때로는 3일이 걸릴 수도 있습니다. 즉, 이러한 유형의 작업은 개발자가 설명을 읽자마자 버그의 내용, 위치, 방법을 즉시 이해하지 않는 한 미리 예측하기가 특히 어렵다는 것을 의미합니다. 이 경우,

5. 코드 검토

위에서 언급했듯이 작업을 완료하는 즉시 검토를 위해 보내야 합니다. 심사를 통과하면 메인 브랜치로 들어간다. 그렇지 않은 경우 해결해야 할 설명과 함께 개발자에게 반환됩니다. 물론 당신의 코드는 일부 고위층이 아니라 동료 개발자들에 의해 모두 검사된다는 것을 이해합니다. 즉, 모든 사람이 코드 검토를 수행할 수 있는 것은 아닙니다. 좋은 코드와 나쁜 코드를 구분할 수 있는 실제 사례로 단련된 가장 경험이 풍부한 개발자만 수행할 수 있습니다. 코드 검토는 일반적으로 Crucible 과 같은 도우미 도구를 사용하여 수행됩니다.. 검토자는 코드를 살펴보고 필요한 경우 특정 줄에 대한 설명을 남깁니다. 다양한 댓글이 있을 수 있습니다. 예를 들어 일부는 중요합니다. 해결되지 않으면 검토자는 코드 커밋을 허용하지 않습니다. 예를 들어 다른 의견은 선택한 접근 방식에 대한 간단한 의견입니다. 개발자는 이를 듣거나, 메모하거나, 무시할 수 있습니다. 팀은 코드 검토를 위한 고유한 규칙과 절차를 만들고 주의를 기울일 가치가 있는 것과 그렇지 않은 것, 코드 검토를 완료하는 데 할당해야 하는 기간 등에 대해 합의할 수 있습니다. 경험만으로는 검토를 수행하기에 충분하지 않습니다. 기술 능력을 많이 향상시키고 다양한 책(예: "클린 코드")을 읽어야 합니다.

6. 코드 분석

다르게 생각하는 여러 사람이 프로젝트에 대한 코드를 동시에 작성하기 때문에 그들의 코드와 접근 방식이 다를 것입니다. 그리고 시간이 지남에 따라 모든 것이 점차 혼란스러워집니다. 코드를 개선하기 위해 특정 모듈 또는 전체 애플리케이션을 분석하고, 단점을 찾아 기록하고, 나중에 이 분석을 기반으로 리팩토링 작업을 생성하는 작업이 생성되는 경우가 있습니다. 이러한 분석은 개발이 시작되었을 때 팀이 더 간단하고 간결한 솔루션을 볼 수 없었지만 지금은 볼 수 있는 상황에서도 도움이 됩니다. 예를 들어 논리는 일부 메서드에서 종종 중복됩니다. 따라서 별도의 방법으로 추출하여 여러 번 재사용할 수 있습니다. 또는 클래스가 너무 커졌거나 일부 코드가 유지 관리하기 어렵거나 구식이 되었거나... 분석 작업은 코드 및 응용 프로그램의 품질을 개선하는 데 도움이 됩니다. 즉, 저에게는 많은 양의 코드를 분석하는 것이 지루할 수 있습니다.

7. 리팩토링 코드

코드 분석의 다음 부분은 리팩토링입니다. 코드는 구식이거나 구식이거나 잘못 작성되었거나 읽기 어려울 수 있습니다. 항상 완벽함(비록 존재하지는 않지만)과 최신 코드를 위해 노력해야 합니다. 불필요한 것은 혼란만 초래하고 코드가 수행하는 작업을 보는 기능을 방해하기 때문입니다. 프로젝트 초기에 이러한 작업을 볼 가능성이 낮다는 것은 말할 필요도 없습니다. 응용 프로그램이 다듬어지고 완벽해질 때 개발 후반 단계에서 이러한 작업을 보게 됩니다. 여기에서 동료가 무엇을 할 것인지, 어떤 함정이 있는지에 대해 동료와 상의하는 것이 적절할 수 있습니다. 본질적으로 이러한 작업은 새로운 기능을 개발하는 것과 유사합니다. 예를 들어 동작을 변경하지 않고 일부 기능을 편집하는 작업을 받았다고 가정합니다. 이렇게 하려면 이전 코드를 삭제하고 직접 작성하고 테스트를 확인합니다. 모든 것을 올바르게 수행했다면 테스트를 변경하지 않고 이전과 같이 모두 통과해야 합니다. 코드의 모든 것이 제대로 된 후 검토를 위해 코드를 보내고 커피를 마시러 갑니다 :)

8. 문서 작성

당신이 장기 소프트웨어 개발 프로젝트의 신입 개발자라고 상상해 보십시오. 코드 베이스를 숙지하거나 특정 작업(예: 버그 진단)을 수행해야 합니다. 프로젝트를 어떻게 탐색할 것인가? 5분마다 팀원을 귀찮게 합니까? 그들이 바쁘거나 주말이면 어떻게 합니까? 이것이 바로 우리가 문서를 가지고 있는 이유입니다. 코드에 익숙하지 않은 사람이 들어와서 관련 페이지를 찾고 관심 있는 응용 프로그램 부분에서 어떤 일이 벌어지고 있는지 빠르게 파악할 수 있도록 말입니다. 하지만 누군가는 문서를 작성해야 합니다. 하하. 프로젝트에 개발자가 지원해야 하는 문서가 있는 경우 새 기능을 구현할 때 이를 설명하고 코드 변경 또는 리팩토링과 함께 문서를 업데이트합니다. 문서 작성, 유지 관리 및 감독을 위해 별도의 직원(기술 작가)을 고용하는 상황도 있을 수 있습니다. 그런 전문가가 있으면 일반 개발자의 삶은 조금 더 쉬워집니다.

9. 각종 회의

다양한 회의, 협상 및 계획에 개발자의 많은 시간이 소요됩니다. 가장 간단한 예는 어제 한 일과 오늘 할 일을 보고해야 하는 일일 스탠드업 회의입니다. 또한 예를 들어 테스터와 일대일 전화 통화를 해야 버그 재현의 뉘앙스를 시연/설명하거나 비즈니스 분석가와 미묘함 및 요구 사항을 논의하거나 조직 문제에 대해 이야기할 수 있습니다. 오후와 함께. 이것은 개발자가 고독을 선호하는 내향적일 수 있지만 여전히 다른 사람들과 공통점을 찾을 수 있어야 한다는 것을 의미합니다(적어도 조금은). 개발자의 직급이 높을수록 의사소통에 더 많은 시간을 할애하고 코드를 작성하는 시간은 줄어듭니다. 개발 책임자는 근무 시간의 절반 또는 그 이상을 대화와 회의에만 할애할 수 있으며 코드 작성 빈도를 줄일 수 있습니다(아마도 그의 코딩 능력을 약간 잃을 수 있음). 하지만 대화를 좋아한다면 팀 리더로서 경영진으로 전환하고 코드 작성을 완전히 잊을 수 있습니다. 대신 다양한 팀, 고객 및 기타 관리자와 하루 종일 의사 소통을 할 수 있습니다.

10. 면접 실시/통과

아웃소싱 또는 인력 파견 회사에서 일하는 경우 내부 인터뷰뿐만 아니라 고객에게 자신을 "판매"해야 하는 외부 인터뷰(클라이언트를 위해 일하는 누군가와 인터뷰를 할 수 있음)를 거쳐야 하는 경우가 많습니다. 회사 내에서 순위를 올리는 것. 나는 이것을 성장을 위한 좋은 기회라고 부를 것입니다. 왜냐하면 빈번한 인터뷰는 당신이 당신의 지식을 예리하게 유지하도록 강요할 것이기 때문입니다: 당신은 녹슬거나 부드러워지지 않을 것입니다. 결국 IT에 약해지면 현장에서 완전히 떨어질 수 있습니다. 경험이 많은 개발자가 되면 면접을 통과하기보다 면접을 진행하면서 테이블 반대편에 있는 자신을 발견할 수 있을 것입니다. 저를 믿으세요. 면접 질문을 하는 것이 응답하는 것보다 더 무서울 수 있기 때문에 이 입장에서 보면 매우 놀랄 것입니다. 자신만의 면접 전략, 질문 목록, 필요한 모든 주제에 대해 한 시간 안에 질문할 시간이 필요합니다. 그런 다음 채용 결정에 영향을 미치고 후보자가 오랫동안 기대했던 제안이나 승진을 받는지 여부에 영향을 미칠 피드백을 제공할 책임이 있습니다. 또는 분명히 약한 후보자가 자격이 없는 직위를 얻도록 허용한 다음 "어떻게 그녀를 그 수준의 지식으로 고용하도록 허용할 수 있습니까?"라는 질문을 받을 수 있습니다. 따라서 인터뷰 중 화끈한 자리에 있을 때 앞에 있는 사람도 도전에 직면하고 있으며 스트레스를 받을 수 있음을 명심하십시오. 귀하는 채용 결정에 영향을 미치고 후보자가 오랫동안 기다려온 제안이나 승진을 받는지 여부에 영향을 미칠 피드백을 제공할 책임이 있습니다. 또는 분명히 약한 후보자가 자격이 없는 직위를 얻도록 허용한 다음 "어떻게 그녀를 그 수준의 지식으로 고용하도록 허용할 수 있습니까?"라는 질문을 받을 수 있습니다. 따라서 인터뷰 중 화끈한 자리에 있을 때 앞에 있는 사람도 도전에 직면하고 있으며 스트레스를 받을 수 있음을 명심하십시오. 귀하는 채용 결정에 영향을 미치고 후보자가 오랫동안 기다려온 제안이나 승진을 받는지 여부에 영향을 미칠 피드백을 제공할 책임이 있습니다. 또는 분명히 약한 후보자가 자격이 없는 직위를 얻도록 허용한 다음 "어떻게 그녀를 그 수준의 지식으로 고용하도록 허용할 수 있습니까?"라는 질문을 받을 수 있습니다. 따라서 인터뷰 중 화끈한 자리에 있을 때 앞에 있는 사람도 도전에 직면하고 있으며 스트레스를 받을 수 있음을 명심하십시오. 모든 면접은 지원자와 면접관 모두에게 스트레스를 줍니다. 우리는 아마 여기서 끝날 것입니다. 이 글을 읽어주신 모든 분들께 감사드립니다. 좋아요를 남겨주시고 자바를 계속 배워보세요 :)