상위 1% 개발자들이 지키는 7가지 습관
1. 코드에 대한 애착이 없음
- 1% 개발자는 최종 결과물에 개선점이 있을 수 있다 하면 지금까지 짠 90% 코드를 날리고 다시 짠다 하더라도 두려움이 없다고 합니다.
- 쉽게 말해서 일주일 동안 내가 열심히 짠 코드를 배포까지 준비했는데,
- 라이센스가 바뀌어서 다시 짜달라고 했을 떄, 처음부터 짜는거를 두려워하지 않고 싫어하지 않는다 합니다.
- 왜냐면은 이제 코드에 대한 애착이라는게 없다 보니까 피드백을 적극적으로 받아드리는 거겠죠.
- 그리고 글을 좀 더 요약하면 코드는 완벽하지 않고 아무도 완벽한 코드에 관심을 두지 않는다는 걸 잘 알고 있다고 합니다.
- 사실 오로지 변화를 가져오는 코드에 관심이 있다고 하네요.
- 여기서 코드에 집착하지 않도록 스스로 가르치는 방법은 20년 후에 코드는 대부분 기술 부채가 되거나 더 이상 사용되지 않을 가능성이 높다는 걸 깨닫는 거라고 합니다
- 실제로 회사에서 한 달 동안 열심히 만든 코드가 있었는데,
- 회사가 사업적인 방향성이나 여러 다른 요인에 의해서 방향이 바뀌면서 그 코드가 통째로 필요 없어지는 경우도 꽤 많거든요.
- 이때 훌륭한 개발자는 감정에 동의 없이 다시 코드를 짤 수 있는 그런 사람이겠죠
2. 인간을 위한 코드 작성
- 여기서 말하는 인간은 앱을 사용하는 사용자라고 합니다.
- 이게 무슨 말이냐면 제품 중심으로 사고를 한다는 뜻인데요.
- 결국 우리가 짠 코드는 문제를 해결하고 사용자에게 기능을 제공하는 일이기 때문에
- 즉 사용자를 위한 코드를 작성한다고 합니다.
- 심지어 고객이 한 명이라도 고객 중 한 명이라도 만족시키지 못했다면 그 그 코드는 제품으로 출시되지 못합니다.
- 그리고 사용자뿐만 아니라 팀 동료들도 이해하기 쉬운 코드를 작성한다고 합니다.
- 왜냐면은 내가 작성한 코드를 결국에 읽고 이해하고 수정하는 사람들은 옆에 있는 동료니까
- 참고로 미래에 나도 포함된다고 합니다
- 왜냐면 내가 짱 코다 내가 수정하는 일 많으니까요
- 한마디로 요약하면
- 누구나 컴퓨터가 이해할 수 있는 코드를 작성할 수는 있지만 훌륭한 개발자는 인간이 이해할 수 있는 코드를 작성한다
3. 간단한 코드 작성
- 기능적으로는 복잡하지만 결국에는 뭔가 읽기 쉬운 코드를 작성한다고 합니다
- 코드가 미적으로 만족스럽다고 하네요.
- 코드가 어떤 아트도 아니고 미적으로 아름답기 쉽지 않잖아요.
- 근데 실제로 회사에서 코드를 잘 짜는 분의 코드를 보면은 미적으로 만족스럽다.
- 코드에서 내린 결정 사항들은 합리적이고 만약 그게 아니라면 문서화가 잘 돼 있다고 합니다.
- 코드를 읽다가 이거 왜 이렇게 작성했을까 의문이 드는 부분에 설명을 주석으로 누가 달아둔 걸 보면은 의도를 일단 파악하기도 쉽고요
- 오해도 없어지더라고요
- 이어서 간단한 코드 작성을 위해서 솔리드 원칙을 따랐다고 합니다
- SOLID
- Single Responsibility: 한 클래스는 하나의 책임만 가져야 함
- Open-Closed: 소프트웨어 객체(클래스, 모듈 등)는 확장에는 개방적이지만 수정에는 폐쇄적이어야 예측 가능하고 유지 관리 가능한 코드를 만들 수 있음
- Liskov Substitution: 하위 유형은 프로그램의 정확성에 영향을 주지 않으면서 기본 유형으로 대체할 수 있어야 함
- Interface Segregation: 코드가 모든 것을 사용하지 않는 거대한 인터페이스에 종속되어서는 안 됨. 대신 패키지는 더 작은 특정 인터페이스를 포함하고 임포트할 수 있도록 허용해야 함
- Dependency Inversion: 상위 레벨 모듈이 하위 레벨 모듈에 종속되어서는 안 되며, 둘 다 추상화에 종속되어 보다 유연하고 분리된 시스템 설계를 촉진해야 함
4. 일관된 표준 사용
- 쉽게 말해서 변수명을 짓는 방식이나 함수명을 짓는 방식, 들여쓰기를 몇 칸으로 할지 이런 것들이겠죠
- 이게 왜 중요하냐면 어쨌든 일관된 코딩 스타일 덕분에 내가 작성한 코드를 누가 읽던 방금 입사한 사람이 읽던
- 아니면 타 회사의 사람이 읽든 아니면 옆에 사람이 읽던 수정하기가 쉽고 결과를 예측 가능하기 때문에 코드의 주인이 없어지게 돼요
- 그래서 생각해 보면은 구글이나 페이스북에서 이런 코딩 스타일 같은 걸 만들어서 기업에 올리는 거는 다 이유가 있는 거예요
5. 예측 가능한 코드 작성
- 코드가 얘기치 하는 결과를 가져오지 않는다는 겁니다
- 쉽게 말해서 코드가 한 번 실행이 되든 1천번 만 번 실행이 되든 같은 결과를 만드는 거죠
- 그럼 대체 어떻게 하면 코드가 예측이 가능하냐라고 말씀하시면,
- 원칙을 따르고 적절하게 테스트하는 거라고 합니다 쉽게 말해서 자동화 테스트 를 구축한 다음에
- 팀이 코드에 변경을가 있을 때 안전하게 할 수 있도록 해야 한다고 하네요
- 왜냐면은 자동화 테스트가 없으면은 내가 특정 부분을 수정을 하고 커밋을 하고 푸시를 했어요
- 근데 이게 버그를 만드는지 아닌지 알 수가 없으니까,
- 적극적으로 누구나 코드를 수정하려면 자동화 테스트를 잘 해놔야겠습니다
6. 자주 소통하기
- 1% 상의 개발자들은 어쨌든 시스템이라는 거는 혼자 만들 수 있는게 아니라는 걸 안다고 합니다.
- 일단 시스템 만드는 절차를 좀 얘기해 보면 일단 첫 번째 설계를 검토를 하고,
- 피드백을 요청하고 코드에 대한 초기 설계를 계속 반복한다고 합니다.
- 누구나 자신의 지식에는 다른 사람이 채워줄 수 있는 빈틈이 있기 때문에,
- 자주 소통하면서 새로운 관점으로 코드를 더 명확하게 만들고
- 이전에 생각지 못한 새로운 접근 방식을 사용할 수 있다고 하네요.
- 쉽게 말해서 자주 소통하면서 피드백을 적극적으로 수용한다 뜻이겠죠.
- 그리고 피드백을 수용했으면 또 설계를 검토를 하고 또 수정을 하고 이런 하나 이터레이션을 짧게 만드는 거겠죠.
- 그리고 의사 소통이라는게 뭔가 별게 아니고
- 문서에 대한 빠른 검토를 요청하거나 코드 리뷰 풀리퀘스트를 요청하는 거라고 합니다
7. 빠르게 그리고 느리게 코딩
- 최고의 개발자들은 프로젝트를 빠르게 완료하지 코딩 그 자체는 느리게 한다고 합니다.
- 이게 무슨 뚱딴지 같은 소리냐 앞에서 설명한 그 모든 원칙이란 습관을 지키다 보면,
- 어쨌든 뭔가 첫 번째로 코딩을 작성하기 지에는 긴 시간을 들게 하겠죠.
- 왜냐면은 지켜할게 많다 보니까 코드 자체를 치기까지 드는 시간이 긴 거예요.
- 하지만 이 원칙을 적용함으로써이 프로젝트의 진행 상황을 한 단계에 더 발전시킬 수 있다고 합니다.
- 큰 그림을 그리는 거겠죠.
- 정리해서 바로 코드를 작성하기다는 표준을 사용하고 적절히 테스트하고
- 원칙을 사용하고 자주 소통하는데 시간을 하려함으로써 장기적으로는 더 많은 시간을 절약한다고 하네요.
- 훌륭한 시니어 분들은 뭔가 급하게 코딩을 하진 않아요.
- 2보 전진을 위한 1보 후퇴 같은 방식으로 일을 하시더라고요.
- 요약하면 프로젝트를 빠르게 완료하지 코딩 그 자체는 느리게 한다
- 왜냐면 바로 코드를 작성하지 않고 표준 사용 적절한 테스트 원칙 사용 자주 소통 이런 걸 하는데 있어서
- 시간을 많이 해서 장기적으로 더 많은 시간을 절약한다