Sean :: Dev

프로그래머스) 다리를 지나는 트럭 github/Stack%2CQueue 큐를 정직하게 사용하기보다, 배열로 거리를 관리하고 left, right 역할의 두 변수로 비즈니스 코드를 해결했다. 나름 만족. (문제의 1차선도로 기능을 잊고 동시에 트럭의 출입이 가능한것으로 오해해, 추가적인 for문과 그 인덱스 관리하느라 삽질하며 시간소비함) v2 코드처럼 truckStack 스택과 bridgeMap 해시맵을 이용한 풀이도 있다. 전체적인 로직은 나와 비슷하지만, HashMap과 그 함수를 이용한 점, answer 시간값을 거리계산에 이용한 점 등은 주목할만하다. 자세히 읽어보진 않았지만, v3 코드처럼 정직하게 Queue를 이용해 코드의 가독성과 그 의미에 더 집중한 풀이도 있긴하다.

프로그래머스) 기능개발 github/Stack%2CQueue ver2 코드와 내 코드를 비교하면, 효율성의 차이가 매우 크다. 내 코드는 메모리공간도 더 사용하고, progress + n*speed 방식이 아닌, 매n마다 더하고 있으며, 이에따라 역시 매n마다 100을 넘었는지도 체크한다. Queue 문제라는 점이 오히려 사고를 제한할수도 있겠다. 좀더 자유롭게 생각해보자. * 특히 내 코드처럼 큐나 리스트 같은 자료구조를 순회하면서 동시에 삽입/삭제 작업을 하는것은 안정적이지 못하다. iterator도 없이. 그래서 queueSize 변수를 별도로 만들어서 for문 돌려야 제대로 동작했었음.

프로그래머스) 탑 github/Stack%2CQueue 스택 카테고리에 위치한 문제라서 스택을 이용해 해결할수도(스택안의 값으로 기본데이터형은 안되고, height와 index 정보를 함께 전달) 있었으나, 워낙 간단히 값 순회를 통해 해결되어 생략.

프로그래머스) 프린터 github/Stack%2CQueue 내 코드는 너무 문제에 충실하게 풀어서, 코드 가독성은 좋을수 있으나 효율적이지 못하다. ver2와 같이 자료구조 2개를 유지하며 순회할수도 있었다. 코드보며 이해할것.

프로그래머스) 타겟 넘버 github/DFS%2CBFS https://lkhlkh23.tistory.com/74 위 링크를 참조해, 그래프를 보면 직관적으로 BFS보단 DFS를 사용해야함을 떠올릴수있다. 종료조건은 depth limit에 도달했을때(배열의 모든원소에 접근했을때)이고, 점화식은 좌측leaf는 +로, 우측leaf는 -로 가정해 계산해낸다. depth limit에선 target값과의 대조를 통해 카운팅(1)할지 / 말지(0) 결정한다.

프로그래머스) K번째 수 가장 기본적인 정렬문제. System.arraycopy로 배열의 일부분을 복사하고 Bubble Sort로 정렬후 Arrays.toString()로 결과확인 github/Sort 이런 더 간결한 방법도 있다고 한다. System.arraycopy대신 Arrays.copyOfRange를 사용함 내 코드에서 BubbleSort 직접구현 대신 Arrays.sort()를 사용하면 비슷하게 짧아진다.

프로그래머스) 쇠막대기 () 레이저를 만나면, 스택안의 개수만큼 카운팅 (를 만나면, 스택에 넣고 카운팅 )를 만나면, 스택에서 뺀다 맨마지막은 무조건 )으로 내 로직에 영향을 미치지않아, for(int i\=0; i