본문 바로가기
Book & Lesson

[책] 더 나은 프로그래머 되는법 Part2. 연습을 통해 완벽해진다

by 카프리썬_ 2024. 5. 13.
728x90
728x90

 

아래 글은 <더 나은 프로그래머 되는법>을 읽고 요약한 내용이며 개인적인 생각이 담겨있습니다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.


     

    Ch14. 소프트웨어 개발이란 

    소프트웨어 개발은 예술이다. 
    일부 프로그램은 우아하고, 어떤것은 절묘하며, 어떤것은 빛이 난다. 
    뛰어난 코드를 작성하고자 하는 프로그래머는 좋은 취향과 미적감각을 지녀야한다. 

    소프트웨어 개발은 과학이다. 
    좋은 개발은 코드를 뱉어내는 카우보이식 코딩이 아니다.
    신중하고 심사숙고하며 정확한 노력의 산물이다. 

    소프트웨어 개발은 스포츠다.
    목표로 하는 비전을 공유하고 높은 수준에서 각자의 기능을 담당하며 조직을 형성한다. 

    소프트웨어 개발은 아이들 놀이다. 
    아이들은 아직 배우는 과정이며, 모든것을 알지 못한다. 
    협업하기 가장 어려워보이는 사람은 자신이 모든것을 알고 있다고 생각하는 사람들이다.
    좋은 프로그래머는 겸손한 자세로 일한다. 그들은 자신이 모든것을 알지 못한다는 점을 인정한다. 
    아이들처럼 끊임없이 이유에 대해 질문해야한다. 그리고 작업물에 대해 간결함을 추구해야한다. 

     

    개발이 아이들 놀이같다는 부분에 띵했다.
    애기들이 왜?라는 궁금증을 매번 내는것과 같고, 단순하고 즐기는것 또한 동일하다. 
    그리고 배우는 과정이고 모든것을 알지못하는 애기들이 노느것과 똑같다는 표현이 재밌었다. 

     

    소프트웨어 개발은 집안일이다. 
    집안일처럼 단조롭고 고된일이다. 하지만 집안일을 두려워해서는 안된다. 어려운 일임을 인지하라. 

    제품을 출시하고 오래된 지저분한 코드에서 오류를 찾아 수정하는 지루한 작업을 종종해야될때도있다. 

     

    집에서 청소하는건 좋아하면서 왜 코드 청소하는건 그렇게 귀찮을까?ㅎ

     

    Ch15. 규칙 가지고 놀기

    코드스페이스에서 따라야하는 넓은 범위의 규칙이 있다. 개발표준,도구,작업흐름, 사내규칙, 디자인패턴 같은 것.

    무엇을 하고 어떻게 하는지를 정의하는 규칙이다. 코딩문화를 설명하는 규칟이기도 하다.

     

    좋은코드를 작성하기 위한 규칙 

    - 간결하게 하라.

    -  머리를 쓰라.

    - 변하지 않는 것은 없다. 

     

    모하게 구두로 전해지는 팀 규칙에 의존하지 마라. 무언의 규칙을 명백하게 만들고 코딩문화를 만들어라. 

     

    Ch16. 간결하게 하기 

    간결한 코드는 설계하는데 많은 노력이 든다. 다만 간결한 코드가 과도하게 단순한 코드를 의미하진 않는다.

     

    간결한 설계는 빠르게 묘사할 수 있고, 쉽게 이해할 수 있다. 

    간결한 설계는 가능한 작은 크기로 이루어진다. 

    간결한 설게는 오용하거나 악용하기 어렵다. 

     

    딱 필요한 만큼의 코드만 작성하라. 무엇이든 추가하는것은 복잡하고 짐이 된다. 

    글을 쓸때도 짧고 간결하게 쓰는게 중요하다고 생각한다. 글쓰기와 코드가 이렇게 유사할수가!

     

    Ch17. 머리 쓰기 

    Kiss 규칙. Keep it Simple, Stupid (단순하게 해 바보야)

    바보같은 코드를 작성하지 마라.

     

    하지만 모두 실수를 하니, 누구의 코드도 언제나 완벽할수 없다.

    멍청한 코드를 작성했다는걸 깨닫고 실수를 인정하고 다시 배워라. 

     

     이 부분에서 갑자기 따뜻한 위로..감동...
    당연히 바보같은 코드를 작성할수 있다.하지만 내가 바보같았네ㅜ하는걸 인정하고 다시 새로 배우면 된다.
    다음번에는 안그러려고 더 노력하면 된다! 

    Ch18. 변하지 않는 것은 없다. 

    코드 내부구조는 더이상 다뤄서는 안되는것을 취급한다. 왜냐? 두려움 때문이다. 

    잘못될지도 모른다는 두려움, 추가업무에 대한 두려움, 수정비용에 대한 두려움.

    하지만 소프트웨어는 단단하지 않고 부드러워야한다.

    그러나 개발자들은 두려움을 느끼고 코드를 깨뜨리지 않도록 하려고 하니 코드를 얼어붙게 만든다. 소프트웨어의 사후경직.

     

    이 두려움에 대해서 너무 부끄러울정도로 너무 공감이 되었다.
    바꿔야하는데, 수정해야하는데, 잘못될지도 모른다는 두려움 때문에,
    용기가 없어서 수정하지 못하고 흐린눈하고 넘어간게 많았다. 

     

    그냥 대담하게 수정하라. 물론 실패할지도 모르고 잘못될수도 있다. 

    그러나 언제든지 코드를 정상적인 상태로 되돌릴수 있도 다시 시도하면 된다. 

    수정에 필요한것은 무모함이 아니라 용기와 기술이다.

     

    떄로는 광범위하게 코드를 수정하는것보다 자주 조금씩 검증할 수 있는 수정을 하는 편이더 낫다. 

    자동화된 테스트코드는 수정에 대한 확신을 심어줄수 있다.

     

    대담하게 수정해야겠다.
    근데 그러면 수정할게 너무 많은데 어쩌지.......? 

    Ch19. 코드 재사용 사례 

    사례1. 복붙

    코드의 저작권 침해와 동등하게 사악한 행위. 더러운 행위이며 자존심있는 개발자라면 이런 복붙 코드 재사용을 용납하지 않을 것이다. 

     

    사례2.재사용을 위한 설계 

    다양한 프로젝트에 포괄적으로 사용할 라이브러리를 처음부터 설계하는 행위.불필요하다.

     

    사례3.개선하고 리팩토링하기

    여러곳에서 사용되어야 된다는것을 깨달은 순간 리팩토링해라. '공통' 라이브러리 혹은 코드파일을 만들어라.

     

    사례4.매입하라. 아니면 시간낭비다. 

    새로운 기능을 추가할때 잘 모르는것에 대한 불신때문에 스스로 코드를 작성하는데

    자신의 버전보다 이미 존재하는 라이브러리를 사용하는 편이 더 나을수 있다. 

     

    Ch20. 효과적인 버전관리 

    버전관리 도구에 소프트웨어 프로젝트를 구성하는 모든 파일을 저장하라.다만 가능한 최소한으로 유지하라.

    배포본은 어딘가의 폴더에 저장하는 방식으로 고려해라. 

    최상위 디렉토리레 read me 문서를 포함해라. 

     

    코드 레이아웃 변경과 기능변경을 동시에 커밋하지 마라.

    만약 내부구조 리팩토링과 버튼변경 기능추가가 작업을 한다면 두개의 커밋으로 나눠라.

     

    Ch21. 골키퍼 있다고 골 안들어가랴

    개발자로서 불안정한 관계를 맺게 되는게 QA팀이다. 

    개발과정에서 스트레스를 많이 받는 시점에 긴밀한 관계를 유지하며 협업해야하기 때문이다. 

     

    QA는 충분한 품질을 보장한 상태로 소프트웨어를 배포하기 위해 존재한다. 생산과정에 핊수적이고 핵심인 부서이다. 

    개발요구사항이 부합되는지, 모든기능이 부합되는지 확인한다. 모든 플랫폼에서 정확히 작동하는지 확인한다. 단순 테스트부서가 아니다.

     

    개발자들은 만들고, 테스터들이 부순다. 테스터들의 목표는 결함을 찾아 물건을 망가뜨리고, 개발자에게 지옥을 맛보게 하려는게 아니다. 

    품질이 뛰어난 물건을 만들기 위해 존재하는 것이다. 개발자와 QA는 같은 편이다.

     

    QA 배포버전을 신중하게 만들지 않는것은 테스터들을 존중하지 않는것이다. 

    개발자들은 출시 빌드를 만들기전 자신의 결과물이 정확하게 구현되었음을 증명하는 테스트를 실시해야한다.

     

    테스터가 오류를 발견했다면 그 오류는 처음부터 개발자의 책임이다. 

    오류보고서를 개인적으로 받아들이지 말라. 개인적인 모욕이 아니다. 고객보다 먼저 발견했음에 오히려 기뻐하라. 

     

    요즘들어 QA팀과 자주 교류하는 일이 많아서인지 꽤 공감갔다.
    하지만 다행히도 나는 아직(?) QA분들이 버그를 찾아주시면 감사할 따름이라고 생각한다.
    다만 나도 모르게 무의식적으로 테스터분들을 존중하지 않았나 싶은생각에 반성했다. 
    최근에 QA팀을 위한 테스트 환경을 만드는게 꽤나 번거롭고 귀찮다고 느꼈기 때문이다. 유감스럽게도 우리회사는 개발환경과 테스트환경이 약간 달라서 개발하면서 테스트를 다 했는데도 불구하고 QA를 위한 테스트환경을 또 만들어야했다. 이부분에서 약간 현타(?)가 왔는데 생각해보니 QA분들을 존중하는 태도가 부족했던것 같다. 

     

    Ch22. 프리징 된 코드의 신기한 사례 

    코드 프리징은 더이상 변경이 이루어지지 않을것으로 예사되는 출시 직전까지의 기간이다. 

    하지만 코드가 변하지 않길 바라지만 코드는 반드시 변경되기 마련이다. 

     

    위험을 감수하고 수정해야할만큼 중요하지 않은 버그들이 발견될수도 있다. 버그를 발견한 이상 다음에 수정하여 출시할수 있을것이다. 

     

    Ch23. 제발 저를 출시해주세요

    출시절차의 개요

    1.출시착수 : 정식출시버전은 개발/테스트 빌드와 다르다. 

    2.출시준비 : 어떤 코드를 이번 출시 버전에 포함시킬것인지 명확히하라. 

    3.버전빌드 : 소프트웨어 빌드. 이상적으로 CI/CD툴로 빌드 자동화.

    728x90
    반응형