개요


이 페이지는 개발자가 어떤 종류의 능력을 키워야하고,

어떤 전략을 가지고 학습하는 것이 더 빨리 전문성을 쌓을 수 있을지에 대한 내용을 정리하였습니다.

최근 회사에서 받은 커리어 디자인 교육 강의를 기반으로 작성하였고,

개발자로서 학습 전략과 방향을 선정하는데 도움이 될 수 있습니다.

 

개발자란 어떤 직업인가?

일반적으로 개발자는 프로그래밍을 업으로 하는 사람이다.

 

프로그래밍에 요구 되는 3가지 능력


1. 사고 능력 → 논리(Usecase)를 설계하고 구조화할 수 있는가?

다른 말로 문제 해결력이라고 할 수 있다.

개발은 프로그램에서 필요한 기능을 구현하기 위해 발생하는 수많은 문제 해결의 연속 과정이다.

원하는 기능을 구현하기 위해 또는 문제 상황을 해결하기 위한 적절한 Logic을 구성하고 설계할 수 있는가?

 

개발자는 계속해서 사고 능력을 키우는 학습을 해야 한다...

 

2. 기술 능력 → 프레임워크, 기술을 사용하여 코드로 구현할 수 있는가?

문제에 대한 해결책을 그릴 수 있다고 해서,

다른 사람이 이미 해결한 해결 방법 없이 프로그래밍을 한다면,

고객이 원하는 수준의 프로그램을 원하는 기간 내에 구현하기란 어려울 것이다.

 

개발자는 계속해서 신규 프레임워크, 기술의 등장 배경, 컨셉, 원리, 사용법 등을 공부하고,

연습해서 빠르게 원하는 결과물을 만들어내는 능력을 키워야 한다...

 

3. 과학 능력 → 컴퓨터의 여러 요소에 대한 근본적이고 지식적인 이해가 있는가?

개발자에게는 기본 CS에 대한 지식 학습과 이해가 필수적이다.

CS에 대한 기본 지식 없이 개발을 하면, 성능, 메모리, 네트워크 등의 동작 방식을 고려하지 않기 때문에

기능만 구현하는 수준의 개발을 진행할 수 밖게 없고, 이것은 결국 프로그램에 잠재적인 문제를 야기한다.

 

개발자는 CS의 기본적인 지식에 대한 이해를 목적으로 학습을 꾸준히 해야 한다...

 

프로그래밍을 잘하려면 기본적으로, 위의 3가지 카테고리에서

일반인보다 더 높은 능력치가 골고루 요구된다고 한다...

노오력이 필요하다.

 

 

영역별 실제적인 학습 방법


1. 사고 능력 → 문제를 쪼개는 훈련을 하고, 자주 사용될만한 문제 해결 패턴을 기록하라.

논리(Usecase)를 큰 문제에서 작은 문제로, Top-down 방식으로 쪼개는 훈련을 한다.

UML, Flow Chart 등으로 도식화해보는 작업도 한다.

자주 사용될 만한 논리 사고의 패턴이나 프레임이 발견되면 기록한다.

 

2. 기술 능력 → 공식 문서를 번역해서 공부하고, 자주 사용될만한 코드 패턴을 기록하라.

웬만하면 공식문서를 보고, 번역하면서 공부하는 것이 좋다. (블로그, 2nd 블로그 지양 하자.)

심화 내용은 책을 통하거나, 다른 사람들을 통해 도움을 받는 것이 좋다.

기술은 항상 상황에 적합한 케이스나, 패턴 프레임이 존재하기 때문에 기록한다.

 

3. 과학 공부 → CS 책을 보고 외우고, 이해하라.

보고 외워라. 보통 책을 정하고 공부하는 것이 좋다.

 

 

 

 

개발 학습의 핵심은?


결국 학습하면서 경험을 해보고, 제대로 이해한 것을 기록하는 것이 중요하다.

결국 패턴, 프레임, 케이스 공부이고, 그것들을 축적시켜나가고 나의 것으로 만들어가는 훈련이다.

패턴은 곧 프레임워크나 라이브러리가 될 수 있다.

UseCase, 설계 패턴, 디자인 패턴을 기록해 둔다. -> 경험이 쌓이면서 내가 아는 패턴이 많아진다.

지속적으로 안해봤던 것을 해보는 노력이 중요하다.

일할 때, 리팩토링 습관을 들이는 것이 중요하다. (컴포넌트 간, 모듈의 확장성이 고려되어 있지 않을 때)

학습, 교육을 받았으면 반드시 산출물이 남아야 한다.

산출물을 작성하기 위해 시간을 들이는 것은 투자의 개념으로 생각해야 한다.

 

개발 관련 지식을 기록할 때 주의할 점

1.  지치지 않도록 매몰되면 안된다.

너무 몰두하면 지친다.

이 부분은 완벽주의자한테 나에게 너무 공감이 되는 부분이었다.

적당히 하자!!!!!!!!

2.  너무 코드와 기술에 집착하지 않는다. 

어차피 해가 지나가면 매장될 기술일 수 있다.

필요 이상으로 코드와 기술에 집착하지 말자.

적당히 하자!!!!!!!!

 

 

개발한 코드에 대한 4가지 물음


1. 개발자가 쉽게 이해할 수 있는가?

요즘은 짧게 줄이는 것보다,

다른 개발자 또는 미래의 내가 이해할 수 있도록 가독성 있는 코드를 짜는 연습이 중요하다.

 

2. 예측 가능하고, 유지보수할 수 있는 상태인가?

유지보수할 수 있는 상태란 대부분 제대로된 프로젝트 코드 구조를 가지고 있는가? 있는 것 같다.

어떠한 컨벤션 룰 없이 개발한 프로젝트는 중구난방 정리되어 있지도 않고,

객체 지향적으로 개발되어 있지도 않아서 기능을 추가하거나 제거할 때 너무 많은 기능들이 얽혀 있어서

수정조차 못하는 상황이 생길 수 있다.

 

3. 부작용이 제대로 알려져 있는가?

코드의 한계점이나 부작용이 제대로 고지되어 있지 않다면, 언젠가는 문제가 되더라..

 

4. 테스트할 수 있는가?

테스트할 수 없다면, 신뢰할 수 없는 코드가 되고, 이것은 수많은 버그를 야기할 수 있다.

 

 

시니어 개발자의 기본 소양


1. 요구사항에 대한 질문

시니어 개발자는 고객에게 요구사항을 들었을 때,

그에 대한 대표적인 해결 방법이 그려지고 최소 1개 이상 제시할 수 있어야 한다.

또한 요구사항에서 문제될 수 있는 포인트를 미리 포착하여, 질문할 수 있어야 한다.


2. 비즈니스에 대한 이해

시니어 개발자는 비즈니스에 대한 기본적인 이해를 가지고 있어야 한다.

이는 당연히 요구사항을 이해하기 위해 필요한 부분이다.

비즈니스의 구조와 동작 방식에 대해 이해하지 못하면 요구사항을 이해하기 힘들다.


3. 개선사항에 대한 의견 표출 

시니어 개발자는 위에 두가지 항목에 대한 온전한 이해를 바탕으로

요구사항을 구현하는 선에서 그치는 것이 아니라,

더 나은 방법이나 기능들을 제시할 수 있어야 한다.

 

 

IT 회사에서의 기억해야할 태도


직장인 마인드가 아닌 직업인 마인드로 살자.

직장인에게는 연차와 경험을 쌓아서, 높은 직위로 가면 장땡이지만...

IT 직업에 있어서는 그런 마인드로는 부족할 뿐더러 살아남을 수 없는 것 같다.ㅠㅠ

직업인 마인드로 지속적으로 전문성을 키워야하는 필요성을 인지해야 공부를 할 수 있다~!!

 

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 카카오스토리 공유하기