손이 가는 프로그래밍 일탈 10가지

 

‘좋은 걸 어떡해’··· 손이 가는 프로그래밍 일탈 10가지

첨부한 파일 내용에 따라 자기가 짠 프로그램에 그런 유형의 오류가 있는 예를 보이면서 스스로 어떻게 프로그램을 짤지 설명하라.

 

나쁜 프로그래밍 습관 No. 1 : 베끼기(Copying)

 - 코드를 짤 때 비즈니스 로직은 거의 copy paste 없이 작성하는 것 같다. 그러나 유틸리티 개념의 코드들은 stackoverflow 나 google 의 개발 블로그에서 많이 참조하는 편이다. 예를 들어 내가 iOS 외주 개발을 하면서 항상 자주 쓰는 유틸리티 코드들이 있는데 이 코드들은 대부분 내가 다른 코드를 참고한 것이며 static 하게 바꾸어 프로젝트 전체적으로 쓸 수 있고 입출력을 내 필요에 맞게 수정한 것들이다.

예시) 앱이 로딩중인지를 보여주는 로딩 인디케이터

이 코드의 경우는 필요 없는 건 주석처리하고 로직의 뼈대만 사용하여 아이콘과 애니매이션만 커스터마이즈한 코드이다.

 

나쁜 프로그래밍 습관 No. 2 : 논-펑셔널 코드(Non-functional code)

 - functional code는 함수형 프로그래밍으로 선언형 프로그래밍에 속한다. 명령형 프로그래밍은 How를 표현하고 함수형은 What을 표현한다. 거의 대부분의 내 코드는 non-functional 한 코드였다. 내가 Swift와 Java를 써서 그런것도 있지만 functional 패러다임에 익숙하지 않은 것도 있다.

예시)

가게의 메뉴리스트를 받아 카테고리별로 나누어 저장하는 로직이다. 조금의 주석이 달려있지만 여전히 처음 코드를 보는 사람에겐 이해하기 어려울 것이다.

 

나쁜 프로그래밍 습관 No. 3 : 비표준적 띄어쓰기(Non-standard spacing)

 - 대부분의 IDE 들은 정렬이나 인덴트를 맞춰주는 기능이 있다. (Xcode의 경우 cmd+i) 그러나 특수한 경우에는 개발자의 습관이 들어가게 되는데 회사차원에서 정한 스타일이 없다면 혼자 코드를 짜더라도 어떤 코드는 띄우고 어떤 코드는 붙일것이다.

예시)

서버에서 파싱할 데이터의 구조를 선언해 놓은 코드이다. QuestionList의 경우 변수를 선언한 후 공백을 띄우고 : 를 넣는데 QuestionInfo의 경우 변수 선언 바로뒤에 :를 붙인걸 볼 수 있다. 로직이 있는 코드는 아니라 큰 불편함을 없을 것 같지만 for문이나 if 문에서 이러한 코드를 작성한다면 페어 프로그래밍이 힘들어질 것 같다.

 

나쁜 프로그래밍 습관 No. 4 : ‘고투’(goto) 사용

 - goto는 처음 C언어로 프로그래밍을 배울 때 최대한 사용하지 말라고 배웠던것이 기억이 난다. goto로 흐름을 제어하면 코드를 읽을 때 분기점이나 흐름을 한눈에 알아보기 힘들다고 알고있다. 흐름을 제어하는 다른 방법들이 많기 때문에 (if, switch 등등) goto는 쓰지 않는다.

 

나쁜 프로그래밍 습관 No. 5 : 유형을 선언하지 않기(Not declaring types)

 - Swift를 주로 쓰는 나는 타입을 명시적으로 선언하지 않을 때가 많다. 왜냐하면 Swift의 언어 특성상 컴파일러가 타입을 유추가 가능하기 때문이다. optionals의 개념을 사용할 땐 타입을 명시해 주지만 변수에 바로 할당이 되는 값의 경우 따로 선언해 주지 않는 편이다.

예)

특별한 타입인 NSInteger과 storeInfo에서 초기화 대신 optional 으로 StoreInfo(커스텀 모델)를 명시해 주었고 String이나 Int 타입으로 초기화 해주는 변수의 경우 명시적으로 작성하지 않았다. 타입을 정확하게 선언해 주는게 정확성과 안정성은 좋아지지만 코드가 길어지고 당연한 사실을 작성하는 작업이라면 효율성이 떨어질 것 같다.

 

나쁜 프로그래밍 습관 No. 6 : 요요 코드(Yo-yo code)

 - POS어플리케이션과 식당예약 어플리케이션을 개발하면서 제일 많이 경험했던 요요코드는 바로 금액에 대한 콤마넣기(ex. 3,000원)이었다. Int형에서 콤마를 넣고 화면에 표시할 수 없었기 때문에 String으로 바꾼다음 표기했다. 여기까지면 나름 요요코드라고 부르기엔 아쉽다. 하지만 나는 그 변수를 이용하여 추가계산(메뉴를 추가하거나 할인이 추가)를 했기 때문에 콤마를 지우고 Int형으로 바꾼다음 다시 계산하는 코드를 구현한적이 있다. 또한 디비에서 Date를 받아올 때 Date format에 맞게 계속 String 타입과 Date 타입을 바꾼 코드도 있었다. 데이터와 UI 를 분리하여 코드를 작업하면 이런 요요현상을 줄일 수 있을 것 같다.

withCommas()라는 유틸리티 펑션을 만들어 해결했다. UI에 표시할때만 콤마를 붙여주는 함수이다.

 

나쁜 프로그래밍 습관 No. 7 : 나만의 데이터 구조 작성(Writing your own data structures)

 - 감히 내가 커스텀한 자료 구조를 만들어서 쓸 생각은 해보지 않았다. 이미 기존언어에서 제공해 주는 여러가지 효율적인 자료구조가 있기 때문에 커스텀한 자료구조를 사용해 본적이 없다. 만약 기존의 자료구조로의 속도가 스펙에 못 미친다면 커스텀한 자료구조를 사용하는게 방법 일 수 있겠지만 유지 보수와 인수 인계를 항상 생각하며 사용해야 문제가 없을 것 같다.

 

나쁜 프로그래밍 습관 No. 8 : 구식 루프(Old-fashioned loops)

 - 개발을 하다보면 배열형태로 데이터가 오는 경우가 많다. 가장 단순한 처리방식은 for문을 돌리면서 배열하나씩을 Array나 List에 추가하는 것이다. 그러나 어떤 데이터에 매핑된 연산 템플릿이 있는 더 기능적인 패러다임이 많이 나타났다.

예)

위 코드는 예약 가능한 상점의 리스트를 가져오는 네트워크 부분이다. storeArrayList에 상점을 추가할 때 for문을 돌면서 response에서 온 항목들을 하나씩 append 하는 경우도 있지만 나는 JSONDecoder을 통해 바로 배열에 데이터를 넣어주고 있다.

 

나쁜 프로그래밍 습관 No. 9 : 중간에 루프에서 이탈하기(Breaking out of loops in the middle)

 - 알고리즘 문제를 풀 때 루프를 돌다가 답을 찾거나 원하는 값이 나오면 break 하거나 return 하는 경우가 있다. 물론 변수를 두어 (answer 같은?) 루프를 완료 한 뒤에 답을 리턴하는 방법도 있지만 시간 복잡도가 있는 알고리즘 문제에서는 루프 불변성을 깨는게 좋은 선택인 것 같다.

예시)

 

나쁜 프로그래밍 습관 No. 10 : 연산자와 함수 재정의(Redefining operators and functions)

 - 일부의 프로그래밍 언어는 개발자가 요소의 값을 재정의 하는 것을 허용한다. 파이썬의 경우 TRUE=FALSE를 입력 할 수 있다. 여태까지 작성했던 내 코드를 생각하면 굳이 special word 로 빠져 있는 name들은 자연스럽게 쓰지 않았던 것 같다.