Programmer/Programming
-
C++에서 언제 어떻게 struct를 사용하는가?Programmer/Programming 2017. 9. 25. 16:03
C++로 코딩할 때에 class와 struct 중에 무엇을 사용할 지 고민을 할 때가 있다. 내가 C++에서 struct를 선택하는 기준은 다음과 같다. 분해하면 모든 멤버 변수가 scala data type이다. 멤버 변수 중에 union, struct 또는 고정 길이 array를 만나면 재귀적으로 분해한다. 모든 말단이 scala data type으로 이루어졌다면 struct를 사용한다. 즉, 분해하는 과정에서 포인터나 가변 길이 배열, 클래스를 만나면 struct를 사용하지 않는다. 구조체를 이진 데이타로 고스란히 pack/unpack 해야 한다. struct는 메모리 형태 그대로 데이터로 상호 변환 가능함으로 개발하기 편하다. 굳이 별도의 pack/unpack 함수를 작성할 필요가 없다. 단, 데..
-
일단 만들어라. 두 번 만들어라. 그러면 보일 것이다.Programmer/Programming 2017. 6. 29. 06:26
내가 실무에서 배운 최고의 코드 설계 방법은? 일단 만들어라. 두 번 만들어라. 그러면 보일 것이다. 문제를 이해하는 가장 좋은 방법은 만들어보는 것이다. 생각만으로는 알 수 없다. 구현하면서 문제에 대한 이해가 높아진다. (관련 링크: 창의적인 일을 찾지 말고 창의적으로 일을 하라.) 어떻게 하면 효과적으로 문제를 탐색할 수 있을까? 첫번째 구현에서는 문제의 탐색에 초점을 두어야 한다. 머릿속에 떠오르는 이상적인 시나리오를 직선적으로 표현한다. 세세한 예외 처리나 아름다운 코딩 등에 시간을 빼앗기지 말자. 그림에 비유하자면, 머릿속에 떠오른 이미지를 거침없이 스케치를 하는 것과 같다. 화폭에 그리면서 전반적인 이야기와 구도를 잡는 것이 가장 효과적이다. 이 단계에서는 눈가의 잔주름과 같은 세부적인 부분..
-
문제가 발생하면 근본 원인 찾아라.Programmer/Programming 2017. 3. 6. 22:10
문제가 발생하면 근본 원인 찾아라. 근본 원인을 찾지 않고 성급하게 해결하는 것은 나쁘다.대표적인 사례가 핵(hack)이다. 핵은 원인을 고치지 않고 드러나는 문제만을 처리한다. 근본 원인 파악 없이 방어 코드로 해결한다. [표면적인 문제만 해결하려는 우리들의 모습] 자동차의 시동을 두세번 시도해야 비로서 작동하는 문제가 있다고 가정해보자. 핵를 쓰는 엔지니어는 시동 걸릴 때까지 자동으로 반복해주는 기능을 추가한다. 여러 가능성이 있는 원인을 조사하지 않고 표면적인 문제만을 처리하였다.그러나, 이러한 방식은 문제를 감추었을 뿐 근본이 해결되었는지 알 수 없다. 숨겨진 문제가 언제 드러날지 누구도 알 수 없다. 게다가, 이렇게 원인이 해결 안 된 문제들이 숨겨지면서 누적된다는 것이 더 심각하다. 시동이 잘..
-
엑세스 함수(getter/setter)를 올바로 사용하기Programmer/Programming 2017. 2. 13. 13:05
객체의 속성을 읽고 쓰는 일관된 표현 방식을 제공하라. 엑세스 함수를 추천한다.[각주:1] 엑세스 함수를 사용하면 의존성 깨짐의 걱정 없이 구현을 바꿀 수 있다. Null을 할당하는 것을 허용하지 않거나 객체의 속성을 외부에서 바꿀 수 없는[각주:2] 규칙이 더해질 수 있다. 메모이제이션(memoization)[각주:3]과 같은 기능을 추가할 수도 있다. 자료형과 알고리듬이 변경되기도 한다. 엑세스 함수를 사용했으면, 이것을 이용하는 의존 모듈의 수정 없이 규칙과 기능을 추가할 수 있다. 추상적인 자료형을 사용한 엑세스 함수는 객체의 자료형 변경을 용이하게 한다. 위 이유는 명확하니 굳이 설명할 필요가 없다. 모호한 상황에서도 엑세스 함수 강제가 정당한지 생각해보겠다. 멤버 변수의 자료형, 알고리듬의 변..
-
public, private, const 키워드가 필요한 이유Programmer/Programming 2017. 2. 8. 11:08
public/private 키워드는 정보 은닉, 캡슐화 등에 도움을 주는 도구이다. 정보 은닉은 복잡하거나 변경 가능한 설계 결정을 안정적인 인터페이스 뒤로 숨기는 기본 설계 원리이다. 정보 은닉은 모듈을 분할하기 위한 기본 원리다. 모듈은 변경될 가능성이 있는 비밀을 내부로 감추고 잘 정의되고 쉽게 변경되지 않을 공용 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 한다. 캡슐화는 ‘온갖 방법의 숨기기’라고 생각하면 쉽다. 캡슐화를 통해 데이터를 숨길 수 있다. 그리고 구현 코드, 파생 클래스 또는 여러 가지의 것들을 숨길 수 있다. - 알란 섈로웨이, 제임스 트로트, “알기 쉬운 디자인 패턴 캡슐화는 가해지는 변경에 대한 파급 효과를 일정한 영역 내부로 제한시킬 수 있다. 대부분의..
-
C언어에서 struct 정의 그대로 이진 데이터로 만들기Programmer/Programming 2017. 1. 13. 15:15
C의 struct를 이진 데이터로 저장하고 불러오는데 원하는대로 되지 않을 때가 있다. 예를 들어, 2 바이트 이후에 적혀야 하는데 4바이트 뒤에 위치하는 경우이다. 예상한 이진 데이터의 구조: 실제 이진 데이터의 구조 (목표 머신-target machine-을 64 bits로 컴파일한 경우): 이는 데이터 구조체 정렬(data structure alignment) 때문에 발생한다. 데이타 구조체 정렬이란 해당 머신의 읽고 쓰는 단위 크기의 배수로 데이타를 할당하는 것을 말한다. 데이터가 이 배수값보다 작으면 데이터 구조체 패딩(data structure padding)을 해준다. 현대의 컴퓨터는 성능을 높이기 위해서 이런 방식을 기본으로 사용한다. 따라서, 프로그래머가 정확한 이진 데이터를 생성하려면 ..
-
교착상태(deadlock)를 프로세스 상태와 디버거를 사용해서 찾아내기Programmer/Programming 2017. 1. 6. 15:37
멀티미디어(multimedia) 소스를 수신 받아서 가공하고 송출하는 프로그램을 개선하고 있었다. 에이징 테스트(aging test)에서 얼마간 프로그램이 동작하다가 미디어를 송출하지 못하는 버그를 발견했다. 로그를 살펴보니 송출이 멈추기 전에 수신부터 진행이 되지 않는 것을 발견했다. UDP로 입력 데이터는 들어오는데 읽지 못하고 있었다. 기능이 멈춰있으면 있으면 두가지를 의심할 수 있다. 하나는 무한루프, 나머지 하나는 교착상태(deadlock)이다. 무한루프에 빠지거나 교착 상태에 진입하면 다음 단계로 나아가지 못한다. 무한 루프인지 교착 상태인지 간단하게 판단하는 방법은 프로세스의 CPU 점유율과 상태를 확인하는 것이다. `ps -u`나 top 유틸리티로 확인한다. 무한 루프는 CPU를 과도하게 ..
-
버젼 관리 시스템을 사용하여 문제를 해결하기Programmer/Programming 2017. 1. 6. 15:01
초반에는 문제의 원인을 충분히 넓게 잡아라."에서 중요한 디버깅 기법 하나를 간단하게 언급하고 넘어갔다. 분석의 과정이 없이 추론에 근거하여 새로 추가된 원격 기능과 캐싱 알고리즘만을 의심했다. 코드를 수정해도 상태가 개선되지 않았다. ... 중략 ... 이전 버젼과 차이점을 면밀하게 비교하면서 비로서 문제의 원인을 발견했다. 같은 환경과 같은 기능(즉, 로컬 파일 읽기)에서도 새 버젼에서 동일한 문제가 일어났다. 즉, 새로운 기능이 동작할 때 발생하는 것이 아니란 의미이다. 로깅 시스템을 리펙토링을 했는데, 이와 연관이 깊을 것으로 추정했고 다양한 테스트로 이를 검증했다. - 2014/07/15 - [Practice/Debugging] - 초반에는 문제의 원인을 충분히 넓게 잡아라. 버젼 콘트롤 시스템..