프로그래밍에 대한 고찰 및 생각

지난번 Semantic Version 에 이어 버전 옆에 붙는 태그들에 대해 알아보고자 한다. GA (General Availability) public 으로 배포된 버전을 의미한다. CURRENT GA 중에 가장 최신 버전을 의미한다. 이것은 보통 모든 새로운 프로젝트에 사용된다. M (Milestone) release 과정에서 주요한 stage를 마크할 때 사용되며 정해진 주기마다 배포된다. SNAPSHOT release 되기 전 버전을 의미한다. 예를 들어 1.0.0 버전이 배포되기 전에는 1.0.0-SNAPSHOT 이 존재하며 이 버전은 이후에 1.0.0 이 될 것이다. Q. 실제 version 과 snapshot version은 어떤 차이가 있나? A. snapshot version 은 수시로 ..

Spring boot 를 사용하면서 아래와 같은 다양한 버전들을 보게되는데 버전 이름 생성하는 규칙과 옆에 붙어있는 태그들(CURRENT, GA...) 이 정확히 어떻게 붙여지고 어떤것을 의미하는지 정리를 한번 해봐야겠다는 생각이 들었다. 그 중 5.6.2 5.2.15 처럼 숫자로 이루어진 형태의 버전들에 대해 먼저 알아보았다. 01. 소프트웨어 개발에서 Versioning이 중요한 이유? 소프트웨어 Version 은 특정한 이름/번호를 통해 소프트웨어나 패키지의 상태를 구분할 수 있게 해준다. 여기에는 다양한 Versioning Schemes 가 있지만 그중 유명한 것중 하나는 Semantic Versioning (SemVer) 이다. 02. SemVer ? SemVer 의 기본적인 포맷은 위와 같다...

오브젝트의 두번째 챕터인 '객체지향 프로그래밍'에서는 '영화예매 시스템'을 기반으로 객체지향 패러다임에 대해 설명한다. 해당 시스템에 대해 간략하게 설명하면 - 하나의 예매(Reservation)에는 하나의 상영(Screening) 및 상영시간과 순서가 존재한다. - 하나의 상영에는 하나의 영화(Movie)가 존재하고, 하나의 영화에는 요금과 할인 정책이 존재한다. - 할인 정책은 특정 금액을 할인해주는 정책(Amount DiscountPolicy)과 특정 비율을 할인해주는 정책(Percent DiscountPolicy)이 존재하며, 할인 조건으로는 상영순서에 따른 조건(Sequence Condition)과 상영기간에 따른 조건(Period)가 존재한다. 01. 객체지향 패러다임으로의 전환 클래스가 아닌..

오브젝트의 가장 첫번째 챕터인 "객체, 설계" 파트에서는 극장에서의 티켓판매 시스템을 중심으로 좋은 설계가 무엇이고, 어떤 설계가 문제인지, 그래서 객체지향 설계가 무엇이고 왜 필요한지에 대해 설명한다. 01. 좋은 설계란? 이 책에서는 좋은 소프트웨어 모듈 설계에 있어서 다음 3가지를 만족해야 한다고 설명한다. 1. 잘 작동해야 한다. 2. 변경이 용이해야 한다. 3. 쉽게 읽고 이해할 수 있어야 한다. 그간 소프트웨어 모듈을 설계할 때 1번, 잘 작동하는 것에 모든 초점을 맞추어 설계하였다. 예전에는 무언가 조잡해 보이지만 코드를 실행 했을 때 "잘 작동하니까 나름 문제 없는 코드지!" 라는 생각을 했었다. 그러다가 코드리뷰를 통해 잘 작동하는 것을 넘어서 좋은 설계를 하기 위한 조언들을 받으면서 잘..

Q 01. 왜 읽는가? 사실 이 책은 회사에 입사할 때 입사선물로 받은 책이다. "오브젝트"라는 책은 이미 객체지향 설계에 있어서 유명한 책이고 평이 좋아서 항상 읽어야지 생각만 하다가 읽지 못했다. 최근에 spring boot를 이용하여 백엔드 개발을 하면서 "설계"에 대해서 고민을 많이 하고 있다. 단순히 동작하는 코드를 넘어서 어떻게 설계해야 "잘" 설계하는가가 궁금했다. 항상 의식의 흐름대로 "잘 동작하는 것"에만 목적을 두고 코딩을 하였는데 무언가 좋은 설계에 대한 갈망이 커진 것 같았다. 그래서 책장 한켠에 놓여있던 오브젝트 라는 책을 펴야겠다는 생각이 들었다. 이 책을 통해 더 좋은 객체지향적인 설계를 할 수 있는 능력을 키우는 것이 목적이다. Q 02. 목표 기간은? 나는 보통 무언가 목표..

새로운 레포지토리를 clone 하는 것 부터 add, commit, push 그리고 branch 생성 및 변경, 마지막으로 PR(Pull Request) 하는 과정까지 간략하게 살펴보자. 시작 0. 레포지토리 clone git clone 1. master branch 에서 testfile 생성 ( 내용 : test ) git add . && git commit -m "update" && git push origin master 2. master branch 에서 testfile 내용 변경 (test -> test2) git add . && git commit -m "update" && git push origin master 3. develop branch 생성 # develop 이라는 브랜치 생성 후 ..

전략 N의 최대크기는 100만이므로 배열이 주어졌을 때 한명한명 맨 앞 또는 맨 뒤로 전부 보내보는 것은 불가능해 보인다. 따라서 다른 전략이 필요할 것 같았다. 이런 문제처럼 감이 잘 안올 때에는 간단한 예제를 통해서 대략적인 전략을 찾아야 한다. 먼저 문제에서 주어진 예제를 먼저 보자. 예제의 입력에 대해서 답을 도출하는 과정은 위와 같다. 이 예제에서 주목한 부분은 "움직인 숫자" 와 "움직이지 않은 숫자" 였다. 아래와 같이 구분하면 좀 더 보기 쉬울 것이다. 2와 3은 그대로 두었고 5,4,1은 앞 또는 뒤로 옮겼다. 왜 2,3은 두고 5,4,1만 옮겼을 때 최소의 움직임이 되는지를 고민해보았다. 이 예제만으로는 감이 잘 안올 수도 있어 다른 예제를 하나 더 살펴보자. 위 예제의 경우 1,2,6..

인턴십 시작 6월 28일, 카카오에서의 인턴생활이 본격적으로 시작되었다. 적응을 위해 온보딩 기간을 가지고 바로 과제를 수행했다. 과제내용은 내가 속한 부서의 기본적인 시스템을 구축하는 것이였다. 해당 시스템을 구축하기 위해 Spring boot를 비롯한 여러 오픈소스들이 활용되었다. Spring boot도 사실 많이 안써봤지만 다른 오픈소스들은 들어본적도 없는것들이 많았다. 초반 일주일은 거의 해당 내용들을 알아보고 공부하는데 보낸 것 같다. 약 6주간 과제에 대한 개발을 진행하고 남은 2주간은 최종 인터뷰를 위한 준비를 했다. 인턴십 초기 7월에는 카카오에서 일한다는 설렘과 신기함이 컸다. 그러나 8월이 넘어갈수록 최종 전환에 대한 압박이 커졌고 이번 기회를 놓치게 되면 다시 여기까지 올 수 있을까 ..