나는 그저 그런 개발자입니다.

티스토리 메뉴 펼치기 댓글수3

Meeta

나는 그저 그런 개발자입니다.

Meeta - 개발자의 포트폴리오
댓글수3




*이 글은 허락을 받아 Nikita Sobolev의 dev.to블로그를 번역한 글입니다. (원글: https://dev.to/sobolevn/i-am-a-mediocre-developer--30hn)


나는 개인적으로 굉장히 능력있고, 손쉽게 멋진 소프트웨어를 만들 수 있는 개발자들을 몇몇 알고있다. 이런 특별한 이들 때문인지 개발 분야에서 개발자에 대한 기대치는 매우 높다. 하지만 슬프게도 우리가 모두 그런 스타/구루/네임드 개발자는 아니다.


그리고 나는 나를 너무 잘 알고있다. 나는 그저 그런 개발자다. 이 글은 천재 개발자가 아닌 당신이 개발 분야에서 살아남는 방법을 가르쳐 주기 위한 글이다.


나는 항상 말도 안되게 쉬운 걸 구글링한다.

나는 기억력이 좋지않다. 표준 라이브러리의 함수나 method, argument position, package 이름, boilerplate 코드같은 것들을 항상 까먹는다. 


그래서 난 매일매일 그것들을 구글링한다. 예전 프로젝트의 코드를 그대로 가져다 쓰기도하고, GitHub나 StackOverflow의 답변을 복붙하기도 한다. 나는 말 그대로 StackOverflow가 시키는 대로 코딩한다.


하지만 사실 StackOverflow가 시키는 대로 코딩하는 사람은 나 혼자만이 아니다. 실제로 Ruby on Rails의 개발자도 버블소트를 어떻게 하는 지 인터넷에서 찾아봤다고 트윗했다. (Twitter)


그게 나쁜 건가? 안좋은 점이 몇가지 있긴 하다.


1. 다른 사람들의 안좋은 방법이나 취약한 코드를 복사하게 될 수도 있다.

2. 별로 좋지 않은 마음가짐을 가지 된다. 구글링해서 안나오는 문제를 진짜 문제로 여긴다.

3. 인터넷이 없으면 일을 할 수가 없다.


하지만 사실 이게 엄청난 문제는 아니다. 이런 약점조차 숨겨진 필살기로 만들 수 있는 나의 팁들을 공개한다.


How to survive:


1. IDE의 자동완성기능을 사용하면 기본적인 언어에 대한 부분을 구글링하지 않아도 된다.

2. 전에 문제를 해결한 방법이 아니라 코드의 위치를 기억해라. 다음에 문제가 발생했을 때 방법이 아니라 위치로 찾을 수 있다!

3. 프로젝트에 붙여넣은 코드는 나중에 꼭 다시보고 분석하자. 이렇게 하면 나쁜 코드로 프로젝트를 망치지 않고, 빠르게 솔루션을 찾을 수 있다.


단순하게 생각하자.

컴퓨터는 거짓말을 안한다. 걔들은 그냥 시킨 것만 한다. 그러니까 제일 큰 문제는 컴퓨터에 있는 것이 아니라 개발자의 능력에 달려있다. 그래서 우리같은 '그저 그런 개발자'들은 쓸데없이 어려운 걸 추상화하고, 애매한 알고리즘이나 읽기도 어려운 코드 블럭을 만드느라 시간을 쓰지말고, 그냥 단순하게 생각하자!


그런데 우리는 어떻게 단순한 코드와 복잡한 코드를 구분할 수 있을까? 우리는 이걸 결정하기 위해서 분당 "잉?"코드 판독법을 활용할 수 있다. 내 코드를 보고 내가 당황하는 횟수가 적을 수록 좋은 코드이다.




원칙은 간단하고 명쾌하다. 네가 썼지만 너무 복잡해서 이해가 되지 않는 코드를 찾아낸다면 넌 뭘할 수 있을까?


1. 코드를 보기 쉽게 다시 써본다.

2. documentation을 써준다.

3. 제일 복잡한 부분에 주석을 쓴다. 하지만 주석을 썼다는 것 자체가 좀 수상하다는 것을 기억해라


처음부터 간단하게 코드를 쓰는 방법:


1. 변수, 함수, 클래스 이름을 정확하게 써라

2. 한 파트가 하나의 기능만 수행하도록 프로그래밍 해라

3. 함수보다는 순수함수를 써라

4. 클래스보다는 함수를 써라

5. 꼭 필요할 때만 클래스를 사용하자

*순수함수(Pure Function): 입력 값이 아닌 다른 조건에 의해 결과 값이 바뀌지 않는 함수.


나는 나를 못믿겠다.

아폴로 프로젝트의 수석 소프트웨어 엔지니어 Margaret Hamilton같은 개발자들은 자신들이 좋은 코드를 쓸 수 있다는 것을 증명했다! 아래 사진은 Margaret Hamilton이 달에 가기위해 쓴 코드 옆에 서있는 사진이다.



하지만 나는 코드를 쓸 때마다 나를 믿을 수가 없다. 나는 프로젝트에서 가장 쉬운 부분을 작업할 때조차 실수로 모든 것들을 망쳐버리곤 한다. 별거 아닌 에러들이 빈번히 발생하곤 한다.


1. Language 에러

2. Logic 에러

3. Design 에러

4. Style 에러

5. Security 에러

6. (내가 제일 좋아하는)"잉...?" 에러


"버그없는 코드 쓰는 법" 같은 바이블은 어디에도 없다. 그리고 사실 그게 정상이다. 하나의 프레임워크를 제외하고 모든 소프트웨어에는 버그가 있다.


누구도 중대한 에러가 있는 코드를 쓰고 싶어하지 않는다. 최소한 노력이라도 해야한다. 그런데 어떻게 (믿을 수 없는)나로부터 내 프로젝트를 지킬 수 있을까? 다시 한 번 몇가지 팁을 공개한다.


How to survive:


1. test코드를 써라. test코드를 진짜 많이 써야한다. 통합 test코드부터 함수 레벨의 단일 test코드까지 쓰고, pull request 전에 CI를 수행해라. 이렇게 하면 logical 에러를 피할 수 있다.

2. static typing이나 optional static typing을 사용해라. 예를 들어 python에서 mypy를 사용하고 javascript에서 flow를 사용하면 더 깨끗한 디자인과 컴파일 시간을 체크할 수 있다.

3. automated style check를 사용해라. 잘 찾아보면 모든 언어에 대한 style checker가 굉장히 많다.

4. quality check를 사용해라. 어떤 툴들은 logic이 너무 많다던가, 클래스가 필요없다던가 함수가 너무 복잡한 것과 같은 문제들을 복잡한 heuristic algorithm을 활용하여 발견해 준다.

5. 코드 리뷰를 해라. master에 합치기 전에는 꼭 코드 리뷰를 하고, 머지 후에도 리뷰를 해줘라.

6. 코드를 남들에게 보여줘라. 코드를 보여주는 건 장점이 꽤 많다. 개발자들은 처음보는 코드에서 나쁜점이나 오류를 더 잘찾아내기 때문에 코드의 문제점을 쉽게 찾아 낼 수 있다.


내 코드가 내 컴퓨터에서만 실행되는 건 아니잖아


10년쯤 전에 우리팀이 처음으로 대형 소프트웨어 프로젝트를 진행할 때, 우리는 java소스파일을 보내줬지만 서버에서 컴파일 되지 않았다. 그 때가 클라이언트 프레젠테이션 몇시간 전이었기 때문에 엄청나게 큰일이었다. 결국 어떻게든 우리는 소프트웨어가 구동되게 만들었고 이건 내 개발 인생의 전환점이 되었다.


앞선 문제는 빌드 pipeline에서 엄청 많은 configuration과 복잡성 때문에 발생했는데, 우리는 이런 시스템의 복잡성을 제대로 관리하고 있지 못했다. 그 날부터 나는 이 과정에서의 복잡도를 줄이기 위하여 내 프로그램을 고립된 환경으로 떼어놨다. 그리고 테스트할 때는 실제로 출시할 환경과 같은 환경에서 테스트했다. 


작년 즈음 docker가 나오고 나서부터는 환경을 통제하는 것이 전보다 확실히 쉬워졌다. docker를 통해 개발, 테스트, 제품을 독립된 환경에서 수행할 수 있게 되었기 때문에 개발이나 테스트 과정에서 발생하는 환경 통제문제를 쉽게 해결할 수 있다.


내 이야기를 조금 하자면, 나는 서버 만들 때나, 초기 환경설정할 때 아니면 linking하는 과정에서 항상 뭔가를 까먹는다. 너무 기억해야할 것이 많다!!! 다행히도 terraform, ansiblepacker같은 출시과정을 자동화주는 툴들이 나와있다. 이들 중에 본인 업무에 가장 잘 맞는 것을 사용하면 된다.


How to survive:


1. 출시 과정의 모든 걸 자동화 해라

2. docker를 활용하여 개발, 테스트, 출시 환경을 통제해라

3. 출시 도구를 활용해라.


출시 끝! 하지만 여전히 나를 못믿겠다!

결국 나는 어플리케이션을 출시했다! 이제 좀 쉴 수 있겠다 싶었는데 아직 뭔가 찜찜하다.


하지만 출시된 어플리케이션 문제들을 쉽게 찾고 고칠 수 있게 도와주는 툴들이 몇몇 있다.


1. Sentry, 유저들중 누군가에게 문제가 생겼을 때 알려준다. 대부분의 프로그래밍 언어를 지원한다.

2. 다른 서비스들을 활용해서 여러 프로세스 상의 로그나 서버에 대한 로그를 한번에 확인할 수 있다.

3. Server monitoring,서버의 CPU, disk, entwork, memory를 총괄적으로 확인할 수 있다. 유저가 진짜 서비스를 망가뜨리기 전에 문제를 찾아낼 수 있다.


쉽게 말하면, 제품화 된 어플리케이션을 모니터링할 필요가 있다. 위에 말한 모든 툴을 한 번에 전부 사용할 때도 있고, 필요한 부분만 사용할 때도 있다.


계속해서 공부해라!

좋은 소프트웨어를 만들기 위해서는 배울 것이 너무 많다. 개발에 왕도는 없다. 단지 매일매일 더 나은 방법을 배울 뿐이다!


끝으로 기본적인 것 두가지를 이해할 필요가 있다.


1. 문제는 누구에게나 생긴다. 중요한 것은 우리가 이런 문제들에 얼마나 대비되어 있는가 하는 것이다.

2. 그리고 이러한 문제의 원인들을 꽤나 줄이는 것이 가능하다.


그리고 기억해라 당신은 개발자로써 마음가짐이나 능력적인 측면에서는 부족한 점이 없다. ;)





안녕하세요 Meeta 매니저 아몬드🤴입니다.

개발자라면 누구나 공감하는 이야기일 것 같습니다.


기존에 나와있는 좋은 툴들을 자유롭게 사용해서 에러를 줄이고, 효율적으로 개발할 수 있는 것도

개발자가 가질 수 있는 중요한 역량이라고 생각합니다 ;)




개발자 포트폴리오를 만드는 단 하나의 솔루션 Meeta.

https://meeta.io


2018/02/20 - [채용소식] - [라온버드] 머신러닝 엔지니어를 채용합니다.

2018/02/20 - [채용소식] - [부동산다이어트] back-end 개발자를 채용합니다.

2018/02/20 - [채용소식] - [화해 - 버드뷰] web 개발자를 채용합니다.



맨위로