개발자가 가져야 할 자질과 좋은 코드

Sheryl Yun·2023년 12월 19일

생각거리

목록 보기

2/2

벨로그 leehyunho2001님의 회고글들이 너무 좋아서 읽다가 요약해본 글

React와 Vue는 도구일 뿐 어떻게 잘 사용하느냐는 다른 문제
아직도 대세를 따라가는 생각은 유효함
- 커다란 생태계가 있어 좋은 레퍼런스들이 많음
- 실제로 많은 회사에서 사용하고 있어 이직에 더 수월
그런데 공고들을 살펴보면 재밌는 사실을 하나 알 수 있다.
- 특정 프레임워크/라이브러리보다 앵귤러, 뷰, 리액트와 같은 'SPA' ~~ 와 같은 멘트들이 많이 보인다는 것이다.
- 즉, Front를 개발하기 위해 도구보다 더 중요한 것이 있다는 의미이다.
  - 그것 중 하나가 바로 개발자적인 사고 방식

=> 이러한 능력들이 갖춰져 있을 경우, 새로운 프레임워크나 라이브러리를 사용 하더라도 공식 문서를 보며 효율적인 패턴을 금방 찾고 익숙해진다.

= 가독성이 좋은 코드

무작정 코드부터 작성하는 것이 아니라, 여러 측면으로 문제를 바라보기
- 그 후에 동료 개발자와 방향성에 대해 논의
- 내가 생각도 못한 곳에서 좋은 지적이 나오는 경우에는 "~~님은 어떤 식으로 접근해서 그런 생각에 도달하셨나요?" 라고 질문
소통을 통해 아직 내가 가지지 못한 좋은 사고 방식 알아가기

기획이나 디자인이 나오면, '아 이거는 안될 것 같은데..' 라는 부분이 있다.
- 대부분 '이 기간까지는 안될 것 같은데..'
- 혹은 사용하고 있는 '서드 파티에서 거기까지 커스텀은 안 되는데..' 등
먼저 어떤 이유에서 안될 것 같다고 생각했는지
- 설계된 서비스의 구조상 불가능하다면, 기획이나 디자인 회의에서 확실하게 말하기
  - 이때 '정말 안 되는 것인지' 팩트 체크 꼭 하기
- 비개발 직무는 이해하기 어려운 내용이더라도, 어떤 이유에서 불가능한지 최대한 쉬운 비유를 들며 공유
그렇다면, 기간 혹은 오버 엔지니어링이 필요한 까다로운 조건들이 이유인 경우에는 어떻게 소통을 하면 될까?
- 여기서부터는 의사소통 능력이 매우 중요
- 그냥 안 된다고만 말하는 것이 아니라 새로운 방법을 제안한다.
- 생각해보면 무작정 안 된다고 하는 것은, 기획자나 디자이너 입장에서는 대화 단절 = 말하고 있는데, 조용히 하라는 것과 다를 게 없다.

이번에 개발해야 할 Feature 에서 여러 기능 중에 A라는 기능이 있다. 기간 안에 안 될 것 같은 기능을 A라고 해보자.

소통하기 전에 A가 정말 필요한 기능인지 판단
- 모두 개발하면 좋지만, 시간은 한정적이기 때문에 더 중요한 부분에 힘쓰는 것도 방법
정말 필요한 기능이라면,
- 현재 상황에서 A기능을 더 간단하게 구현할 수 있는 방법
- 또는 A기능과 유사한 효과를 내는 기능 생각해보기

나보다 높은 연차의 개발자와 일하는 구도라면 소통해야 하는 과정에서 무조건 수긍하는 자세가 될 수 있다.
- 개발 중 에러가 발생하더라도, 내가 어디를 잘못 작성했나보다 라는 생각부터 들 수 있다.
- 나보다 회사의 서비스에 대해 깊은 이해가 있고, 실력 있는 개발자가 말한 거니까 라는 생각 때문에
하지만 문제가 생겼을 때 이처럼 과하게 수동적인 태도는 좋지 않다.
- 일의 효율을 떨어뜨릴 뿐더러 소통이 아닌 일방적인 상황이 된다.
- 내가 생각하고 있는 논리와 상황을 상대방에게 잘 전달하도록 하자.
- 합리적이라면 받아들여지고, 아니라고 한다면 나의 논리에 반박하는 대답이 돌아올 것이다.

요약을 하려 했는데 좋은 내용이 너무 많아서 가져와버린 문구가 많습니다..
=> 전체 내용은 아래 leehyunho2001님의 원본 글 참고