Software Engineering Note

책을 읽던 중 사례 연구를 다루는 부분을 읽다가 생각이 나서 작성해 본다. 평화롭던 어느 날 서버 애플리케이션이 내려가기 시작했다. 동일한 어플리케이션이 수십대 서버에서 돌아가고 있었는데 하나씩 차례대로 내려갔다. 우선은 서비스 복구가 먼저이므로 한 명은 애플리케이션을 재시작하기 시작했고, 다른 팀원들은 원인 분석에 들어갔다. 원인은 너무 큰 데이터가 들어왔고, 이 데이터를 읽어 객체로 변환하는 과정에서 발생한 것이었다. 다만, 무조건 발생하는 건 아니었다. 이 애플리케이션은 요청한 size 만큼 결과를 내어주는데, 요청 size 가 작으면 버틸만했다. 원인을 알아냈으니 이제 개선을 해야 한다. 어떻게 개선을 할 수 있을까? 생각해 보자. 너무 큰 데이터를 읽으려고 하면 에러를 발생시켜 에러 응답이 나가..

1. 장인 정신 주어진 일을 직업이나 직장생활에서 해야 하는 의무로 생각하느냐, 정말 잘 끝내야 하는 작품으로 생각하느냐의 차이는 엄청 큰 것이다. (개발자의 업무는 대부분 코드를 생산하는 것이라, 이것을 작품이라 표현했다.) 코드를 보면 이 사람이 어떤 마인드로, 어느 정도의 정성으로 일을 했는지가 보인다. 생계를 위한 코드는 동작하는데 만족한다. 고민의 흔적이 많이 보이지 않는다. 여기저기 중복이 존재하고, 확장성은 찾아보기 힘들다. 내가 같이 일 하고 싶은 동료들은 모두 장인 정신이 어느 수준 이상은 있었다. 내 기준으로는 그런 동료들이 좋은 개발자이다. 그들에게는 배울 점이 있고, 같이 성장하는 기분이 든다. 그들은 일단 눈높이가 높아서 같은 일을 해도 일의 퀄리티가 다르다. 더 좋은 코드, 더 ..

코딩 테스트에 대한 생각을 적어보려 한다. 코딩 테스트의 유형은 크게 두 가지로 나뉜다. 온라인 코딩 테스트, 그리고 직접 만나서 티키타카를 하며 진행하는 코딩 인터뷰 온라인 코딩 테스트는 주로 테스트 환경을 제공하는 업체를 통해 진행되고 지원자에게 링크가 전송되어 언제까지 풀라고 요구한다. 코딩 테스트를 생각하기 전에 먼저 어떤 개발자를 뽑고 싶은지 생각할 필요가 있다. - 최소한의 코딩 능력만 갖춰도 괜찮은 개발자를 원하는가? - 알고리즘에 탁월하거나 머리가 좋은, 순발력이 뛰어난 개발자를 원하는가? - 기본적인 코딩능력과 문제 해결 능력이 있고 잠재력이 있는 개발자를 원하는가? 알고리즘에 탁월하거나 문제 해결 능력이 엄청 뛰어난 개발자를 뽑고 싶다면, 미친 수준의 하드코어 알고리즘 문제를 내고 온라..

저는 올해로 12년 차 개발자입니다. 최근 어떤 계기로 사회에 진출하려는 분들의 고민을 듣게 되었고 조금이나마 도움이 되고자 글을 씁니다. 개발자를 위한 조언은 여기저기서 쉽게 얻을 수 있지만, 정보는 많을수록 좋으므로 오늘 그 주제에 하나의 글을 더 추가하려 합니다. 이 역시 개인적인 의견이므로 참고만 하시길 바랍니다. 1. 백문이 불여일타 일단, 많이 만들어봐야 합니다. 거창한 거 말고 할 수 있는 것부터 만들어보세요. 아주 간단한 거라도 괜찮습니다. 저는 대학 때 게임 제작 동아리에서 활동했습니다. 숫자 3,6,9 게임 같은 것을 시작으로 테트리스도 직접 만들어봤습니다. 나중에는 비행 슈팅 게임도 만들게 되었습니다. 물론, 결과물 자체만 보면 하찮죠. 이미 흔한 것이고요. 훈련에 의미를 둬야 합니다..

1. O(N^2), O(N), O(logN)... 자료구조나 알고리즘 시간에 많이 보던 수식입니다. 머릿속에는 이런 형태의 공식으로 박혀있죠. "x 알고리즘 = 복잡도 y" 저도 꽤 오랫동안 그랬던 것 같습니다. 하지만 현업에서도 이걸 잘 따져봐야 하는 일들이 가끔 생깁니다. 예를 들어봅시다. 당신이 만든 프로그램이 2중 for 문으로 구성되어있다고 합시다. 복잡도가 O(N^2) 라고 해보죠. 시간이 너무 오래 걸려서 개선을 하고 싶습니다. 당신은 N을 약 N-3 정도로 줄여서 약간 개선시켜, 다행히 사용 가능한 정도는 되었습니다. 이건 잘 개선되었다고 말할 수 있을까요? 아마 높은 확률로 머지않아 문제가 생길 겁니다. 그런데 새로운 방법을 생각해서 복잡도를 O(N*logN) 정도로 개선을 했다고 합시다..

파일 다운로드 > 압축 해제 > hdfs 업로드 > hdfs to storage 업로드 이런 플로우로 데이터를 처리할 일이 있었다. (n = 0 ... ?) shell script로 구현을 하고 돌려보는데 속도가 너무 느렸다. 어디가 병목일까? 보니 압축 해제하는 부분이 특히 느렸다. 그래서 그 부분부터 병렬화 하기로 했다. 병렬화는 script 파일을 나누고 백그라운드(&) 로 돌리면 된다. ex) hdfs_uploader.sh ... & 여기서 다시 아래와 같은 문제가 발생했다. 1) unzip 하는 작업이 많아지면 cpu를 너무 많이 차지한다. 2) storage upload 작업이 너무 빈번해지면 문제가 된다. 이제 다시 한 번 정리를 해보자. 1) 파일 다운로드는 빠르다. 문제없는 부분 2) u..

클래스를 나누고 싶어질 때는 물론 하나의 클래스가 너무 커질 때입니다.하지만 크다고 해서 무조건 나누지는 않죠. 그냥 나누는 건 의미가 없기 때문입니다. "잘" 나눠야죠. 커져버린 클래스를 나누는 것 외에 클래스를 나누고 싶어 질 때가 있습니다.보통은 느낌상 코드가 예쁘지 않을 때인데, 최근에 경험한 것을 정리하자면 바로 "문맥"이 섞이는 때입니다.예를 들어, 클래스 A에서는 "취소"가 맞아 보이는데 메서드를 정리하다 보니 어떤 부분에서는 "삭제"라는 문맥이 발생하는 것입니다.이런 때는 문맥을 기준으로 클래스를 분리하면 역할이 명확해집니다.보통 하나의 클래스를 여러 개의 메서드로 분리하고 중복을 제거하다 보면 발견될 것입니다. 그런데 클래스를 나누고 나서 어떻게 잘 나누어진 것인지 확신할 수 있을까요?이..

FDD(Feeling-Driven Development)- 개발자의 촉으로 이상한 기운을 탐지하고 즉각 리팩터링을 실행한다. - 그리고, 그 느낌이 무엇이었는지 되도록 객관적으로 정리한다. 기존 이론과 엮으면 더 좋다.

TDD에서는 테스트를 먼저 작성하고 코드를 작성하라고 하죠. 오늘 그렇게 해야 하는 이유가 두 가지 느껴져서 적어봅니다. 첫 번째 이유는 테스트를 "완벽히" 실패 시키기 위해서입니다. 왜 실패를 시켜야 할까요? 그건 "운이 좋아서 패스하는 경우" 를 피하기 위해서입니다. 로직을 먼저 작성하고 테스트를 만든다고 가정 해봅시다. 새로운 if가 생겼고 필요한 코드를 모두 작성했습니다. 테스트를 돌려보니 파란불이 뜨네요. "역시 내 실력이란 훗" 그런데 알고보니 다른 if로 빠져서 테스트가 운좋게 통과 된것입니다. 이러한 우연은 가끔씩 찾아오기때문에 무시할 수가 없습니다. 그래서 지금 상태에서 실패되는 상황을 완벽하게 재현해줄 필요가 있는 것입니다. 두 번째 이유는 불필요한 코드를 작성하지않기 위해서입니다. 로..

개발 하다가 느끼는 좋은 코드를 만드는 간단한 습관 딱 2가지. 1. 메소드로 추출해서 잘개 쪼개기2. 중복 제거 이게 땡이라는게 아니라 시작점이라고 말하고싶다. 메소드로 잘게 쪼개다보면 누가누가 친한지가 보이게되고, 친한 애들은 따로 모아놓고싶어진다. 그러면 클래스로 빼내게 되고 친한 애들은 모여있게 되니 전문용어로 응집도가 높아지게 되겠다. 그리고 이렇게 기능별로 잘 나누어지게 되면 테스트 하기도 수월해진다. 중복제거는 말 그대로 반복되는 코드는 하나로 묶어두고 재사용하자는 것이다. 이걸 잘 하려면 어떤 부분이 공통부분이고, 어떤 부분이 독립적인지 잘 가려내야한다. 그냥 머리로 파악하는게 아니라 실제로 이렇게 해보고 저렇게 해보면서 (일명 삽질) 공통된 부분을 추출해가는 것이다. 실용주의 프로그래머에..