function void hello(int a, int b){}
// 실수
hello(b,a);
// expect
hello(a,b);
빠르게 찾을 순 있었고 문제는 해결했다. 하지만 이로인해 내 코드를 의심 할 수 있는 좋은 기회였다.
위 문제가 아니었더라도 협업하는 환경에서 문제가 자잘하게 많았다. 동시 병렬적으로 작업을 하다보니 코드의 충돌이 생기고 서로 빠른 주기로 개발은 하는데 리뷰시간이 아깝다는 핑계로 리뷰를 안하더니 막상 코드의 히스토리를 이해하기위한 리뷰가 더 길어지는 문제는 말해 뭐해다.
내가 겪은 경험들이 말해주는 바는 "지금까지 일해왔던 방식은 일하는 시간이 증가하고 코드의 품질을 높이지는 못한다." 이다
도입 허락해줘 ..
코드 스타일도 다르고. 쪼개서 해야하는 리뷰도 안하니 다른 사람이 짠 코드의 히스토리를 이해하지 못한다. 내가 짠 코드도 못 믿는다. 남이 짠 코드는 더더욱 신뢰할 수 없다. 누가 검증을 해 줄수 있는가 ?
- 개발 시간의 증가, 코드 신뢰도 하락
검증은 하지만 자기 PC에서만 한다는 것, 막상 배포하려고 하니 환경 문제가 생긴다.
- 개발 외 업무 증가
신뢰 할 수 없는 개발 주기안에서 열심히 개발을 하고 나니 남는 건 버그와 연장 근무뿐이 아니겠는가? from su8y
CICD 도구를 통해 개발 상태, 배포 상태 등을 한 눈에 확인이 가능하므로 매니저한테도 좋은 일이 아닐수가 없다.
일하는 사람이라면 효율적으로 일 할수 있는 방법에 대해서 고민을 해봐야한다. 이를 위해서 깃랩 CI/CD 파이프라인 구상을 해보려고 한다.
지속적인 통합/제공/배포
ci: application 코드의 변경사항이 정기적으로 빌드 및 테스트(품질 검사 등)을 거쳐 공유 Repository에 병합이 되는 프로세스로 버그가 없고 좋은 application을 고객에게 전달하기 위한 초석입니다.
cd: 개발을 신명나게 하고나서 배포하는 과정의 자동화 프로세스입니다.
전체적인 CI/CD 흐름
개발 후 배포 해야되는 브랜치로 Pull Requests(PR)을 보냅니다.
해당 PR에 대해서 build, test, image push 를 합니다.
실패했다면 사유와 알림을 알려줍니다.
해당 파이프라인을 통해 발생한 개발 서버의 URL을 댓글, 이메일, SMS 등으로 안내해줍니다.
안녕하세요 오늘은 LeetCode의 TwoSum 문제를 리뷰하려고 합니다. 이 문제는 아주 간단한데요
배열 nums에서 2개의 중복되지 않은 임의의 위치의 숫자를 더해 target을 만드는 인덱스를 반환하면 되는 문제입니다.
조건을 봐보겠습니다.
$2 <= nums.length <= 10^4$
$10^9 <= nums[i] <= 10^9$
$10^9 <= target <= 10^9$
nums.size 같은 경우에는 최대 1만이고, 각 요소는 1_000_000_000 입니다. 2개의 합을 처리하는 자료로 int형으로 충분하고, nums에서 단순하게 2개의 요소를 뽑는 방법을 나이브하게 Broute Forcing 방식으로 접근해도 100 _000_000 이므로 $N^2$ 으로 안전하게 구할 수 있을거 같습니다