Rallit Linkedin

필독 개발자 온보딩 가이드 2장

필독 개발자 온보딩 가이드 2장

필독 개발자 온보딩 가이드을 읽고 정리하는 글이며, 혹시 문제가 되면 삭제하겠습니다.

역량을 높이는 의식적 노력 - 경쟁자가 갖춘 개발자가 되기 위해 스스로 해야 할 일

1. 들어가며

학습을 위한 가르침이라는 책에서 능숙함을 4가지 단계로 나누어 의미 했다.

  1. 무의식적 능력 부족

  2. 의식적 능력 부족

  3. 의식적 능숙

  4. 무의식적 능숙

모든 엔지니어는 의식적이든 무의식적이든 능력 부족 단계에서 시작하며, 목표는 최대한 빨리 의식적 능숙 단계로 접어드는 것이 좋다. 또한 이 장에서 자기주도 학습이라는 습관 방법과 균형 유지, 가면 증후군, 더닝 크루거 효과에 대해서도 다룬다. 스스로에 대한 불신이나 과신에 빠지지 않도록 주의하며 자기주도 학습을 계속하고 효율적인 질문을 하다 보면 의식적 능숙함을 빠르게 갖출 수 있을 것이다.

2. 실전에 앞서 익혀야 할 자기주도 학습 방안

  • 학습에 모든 방법을 동시에 시도해서는 안 된다.

  • 지속적인 성장도 중요하지만 깨어 있는 내내 일만 하는 것은 건강을 해치므로 개인 시간을 반드시 확보하기 바란다.

3. 본격적인 학습을 위한 몸풀기

이 초반 과정은 지루할 수도 있고 다른 사람은 바쁜데 마치 자신만 한가한 것 같은 느낌도 들 것이다. 하지만 걱정마라. 적응할 시간이 필요하다는 사실은 모든 사람이 알고 있을 것이다.

  • 입사 후 처음 몇 달간은 일단 상황이 어떻게 돌아가는지 파악하는 데 집중하자.

  • 그러면 설계 회의나 온콜 교대 업무, 운영 이슈, 코드 리뷰 등에 참여하는데 도움이 된다.

4. 직접 부딪혀보면 깨닫자

코드를 처음 배포할 때 어딘가 문제가 생기지 않을 두려울 수 있지만 팀장들도 녹록치 않아서 결코 심각한 피해를 입힐 만한 상황을 만들지 않는다. (디만 대안이 없는 경우 신규 입사자가 위험 부담 높은 작업에 투입될 때도 있다.)

  • 문서를 읽어 배울 수 있는 것보다는 실전을 통해 배울 수 있는 것이 훨씬 많다.

  • 그러므로 코딩을 하고 결과물을 배포해야 한다.

  • 만약 실수하더라도 스스로를 너무 책망하지 말자. 실수로부터 배운 것이 있다면 기록해두고 계속 정진해 나가면 된다.

5. 코드 동작을 이해하기 위해 다양한 실험을 해보자

어떤 메소드가 호출이 된 것은 알겠는데 도대체 어떤 경로로 그 메소드가 호출됐는지 알아내지 못하는 경우가 있다. 이럴 때는 예외를 던지거나 스택 트레이스를 출력해보거나 아니면 디버거를 붙여 호출 경로를 살펴보는 등의 시도

  • 여러 가지 시도를 해보며 코드가 어떻게 동작하는지 알아두자.

🍊 여기서 잠깐! 스택 트레이스란?

일단 출처 https://jaehoney.tistory.com/51 https://okky.kr/articles/338405

개념

  • 프로그램이 시작된 시점부터 현재 위치까지의 메서드 호출 목록

  • 예외가 어디서 발생했는지 알려주기 위해 JVM을 생성

필요 이유

  • 스택 트레이스를 읽는 능력은 선택이 아닌 필수

  • 무턱대고 오류내용을 복붙하고 해결을 위한 코드도 복붙한다면 직면한 문제는 해결할 수 있지만 발전 없이 머물러 있게 됨

  • 강사님도 항상 강조하는 내용

그렇다면 읽는 법?

public class StackTraceTest 
{
	public static void main(String[] args) 
	{
		one();
	}
	
	public static void one()
	{
		two();
	}

	public static void two()
	{
		three();
	}
	
	public static void three()
	{
		Integer.parseInt("abcde");
	}
}

  1. 스택트레이스는 에러가 발생된 시점부터 프로그램이 시작된 시점까지 거슬러 올라가면서 출력되기 때문에 먼저 실행된 메서드가 가장 아래

  2. 나도 보려고 노력하지만 겁먹기 마련이다. 대부분 처음 시작하는 분들이 그렇더라

  3. 하지만 에러의 진정한 원인은 가장 아래쪽(초기)에 있는 Caused by:로 시작되는 줄부터 아래로 세줄이면 충분

Caused by: java.lang.NullPointerException
     at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603)
     at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)

  1. 위의 내용은 com.mycompany.service.impl.PortalManagerImpl' 클래스의 deletePortal 메소드 358라인에서 같은 클래스의 deleteMenuItem메소드를 호출했는데 해당 메소드 603번 째 줄에서 널포인터 예외가 발생했다라고 해석

  1. PortalManagerImpl 클래스 소스

if (item == null) {
    throw new NullArgumentException("item");
}

//중간 생략
List<PortalMenu> children = getMenuItems(item.getPortal().getId(), item.getId()); // 603번째 줄

for (PortalMenu child : children) {
    deleteMenuItem(child);
 }

그렇다면..? 널포인트 exception 원인은?

  • 많은 수의 지원자들이 children이나 item.getId() 등에 널값이 들어간 것 같다고 답했다고 한다. 이론적으로 해당 라인에서 널값이 들어갈 수 있는 모든 경우의 수는,

  1. children

  1. item

  2. item.getPortal()

  3. item.getPortal().getId()

  4. item.getId()

  • 이 중 적어도 두 가지, 즉 2번 혹은 3번으로 가능성을 바로 좁히지 못한다면 그것은 널포인터 예외의 의미를 정확하게 파악하지 못하고 있기 때문이라고 한다.

널포인터 예외는 단순하게 변수에 널값이 들어가서 생기는 오류가 아니다. 널포인터 예외는 명확하게 객체의 널레퍼런스에 대해 메소드 호출이나 필드 참조 등의 작업을 했을 때 발생하는 문제라는 것을 이해한다면 이런 문제는 곧바로 원인을 좁힐 수 있어야 한다.

  • 즉, 1번의 경우처럼 단순히 변수에 널값을 할당하는 것만으로는 절대로 널포인터 예외가 날 수 없다. 그리고 만일 4 번 item.getPortal().getId()이나 5번 item.getId()이 널이라면 이는 널 레퍼런스에 대한 호출이 아니라 널값을 getMenuItems라는 메소드의 인자로 넘기는 것 뿐이기 때문에 역시 널포인터 예외의 원인이 될 수 없다.

  • 물론 getMenuItem 메소드 안에서 해당 인자에 대한 널체크 없이 값을 사용하다가 예외가 날 수도 있겠지만 이 경우엔 절대로 트레이스 상에 굵은 글자로 표시된 603번 째에서 예외를 뿌리지 않는다.

  • 그렇다면 남은 가능성은 2번 'item'이 널이거나 3번 'item.getPortal()'이 널인 경우뿐인데, 'item' 변수는 위에서 널체크를 하기 때문에 603번 째 줄에서 절대로 널값을 가질 수 없다. 그렇기 때문에 답은 3번이 되는 것

읽어보면 좋은 글

개발은 암기과목이 아닙니다

논외 Visual Studio와 Visual Studio Code

스택 트레이스 를 읽는 법을 찾다가 알게 된 것인데... 둘은 완전히 다르다는 것 Visual Studio는 IDE(통합 개발 환경)이며 Visual Studio Code는 Sublime Text 및 Atom과 같은 리치 텍스트 편집기로 도구 간의 차이점은 IDE와 텍스트 편집기 그 이상이라고 한다. IDE는 코드 작성, 편집, 디버깅 및 실행을 위한 강력한 도구로 텍스트 편집기에서는 코드를 작성하고 편집할 수만 있다. 코드를 실행하거나 자동으로 실행되도록 플러그인을 다운로드하려면 텍스트 편집기에서 나가야 할 수도 있다고 함.. 깊게 공부 안하고 돌리기만 해서... 몰랐다.

🍊 이런 실험을 할 때 디버거 십분 활용

  1. 실행 중인 코드를 잠시 정지시키고 실행 중인 스레드, 스택 트레이스, 변숫값 등을 확인할 수 있다.

  2. 디버거를 붙여 이벤트 발생시킨 후 코드가 해당 이벤트를 어떻게 처리하는지 단계적으로 확인

  3. 브레이크 포인트는 디버거에서 코드 실행을 중지시키는 지점을 설정하는 도구로 이를 통해 해당 지점에서 코드의 실행 상태를 분석하고 변수 값을 확인할 수 있다.

intellij에서 브레이크 포인트 설정 방법

IntelliJ IDEA를 열고 디버그할 프로젝트를 로드

  1. 디버그하고 싶은 코드 파일을 엽니다.

  2. 브레이크 포인트를 설정하려는 줄에 마우스 커서를 가져갑니다.

  3. 해당 줄의 왼쪽 마진(라인 넘버 부분)을 클릭하면 브레이크 포인트가 설정됩니다. 또는, 해당 줄을 클릭한 후 Ctrl + F8 (Windows/Linux) 또는 Command + F8 (Mac)을 누르면 컨텍스트 메뉴가 나타납니다. 이 메뉴에서 Toggle Line Breakpoint를 선택하면 브레이크 포인트가 설정됩니다.

  4. 설정한 브레이크 포인트는 빨간 동그라미로 표시됩니다.

  5. 디버그 모드로 실행하려면 해당 클래스 또는 메서드 내에서 마우스 우클릭하여 "Debug" 옵션을 선택하거나, 코드 에디터 상단의 "Run" 또는 "Debug" 버튼을 클릭합니다.

  6. 프로그램이 브레이크 포인트에 도달하면 실행이 일시 정지됩니다. 이때 디버거 창에서 변수 값을 확인하거나 단계별로 코드를 실행해볼 수 있습니다.

🍊 디버거는 강력한 기능을 제공하지만 가끔은 로그나 print를 넣어두는 것이 코드의 동작을 이해하는 것이 가장 쉬운 방법

  • 다만, 멀티스레드 애플리케이션 같은 복잡한 상황에서 print문을 이용한 디버깅은 잘못된 결과를 도출할 수 있다는 점에서 유의

쉽지만 유용한 방법

  • 원래 코드가 아니라 내가 수정 중인 코드가 실행되고 있는 사실을 눈에 띄게 알려주는 문장을 프로그램이 처음 실행되는 시점에 출력

6. 문서 읽는 습관은 몸에 배야 한다.

읽을 자료는 무궁무진하다. 다만 이 자료들을 한 번에 모두 읽을 생각은 하지말자.

  1. 먼저 팀문서와 설계 문서부터 시작

  • 그렇게 되면, 여러 부분이 어떻게 결합되어 동작하는지 대략적으로 이해 가능하게 된다.

  • 특히 트레이드 오프와 컨텍스트에 대한 논의는 더욱 주의를 기울이자

  • 그러면 서브시스템에 대한 이해가 더 깊게 가능할 것이다.

🍊 잠깐!! 트레이드 오프(trade-off)와 컨텍스트(context)란?

  • 트레이드 오프 : 객체의 어느 한 부분을 품질을 높이거나 낮추는 데 다른 한쪽의 영향을 미치는 상황 EX. 개발의 시간 UP => 완성도 UP => 비용 UP 적절한 최적의 타협 필요

  • 컨텍스트 : 코드나 기능이 작동하는 환경, 어떤 특정 작업한 단위 수행한 필요한 기본정보, 준비사항, 그 경계의 지침

  1. 코드는 소설처럼 처음부터 끝까지 쭉 읽는 것이 아니다. IDE를 이용해 코드의 이곳저곳을 훑어보자. 주요 기능에 대해서는 코드의 흐름과 상태를 다이어그램으로 그려보자. 코드의 데이터 구조와 알고리즘을 파헤쳐보자. 예외 상황을 어떻게 처리하는지도 잘 살펴보자. 그러면서 팀의 코딩 스타일과 용어도 꼼꼼히 확인하자. 그래야 내부 의사소통이 원할해진다.

  2. 앞으로 해야 할 일은 티켓(ticket)이나 이슈(issue)로 관리한다.

7. 그 외

1. 발표 영상을 찾아서 찾아보자

  • 다만, 수동적인 태도는 금물 내용을 기록하고 익숙하지 않은 용어 찾아보기

2. 때로는 밋업과 컨퍼런스를 참여하자.

  • 때때로 참석은 좋지만 너무 잦은 참석은 금물이다.

3. 시니어 엔진니어의 체험하고 협업하자.

  • 체험하기(shadowing) : 다른 사람 업무를 수행하는 동안 그림자처럼 따라 다니며, 일정 전 후에 계획과 회고 시간 마련하기

  • 짝 프로그래밍(pair programming) : 두 명의 엔진니어가 번갈아가며 함께 코드를 작성하는 방법은 상대에게 뭔가를 배우는데 가장 빠른 방법 중 하나이다.

4. 개인 프로젝트 활동에서도 배움을 얻을 수 있다.

  • 사이드 프로젝트를 진행하자.

  • 배워야 할 소재를 근거로 프로젝트를 선택해서는 안 된다. 해결하고 싶은 도구를 이용해서 그 문제를 해결해야 한다. **목표가 있어야 더 오래 몰두하고 더 많이 배울 수 있는 본질적인 동기가 스스로에게 부여된다. **

  • 대체로 회사에는 업무 외 활동에 대한 규정이 나와있으니 회사 정책 읽기 필수

5. 제대로 질문하기

  • 질문은 배움에 있어 매우 중요하다.

  • 팀 동료에게 민폐가 될까 싶어 모든 것을 혼자 알아내려고 하는데, 비효율적이다.

  • 질문할 때는 먼저 스스로 찾아보고 명확히 질문하며, 질문에 대한 답을 들을 때까지 적절한 시간을 기다리는 세 단계를 밟아가길 바란다.

6. 스스로 문제를 해결해보자

아무런 단서도 찾지 못한다면 실험을 통해 스스로 해결해보자. 어디를 살펴봤는지 어떤 방법을 왜 시도했는지, 결과는 어땠는지 그리고 그로부터 배운 것은 무엇인지 모조리 기록하자.

  • 무작정 인터넷만 뒤지는 방법은 옳지 않다. 만일 궁금한 점이 코드에 대한 것이라면 문제를 입증하는 단위 테스트로 바뀌보자.

  • 메일링 리스트나 채팅 그룹을 뒤져보자

7. 제한 시간을 정하자

문제를 스스로 해결하기 위한 기한을 정해두자.

  • 언제까지 답을 구해야 할 지 생각해보고, 질문을 하고 답을 찾고 배운 것을 토대로 조치를 취할 수 있을 정도로 충분한 시간을 확보해주자. 제한시간을 다 썻는데 아직 답을 찾지 못했다면 질문하자.

  • 제한 시간을 늘리는 것은 스스로의 노력이 제대로 진척을 이룰 경우에만 허용하자.

8. 자신이 시도한 방법을 공유하자

  • 기록해둔 내용을 그대로 전달하는 것이 아니라 여러분이 시도해본 방법과 알아낸 내용을 간결하게 요약하자.

  • 질문을 하려면, 컨텍스트를 제공하고 문제를 설명하며 지금까지 시도한 방법을 전달하며, 도움을 요청한다. 또한 문제의 영향력과 긴급도에 대해서 첨언했다.

9. 동료를 방해하지 말자

  • 각자의 업무에 집중하고 있다면 방해하지 말자

10. 비동기식 멀티캐스팅 의사소통을 시도하자.

  • 질문은 여러 사람(멀티캐스트)이 각자의 상황에 따라(비동기식 = 바로 답하지 않고 나중에 처리) 응답할 수 있는 곳에 올리자

11. 동기식 요청은 한 번만 보내자

8. 성장의 장애물을 극복하자.

🍊 가면 증후군

  1. 대부분의 신입 엔지니어는 의식적 능력부족 상태에서 시작

  2. 간혹 스스로에게 너무 엄격해지기도 한다.

  3. 자기 스스로에 대한 불신은 누구나에게 있는 보편적인 현상이라는 점을 우선 염두에 두자

  4. 자기 인식은 도움이 된다.

  5. 무언가를 달성했다면 그건 실제로 일을 잘 해냈기 때문이지, 그저 운이 좋았기 때뭔이 아니다. 칭찬과 성과를 애써 외면하지말고 아무리 작은 일이라도 기록해두자

  6. 피드백을 받는 것도 도움이 된다.

🍊 더닝 크루거 현상

  1. 스스로를 과대평가하는 인지적 편견을 갖는 것이다.

  2. 자신이 뭘 모르는지를 모른다.

  3. 의식적으로 호기심을 계발하는 것부터 시작하자.

  4. 그리고 자신이 틀릴 수도 있음을 인정하자.

  5. 자신이 존경하는 엔지니어를 찾아 여러분이 잘하고 있는지를 물어보고 경청하자

9. 개발자의 필수 체크리스트

❗ 회고

지금 글을 쓰고 있는 시점에는 3장까지 읽어봤는데 회사에 가서 처음 헤매는 사람이랑 공부하는 방향을 모르겠는 사람에게 좋은 것 같다. 특히 에러 났을 때 스택 트레이스를 보는 것 국비에서도 대부분 사람들이 이걸 보는 거 어려워 한다. 어 왜 안돼..? 왜..? 여기서 끝이고 무슨 이유인지 콘솔을 볼려고 하지 않는다 그건 나도 그런 것 같다.

거기서 보고 이유 뿐 아니라 위에서 설명한 것 처럼 nullpointException이 정확히 언제 나는 지 등을 알아두는 것 또한 중요하다 생각한다.

Previous필독 개발자 온보딩 가이드 1장Next필독 개발자 온보딩 가이드 3장

Last updated