Technique
-
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. 헤쳐 나가기 더러운 코드를 만들게 된 이유부터 냉정하게 분석해야 한다.더러운 코드를 방금 발견 했다..
-
6. 경로 탐색Technique/Programmer 2017. 2. 2. 15:25
개발자 라면 더 많은 코드를 둘러봐야 하고 더 자주 새로운 프로젝트에 투입되어야 하낟. 하나의 팀에서 영원히 하나의 코드베이스만 다루다가 고인 물이 되지 말아야 한다 이미 존재하는 거대한 코드베이스에 적응하기란 어려운 일이다. 적응을 위해서는 다음과 같은 작업을 빠르게 해내어야 한다.코드의 어느 부분부터 보아야 하는지 파악하기코드의 부분별 기능을 알아내고, 그 기능을 어떻게 수행할지 살펴보기코드의 품질을 가늠하기시스템 내부를 어떻게 탐색할 것인지 계획하기코딩 관례를 이해하고, 본인의 수정 사항이 그것과 어울리도록 만들기특정 기능이 있을 법한 위치를 파악하고, 그 기능에 의해 발생하는 버그 찾아보기코드와 함께 그것의 주요한 부속 부분들의 테스트 코드 및 문서 등의 관계를 이해하기 1. 친구들의 작은 도움 ..
-
[ 펌 ] 버그는 나의 힘Technique/Column 2017. 1. 31. 17:30
이 글은 임백준 님의 칼럼을 퍼온 글 입니다.원문 : http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170131085723&lo=z46 버그를 두려워 하거나 부끄러워 하는 개발자가 많다. 10년 전 월스트리트에서 CDS와 채권거래 시스템을 개발하던 시절, 매일 받은 심리적 압박이 기억난다. 사소한 버그가 어마어마한 돈의 방향을 바꿀 수 있기 때문에 코드의 정확성은 생명과 같았다. 런던에 출장을 가서 거래소에서 여러 사용자와 대화를 나누는데 우리가 만든 소프트웨어에서 버그가 출몰한 적이 있었다.누군가와 통화를 나누던 사용자는 수화기를 던지며 욕설을 퍼부었고, 나는 그의 원초적인 분노를 받아내며 디버깅을 위한 자료를 수집해야 했다. 대체로 회사의 규..