튼튼발자 개발 성장기🏋️

문제 기출 : [https://www.acmicpc.net/problem/1931] 풀이 방법 [그리디알고리즘] 접근 여러가지 풀이 방법이 떠올랐다. 한참 이 문제를 풀 때 쯤에 Comparator와 Comparable을 연습하고있던 찰나여서 생각나는대로 작성했다. 2차원 배열에 입력 값을 저장 -> sort (끝나는 시간 기준, 같으면 시작시간 기준) -> 끝나는 시간을 체크해가면 카운팅 -> 마지막 카운트 값을 출력 참고로 더 간단하게 풀이도 가능하다. 우선순위 큐를 생각해보면 답이 나올 것이다. 문제 풀이 public class Main { public static void main(String[] args) { BufferedReader br = new BufferedReader(new Input..

문제 기출 : [https://www.acmicpc.net/problem/1541] 풀이 방법 [그리디알고리즘] 접근 연산자는 +와 -만을 다루고 피연산자는 양수인 것만 알아도 쉽게 접근할 수 있다. 괄호를 사용해서 최소값을 만든다고 했는데 괄호에 현혹될뻔했다. 먼저 +연산 먼저 해서 크기를 키운 다음 -연산을 하면 되지 않는가? 한 마디로, +연산으로 최대한 값을 키운 다음 그 값을 빼면 최소 값을 쉽게 도출할 수 있다. 식에서 '-'를 기준으로 식을 잘라 저장하면 나머지는 +연산이 되고, 그 값을 모두 더한 다음 -연산하면 정답을 빠르게 구할 수 있다. ※ 번외. 어디선가 비슷한 문제를 풀어본 적이 있다. 문자열로 사칙연산과 괄호를 포함한 문자열(String)을 input으로 주고 그 연산을 실행한 ..

좋은 주석은 뭐고 나쁜 주석의 차이는 뭔지 곰곰히 생각해보자.. 내 생각은 좋은 주석은 없다. 주석이 없는 주석이 가장 좋은 주석이다. 물론 코드가 개발자 의도를 100% 표현 했다는 가정 하에!☝️ 나의 경우는 내가 짠 코드의 일부분을 혹시나 다른 개발자가 못알아 듣거나 이해를 못할까 걱정이 되어 주석을 사용하곤 한다. 즉 내가 나를 못믿는데 누군가 나를 어떻게 믿을까😥😥😥 대부분의 주석은 쓸때 없는 주석, 주절거리는 주석 등으로 이루어 지지만 난 가장 필요한 주석은 히스토리 주석과 TODO주석이라 생각한다. ☝️소스코드 관리 시스템이 있다 한들, 특정 부분이 수정된 사유와 날짜 등을 파악하려면 시간을 들여야한다. ✌ TODO주석이 있다는 말은 일을 다 못끝냈다는 이야기. 그러나 그 누가 하루만에 개발..

함수는 "한 가지의 일만 해야하며 무슨 일을 하는지 딱 봐도 알 수 있을 정도의 네이밍이 필요하다."라는 것 정도는 알고 있는 사실이다☝️ 그런데 최소한의 인수와 break, continue를 사용하면 좋지 않다는 것이 저자 의견. break, continue는 반복문과 제어문의 쌍을 스무스하고 부드럽게 해주는 장치 역할을 한다고 생각한다. 이 녀석을 사용해야할 때에 사용하지 않는 방법이 있는가? 고민해볼 가치는 있어보인다. 인수를 두지 않고 클래스 혹은 전역 변수를 활용하는 것은 불필요한 자원을 사용하는 것이고 위험부담이 크다고 생각 되기에 공감하지는 않지만, 인수의 수에따른 단위 테스트의 어려움은 어느정도 공감 한다.🤔 처음부터 코드를 잘 짜는 사람은 없다. 코드를 짜기 전에 일단 문단으로 적어 보고..

문제 기출 : [https://www.acmicpc.net/problem/11399] 풀이 방법 [그리디알고리즘] 접근 굉장히 쉽게 접근할 수 있다. Pi를 오름차순으로 정렬해서 최소로 걸리는 사람부터 탐색하는 것이 기본. 다음과 같은 조건을 만족하면 된다. 기다리는 시간 = i번째 사람이 돈 뽑는데 걸리는 시간 x (사람 수 - i) 즉 기다리는 시간을 누적해 나아가면 답이 나올 것이다. 문제 풀이 public class Main { public static void main(String[] args) { int answer = 0; Scanner sc = new Scanner(System.in); int peopleCount = sc.nextInt(); int[] peopleTime = new int..

소스를 볼 때면 "이 변수에 뭐가 담겨 있는겨?" 혹은 "이 함수는 뭐하는 겨?"혹은 "이 클래스는 뭐여?" 등과 같은 의문을 품곤 한다. 나의 소스건 남의 소스건 "개떡같이 이름 지었네.."라고 마음 속으로 한 마디 하고 열심히 코드분석을 시작한다. 네이밍이 말은 쉽지만 정말 어려운 부분이 될 수 있다. [읽기 쉬운 코드]를 작성하기 위한 첫 걸음이 아닌가 싶다. 항상 어떤 function, 변수, Object, DB field, table 등을 만들 때 네이밍에서 시간을 한참 잡아먹는다. 네이밍 센스가 없기 때문이다. 하지만 시간을 많이 들여도 괜찮으니 최대한 좋은 이름일 짓도록 투자해보는 것이 우리 모두가 이로운 일이 될 수 있다! 내가 취업한지 2년도 채 되지 않았지만 이런 경험이 가장 많다. "..

문제 기출 : [https://www.acmicpc.net/problem/11047] 풀이 방법 [그리디 알고리즘] 접근 K원을 민드는데 필요 동전의 개수의 최소값은 동전의 가치가 큰 녀석부터 선택해가면서 차감시킨다. 물론K보다 같거나 작은지 체크 해가면서. 문제에서 친절하게도 오름차순으로 준다. sort가 필요 없다는 말이다. 나는 읽은 동전의 가치가 K보다 같거나 크면 더 이상 읽지 않는다. 무의미하기 때문이다. 어차피 사용하지 못하는 동전이기 때문이다. 그럼 읽은 동전의 가치 중에서 가장 가치가 높은 순서대로 선택해서 K가 0 이하가 될 때까지 K원에서 차감시킨다. 문제 풀이 import java.io.BufferedReader; import java.io.IOException; import jav..

좋은코드라는게 참 말은 쉽다. 우아하고💃 효율적인👍 코드. 단순하고😄 직접적인☝️ 코드. 다른 사람이 고치기 쉬운 코드. 자고로 이런 코드를 짜려면 단호한 프로그래머가 되어야 한다!(?) Memory leak, Race conditional, 명명법의 일관성 등을 소홀히 하면 안된다. 아무리 가독성이 높고 우아한 코드임에 틀림없어도 테스트 케이스가 없으면 무용지물. (그래서 TDD가 중요한 것..!!!!🤔) 그래서 깨끗하고 좋은 코드를 보면 마치 영화보듯이 느낀다고....(ㄹㅇ?) 의외로 좋은코드는 명쾌한 추상화와 제어문으로 가득 차 있다고 한다. 사실 나는 개인적으로 제어문이 가득한 코드를 싫어한다. 그만큼 복잡하고 얽혀있다는 생각이 들기 마련이기 때문. 그래서 어떻게 해야하는데?😥 ☝️중복을 줄이자!..