0w0

주니어 개발자에게

글

이 글은 많은 가치있는 개념을 다루고 링크하고 있으므로 마음가는대로 더욱 탐구해주시길 바랍니다.

글은 3개의 세션으로 나눠있습니다.

일반적 조언

  1. 코드는 중요한 것이 아니다.

우리 개발자는 코드를 적는 것을 좋아합니다. 대부분은 확실한 태스크를 부여하고 싶다 생각하고요. 다른 것을 보지 못하고 단지 즐겁게 기술적인 퍼즐을 풀고 싶습니다.

문제를 풀기 위해서는 상응하는 노력이 필요합니다. 피터 드러커의 말처럼 빌릴자면 "절대 하면 안될 것을 효율적으로 하려는 것 것만큼 낭비가 없다" 입니다. 실제 유저에게 지속적으로 전달해서 빈번히 피드백을 모을 수 있습니다. 바로 애자일입니다.

소프트웨어 개발에는 비용이 드며, 현실 프로젝트의 노력의 대부분은 관리에 드는 것이 일반적입니다. 이에, 유저나 비즈니스 성과를 목표로 하고 있다면 종종 노코드가 최상의 코드일 수도 있습니다. 빌 게이츠의 말을 빌리면 "프로그래밍의 진취를 코드 행수로 측정하는 것은 비행기 생산을 무게로 측정하는 것이다"

같이 보기: YAGNI, KISS, The Last Responsible Moment.

  1. 소프트웨어 디자인에 관하여.

제 개발 커리어 첫 5년간은 소프트웨어 디자인은 소프트웨어 아키텍처나 다른 특별한 역할을 가진 사람을 위한 것이라 생각했습니다. 저는 "완성에 초점을 두자"에 집중해 소프트웨어 디자인이나 테스트를 쓰기 등 모범사례의 중요함을 눈치채지 못했습니다. 그리고 코드는 움직였고, 많은 것을 달성했다 생각했습니다.

그러다 클린 코드를 읽었습니다. 이 책은 소프트웨어 설계에 관련해 눈을 뜨게 해줬으며, 예제나 많은 기술적 휴리스틱을 포함하고 있었습니다. 가장 큰 수확은 "가장 빠르게 가는 방법은 바르게 가는 것이다." 이 말입니다. 다르게 말하면 난잡하게 만들면 그만큼 느리게 가는 것입니다.

같이 보기: TradableQualityHypothesis, DesignStaminaHypothesis

디자인성 높은 클린 코드를 배우는 것에는 물론 시간이나 노력이 필요합니다. 그리고 시작한다하더라도 느려지고 실수도 합니다. 단순함은 쉬게 얻을 수 없습니다.

  1. 모범사례를 사용하라.

테스트를 적는 것이 이득일 경향이 있습니다. 예외도 있지만 거의 대부분은 자동적으로 테스트를 매우 합리적입니다. 테스트를 적는다는 것은 모범 사례의 일부입니다.

테스트를 적는 것이 처음이라면 우번 모범 사례를 따라 테스트를 적어보세요. 맨 처음에는 모범 사례를 맹목적으로 따르겠지만, 자신의 미숙함을 따르는 것보다는 나을 것입니다. 그러다보면 효율적으로 테스트를 적는 방법을 배우고, 자신이 실패한 것인가 테스트를 적을 가치가 있는 것인가 구분할 수 있을 것입니다. 또한 디버그 회수도 적어지며 테스트에 의해 심리적 안정을 가지고 리팩터링하는 경험을 얻을 수 있습니다. 이 경험으로 인해 테스트가 어떤 가치가 있는가 직감적으로 이해될 것입니다. 판단력을 기른 후에는 모범 사례를 초월할 수도 있겠지요.

이 조언은 당신이 주니어인 어떤 분야에서도 모범 사례에 해당합니다. 자동화된 테스트는 아주 일부겠지만요.

문제는 현명하게 모범 사례와 무의한 것 혹은 역효과의 차이를 구별하는 것이 어렵다는 것입니다. 이는 기존 코드가 혼잡되어 있기에 이며, "경험 풍부한 개발자나 "시니어" 개발자를 포함해 좋은 멘토를 갖는 것는 것이 소중한 일이기 때문입니다. 그렇기에 좋은 멘토를 갖는 것은 상당히 가치있는 일입니다. 그 밖에 저의 경험에 기반에 조언을 하나 한다면, 사용하고 있는 언어나 프레임워크 커뮤니티 특유의 모범사례에 주의하시길 바랍니다. 수십년 전부터 지식을 쌓아올린 것을 찾길 바랍니다.

기술적 조언

이제부터는 기술에 집중보겠습니다. 건강, 행복, 커리어, 소프트스킬 등 다른 많은 분야도 중요합니다. 기술적인 함정을 피하는 방법을 알아도 수면부족, 낮은 급여와 나쁜 상사때문에 그른 일에 엮인다면 아무 것도 할 수 없습니다.

  1. 테스트를 적어라.

자동화된 테스트를 적습니다. 테스트 주도 개발(TDD) 등에서는 코드 적기 전에 테스트를 적기도 합니다. 이에 당신 코드가 옳은가 어떤가 지속적으로 검증하기 쉬워지며 수작업 반복 테스트나 디버그 수고도 적어집니다.

테스트 적기가 어려운가요? 디버그 애프터를 해보세요.

가장 중요한 것은 테스트 코드는 리팩터링할 때 안전망을 피는 것입니다. 그리고 코드의 아름다움을 유지하기 위해 지속적으로 리팩터링이 필요합니다. 신뢰할 수 있는 테스트가 없다면 당신의 코드는 부패할 가능성이 높아집니다.

코드 재이용을 위해 계승이나 스태틱 함수를 사용 등 코드 설계가 나쁘다면 테스트를 적는 것이 어렵습니다. 한 편, 글로벌에 의존하지 않은 SOLID 클래스라면 테스트 쓰기가 그리 어렵지 않을 것 입니다.

테스트 설계는 중요합니다. 왜냐면 대충 쓴 테스트를 적으면 속도가 떨어지기 때문입니다. 테스트 대상의 코드 구현이나 시스템 구조에 얽매이지 않도록 합시다. 목을 너무 사용하지 않도록하며, 좋은 방법은 테스트 더블을 적는 것입니다.

  1. 코드 재사용을 위해 계승을 사용하지 말아라.

이는 모범 사례 중 하나로, "모범 사례를 사용하라"를 떠올리게 할 것입니다. 제 조언으로는 코드 재이용하려면 계승은 애초에 쓰지 말아 주십시오. 드물에 옳게도 되지만, 대부분의 경우 유해할 것입니다. 계승보다 합성을 우선해주세요.

  1. 객체지향으로 코드를 적어라.

STUPID가 아니라 SOLID 코드를 적읍시다. 이 원칙과 안티패턴을 이해하는 것은 상당한 가치가 있습니다.

실제 객체를 만들어봅시다. 스태틱 메서드만으로 구성된 클래스는 OO가 아닙니다. 스태틱 코드는 최대한 피해야합니다.

같이 보기: SOLID 관한 제 주장

  1. 함수형으로 코드를 적어라

(함수형 프로그래밍과 명령형 구조 프로그래밍을 혼동하면 안됩니다.)

이는 함수형 언어로 완전히 갈아엎으라는 말이 아닙니다. OO 언어로 함수형 스타일을 사용하는 것도 유익합니다. 상태, 특히 변경 가능한 상태를 최소화하며 함수는 하나의 기능만 하도록 합시다.

같이 보기: functional core, imperative shell.

  1. 지식을 기반한 복붙.

코드를 큰 덩어리째로 복붙하는 것은 거의 대부분 현명한 일이 아닙니다. 자존심 있는 개발자라면 이를 깨우치고 어떠한 형태로든 Don't Repeat Yourself (DRY)를 실천할 것입니다. 하지만 안타깝게도 의도적으로 DRY를 추구하다보니 과잉 엔지니어링이나 우발적 복제화를 일으킵니다. 이에 DRY에 상극하는 Write Everything Twice (WET)도 등장했습니다.

중복 배제로 인한 비용과 이점에 대한 상세한 고찰은 "DRY의 오해"를 참조하시길 바랍니다.

  1. 자료형, 이름 그리고 주석.

자기 기록적인 코드를 적으며, 주석을 피하세요.

주석을 적을 때마다, 자신의 표현력이 없음을 통감하며 스스로에게 실소를 하시길 바랍니다. -- Robert C. Martin

주석은 거짓말하기 십상이므로 위험합니다. 주석이 갱신되지 않은채 코드만 변경될 가능성도 있습니다. 새로운 코드가 주석 바로 밑에 추가될 수도 있습니다. 주석은 애초에 잘못되거나 부정확하기도 합니다. 이러한 일이 일어나면 주석은 도움이 보다 오해를 불러일으키고는 합니다.

자기 기록적인 코드를 적으세요:

Clean Code by Robert C. Martin 에는 명명이나 주석에 관한 좋은 이야기가 있습니다.

읽을거리

도서

블로그

같이 보기: 개발자 읽을 거리 추천을 확인해주세요 by Jeff Atwood

보너스 링크

저자에 대해

Jeroen De Dauw는 Wiki 호스팅 서비스를 제공하는 Professional Wiki CEO입니다. 가끔씩 software design blog에 글을 올립니다. 내키시면 저를 팔로우해주세요.