프로그래머
-
기술 부채Technique/Programmer 2017. 3. 19. 14:19
기술 부채 ( Technical debt ) 기술 부채는 위키사이트의 창시자로 알려진 컴퓨터 프로그래머 워드 커닝햄에 의해 만들어진 신조어로서, 오늘날 소프트웨어 업계에서 광범위하게 사용되고 있다. 금융업계에서 유래한 이 은유적 표현은 소프트웨어를 빠르게 출시하기 위한 결정을 내리는 것은 부채를 지는 것과 다름 없다는 의미를 갖고 있다. 즉 지금 무언가를 할 수 있게 해주는 것으로 그것이 없었다면 무언가를 할 수 없었다는 뜻이다. 다만 부채는 무시해서는 안 되며 반드시 되갚아야 한다. 되갚는 시기가 늦어질수록 더 많은 비용이 든다. 적절한 시간에 갚지 않는다면, 부채에 대한 이자가 늘어나고 효용은 줄어든다. 소프트웨어 세상에서의 기술 부채란 코드로 되돌아가 업데이트 하라는 뜻이다. 수정하지 않은 채 코드..
-
응집도와 결합도Technique/Programmer 2017. 3. 16. 22:32
소프트웨어 설계의 품질과 관련한 핵심적 요소로 응집도와 결합도가 있다. 이는 OO( Object-Oriented ) 개념에서 비롯된 것이 아니다.개발자 들은 1970년대초 구조적 설계에 대한 이야기를 시작한 시점부터 오랜 시간에 걸쳐 이에 대해 이야기해왔다. 응집도와 결합도는 다음과 같은 특징을 지닌 컴포넌트로 시스템을 설계하는 것을 목표로 한다. - 강력한 응집도응집도는 기능적으로 연관된 것끼리 얼마나 모여 있고, 하나의 모듈 내에서 내부 부분들이 얼마나 유기적으로 작동하는지에 대한 척도이다. 응집도는 모듈을 단단하게 뭉쳐놓는 접착제에 비유할 수 있다. 한편 빈약한 응집도를 가진 모듈은 잘못된 기능 분해의 징후이다. 각 모듈은 명확하게 정의된 역할을 가져야 하며, 관련없는 기능을 마구잡이로 모아놓은 덩..
-
12. 복잡도 다루기Technique/Programmer 2017. 3. 16. 00:02
간결함은 가장 위대한 덕목이지만, 이를 달성하려면 고된 작업이 필요하며 또한 이해하려면 별도의 교육이 필요하다. 상황을 더 어렵게 만드는 것은 "복잡하면 더 잘 팔린다" 라는 사실이다. 에츠허르 데이크스트라 복잡한 무언가를 작성하는 일은 너무나 쉽게 일어진다. 집중하지 않고 충분히 계획을 세우지 않으면 일어날 수 있다.복잡한 것을 간단한 문제로 간주하고 작업할 때도 일어날 수 있다. 소프트웨어의 복잡도는 크게 세 가지 원인에서 기인한다.- 블럽- 라인- 사람 1. 블럽( Binary Large OBject ) 블럽의 크기와 수가 복잡도를 결정한다. 일부 소프트웨어의 복잡도는 블럽의 크기에 따른 자연스러운 결과라 할 수있다.프로젝트가 크면 클 수록 더 많은 블럽을 필요로 한다. 그럴수록 이해하기는 더 어려..
-
11. 테스트 하기Technique/Programmer 2017. 2. 22. 01:41
TDD는 더 나은 소프트웨어를 만들기 위한 중요한 기법 중 하나다. 그런데 테스트 주도와 유닛 테스트가 실제로 무엇을 의미하는가에 대해서는 명확하지 않은 점이 있다. 우선 이를 명확히 한 뒤 개발자 테스트에 대한 적절한 방법을 찾아본다면, 더 나은 코드를 짤 수 있을 것이다. 1. 왜 테스트 하는가?자신의 코드는 자신이 테스트해야 한다. 생각할 필요도 없는 당연한 일이다. 1-1. 피드백 과정 줄이기위대한 소프트웨어를 제대로 만들기 위해서는 피드백을 받아야 한다. 가능하면 자주 그리고 빨리 피드백을 받는 것이 좋다. 좋은 텟트 전략이란 피드백 절차를 간소화하는 것으로, 이를 통해 더 효율적으로 일할 수 있다.피드백 과정이 짧을수록 설계 변경을 더 빠르게 반복할 수 있고 코드에 대해 더 강하게 확신할 수 ..
-
10. 버그 사냥하기Technique/Programmer 2017. 2. 8. 00:59
프로그래머가 코드를 작성한다. 하지만 프로그래머는 완벽하지 않고, 프로그래머의 코드 역시 완벽하지 않다. 즉 처음부터 완벽할 수 없기 때문에 버그기 생긴다. 만약 더 나은 프로그래머가 나타난다면 그 만큼 더 나은 버그를 키워낼 뿐이다.대부분의 버그는 많은 시간을 할애하여 추적하는 과정에서 머리카락이 듬성듬성 빠져버릴 정도로 끔찍하고 미묘한 문제거리가 된다. 그러한 버크들은 이상하고 놀라운 상호 작용이나 예상치 못한 알고리즘의 결과물 로서, 매우 간단해 보이는 소프트웨어의 비결정론적 형태라 할 수 있다.버그를 피하지 말자. 어차피 많은 디버깅을 하게 될 것이다. 점차 그에 익숙해질 것이고 또한 잘 해낼 것이다! 1. 경제적 우려 단지 개발자의 임금에 국한된 문제가 아니다. 버그가 많은 소프트웨어로 인해 비..
-
9. 예상하지 못한 것을 예상하기Technique/Programmer 2017. 2. 6. 14:57
코드 작성 시 벌어질 것으로 예상되는 상황에 대한 대비만으로는 부족하다. 모든 단계에서 조금이라도 발생할 가능성이 있는 특이 사항들은 모두 고려해야 한다. 1. 오류 호출되는 어떤 함수도 예쌍대로 작동하지 않을 수 있다.운이 좋다면 오류 코드를 전달받을 수 있을 것이다. 그렇다면 값을 확인하라. 절대 무시하지 말자함수는 자신의 기능이 제대로 이행되지 않을 때 예외를던질 수도 있다. 코드가 예외 발생에 대해 대처하도록 하자. 직접 예외를 처리하든 아니면 스택 호출을 통과하게 놔두든 간에, 코드가 정확히 카동하도록 하자. ( 여기서 말하는 정확함이라 함은 리소스 누수가 없고 프로그램이 부적절한 상태가 되지 않도록 하는 것 )함수가 실패의 징후인 반환 코드나 예외 등을 돌려주지 않은 채, 기대되던 기능을 수행..
-
8. 오류 무시하지 않기Technique/Programmer 2017. 2. 6. 14:21
오류가 났다고? 무슨 오류? 별문제가 아닐 수도 있다. 솔직히 말하면 그냥 무시할 수도 있다.하지만 이러한 태도는 견고한코드를 만들기 위한 좋은 전략이라고 할 수 없다. 혹은 단순히 게으름에서 비롯된 결과일 수 있다.코드 안에 오류가 있을 것으로 여겨지지 않아도, 만약을 대비해 항상 유심히 확인하고 검토해야 한다. 1. 메커니즘우리는 여러 바법으로 코드의 오류를 확인한다. 코드 응답 함수는 값을 반환한다. 그중 어떤 것들은 작동하지 않음 을 뜻한다. 오류에 대한 반환 코드는 무시되기 십상이다. 코드에 문제가 있음을 알리는 어떤 것도 발견되지 않을 것이다. 반환 코드는 가장 보편적인 오류 검출 방법이다. 함수들은 값을 반환하고, 운영 체제 프로세스도 값을 반환하며, 어떤 시스템에서는 스레드 역시 값을 반환..
-
7. 똥통에서 뒹굴기Technique/Programmer 2017. 2. 5. 23:37
누구나 늪과 같은 코드를 만나본 적이 있을 것이다. 알지 못하는 사이에 코드 속에서 허우적 거리다가 결국 점점 빠져들고 있음을 깨닫는다.코드가 꽉 짜여 있어 고치기도 어렵고, 뭔가 바꿔 보려 하면 많은 에러를 뱉어 낸다. 바꿔보려 할수록 그 속에 더 깊이 빠져들 뿐이다. 1. 눈치 채기 훌륭한 코드는 순수 예술이나 한 편의 시와 같다. 그러나 언제나 이런 시와 같은 훌륭한 코드만 존재하진 않는다.이상한 코드를 효과적으로 다루기 위해서는, 문제 지점을 어떻게 찾고 다룰지 알아야 한다.※ 나쁜 코드를 언제든 만날 수 있다는 마음의 준비를 하자. 나쁜 코드를 다룰 때 쓸 강력한 도구들을 미리 준비해 두자. 2. 헤쳐 나가기 더러운 코드를 만들게 된 이유부터 냉정하게 분석해야 한다.더러운 코드를 방금 발견 했다..