코딩정비소 코딩정비소

소프트웨어에서 이름은 어디나 쓰인다. 이름을 잘 지으면 여러모로 편한다. 의도를 분명히 밝혀라 그릇된 정보를 피하라 의미 있게 구분하라 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 인코딩을 피하라 자신의 기억력을 자랑하지 마라 기발한 이름은 피해라 한 개념에 한 단어를 사용해라 해법 영역에서 가져온 이름을 사용해라 문제 영역에서 가져온 이름을 사용해라 의미 있는 맥락을 추가하라 불필요한 맥락을 없애라

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. ...중략... 다시 돌아와 정리하겠다고 다짐했었다. 나중은 결코 오지 않는다. 맞다... 구현하기에 급급해 쓰레기 코드를 양산해 냈다. 어쩔수 없었다. 이렇게 해야만 했다. 다른 방법은 보이지 않았다. 나중에 고치기로 마음먹었었다. 다른 소스코드들을 통해 좋은 소스코드를 발견했고 수정하고 싶었다. 하지만 QA중이기에 함부로 고치기가 무서웠다. 분명히 체크했는데 왜 안되죠? 라는 소리를 듣기 싫었다. 어떻게 하면 한번에 좋은 코드를 작성할수 있을까? 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 점감하는 방법일 뿐 아니라 전문가로써 살아남는 길이라는 사실을 인정하리라. "깨끗한 코드를 어떻게 작성할까?", 깨끗한 코드..

실용주의 프로그래머 TIL 시작 인증합니다.

개발자의 시선에서 본 단순한 사고의 힘 5W1H책은 개인적으로 도움이 많이 되었다. 왜냐하면 개발자들은 수많은 프로젝트들을 상대하고 만들어나가기 때문이다. 개인적으로 책을 읽고 느낀 점, 그리고 어떻게 프로젝트를 잘 해결해나갈지 고민한 내용을 공유한다. 지레짐작과 마구잡이 사고 패턴을 제거한다 개발자들은 매일이 문제의 발견과 문제 해결의 연속이다. 여기서 나는 궁금증이 있었다. 누구는 쉽게 문제를 해결하는 반면 누구는 문제 해결하는데 시간이 오래 걸린다. 그리고 시간이 오래 걸린다고 문제를 잘 해결했다고 보기도 어렵다. 왜 그럴까? 처음부터 세부사항으로 들어가지 않는다. 이문구가 내 마음에 마치 비수가 날아와 꽂혔다. 나는 일단 문제를 직면하면 긴장한다. 어떻게 이거를 해야 할지 고민하기 전에 너무 긴장..

회사에 취직하고 일을 하다 보면, 현재 사용하고 있는 기능보다 더 좋은 프레임워크, 라이브러리가 발명되어 대체되어야 할 때가 있다. 하지만 팀원들은 더 좋은 프레임워크가 있는지도 모른다. 무엇보다 회사 입장에서는 시간은 곧 돈인데 이게 왜 필요한 건지 도통 이해하지 못한다. 좁혀지지 않는 의견 차이가 있다. 어떻게 이모두를 설득해서 적용할 수 있을까? 설득을 하기위해서는 상대방에 의문과 걱정을 정확하게 이해해야 한다. 상대방이 어떤 질문을 할 것인지에 대해 4단계로 생각해보자. 첫 번째로 중요성에 대한 의문점 이 작업이 어떤 메리트가 있는가? 굳이 왜 바꿔야 해? 이슈 나는데? 책임질 거야? 둘 째로 필요성에 대한 의문 아니 기존에 잘 돌아가는 게 있는데? 어떤 도움을 줄 수 있는가? 서비스적으로 개선되..