ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 실용주의 프로그래머 정리6
    Study/실용주의 프로그래머 2021. 12. 12. 22:04

    코딩하는 동안 해야 할 일들

    기계적으로 하는 코딩은 좋지 않은 구조를 만든다. 항상 고민하고 많이 생각하지 않으면 잘못된 프로그램을 만들 가능성이 높아진다. 기계적으로 해도 좋은 코드가 나왔으면 이미 프로그래머는 대체 됐을 것이다. 이번 장에서는 코딩하는 동안 고려해야 될 점들을 알아본다.

    31. 우연에 맡기는 프로그래밍

    우연히 운좋게 동작하는 동작에 의존하지 말자. 어떤 원리로 돌아가는지 이해하고 있어야 한다. 또한 다른 사람의 라이브러리를 사용할 때는 문서에 없는 동작에 의존하지 말자. 작성자가 의도하지 않은 동작일 가능성이 높다. 확실하지 않은 사실을 가정하지 말고 증명하자.


    의도적으로 프로그래밍하는 것이 우연에 맡기는 프로그래밍 보다 훨씬 안전하다. 의도적 프로그래밍을 지키기위한 원칙은 다음과 같다.

    • 맹목적으로 코딩하지 말라. 이해하지 못한채 사용하는 것은 큰 문제를 불러올 수 있다.
    • 계획을 세우고 코드를 작성하자.
    • 동작에 대한 가정을 문서로 남기자. 문제가 발생했을 때 문서를 참고할 수 있다.
    • 코드만 테스트 하지말고 가정도 같이 테스트하자
    • 노력에 대한 우선순위를 정하자. 가장 중요한 부분에 시간을 투자하자.
    • 적극적으로 리팩토링 하자

    32. 알고리즘의 속도

    알고리즘의 속도를 추정하는 방법 중 빅오 표기법이 유용하다. 알고리즘이 어떤 빅오 표기값을 갖냐에 따라 입력의 크기에 대해 얼마나 속도가 느려질 지 추정할 수 있다. 빅오 표기법으로 알고리즘 속도를 추정하고 느리다면 더 좋은 그래프를 갖는 알고리즘으로 바꿀수 있도록 고민할 수 있다.


    알고리즘 속도를 추정하는 것도 중요하지만 실제 측정해보는 것이 더 중요하다. 성능에 영향을 주는 알고리즘이라면 실제 수행 속도를 측정해보자.


    마지막으로 알고리즘 속도가 병목이 아니라면 억지로 최적화 하지 말자. 성급한 최적화는 더 안좋은 결과를 만들 수 있다.

    33. 리팩토링

    프로그램은 시간이 지나면서 계속 변화한다. 기능이 추가되고 그 과정에서 이전에 고민했던 설계가 안 맞을 수 도 있고 코드가 지저분해질 수 도 있다. 이때는 망설이지 말고 리팩토링을 하자. 리팩토링은 괴로운 과정이지만 지금 맞는 것이 나중에 맞는 것 보다 덜 아프다. 그냥 빨리 맞자.


    리팩토링과 항상 따라다니는 것은 일정이다. 일정이 바빠서 리팩토링을 하기 힘든 경우가 많다. 하지만 미래를 위해서 일정을 넉넉하게 잡고 잘 조율할 수 있도록 하는 것이 좋다. 아까 말했듯이 지금 맞는게 덜 아프다..


    리팩토링 방법에 관해서는 마틴 파울러의 리팩토링 책을 읽어보는 것이 좋다. 여기서는 리팩토링에 가장 중요한 요소만 소개하겠다. 우선 이전에 동작하는 기능에 대한 회귀 테스트를 작성하자. 그 다음 리팩토링을 하면 안심할 수 있다. 리팩토링을 할 때 테스트는 매우 중요하다.

    34. 테스트하기 쉬운 코드

    테스트하기 쉬운 코드는 개인적으로 엄청 중요하다고 생각한다. 테스트하기 쉬운 코드를 짜다보면 자연스럽게 좋은 코드를 작성하게 되기 때문이다. 단위 테스트를 작성할 때 객체 또는 메소드가 여러 객체에 의존하고 있으면 테스트하기가 힘들어진다. 이를 좀더 작은 책임으로 분리하면 결국 테스트하기 쉬운 코드가 나오고 재사용 가능하고 유연한 코드를 작성할 수 있다.


    테스트 코드를 작성할 때는 경계조건과 메소드를 사용하기 위한 계약 조건을 반드시 테스트 해야한다. 그래야 유의미한 테스트가 된다. 보통 버그가 많이 발생하는 곳이 경계 조건과 갖춰야하는 상태이기 때문이다.


    테스트 코드도 잘 구조화 하는 것이 좋은데 테스트 프레임워크를 사용하는 것이 좋다. 자바에서는 junit을 대부분 쓰기 때문에 junit을 활용해서 테스트를 작성하자. 테스트 코드 작성은 문화다. 팀에서 하고 있지 않으면 쉽게 도입하기 힘들다. 만약 팀이 테스트 코드를 작성하고 있지 않다면 나부터 작성해보도록 하자.

    35. 사악한 마법사

    마법사는 복잡한 코드를 쉬운 설정만으로 자동 생성해준다. 매우 유용하지만 한편으로는 안좋은 일이 될 수 있다. 이해하지 못하고 마법사를 사용하면 문제가 발생했을 때 디버깅을 하기 쉽지 않다. 마법사를 사용하려면 마법사가 해주는 일을 이해하자.


    개인적으로 사용하는 것 중에 스프링 부트가 마법을 굉장히 많이 부린다고 생각한다. 설정하지도 않은 빈을 많이 생성해줘서 편리하게 해준다. 하지만 이런 편리함 속에서 문제가 발생했을 때 잘 해결하기 위해서는 스프링 부트가 결국 어떻게 동작하는지 잘 이해해야 한다. 시간 날때 틈틈이 사용하고 있는 프레임워크를 공부하는 것이 좋을 것 같다.

    댓글

Designed by Tistory.