엘키의 주절 주절

명언가장 큰 약점은 약점을 보일 것에 대한 두려움이다 - 보쉬에우리는 종종 뭔가 나아지게 하려다가 괜찮은 것 마저 망친다 - 리어왕 지식에 대한 투자가 언제나 최고의 이윤을 낸다 - 벤자민 프랭클린 당신이 가진 생각이 딱 하나밖에 없다면 그것만큼 위험한 것은 없다 - 에밀 사르티에 언어의 한계가 곧 자기 세계의 한계다 - 루트비히 비트겐슈타인 진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다 - 조지 산타야나 참으로 고통스러운 일입니다. 자신이 겪는 어려움을 보고는 알게 되죠. 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 걸. 소포클래스(아이아스) 상식과 정직만큼 사람을 놀라게 하는 것은 없다 - 랄프 왈도 에머슨 자기 비난에는..

버그는 프로그래머의 숙명이다. 그 섬세하게 만들려한 IOS, OS X에도 버그는 종종 있으며, 사실 많은 사람이 M$라 부르지만 나의 경우는 매우 감사하고 있는 MS의 경우에도 버그는 많다. 구글도 예외는 아니고. (구글 apps 초창기 패치할 때 마다 언어 관련, IME 관련 문제를 겪게 했던 일은 나름 유명한 일화다.) 이러한 회사는 분명히 업계의 엘리트가 모여있을 텐데 어째서 이렇게 버그가 나오는걸까? 어찌보면, 버그는 당연한 숙명이다. 하나의 어플리케이션을 작성하기 위해, 잘 작성된 위지윅 툴을 사용하더라도, 버그가 없다고 단정 지을 수 없다. 하물며, 코드가 들어가고, 각종 코드를 재사용하고, 다른 코드를 얹는 과정에서는 복잡도와 결합도는 증가하고, 당연히 버그가 생길 여지도 많아진다. 자 그렇..

꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다. 빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다. 물론 이 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다. 심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고. 사실 가장 곤욕스러운 과정은 프로젝트 dependency 한 코드를 분석하게 될 때이다. 이 과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다. 예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하..

내가 코드를 작성할 때 신경쓰는 코딩 규약들을 정리해본다. 소유권 객체의 소유 주체는 (생성과 소멸의 관리 주체는) 하나로 규정한다. 객체의 생성,소멸 스레드도 하나로 규정한다. 다른 클래스에서 호출되어야만 하는 메소드를 만들지 말라. Has a 관계가 명확하다면, 이 관계를 혼란 시킬 수 있는 메소드는 절대 만들지 마라. 진입점 진입 점은 명확하게. 한곳으로 관리하자. 만약 다양한 진입 점이 있을 수 밖에 없다면, 다른 각각의 진입 점에서 왔음을 알 수 있게 하라. 중복 중복을 허용하지 말라. 단일 규칙 두 가지 이상의 규칙을 허용하지 말라. 새로운 규칙을 도입하고 싶다면, 기존 규칙대로 작성된 전부를 고쳐라. 두 가지 이상의 규율이 존재하는 것은, 코드 작성/분석 등 모든 과정에서 해가 된다. 전치 ..

유닛 테스트를 내가 접한 지도 어언 10년이 다 되간다. 그간 내가 거쳐온 많은 회사에서 사용되기도, 무시되기도, 우선 순위에 밀리기도 하더라. 이 과정에서 제안도 여러 번 해보고, 설득 과정에서 자주 나왔던 질문이 있었다. 유닛 테스트하면 뭐가 좋은가요? 처음 이 질문을 받았을 당시, 내 답변은 테스트야 하면 당연히 좋은 거다 라고 답변했었다. 사실 누구나 테스트의 중요성은 배운다. 그래서 아주 작은 팀이고 여력이 부족하다면, 개발팀 내 테스트라도 소화하려고들 하는 것은 사실이긴 하다. 하지만 많은 사람들에게 테스트란 재미없고, 지루하지만 해야만 하는 교리 같은 것에 불과하다는 것이 문제다. 듣는 사람도 고개는 끄덕였지만, 막상 실천으로 이끌어 들이는 데에는 실패했다. 결과적으로 동기부여에 실패했다. ..

2000년대 중후반은 모두가 유닛 테스트에 미쳤다. 아니 TDD에 미쳤다.Test Driven Development에 대한 서적이 넘쳐났으며, 모두가 TDD를 통해 구원 받을거라는 희망찬 상상에 들떠 있었다. 이 붐을 주도했던 개발자중 한명인 DHH (rails를 만든 이)도 이 흐름에 동참했었다. 그를 비롯한 많은 이의 주장은 테스트 우선 신앙 (Test first fundamentalism)라 불릴 만큼 테스트를 바탕으로 코드를 작성하면 그 퀄리티가 비약적으로 상승 할 것이라는 의견이었다. 여지껏 내가 해온 테스트는 다음과 같았다. 독립적으로 동작할 수 있는 클래스에 대한 유닛테스트.- 화이트 박스 테스트로써의 유닛 테스트. (나는 크게 선호하진 않았지만, 가끔 진행했고 유닛테스트를 실천한 초반에 특..

지난해 10월, 미국의 북동부 지역은 어딜 가나 아셀라(Acela) 광고 천지였다.아셀라란 암트랙(Amtrak)이 워싱턴-보스턴간 노선에서 운행할 새로운 초고속열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도 이 정도의 물량 공세라면 이 새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다. 글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해 볼 기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한달 앞두고 이 제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는말이 떠오른다. “대단한 홍보 효과야! 이럴..

모든 사람들이 명세서 작업을 해야한다고 생각은 하지만, 아무도 명세서 작업을 하지 않습니다.왜 명세서 작업을 하지 않을까요?명세서 작업단계를 건너뛰면 시간을 절약할 수 있다고 말합니다.이런 사람들은 명세서 작성 작업이 NASA에서 우주 왕복선을 만드는 공학도나 큰 규모의 보험회사 직원에게나 필요한 사치쯤으로 치부합니다.명세서 작업을 하지 않는 관례는 소프트웨어 프로젝트에서 가장 크고 불필요한 위험 요인을 짊어지는 행동입니다. 이는 등에 옷가지만을 걸친 다음에 날기를 기대하며 모하비 사막을 건너려고 출발하는 것만큼이나 바보스럽습니다.명세서 작업을 생략하고 바로 코드 작성으로 뛰어드는 프로그래머나 소프트웨어 개발자는 스스로를 허리춤에서 순식간에 총을 뽑는 멋진 총잡이라고 생각하는 경향이 있습니다.하지만 결코..