Software Engineering Note

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다.- 간단한 규칙을 정하고 따라야 한다.- 팀이 합의해 규칙을 정하고 모두가 따라야 한다.- 규칙을 자동으로 적용하는 도구를 활용한다. 형식을 맞추는 목적- 의사소통이다.- 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드이 품질에 지대한 영향을 미친다. 적절한 행 길이를 유지해라 신문 기사처럼 작성하라 개념은 빈 행으로 분리하라- 빈 행은 새로운 개념을 시작한다는 시각적 단서다. 세로 밀집도- 서로 밀접한 코드 행은 세로로 가까이 놓여야 한다. 수직거리- 서로 밀접한 개념은 세로로 가까이 둬야 한다.- 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다. 변수선언- 사용하는 위치에 최대한 가까이 인스턴..

우리는 코드로 의도를 표현하지 못해, 실패를 만회하기 위해 주석을 사용한다. 주석이 필요한 상황에 처하면 곰곰이 생각하기 바란다. => 상황을 역전해 코드로 의도를 표현할 방법은 없을까? 주석은 나쁜 코드를 보완하지 못한다. 좋은 주석 (그나마 남아있어도 되는 주석?)- 법적인 주석- 정보를 제공하는 주석- 의도를 설명하는 주석- 의미를 명료하게 밝히는 주석- 결과를 경고하는 주석- TODO 주석- 중요성을 강조하는 주석 (자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해)- 공개 API에서 Javadocs 나쁜 주석(대다수 주석...)- 주절거리는 주석- 같은 이야기를 중복하는 주석- 오해할 여지가 있는 주석- 의무적으로 다는 주석- 이력을 기록하는 주석 (코드관리 시스템에 맡기자)- 있으나 ..

작게 만들것! 블록과 들여쓰기- if / else / while 문 등에 들어가는 블록은 한 줄이어야 한다.- 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다. 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한가지만을 해야 한다!! 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. => 사람들이 함수에 세부사항을 점점 더 추가한다.- 한 함수에 다른 함수를 호출하는 부분도 들어있고, 다른 함수에서 해야할 일을 하는 부분도 섞여있는 경우 내려가기 규칙- 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. switch문 => 다형성을 이용한다. 서술적..

문제: FIXPAREN / 구현, 자료구조 잘못 매칭된 괄호를 수정하는 문제. 괄호마다 우선순위가 있고, 잘못된 매칭인 경우 우선순위가 높은 괄호로 변환해야 한다. 스택에 무조건 쌓기만 하고 나중에 빼면 출력 순서가 보장되지 않으므로 임의로 index를 지정할 수 있는 배열을 출력용으로 사용했다. 해결전략 1. 왼쪽 괄호인 경우 스택에 넣는다. 이때, (입력 문자열에서의 위치, 문자) 가 저장되는 정보단위가 된다.2. 오른쪽 괄호인 경우 스택에서 왼쪽괄호를 pop한다. (문제 조건을 읽어보면 오른쪽 괄호전에는 반드시 왼쪽 괄호가 저장됨을 보장할 수 있다.)3. 왼쪽, 오른쪽 우선순위를 비교해서 우선순위가 높은 문자로 변환한다. 그리고 출력용 배열에 저장한다. 코드: https://github.com/xg..

이름 짓기에 대한 장 의도를 분명이 밝혀라 - 존재이유는? 수행기능? 사용방법은?- 주석이 필요없게끔, 주석을 넣을거면 그냥 변수 이름을 잘 지어라 문제는 코드의 단순성이 아니라 코드의 함축성이다. - 코드 자체에 맥락이 명시적으로 드러나도록 할 것 그릇된 정보는 피할 것 - 실제 컨테이너가 List가 아니라면 xxxList와 같은 이름은 피한다. => 개발자가 List로 오해할 수 있음- 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지않는 것이 좋다. 읽는 사람이 차이를 알도록 이름을 지어라 발음하기 쉬운, 검색하기 쉬운 이름을 사용하라 (ex: 대문자로 정의하는 상수, MAX_NUM 같은) 인코딩을 피하라 - 여기서 인코딩은 뭔가 의미를 내포한 축약형 글자따위를 의미한다.- 헝가리식 ..

르블랑의 법칙 - 나중은 결코 오지않는다. - 맞다. 나쁜 코드가 보이는대로 바로바로 수정하자. 나중은 없다. 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 좋은 코드를 사수하는 일은 프로그래머들의 책임이다.나쁜 코드의 위험을 모르는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다. - 시간이 들더라도 코드에 더 신경을 써야겠다. 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. - 잘만되면 정말 맞는 말 같다. 하나 둘 눈감기 시작하면 그 양이 방대해지리라. 깨끗한 코드와 나쁜 코드를 구분하는 능력?열쇠는 '코드감각' 이다. 어떤 사람은 타고나고, 어떤 사람은 투쟁해서 얻어야한다. - 이건 좀 슬픈데 ㅠㅠ 그래도 노력하면 얻을 수 있고, 그래서 많은 책들도 나오지않았던가..

깨끗한 코드를 잘 만들기 위한 시작! 코드리뷰 할 때 들었던 커맨트의 진정한 의미를 깨닫고 싶었고, 나도 느낌이 아닌 지식에 기반한 이야기를 하고싶었다. 언젠가는 스터디를 하고싶었는데 팀원 중 한분이 시동을 걸어서 나도 참여했다. Clean Code(클린 코드)저자로버트 C. 마틴 지음출판사인사이트 | 2013-12-24 출간카테고리컴퓨터/IT책소개나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 ... 이것이 교재.. 사내에도 스터디 자료가 있어서 함께 활용하기로 했다. 굿럭! :)

문제: WEEKLYCALENDAR / 구현 1. 달력을 만들고 시작하니 편하다.2. 작년/내년 달력으로 넘어가는 경우를 체크해야 한다. 코드: https://github.com/xgate/algospot/blob/master/IMPL/WEEKLYCALENDAR.cpp

문제: XHAENEUNG / 구현 처음에는 map에다가 넣고 어쩌고 하려다 그냥 무식하게 풀었다. 힌트 - 결국 모든 알파벳이 한 번씩 사용되어야 하므로 정렬하면 비교가 쉬워진다. 코드: https://github.com/xgate/algospot/blob/master/IMPL/XHAENEUNG.cpp

문제: DARPA / 동적계획법, 이진탐색 처음에 greedy로 접근했다가 몇 번 물먹은 문제다. 잊고 지내다가 알고리즘 책(프로그래밍 콘테스트 챌린징)에서 유사한 문제를 보고 다시 도전해서 성공했다. 핵심전략은 다음과 같다. 모든 카메라에 대해, 임의의 두 카메라 간격을 d로 만들 수 있는지 확인한다. 1. d값은 입력으로 주어진 간격의 최대 값부터 시작한다.2. 만약 모든 카메라를 d간격 이상으로 설치할 수 있다면 d값을 늘려서 시도해본다. 왜? 가장 가까운 카메라 간격을 최대화 시켜야 하니까.3. 만약 실패하면 d값을 줄여서 시도해본다. 이렇게 d값을 조절해가면서 범위를 좁혀나간다. 2, 3번 과정에 이진탐색이 적용된다. 2번일 경우 left 값을 mid값으로 한다. 3번일 경우 right 값을 m..