the_principles_of_programming

전제 프로그래밍 불변사실

프로그래밍에서는 은총알은 없다.

왜? 본질적으로 소프트웨어는 난해하다.

복잡성

규모가 크면 수천 수만라인의 코드도 존재 하고 각 컨퍼넌트간에 종속성도 비선형적으로 증가함

동조성(호환성)

실세계랑 끊임없이 동조 해야 된다. (네트워크, 하드웨어, 다른소프트웨어 등등)

가변성

요구사항이 끊이 없이 바뀌기 때문에 코드 변경이 수시로 일어남

비가시성

눈에 보이지 않은 개념들의 집합이 소프트 웨어임

소프트웨어의 역사나 기법들을 익혀서 복잡성을 줄여 나가야 된다.

코드는 설계서이다.

소프트웨어 개발중 작성된 모든 문서중 엔지리어닝 문서는 코드 이다.

코드가 설계를 하고 컴파일러가 컴파일해서 제조를 담당한다.

그래서 우리의 개선대상은 코드이다.

그래도 모든문서가 쓸때 없는것은 아니다.

코드에는 how와 what은 표현되어 있지만 why가 없다.

설계이유를 문서에 잘기록해 두자.

코드는 항상 변경된다.

코드는 한번 작성했다고 그것으로 끝이 아니다. 나중에는 반듯이 변경된다.

소프트웨어는 위에서 말했듯이 본질적으로 복잡하다. 배포된 후에 반드시 오류가 발생하고 오류를 해결해야 된다.

변경에 강한 코드를 작성하자 변경에 강한코드란 읽기 쉬운 코드이다. 코드는 사람이 읽기 쉽게 나온 언어로 결국엔 작성하는 시간보다 변경에 의해서 읽는 시간이 훨씬더 길다.

원칙 프로그래밍 가이드 라인

KISS(Keep it simple, stupid/Keep it short and simple)

코드 작성의 최우선을 간결함에 둔다.

코드를 생각 없이 수정하다 보면 저절로 무질서해지고 복잡해진다.

복잡한 코드는 읽기 어렵고 수정하기 어렵다.

코드에 불필요한것을 하지 않는다.

신기술 사용 - 신기술을 배우고 나면 불필요하게 코드를 작성할때가 있다. 코드는 두뇌의 명석함을 뽑내기 위한것이 아니라 사용자에게 가치를 제공하는것이다 정말 필요한것인지 생각하고 코드를 단순하게 유지하자
장래의 필요에 대비 - 나중에 필요할지도 몰라서 오버엔지니어링을 하는경우가 있다 지금 꼭필요한 코드만 작성하자 그래서 코드의 단순함을 유지하자.
멋대로 요구사항을 추가 - 멋대로 요구사항을 판단해서 불필요한 코드를 추가할때가 있다 꼭 사용자한테 요구사항을 판단해서 불필요한 코드를 작성하지 말자.

less is more 단순한 것이 더 아름답다 건축분야에 쓰는 말인데 소프트웨어에도 딱 들러맞는다.

개인적인 생각으로 초기 소프트웨어 공학이 건축분야에서 많은것을 차용했는데 비슷한 부분이 많아서 그런게 아닌가 싶다.

DRY (Don’t Repeat Yourself)

코드 복사 붙여넣기는 금물(?) 이렇게 되면 같은로직이 여러군데 흩어지는 경우가 생긴다.

코드 개선할 수 가 없다.

코드를 읽는 작업이 어렵다
코드를 수정하는 작업이 어렵다
테스트가 어렵다.

중복을 줄이는 법은 코드를 추상화 하자 하지만 기존 코드를 건들어야 되니 잘못 수정할수 있다. 그리고 귀찮다. 하지만 중복이 좋지 않다는것은 반론의 여지가 없다 리팩토링 하자

DRY의 적용 범위 소프트웨어 개발 전반적으로 다 적용 되어야 된다 지속적인통합 이야기도 결국에는 개발자가 빌드하고 디플로이하는 중복작업을 줄이는면에서는 DRY원칙이 적용 되었다고 보면된다.

프로그래밍 언어에서도 대부분 DRY를 실현하려고 객체지향이나 함수형 프로그래밍 에서 처럼 중복 제거 기법이 다 녹아들어가 있다.

불가피한 DRY 위반이 있을수도 있다. 불일치가 발생하기 쉬운 부분은 추상화 스타일이 서로 다른 경계선이다.

DRY <-> WET(Write Every Time/Write Everything Twice) 건조함과 촉촉함

데이터 베이스에서는 One Fact in One Place(OFOP) - 일본에서 유명한 말인듯 모델링 쪽에 말인지는 모르겠지만 onefact.net 파피루스 만든 애들인듯

Once And Only Once(OAOO) DRY 보다 적용 범위가 좁고 프로그래밍에서만 사용됨

레거시 코드란 테스트코드가 없는 코드를 레거시 코드라 부른다
예전에는 ‘오래전에 만들어진 이해할수 없고 변경하기 어려운 코드’를 조롱하는 속어 였는데
지금은 테스트가 중요해지면서 테스트코드가 없는코드를 레거시 코드라고 한다. 이런 정의가 지나지체 엄격한 구분이라 생각할수는 있지만 테스트 없이 코드를 변경하는 것은 위험한 도박이기 때문이다.
일단 레거시 코드를 상대하게 되었다면 일단 테스트 코드부터 작성하자.

YAGNI (You Aren’t Gonna Need It)

코드는 필요할때 최소한으로 작성하자

코드는 항상 예측을 벗어난다. 미리 여러가지 상황을 대비해둬도 예측을 벗어나는 경우가 태반이다
확장성을 고려해서 작성 하면 오히려 코드 복잡성을 낳기 마련이다.
나중에 보면 사용하지 않는 코드이고 왜이렇게 작성한지 모르는 일이 태반이다.
열심히 고려한 설계가 무용지물일 뿐만 아니라 오히려 방해물이 된다.

그러면 코드 작성시에 선택방법이 범용성보다 단순함을 우선에 둔다. 위에 KISS에서 설명한 최우선 원칙이다.
나중에 요구사항이 늘어나도 복잡한 코드를 수정하는것 보다 단순한 코드를 수정하는것이 더 편하다.

YAGNI 코드에만 국한되는 말이 아니라 소프트웨어 기능에도 해당 된다. 풍부한 기능은 매력적으로 보이지만
‘과녁에서 빗나간’ 기능은 사용하지 않을 뿐만 아니라 전체 사용법을 복잡하게 만들고 사용성을 떨어뜨린다.

Do The Simplest Thing That Could Possibly Work(dtsttcpw) 효과있는 방법중 가장 간단한 방법으로 하라