엘키의 주절 주절

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

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

예전에 작성했던 글을 다시 보게 됐다. 좋은 프로그래머란 무엇일까? (http://elky.tistory.com/174) 4년이 지난 지금 내가 생각하는 좋은 프로그래머란 무엇일까? (지금은 프로그래머란 표현보다 엔지니어란 표현을 좀 더 즐겨쓴다. 이것도 마인드의 변화겠지?) 우선 무엇보다 부드럽게 이야기하는 법, 대화 자세 이런건도 좋아졌고. 현실과 타협도 많이 한거 같다. 이전에는 책에서 보거나 느낀 최선을 실천하지 못하면 마음이 너무 불안했다. 그런데 그 실천이란 것을 주변 상황을 둘러보지 않고 하다보니, 이 상황에서 중요한 판단들을 놓쳐왔다. 예를 들면 원인 파악보다 중요한게 현재 상황에 대한 대처인 경우가 많다. 또한 패치가 얼마 남지 않은 상황에서 큰 설계상 오류에 대한 대처는 패치를 미루거나..

언젠가 관리자란 주제로 글을 쓰리라 마음 먹었것만, 나를 관리해주시는 관리자도 몇 되지 않으셨었고 (지금도 많진 않지만), 그 분들과 이야기를 나누거나 회고하기에는 재직중인 상황이라 미루다 미루다 이제서야 쓰게 됐다. 사실 좋은 관리자=좋은회사라는 공식이 어느정도 성립한다고 생각이 든다. 그렇게 생각하는 데에는 여러가지 이유가 있다. 1. 소통이 적은 회사 일 수록 직속 상사내지는 관리자와의 대화가 업무 진행에 8할 이상을 차지하기 때문. - 안타깝게도 대부분의 회사가 이렇다는 게 현실 2. 결정권은 관리자에게 있으므로 해당 파트 내지는 팀의 방향성도 관리자에게서 나오기 때문 - 물론 그 보다 위에 계신 분들이 방향성을 잡는 경우도 있지만, 그 마저도 관리자의 역량과 영향이 있다고 볼 수 있음 기본적으로..

Open-Close 원칙 - 객체는 수정(modification)에는 닫혀있고(Close), 확장(extension)에는 열려있어야(Open) 한다. 중복을 제거하라 - 같은 기능을 하는 코드를 묶어, 중복을 제거하자는 원칙. 메소드 간소화 - 메소드는 두가지 일을 하게 만들지 말아라. - 메소드의 이름에서 벗어나는 일을 하지 말라. - 큰 규모의 행동이 필요하다면, 더 큰 범위의 단어로 메소드 명을 짓고, 그 큰 동작을 완성 시키기 위한 메소드의 연결만으로 구현하라. 직교성 - 클래스 끼리의 의존도를 낮춰, 해당 클래스가 변화를 국소화 시키고, 재사용을 촉진하라 가역성 - 변하지 않는 것은 없다. 코드도, 설계도 변화에 대비하라. 계약에 의한 설계 - 이 함수에 들어오기 전에 기대하는 선행 조건(Pre..

1. 소스코드 관리 시스템을 사용하고 있습니까? 2. 한방에 빌드를 만들어 낼 수 있습니까? 3. 일일 빌드를 하고 있습니까? 4. 버그 추적 시스템을 운영하고 있습니까? 5. 코드를 새로 작성하기 전에 버그를 수정합니까? 6. 일정을 업데이트 하고 있습니까? 7. 명세서를 작성하고 있습니까? 8. 조용한 작업환경에서 일하고 있습니까? 9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까? 10. 테스터를 별도로 두고 있습니까? 11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까? 12. 무작위 사용편의성 테스트를 수행하고 있습니까?

문득 코드를 작성하던 중 이런 생각이 들었다. "과연 지금 내가 작성한 이 코드가 분석하기 쉬운 코드일까?" 생각해보면 아마추어 일때를 제외하고는 새 코드 작성보다 다른 사람의 코드 분석하는 시간이 더 잦았고, 새 코드를 작성하더라도 다른 코드와 어울려야 했기 때문에 코드 분석은 늘 필요했다. 심지어 내 코드를 분석해야 되는 일도 잦았다. 기억력에는 한계가 있고, 시스템의 전체적인 이해도는 높을 수록 좋겠지만 세세한 코드 하나 하나가 하는 일까지 외울 필요는 없다고 생각한다. 그렇기에 내 코드를 내가 몇달이 지나고, 심지어 몇년 후에 봤을 때도 읽기 쉽고 유지보수하기 쉬운 코드를 만들기 위해 노력해야 한다. 그래서 우리는 디자인 패턴, 리팩토링 등을 통해서 좋은 코드를 만들기 위해 노력하고, 표기 법을 ..

80%의 효과는 20%의 노력으로 얻어진다는 법칙으로 중요한 일에 노력을 집중해 성공적인 삶을 살 수 있다는 것이다. 이 법칙을 프로그래밍에서 적용해보자면, - 코드 중에 20%가, 수행시간의 80%를 차지한다. - 프로그램의 리소스의 80%는 전체 실행 코드의 약 20%만이 사용한다. - 메모리의 80%는 실행 코드의 약 20%만이 사용한다. - 디스크 접근 회수의 80%는 실행 코드의 20%가 접근한 회수다. - 프로그램 유지보수에 들어가는 수고의 80%는 실행 코드의 20%에 집중된다. 여기서 80-20법칙의 진정한 의미는 아무 곳이나 골라잡고 효율을 향상시키려고 애쓰는 것은 별 도움이 안된다는 의미를 갖고 있다.