[28기 김진균] 실용주의 프로그래머 4장

[28기 김진균]

 

실용주의 프로그래머 4장 실용주의 편집증에 대하여 발표할 선문비트 28기 김진균입니다. 발표를 시작하기 앞서 편집증이란 무엇이라고 생각 하십니까? (잠시쉬고) 네이버 사전에서는 체계적이고 지속적인 망상을 나타내는 병적 상태를 말한다고 합니다. 좀더 넓은 의미로는 사소한 일에 집착하고 사로잡혀 한가지 생각만 하는 증세입니다. 실용주의 프로그래머 책에서 이러한 증상이 실용주의 프로그래머에게 좋은 생각이다 라고 말합니다. (우디앨런)

서두가 길었습니다. 목차 입니다. 첫번째 완벽한 소프트웨어는 만들 수 없다. 저와 같은 소프트웨어개발자를 꿈꾸는 사람에게는 청천벽력과도 같은 말 입니다. 두번째 계약의 의한 설계, 세번째 단정적 프로그래밍, 네번째 죽은 프로그램은 거짓말을 하지 않는다. 죽은 사람은 말이 없다 라는 옛말이 살포시 떠올랐습니다. 다섯번째 언제 예외를 사용할까 여섯번째 리소스 사용의 균형 순서로 진행하겠습니다.

완벽한 SW를 만들 수 없다! (애니메이션 뜨고)왜? 신은 완벽합니까? (잠시쉬고) 신은 완벽합니다. 그러나! 우리는 신이 아닌 인간입니다. 인간은 완벽하지 않습니다. 완벽하지 않은 인간이 완벽한 SW를 만든다? 있을 수 없는 일입니다. 이것을 기정사실로 받아들여라 라는 것입니다. 받아들이지 못한다? 그렇다면 그 사람은 불가능한 꿈을 뒤쫓으며 시간과 노력을 낭비하게 될 것입니다. 실용주의 프로그래머는 어느 누구 심지어는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 자신의 실수에 대비하여 방어적으로 코드를 작성한다고 합니다. 방어적 코드의 작성법은 뒤에서 설명하겠습니다.

계약에 의한 설계는 소프트웨어 모듈들의 권리와 책임을 문서화 하는데 초점을 맞추고 각각의 프로그램이 가져야 하는 기능만큼만 동작하도록 문서화하고 검증하는 것이 계약에 의한 설계의 핵심이다. (모듈 : 다른 프로그램으로도 재사용할 수 있는 형으로 되어 있는 것을 말하며, 복수의 모듈을 취급하기 쉽도록 하나로 일괄시킨 것을 라이브러리(library)라고 한다.)

모듈을 호출하기 위해 참이어야 하는 것을 선행조건이라 하고 모듈이 자기가 할 것이라고 보장하는 것을 후행조건이라 합니다. 그리고 클래스 불변식은 호출자의 입장에서 이 조건이 언제나 참이라고 보장하는 것을 말합니다. 모듈이 내부 처리 중에는 불변식이 참이 아닐 수도 있지만, 모듈이 종료하고 호출 자로 제어 권이 반환되는 때에는 불변식이 참이 되는 것을 말합니다. 다시 말하면 호출자가 모듈의 모든 선행조건을 충족 한다면 해당 모듈은 종료 시 모든 후행조건과 불변식이 참이 될 것을 보증해야 합니다. 이해가 잘 안될 것입니다. 그래서 한가지 예를 들고 왔습니다.

Student라는 클래스에 이름을 설정하는 setName() 메소드가 있습니다. setName()메소드는 화면과 같은 형태입니다. setName()메소드가 가져야 할 선행조건과 후행조건이 무엇입니까? (잠시 쉬고) 선행조건은 인자로 받아오는 name이 null이 되면 안되는 것이고 후행조건은 모듈이 실행되고 나서 Student 클래스의 name이 제대로 변경되는 것입니다. 이렇게 선행조건과 후행조건이 만족한다면 계약을 이행합니다.

다음으로 단정적 프로그래밍은 ‘이런 일은 절대 일어 날 리 없어’ 라고 생각하는 것입니다. 예를 들면 “이 애플리케이션을 외국에서 사용하는 일은 절대 없을 텐데 뭐하러 국제화하지?” 이런 류의 자기기만을 특히 코딩을 할 때 하면 안됩니다. C나 C++에서 assert()함수를 사용하면 더욱더 편리하게 단정을 통해 불가능한 상황을 예방 할 수 있습니다. assert() 함수 사용법은 먼저 assert.h를 추가하고 assert()함수에 조건식을 넣어주면 됩니다. 조건식이 참이 될 때는 아무 일도 일어나지 않고 거짓이 되면 어느 파일의 몇째 줄에서 실패했는지 표시됩니다. 그리고 빌드에서는 전혀 작동하지 않습니다. 즉, 함수 호출에 대한 비용이 전혀 없습니다.

여기까지 달려온 김에 살짝 쉬는 타임으로 퀴즈를 하나 내도록 하겠습니다. 맞추시면 쿨하게 마운틴 듀 음료를 사겠습니다. [한달이 28일보다 적었던 적이 있는가?] 라는 문제입니다. 있으면 언제 있었다의 입증을 해주시고 없으면 단호하게 없다 라고 말해주시면 됩니다. (잠시 쉬고)문제의 답은 ‘있다’ 입니다. 1752년 10월은 19일 밖에 없었다고 합니다. 그레고리 교황의 달력 개혁의 일부로 달력 간의 날짜를 맞추기 위해서 이런 일이 생겼다고 합니다. 지금처럼 불가능이라고 생각했던 것이 실제로 일어날 수 있습니다.

죽은 프로그램은 거짓말을 하지 않는다 프로그래밍 도중 문제가 발생 했을 때 대다수의 프로그래머는 그런 일은 절대 일어날 리 없어 라는 사고에 빠지기 쉽습니다. 또한 에러는 모든 정보를 주지만 대다수의 프로그래머는 에러가 발생할 리 없다고 스스로를 설득하고 그걸 무시하기로 할 수 있습니다. 반면에 실용주의 프로그래머는 만약 에러가 있다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기를 합니다. 가능한 빨리 문제를 발견하게 되면 좀 더 일찍 시스템을 멈출 수 있다는 이득이 있고, 프로그램을 멈추는 것이 가장 최선일 때도 있습니다. 분명히 실행 중인 프로그램을 그냥 종료해 버리는 것은 때로 적절치 못합니다. 해제되지 않는 자원이 남아 있을 수도 있고, 다른 프로세스들과 상호작용해야 할 필요가 있을지도 모릅니다. 방금 불가능한 무언가가 발생했다는 것을 코드가 발견한다면 프로그램은 더 이상 유효하지 않다고 할 수 있고 이 시점 이후로 하는 일은 모두 수상쩍은 게 됩니다. 되도록 빨리 종료하는 것이 할 일 입니다.(망치지 말고 멈추라!)

언제 예외를 사용할까는 ‘경우에 따라 다르다’ 가 답입니다. 만약 파일이 꼭 있어야 한다면 예외가 출동해 마땅하지만 파일이 반드시 있어야만 하는 것인지에 대해 아무 생각이 없다면 그 파일을 찾을 수 없다는 것이 그리 예외적인 일이 아닐 것이며, 에러를 반환하는 것이 적절하다. 예외 처리란 프로그램의 정상 흐름의 일부가 아니므로 사용하는 경우는 없어야 합니다.

한가지 예를 들고 설명하겠습니다. [문제] 새로운 컨테이너 클래스를 설계하는 동안, 다음과 같은 에러 조건이 가능하다는 것을 발견한다. 1.  add모듈에서 새로운 원소를 위한 메모리가 부족하다. 2. fetch모듈에서 요청된 엔트리를 찾을 수 없다. 이렇다면 각각 어떻게 처리를 해야 하겠습니까? (잠시 쉬고) 1. 메모리가 부족한 것은 예외적인 상황이므로 예외를 발생시켜야 합니다. 2. 어떤 항목을 찾는 일을 실패하는 상황은 상당히 자주 일어납니다. 그러므로 에러를 반환해야 합니다.

코딩할 때 우리는 모두 리소스를 관리합니다. 리소스를 할당하고 사용한 다음 해제합니다. (리소스 : 네이버 사전에 의하면 컴퓨터 시스템에 관한 여러가지의 자원을 총칭하는 말입니다.) 그러나 많은 개발자들은 리소스 할당과 해제를 다루는 일관된 계획을 갖고 있지 않습니다. ‘시작한 것은 끝내라’ 이것은 단순히 리소스를 할당하는 모듈이나 객체가 리소스를 해제하는 책임 역시 져야한다는 걸 의미합니다. (중첩할당)그리고 리소스 할당의 기본 패턴을 확장해서 한번에 하나 이상의 리소스를 필요로 하는 모듈에 적용할 수 있습니다. 주의 할 점 첫번째 리소스를 할당한 순서의 반대로 해제하라 입니다. 두번째 코드의 여러 곳에서 동일한 리소스 집합을 할당하는 경우, 할당 순서를 언제나 같게 하라 입니다. (그래야 교착상태에 빠지지 않는다.) (균형을 점검하기)실용주의 프로그래머는 자신을 포함해서 아무도 믿지 않기 때문에 정말로 리소스가 적절하게 해제되었는지 실제로 점검하는 코드를 늘 작성해야 합니다. 강사님께서 예광탄을 많이 쏴라 하는 것이 이말입니다.

이상으로 발표를 마치겠습니다 감사합니다.