🖱️ 개발 경력 14년, 여전히 프로그래밍은 어렵다 (3)

Piglei님의 블로그를 의역/요약한 글입니다. --- 6) 공부하는 것은 좋지만, 방식이 중요하다 요즘은 평생 학습의 시대라고 한다. 특히 개발자들은 이 말에 더 공감할 것이다. 기술은 태생적으로 빠르게 변화하고 지금 사용하는 기술이 3년 후에도 유효할 것이라는 보장이 없다. 좋은 개발자가 되려면 끊임없이 학습하는 것은 선택이 아니라 필수다. 하지만, 한 직군 만 찍어서 보더라도 학습해야 할 범위가 끝도 없다. 예를 들어서, 백엔드 개발자라면 DB, 개발 언어, Redis, 디자인 패턴, 사용자 경험, 네트워크, 분산 시스템, 소프트웨어 개발론 등 알아야할 것이 너무 많다. 다행히 개발자들은 학습하는 것에 거부감을 느끼지 않는다. 오히려 학습하는 것을 좋아하고 의지는 넘친다. 다만, 의지만으로는 부족하다. 학습도 효율적으로 해야 한다. 학습의 효율성을 고려해라. 한 분야를 공부할 때, 학습 초기에는 적은 노력으로 해당 분야의 많은 것을 배울 수 있지만, 깊게 파면 팔수록 하나의 개념을 배우는데 기하급수적으로 더 많은 시간과 노력을 투자해야 한다. 이점을 인지하고 한 분야를 공부할 때, 어느 정도까지 배울 것인지 정하는 것을 추천한다. 지식은 끝없는 바다와 같다. 어떤 분야는 평생 공부해도 다 이해할 수 없고, 어떤 분야는 찍먹만 해도 된다. 우리가 학습에 투자할 수 있는 리소스는 한정적이기에 어떤 분야를 어디까지 배울 것인지 생각해서 전략적으로 배워야 한다. 본인에게 맞는 학습 방식을 선택하라. 학습 분야와 정도를 정했으면 다음 단계는 적절한 방식을 찾는 것이다. 경험을 공유하자면, 난 제품 인터랙션 디자인에 관심이 생겼고 필요성을 느껴서 해당 분야를 배우려고 했다. 이때 내가 선택한 방식은 해당 분야를 심층적으로 설명하는 고전 서적을 구매해서 읽는 것이었다. 다만, 나의 수준에 맞지 않아 첫 장을 넘기지도 못했다. 이 때의 실패로 나는 이후 다른 분야를 공부할 때 입문서를 먼저 읽어보는 것으로 항상 시작한다. 지식도 과유불급이 될 수 있다. 아마 모두가 최대한 많은 지식을 습득하고 싶을 것 이다. 하지만 명심해라, 우리의 학습 리소스는 제한적이고 모든 분야에서 전문가가 될 수도 없고 될 필요도 없다. 7) 단위 테스트는 가급적 빨리 작성해라 난 단위 테스트를 정말 사랑한다. 나의 개발 커리어는 단위 테스트를 작성하기 전과 후로 나뉜다고 볼 수 있다. 그리고 후자가 더 흥미롭고 재밌었다. 단위 테스트의 이점은 정말 많다. 가령, 다른 관점으로 코드 설계를 하게 해주고, 코드를 위한 문서 역할을 하기도 하며, 앞서 말한 시행착오가 가능한 환경을 만들어주는데 필수 요소기도 하다. 이미 단위 테스트에 대한 글은 많이 썼으니 더 논하지는 않겠다. 다만, 만약 유닛 테스트를 한번도 작성해본 적이 없다면, 당장 내일부터 작성해봐라. 8) 개발자의 가장 큰 적은 무엇인가? 개발 밈을 살펴보면 대게 프로덕트 매니저들이 빌런으로 비춰진다. 그들은 항상 프로젝트 요구 사항을 바꾸며, 새로운 아이디어를 매일 분출하고, 개발자들의 인생을 힘들게 한다. 이런 밈을 보고 있노라면, 그저 일 열심히 하는 프로덕트 매니저들이 개발자들에게 가장 큰 적으로 보이기도 한다. 프로덕트 매니저만 없었으면 마치 일하는 환경이 유토피아로 변할 것 만 같다. 이런 밈들이 유쾌하기는 하지만, 프로덕트 매니저는 개발자의 적이 아니다. 소프트웨어 개발이라는 것 자체가 원래 변화하는 것이다. 왜 애초에 소프트웨어 이겠는가? 소프트웨어 개발은 애초에 허물고 다시 짓는 것을 반복하는 일이다. 그러니 프로덕트 매니저와 끊임없이 바뀌는 요구 사항은 개발자에게 가장 큰 허들이 아니다. 오히려 이런 변경 사항을 유연하게 대처할 수 있게 코드를 잘 관리하는 것이 좋은 개발자와 그저 그런 개발자를 분별하는 척도가 된다. 그럼 개발자에게 가장 큰 적은 무엇일까? 복잡성이다. Code Complete에서 기술한 것처럼 소프트웨어 개발은 그저 복잡성 관리다. 관리되지 않은 복잡성이 개발자의 주적이다. 프로젝트 복잡성을 끊임없이 증가 시키는 몇 가지를 살펴보자: * 끊임없이 추가되는 기능: 기능은 새로운 코드를 의미한다. 새로운 코드는 보통 복잡성을 증가시킨다. * 가용성: 높은 가용성을 구현하려면 메세지 큐와 같은 추가적인 기술과 코드를 사용하게 된다. * 성능: 성능 향상을 위해서 캐싱 등 관련된 모듈이 여럿 추가되고, 몇 몇 모듈은 좀 더 빠른 개발 언어로 다시 쓰여지기도 한다. * 우선순위에서 밀리는 리팩토링: 빡빡한 프로젝트 일정으로, 급한 리팩토링이 우선순위에서 밀리며 기술 부채가 늘어난다. * 테스트 자동화를 경시: 아무도 단위 테스트 또는 테스트 자동화를 하지 않는다 이렇게 일을 하다 보면, 어느 순간 아무도 건드리기 싫은 기술 부채가 떡하니 IDE에 뜨게 된다. 과연 누구 잘못일까? 복잡성을 늦추는 방법 복잡성 증가는 피할 수 없다. 하지만 늦추는 방법은 여럿 존재한다. 모두가 노력한다면 복잡성은 감당 가능한 수준으로 유지 될 수 있다. * 사용하는 개발 언어와 툴을 학습하고 클린 코드를 작성하려고 노력해라 * 적절한 디자인 패턴 및 패러다임을 사용해라 * 코드 복붙에 무관용 원칙을 적용하고 라이브러리나 프레임워크를 추상화하라 * 클린 아키텍처와 도메인 주도 디자인 원칙을 제대로 적용해라 * 문서화와 주석을 잘 활용하라 * 효율적이고 효과적인 단위 테스트를 작성하라 * 변경하는 것과 그렇지 않는 것을 잘 구분하고 분리해라 리스트는 끝도 없지만 한 마디로: 더 좋은 코드를 짜라. --- (끝) 원글: https://www.piglei.com/articles/en-programming-is-still-hard-after-14-years/