Daily Layer Daily Layer

소프트웨어 개발 중 만나는 여러 문제가 있다. 그 중 하나인 요구 사항을 제시하는 사람과 요구를 분석하는 사람, 두 사람도 모르는 문제. 미지의 영역에 대한 부분에 집중해본다. 개요 개발을 요청하는 사람이 정말 완벽한 체계를 설계 해온다면 개발자는 작업만 하면 된다. 하지만 대부분의 경우 요구 사항을 토대로 실제 요구를 채굴해내어야 한다. 요구 사항은 요구하는 기능 깊숙한 곳에 숨어있다. 그러면 어떡해야하죠..? 요구사항이 들어오면, 그 요구사항의 의도를 파악하고, 확장 가능한 설계로 나누고, 그 설계의 세부 동작을 설정 가능하도록 분석해내어 요구사항을 채굴해낼 수 있다. 요구사항 예시 다섯가지를 확인해보려 한다. 요구사항 기능의 응답시간은 500ms 이하여야 한다. 대화 상자의 배경은 회색이다. 애플리..

책은 생각 정리에 큰 도움이 된다. 내가 객체지향을 아는데 몰랐던 이유를 이제 조금 알게 되었다. 객체 지향 언어 (Object-oriented programming, OOP) 객체 지향에 대한 이야기는 개발을 공부할 때, 어떤 경로로든 알게 된다. 심지어 대학교에서도 가르쳐주는 개념이다. 하지만 그 깊이와 그 중요성을 알려주는 곳이 적을 뿐더러, 이해의 필요성을 호소하는 사람은 더더욱 없었다. 하물며 지금의 내가 공부할 때 당시의 나에게 가르쳐주려고 시도했다 한들 그 필요성을 제대로 깨달을 수 있었을까? 클래스, 객체(인스턴스), 메서드(메소드), 메시지 객체 지향의 구성 요소의 사전적인 의미는 누구나 배운다. 이게 무엇이냐 물었을 때 그럴싸한 대답을 할 수 있다. 속성과 행위, 그리고 그 연관 관계들..

개발자가 되어 일을 하다가 나름의 경험이 생기고 나서 생긴 일이다. 프로그램의 동작은 내가 생각한게 맞고, 내가 가정한 상황이 전부고, 내가 테스트한 환경이 전부라고 생각하는 오만방자한 순간이 오고, 그 어마무시한 자신감을 코드에 싣게되었다. 어느 순간 깨달았을까, 내가 코드를 작성하면 절대적으로 버그를 생산하고, 의도한 기능에 맞지도 않을때가 많다는것을 깨닫고 코드를 작성하는것이 공포스러운 순간이 왔다. 이를 극복하기 위해 코드를 조심히(?) 작성한다는 정말 말도안되는 생각을 했지만 그 공포감에 휩싸인 사람이 코드를 조심히 작성해도 버그는 멈추지 못하는것은 당연했고, 더 깊은 공포에 사로잡히는 계기가 되었을 뿐이다. 스스로의 오만방자했음을 깨닫고 공포감의 우물을 박차고 나가는데는 여러 글이 도움이 되었..