시니어란? How to Become a Senior Developer

최근 새로운 환경에서 개발하며 들은 인상적인 조언이 있다.

 

"기술보다 일을 할 때 구조적인 사고를 하려고 노력해라"

 

구조적인 사고란 무엇이고, 어떤 것을 고민하면서 일해야 하는지 설명해주는 강의가 있어 기록해본다.

 

좋은 해결 프로세스는 아마도 고품질의 소프트웨어를 제때에 생산하는 것일 것입니다.

이를 달성하는 방법에 대한 황금률을 하나만 제시한다면, 저는 아마도 목수의 속담,

즉 계획에 더 많은 시간을 할애하고 실행에 더 적은 시간을 할애하라는 말을 인용하고 싶습니다.

 

본 글은 Udemy의 How to Become a Senior Developer라는 강의의 요약이다. 

유데미

시니어 개발자를 단순하게 정의하면 4가지 능력을 갖춘 인력이다. 

• 고품질 코드를 생산하는 사람
• 개발 기술, 방법론에 숙련된 사람
• 버그를 빠르게 찾고 수정하는 사람
• 팀을 lead 관리하는 사람 (강의에서 다루지는 않음)

 

팀 관리 외의 능력을 갖추는 법을 공유한 교양 강의라 할 수 있다.

 

Task를 이해하기

1. 왜 코딩 전에 Task 이해가 필요할까?

• Less bug
• Minimizing changes after coding
• Better 시간 관리를 위한 작업 산정

 

2. 그런데 언제, 어떻게 Task를 이해했다고 할 수 있을까?

정확하게 이해하는 것이 중요하다.

그러나 영원히 Task 파악만 할 수는 없다, 언제 코딩해도 될 만큼 Task 이해를 완료했다고 할까? 

 

아래 화면을 보고 4가지에 대해 빠짐없이 고민하고 답이 나왔을 때 Task를 이해했다고 할 수 있다.

1. 유저가 보고 있는 것을 무엇인가?

• UI 컴포넌트는 무엇인가?
• information은 무엇을 의미하며 어떻게 조회 / 계산되고 있는가?

2. Change가 일어났을 때 어떻게 각 Data가 행동하는가?

• ex) 수량 입력하고 order 버튼을 누르면 수량만큼 주문 요청

3. 컴포넌트끼리 서로 어떻게 상호작용하는가?

• ex) 주문이 완료되면 재고가 감소

4. Edge case는 무엇인가? 어떻게 다뤄야 하는가?

• ex) 재고 1개 남은 제품을 2명의 유저가 동시에 Order하면 어떻게 해야 하는가? (syncronization 이슈)
• ex) 은행 송금할 때 예금이 0원이거나 -가 되면 어떻게 해야 하는가?
• ex) 파일 업로드할때 컴퓨터 하드웨어 초과하는 파일이 업로드 되면 어떻게 해야 하는가? 

 

3. 나의Task의 이해한 내용을 어떻게 기억할 수 있을까.

• 사람은 망각의 동물이다.
• 문서화를 효율적으로 하자. 
  • 한번 훑어 봄으로 파악할 수 있도록 Mock up에 Comment를 남긴다.
  • Key info가 되는 중요한 부분에 밑줄, ! 표시 등으로 표시, 왜 표시했는지 메모한다.
  • Flow chart를 만든다.
  • edge case는 시나리오 + 해결책을 표로 정리한다.

 

 

문제해결

1. 왜 문제 해결에 계획이 필요할까?

• 솔루션이 최적의 솔루션이 아닐 수 있다.
• 이미 있는 코드를 또 만들 수 있다.
• 동작하지 않는 코드일 수 있다.
• 확장성 있는 클린코드를 만들고 싶다.

 

2. 최적의 솔루션을 결정하는 방법

• 기술적으로 작업을 정의한다. (ex) What is the scope & context)
  • 무엇이 이미 있는가? 무엇을 해야 하는가?
    • ex) 특정 조건에 따라 직원 급여 조회 기능 만들려고 하는데 조회 함수가 이미 있는가?
    • ex) 조회 기능 추가할 때, 기존 코드에 Exception 코드는? Logging은?
    • 비슷한 코드가 있는가?
    • 코딩 Standard 확인
• pros and cons 최적의 솔루션을 찾는다.
  • Cost : 비교 대상을 나열, 비용을 산정한다.
  • Performance : 성능을 고려한다. (최악 시나리오 가정)
  • Compatibility : 호환성을 고려한다.
  • Simplicity : 단순성을 고려한다.
  • Security : 보안 고려
  • Completeness : 완결성 - 모든 요구사항을 다 처리할 수 있는가
  • 코드 품질
  • etc…
• POC로 검증한다.
  • Proof of concept로 여러 인풋 넣어서 테스트해본다.

 

3. 어떻게 솔루션을 기억할 수 있을까?

• 문서화
  • Mockup에 커멘트를 남긴다.
  • Mark key info
  • 알고리즘, pseudo code (step1, step2, step3)
  • Edge cases

 

Test

왜 테스트를 할까?

• 작성한 코드가 완벽히 동작하는 것을 확인

어떻게 테스트를 할까?

• 완벽히 동작하지 않는다고 가정하고 break 시도
• 무자비하게 시도해라

얼마나 테스트를 할까?

• 내가 버그 없다고 확신할 만큼

언제 테스트를 할까?

• ASAP

 

Bugs

1. Debugger 기능 파악
2. IDE 디버깅 기능 파악
3. 문서화 → 어떤 행동으로 버그 발생했는지 기록 (확신에 기반)
4. 면책사항 확인
5. 정보 수집
   1. 올바른 동작이 무엇인지 재확인,
   2. 연관된 기능 확인,
   3. 에러메시지 확인,
   4. 에러 발생지 확인
6. 디버깅 준비
   1. Flow 이해
   2. 로컬에서 해결 시도
   3. 가독성 높이기
7. 디버깅 : 명확하게 에러 상황 이해하기
   1. 한곳만 바라보는 반복을 하지말자.
   2. 스스로 질문
      • 올바르게 동작하고 가정하고 확인 안한 곳은 어디인가
      • 어떤 문제로 해당 증상이 발생할 수 있는가
      • package, update, network, infra, saas 등에 대한 의존성 문제
   3. 버그를 발견하더라도 바로 수정하지 말자.
      1. 해당 개발자가 왜 이렇게 작성했는지 이해하자

 

출처 

- https://www.udemy.com/course/junior-to-senior-software-developer