개발자 원칙 책 리뷰 :: 마이구미

이 책은 "개발자 원칙" 책을 리뷰한다.
본인은 평범한 프론트엔드 개발자이다. 개인적인 생각과 해석이 들어가 있을 수 있다.
책 링크 - https://product.kyobobook.co.kr/detail/S000200381165

 

 

이 책의 목차를 살펴보면, 섹션별로 각자의 이야기를 다룬다.

9인의 실무자들의 경험과 피드백을 간접적이나마 들을 수 있을 것 같아 도서를 구매하게 되었다.

 

개인적으로는 크게 와닿는 내용이 많지 않아서 막 흥미롭게 읽지는 못했다.

다 좋은 내용들이지만, 대부분 이미 알고 있는 것들이지만 실제로는 행동하지 못하는 것들...

그래도 누군가에게는 다시 한번 상기시켜줄 수 있는 이야기, 좋은 피드백이 될 수 있는 내용들이라고 생각한다.

 

좋았던 건 각 섹션의 마지막에는 섹션 내용과 관련된 책들을 추천해주고 있다.

좀 더 깊게 알고 싶거나 흥미로웠던 섹션이라면 추천해주는 책들을 읽어보면 좋을 것 같다.

 

책에서 도움이 되었던 내용들과 본인의 생각들을 기록해놓고자 한다.

 

---

 

단순한 문자열 비교는 타이밍 공격에 취약하기 때문에 문제가 된다.

 

타이밍 공격은 코드가 실행되는 시간 차이를 측정하여 비밀 정보를 추측하는 공격입니다.

두 문자열을 비교하는 과정에서 걸리는 시간 차이를 통해 민감한 정보를 유출할 수 있다는 의미입니다.

 

개인적으로는 새로운 시각으로 바라볼 수 있는 내용이였다.

암호처럼 보안이 중요한 분야에서는 비교 속도가 균등하지 않으면 문제가 발생한다.

성공하든 실패하든 같은 시간에 응답을 주는 방법으로 구현해야한다.

 

 

코딩 테스트는 최소 프로그래밍 역량을 확인하는 수준이 바람직하다.

 

이미 대부분 공감하고 있는 내용일 것이다.

그래서 대부분 코딩 테스트의 난이도는 크게 어렵지 않은 수준으로 진행되고 있다고 생각한다.

 

하지만 간혹 코딩 테스트의 목적에 벗어나는 상황들을 볼 수 있다.

예를 들어, 변수명이나 코드 스타일을 체크하는 것이다.

물론, 작성된 코드를 통해 지원자의 사소한 습관과 스타일을 볼 수 있다고 생각할 수 있다.

하지만 개인적으로는 주어진 시간내에 빠르게 동작하는 정답을 찾는 상황에서 나온 코드가 그 사람의 습관과 스타일을 대변할 수 있다고 보기는 어렵다고 생각한다.

 

제어할 수 없는 것에 의존하지 않기

 

 

굉장히 좋은 원칙이라고 생각이 들었다.

책에서 설명한 예 중 하나로는 주민등록번호였다.

PK 로 주민등록번호를 사용하고 있었는데 법 개정으로 인해, 주민등록번호와의 의존성을 끊는 작업을 진행할 수 밖에 없었다고 한다.

어떤 값에 의존하는 경우가 생긴다면, 해당 값이 정말 우리가 제어할 수 있는 것인지 신중하게 생각해봐야겠다.

 

그리고 책에서는 해당 원칙은 현실에서의 이직에 대해서도 적용하였다.

많은 부분에서 좋은 원칙으로 활용할 수 있을 것으로 보인다.

개인적으로 스타트업으로 이직을 고민할 때, 투자금에 대해 많이 비중을 두었다. 

하지만, 이건 사실상 내가 제어할 수 없는 영역이기에, 다른 부분들을 더 고민하는 것이 더 낫지 않았을까 생각해보게 되었다.

 

FIXME 태그

 

지금까지는 TODO 태그를 활용하고 있었다.

추후에 작업해야하거나, 개선 필요성이 있는 곳들이 보인다면 TODO 태그를 작성해놓고, 관리하곤 했다.

책에서 언급된 내용중 하나로 FIXME 태그의 존재를 처음 알게 되었다.

동료들과 공감대가 형성된다면, 2가지를 구분해서 활용하면 효율적으로 사용될 수 있을 것이라고 본다.

 

둘의 차이를 간단히 요약하면 다음과 같습니다:

• TODO: 앞으로 할 작업을 남겨두는 표시로, 새로운 기능이나 향후 개선을 염두에 둔 경우 주로 사용합니다.
• FIXME: 현재 코드의 오류나 반드시 수정해야 할 문제점을 명시하는 태그로, 해결하지 않으면 코드가 의도대로 작동하지 않거나 문제가 발생할 가능성이 있는 경우 사용합니다.

FIXME를 사용하는 이유는 우선순위를 부여하기 위해서입니다. FIXME는 꼭 해결해야 하는 문제임을 나타내기 때문에 팀원들이 TODO와 구별해 확인하고 수정할 수 있습니다. 예를 들어, FIXME는 버그나 성능 문제, 예외 처리가 필요한 부분 등 즉각적인 조치가 필요한 부분을 나타내며, 나중에 추가하고 싶은 기능 등은 TODO로 남겨놓습니다.

TODO와 FIXME를 모두 적절히 사용하는 것은 코드 관리에 도움을 주며, 특히 코드 리뷰 시 개선할 부분을 효율적으로 파악할 수 있게 해 줍니다.