실용주의 프로그래머를 읽고

BANGJH·2019년 12월 8일
1

실용주의 프로그래머를 읽고 나서 공감갔던 내용을 요약해보았다.

어설픈 변명을 만들지 말고 대안을 제시하라.
변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지에 대해 설명하라.

깨진 창문을 내버려두지 말라.
눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.

변화의 촉매가 되라.
사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.

큰 그림을 기억하라.
주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.

DRY - 반복하지 마라 Don't Repeat Yourself
어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위있고, 단 하나뿐인 표현을 가져야 한다.

재사용하기 쉽게 만들라.
재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

관련 없는 것들 간에 서로 영향이 없도록 하라.
컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

최종 결정이란 없다.
돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.

추정을 통해 놀람을 피하라.
시작하기 전에 추정부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.

비난 대신 문제를 해결하라.
버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.

완벽한 소프트웨어는 만들 수 없다.
소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라.

일찍 작동을 멈추게 하라.
보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.

예외는 예외적인 문제에 사용하라.
예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두라.

모듈간의 결합도를 최소화하라.
디미터 법칙을 적용하고 부끄럼 타는 코드를 작성해서 결합이 생기는 일을 피하라.

일찍 리팩터링하고, 자주 리팩터링하라.
정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키테처를 만들라. 문제의 근원을 해결하라.

소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.
가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.

자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
마법사는 엄청난 양의 코드를 만들 수 있다. 그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라,

생각의 틀을 벗어나지 말고, 틀을 찾아라.
해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. '정말로 반드시 이런 방식으로 해야하는 일인가? 꼭 해야만 하는 일이긴 한 건가?'

준비가 되었을 때 시작하라
여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

profile
안녕하세요 신입 웹개발자입니다.

0개의 댓글