개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
모든 오류를 테스트를 통해 잡아낼 수는 없다. 놓친 것들을 잡기 위해 단정을 활용하자.
리소스 할당은 언제나 해제까지 책임지도록 해야 한다.
볼 수 있는 미래까지만 고려하자. 모든 경우의 수를 생각하기 보다는 쉽게 교체 가능한 코드를 작성하자.
TIL (Today I Learned) 날짜
2022.03.24
오늘 읽은 범위
4장. 실용주의 편집증
책에서 기억하고 싶은 내용을 써보세요.
실용주의 프로그래머는 자기 자신 역시 믿지 않는다. 어느 누구도, 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 실용주의 프로그래머는 자신의 실수에 대비한 방어책을 마련한다. - 146p
DBC는 단순하지만 강력한 기법으로, 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 권리와 책임을 문서화하고 합의하는 데에 초점을 맞춘다. 정확한 프로그램이란 무엇인가? 자신이 하는 일이라고 주장하는 것보다 많지도 적지도 않게 딱 그만큼만 하는 프로그램이다. 이 주장을 문서화하고 검증하는 것이 ‘계약에 의한 설계’의 핵심이다. - 148p
‘게으름뱅이’ 코드를 강조하고 싶다. 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다. 무엇이든 수용하고 결과로는 무엇이든 다 준다고 계약에 쓰여 있다면, 여러분은 정말이지 많은 코드를 작성해야 할 것이다! - 151p
코드를 작성하기 전에 유효한 입력 범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는 데에 엄청난 도움이 된다. ...(중략)... DBC는 결국 설계 기법이다. 자동 검사가 없더라도 계약을 코드에 주석이나 단위 테스트로 넣어둘 수 있고, 여전히 실질적인 소득이 있다. -153p
가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 게다가 프로그램을 멈추는 것이 할 수 있는 최선인 경우가 흔하다. - 161p
이런 식으로 자신을 기만하지 말자, 특히 코딩할 때는. - 162p
‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문 을 사용하는 것이다. ...(중략)... 하지만 진짜 오류 처리를 해야 하는 곳에 단정을 대신 사용하지는 말라. 단정은 결코 일어나면 안 되는 것들을 검사한다. - 163p
여러분 의 첫 번째 방어선은 가능한 오류를 모두 검사하는 것이고, 그다음은 그러고도 놓친 것을 잡아내기 위해 단정을 사용하는 것이다. - 165p
“자신이 시작한 것은 자신이 끝내라.” 팁이 가르쳐 주는 것은 이상적으로 말해서 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것이다. - 169p
리소스를 할당한 순서의 역순으로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 참조를 망가트리지 않는다. 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착가능성을 줄일 수 있다. - 171p
선택은 각 자료 구조의 상황에 따라 달라진다. 하지만 언제나 어떤 것을 선택할지 확실하게 정하고 그에 따라 일관성 있게 구현해야 한다. - 175p
우리는 미래의 유지 보수를 고려해서 설계해야 하지 않느냐고? 맞다. 하지만 여러분이 볼 수 있는 미래까지만 고려해야 한다. 미래가 어떤 모습일지 더 많이 예측하려 할수록 여러분이 틀릴 가능성은 계속 높아질 것이다. 불확실한 미래에 대비한 설계를 하느라 진을 빼는 대신 언제나 교체 가능한 코드를 작성하여 대비하면 된다. 여러분의 코드를 더 적절한 무언가로 대체하기 쉽게 설계하라. - 179p
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
예전에 프로그래밍 언어를 주제로 한 수업을 들을 때 귀에 딱지가 앉도록 들었던 말이 있다. 프로그래머는 게을러야 한다고. 그런 측면에서 봤을 때 선행 조건과 후행 조건이라는 개념은 정말 인상적인 것 같다. 근데 그 부분을 읽으면서 그런 생각이 가장 많이 들었다. 그렇게 좋은데, 왜 보지 못했을까. DBC 개념이 명확히 이해되지 않아 구글링을 하다가 똑같은 문장을 마주했다. 좋은 개념인데, 왜 다들 사용하지 않을까.
이 챕터, 아니 이 책을 읽는 동안 저자는 항상 자신을 너무 믿지 말라고 한다. 근데 막상 코딩을 시작하면 마음대로 되지 않는다. 코드가 내가 원하는 대로 돌아가지 않으면, 우선, 문제를 외부에서 찾는다. 그래도 곧바로 버그를 해결하기 위해 침착한 자세로 고쳐앉기는 한다. 오늘 며칠 전에 짰던 코드의 결과물을 다시 봤는데, 예상치 못한 오류가 발생했다. 그걸 보고 다시금 깨달았다. 내가 모든 오류의 가능성에 대해 알고 있다고 과신하지 말자. 이런 측면에서 봤을 때, 다양한 상황에 놓인 다양한 사람들이 사용하게 될 서비스라면, 단정은 꼭 필요한 존재인 것 같다.
예전에 인턴십 프로그램을 할 때 위키피디아 데이터를 크롤링해서 텍스트 마이닝을 해야 하는 과제를 맡은 적이 있었다. 그 때 위키피디아의 모든 데이터를 따라가서 크롤링하려다 보니, 양이 너무 방대해 시간이 너무 오래 걸렸다. 그래서 시간을 줄이기 위해 멀티쓰레딩을 처음 써봤는데, 그걸 구현하면서 여러 쓰레드가 동시에 같은 리소스에 접근하려 할 때 발생할 수 있는 문제를 몸소 겪은 것 같다. 리소스를 올바르게 할당하고 해제하는 것의 중요성은 몇 번을 말해도 지나치지 않은 것 같다. 책에서 언급된 팁들을 항상 명심해야겠다.
마지막 부분에 나온 헤드라이트를 이용한 비유는 정말 인상적이었다. 모든 경우의 수를 생각할 수는 없다. 일단 내 앞에 놓인 미래에 집중하고, 언제 닥칠지 모르는 위험에 대비해 코드를 최대한 ETC하게 짜자.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
메모리 누수 (memory leak) : 프로그램이 필요하지 않은 메모리를 계속 점유하고 있는 현상 (참고 : https://118k.tistory.com/608)
오늘 읽은 다른사람의 TIL
내가 위에서 이야기한 DBC에 대한 궁금증에 대한 이야기가 있어 너무 좋았다!