Technique
-
19. 코드 재사용Technique/Programmer 2017. 3. 26. 14:18
복사 & 붙여넣기 복붙이란 하나의 앱에서 복사한 코드를 다른 앱으로 그대로 옮기는 것을 말한다.이는 재사용 이라기 보단 중복에 가깝다. 그것은 코드의 저작권 침해와 동등하게 사악한 행위 이다. “자신이 했던 일을 반복하지 말자 ( Do Not repeat yourself )” DRY를 명심하자.코드베이스에서 파일 간에 코드를 복붙하는 것도 유혹적이지만 웹에서 코드의 많은 부분을 복사하는 것은 훨씬 더 유혹적이다.그것들을 액면 그대로 가져와 중대한 판단 없이 통합하여 적용하는 일이 없도록 하자. - 코드가 정말로 완벽하게 들어 맞는가? 모든 에러를 적절하게 다루고 있는가? 버그는 없는가?- 필요한 것을 이루기 위한 가장 좋은 방법인가? 오래된 예제는 아닌가? - 당신의 코드에 적용해도 되는 권리가 있는가?..
-
18. 변하지 않는 것은 없다.Technique/Programmer 2017. 3. 26. 13:22
항상 시간이 해결해 준다고들 하지만, 실제로는 당신 스스로 변하게 만들어야 한다. –앤디 워홀 제품이 출시 되고 난 뒤의 소프트웨어 내부 구조는 더 이상 다뤄서는 안 되는 것으로 취급된다. 바깥 세계의 모든 인터페이스는 신성시 되고 절대 수정할 수 없게 된다.이것은 바로 두려움 때문이다. 잘못될지도 모른다는 두려움과 어떤 것을 깨뜨려야 한다는 두려움, 추가 업무에 대한 두려움과 수정 비용에 대한 두려움 등이 있다.우리는 아직 완벽하게 알지 못하는 코드를 바꿔야할 때 현실적 불안감을 느낀다. 만약 철저하게 이해하지 못한 로직이 있거나, 자신이 무엇을 하고 있는지에 대한 확신이 없거나, 변화에 따른 모든 가능한 결과를 알지 못할 경우 특이한 코너 케이스에 대한 처리를 변경하여, 제품에 미묘한 버그를 만들어 ..
-
17. 머리 쓰기Technique/Programmer 2017. 3. 26. 12:20
"머리를 쓰라" 는 말은 칠칠치 못한 동료들에 대한 경멸적인 금칙어거 아니다. 오히려 양심적 코더가 되기 위한 핵심 원리이다. 1. 바보짓을 하지 말자.초월적인 지능을 가진 사람도 얼마나 어리석을 수 있는지 참으로 믿기 어려운 일이다.대단한 설계자들 역시 때로는 머릿속이 뿌연 안개로 가득 차서 눈앞의 문제조차 깨닫지 못하고 벽을 향해 돌진하기도 한다.그들은 놀랍고도 새로운 알고리즘을 작성하거나 독창적인 데이터 구조를 만들고자 하는 욕망에 사로잡힌 나머지, 간단한 배열로도 충분하다는 사실을 미처 깨닫지 못할 수가 있다.절대적 존재로 보이는 코딩 전문가조차 그럴 수 있기에 평한 우리는 더 말할 필요도 없다. 코드에서 명백한 사실을 놓치지 않도록 하자.만약 실수를 하게 되었다면 일단 실수했음을 인정하고 코드로..
-
16. 간결하게 하기Technique/Programmer 2017. 3. 22. 22:48
간결함이야말로 궁극의 정교함이다. 단순함은 의심할 여지없이 훌륭한 목표이며, 코드에서 이를 확실하게 추구해야 한다. 그 어떤 프로그래머도 과도하게 복잡한 코드로 일하고 싶어 하지 않는다. 간결한 코드는 투명하다 구조가 명확하고, 버그를 숨기지 않으며, 배우기 쉽고 작업하기도 쉽다.간결한 코드는 설계하는 데 많은 노력이 필요하다. 다만 간결한 코드가 곧 과도하게 단순한 코드를 의미하지 않는다.잘못되고 단세포적인 단순함이 아니라 가장 간결한 코드를 작성하기 위해 노력해야 한다 이는 생각 없이 어리석고 간결한 코드를 작성하는 것과는 완전히 다르다. 머리를 많이 써야 한다. 간결하게 만든다는 것은 엄청나게 어려운 작업이다. 간결한 설계.1. 사용기 간편하다.무의식 적 인지를 뜻한다. 처음에 배울 것이 별로 없는..
-
15. 규칙 가지고 놀기Technique/Programmer 2017. 3. 21. 22:49
모든 규칙을 지켰다면, 나는 어디에도 도달할 없었을 것이다. -마릴린 먼로 코드페이스에 따라야 하는 넓은 범위의 규칙이 있다. 개발 절차 표준이나 반드시 사용해야 하는 도구, 작업 흐름, 사내 규칙, 언어 구문, 디자인 패턴과 같은 것이다. 이러한 규칙은 전문 프로그래머가 되는 방법, 그리고 다른 사람들과 함께 개발해 나가는 방법을 정의한다.새로운 프로젝트에 참여할 때는 다양한 규칙을 지켜야 한다. 높은 품질의 코드 작성에 대한 규칙, 작업 절차와 관례에 대한 규칙, 그리고 프로젝트와 업무 영역에 관한 특정 규칙 등이 그것이다. 더 많은 규칙 필요하다우리에게는 우리 스스로가 만든 규칙이 필요하다 다루기 어려울 만큼 엄격한 칙령일 필요는 없다. 새로운 팀원에게 줄 수 있을 만큼의 간단한 무엇인가로 이를 통..
-
13. 소프트웨어 설계에 대한 이야기Technique/Programmer 2017. 3. 19. 15:06
건축 설계는 공간 낭비에 대한 예술이다 - Philip Johnson 나쁜 구조로 인해 심각한 악영향이 발생되었다. 통찰력과 설계가 부재한 프로젝트에는 다음과 같은 문제가 발생하기 쉽다.- 낮은 품질의 비주기적인 제품 업데이트- 유연하지 못한 시스템으로 어려워진 신규 기능 추가 및 변경- 시스템 전체에 만연한 코드 수준의 문제들- 스트레스, 사기, 이직 등 사람의 문제- 회사 내부에 만연한 지저분하고 정치적인 문제들- 회사에 필요한 성공의 부재- 코드 작업에 필요한 엄청난 고뇌와 야근 좋은 프로젝트를 이끌어 가기 위해선 어떤 점을 유의해야 하는가? 시스템 구조에 대한 명확한 비전을 처음부터 가지고 있어야 한다.그래야만 새로운 기능 단위들을 코드베이스상의 정확한 기능 영역에 일관되게 추가할 수 있다.그렇게..
-
기술 부채Technique/Programmer 2017. 3. 19. 14:19
기술 부채 ( Technical debt ) 기술 부채는 위키사이트의 창시자로 알려진 컴퓨터 프로그래머 워드 커닝햄에 의해 만들어진 신조어로서, 오늘날 소프트웨어 업계에서 광범위하게 사용되고 있다. 금융업계에서 유래한 이 은유적 표현은 소프트웨어를 빠르게 출시하기 위한 결정을 내리는 것은 부채를 지는 것과 다름 없다는 의미를 갖고 있다. 즉 지금 무언가를 할 수 있게 해주는 것으로 그것이 없었다면 무언가를 할 수 없었다는 뜻이다. 다만 부채는 무시해서는 안 되며 반드시 되갚아야 한다. 되갚는 시기가 늦어질수록 더 많은 비용이 든다. 적절한 시간에 갚지 않는다면, 부채에 대한 이자가 늘어나고 효용은 줄어든다. 소프트웨어 세상에서의 기술 부채란 코드로 되돌아가 업데이트 하라는 뜻이다. 수정하지 않은 채 코드..
-
응집도와 결합도Technique/Programmer 2017. 3. 16. 22:32
소프트웨어 설계의 품질과 관련한 핵심적 요소로 응집도와 결합도가 있다. 이는 OO( Object-Oriented ) 개념에서 비롯된 것이 아니다.개발자 들은 1970년대초 구조적 설계에 대한 이야기를 시작한 시점부터 오랜 시간에 걸쳐 이에 대해 이야기해왔다. 응집도와 결합도는 다음과 같은 특징을 지닌 컴포넌트로 시스템을 설계하는 것을 목표로 한다. - 강력한 응집도응집도는 기능적으로 연관된 것끼리 얼마나 모여 있고, 하나의 모듈 내에서 내부 부분들이 얼마나 유기적으로 작동하는지에 대한 척도이다. 응집도는 모듈을 단단하게 뭉쳐놓는 접착제에 비유할 수 있다. 한편 빈약한 응집도를 가진 모듈은 잘못된 기능 분해의 징후이다. 각 모듈은 명확하게 정의된 역할을 가져야 하며, 관련없는 기능을 마구잡이로 모아놓은 덩..