추상화: 아랫부분에서 일어나는 아주 복잡한 어떤 작요을 간소화하는 방법 수많은 컴퓨터 프로그래밍은 추상화 요소를 포함하고 있다. 허술한 추상화의 법칙: 모든 쓸 만한 추상화에는 어딘가 구멍이 존재한다. 허술한 추상화의 법칙은 추상화가 의미하는 바와는 달리 우리 삶을 정말로 단순화시키지 못한다는 사실을 의미하기 떄문에 문제가 된다. 무언가를 추상화하는 듯이 보이는 코드생성 도구는 구멍이 있으며, 이런 구멍을 제대로 메워주는 유일한 해결책은 추상화 동작원리와 추상화 대상을 배우는 방법뿐이다. 추상화는 그저 일하는 시간을 절약해주지만, 배우는 시간을 절약해주지는 못한다....

고객은 자신이 원하는 내용이 뭔지 모른다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마라. 멋진 사용자 인터페이스는 실제 프로그래밍 작업의 10%를 차지할 뿐이고, 나머지 90%의 작업은 보이지 않는 물밑에 가라앉아 있다. 프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘 못 만들어진 화면을 보여주면, 사람들의 전체 프로그램의 90%가 잘못됐다고 생각한다. 프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것이다. 멋지고 산뜻하게 다듬었으나 분량이 네 페이지인 웹 사이트를 운영하는 닷컴은, 3700여년에 이르는 자료로 무미건조하게 꾸며놓았지만 실용적인 사이트보다 훨씬 더 높은 평가를 받을 것이다....

편집 시간: 2022년 4월 7일 오후 6:48 코드 Algorithm/2473.py at main · Junroot/Algorithm 풀이 용액의 수가 최대 5000개이므로 O(N^2)으로 해결될거라고 생각했다. 기존 용액 문제에서 투 포인터로 O(n)만에 해결했으니 투 포인터를 사용하면서 한 번 더 n개를 루프돌아도 되겠다는 생각이 들었다. 그래서 용액 하나를 고정시키고 용액의 산성도가 0개 가까운 정도를 투 포인터를 이용해서 구했다.

편집 시간: 2022년 2월 24일 오후 3:25 코드 Algorithm/2407.py at main · Junroot/Algorithm 풀이 n에 대한 팩토리얼을 계산하면서, n보다 작은 값의 팩토리얼 값들을 배열에 저장해두면 O(n)으로 해결이 가능하다.

프로그래머가 항상 코드를 버리고 새로 시작하기를 원하는 미묘한 이유가 있다. 예전 코드가 엉망진창이라는 생각 떄문이다. 예전 코드가 엉망진창이라는 생각은 다음과 같이 기본적이며 근원적인 프로그래밍 법칙때문에 생긴다. “코드 쓰는 작업보다 읽는 작업이 더 어렵다” 함수가 점점 길어지고 비대해지는 이유는 버그 수정 때문이다. 코드를 버리고 새로 시작하면, 여기에 속한 노하우도 모두 버려야 한다. 이미 존재하는 코드를 다시 작성하느라 쓸데없이 많은 돈을 낭비하는 셈이다. 프로그래머가 작성한 코드를 완전히 엉망진창이라고 말할 때, 이와 관련해서 잘못된 이유가 세가지 있다....

직렬처리 방식은 평균적으로 결과값이 더 빨리 나온다. 과업 전환이 오래 걸릴수록, 멀티태스킹을 위해 지불해야 하는 대가도 커진다. 프로그래머의 과업 전환 시간이 오래 걸린다. 프로그램은 머리 속에 엄청나게 복잡한 내용을 한꺼번에 유지해야만 하는 일이기 때문에 이런 일이 벌어질 수 밖에 없다. 개발자 한명에게 한 가지 일을 던져주면 훌륭하게 처리하지만, 한 사람에게 두 가지 일을 한꺼번에 주면 그다지 매끄럽게 처리하지 못한다.

오답 여부: o 편집 시간: 2022년 2월 24일 오후 4:04 코드 Algorithm/2263.py at main · Junroot/Algorithm 풀이 포스트오더로부터 부모 노드를 찾고 인오더로부터 왼쪽 자식 노드와 오른쪽 자식 노드를 찾는 것은 쉽게 찾아냈다. 하지만 인오더와 포스트오더의 인덱스를 계산하는데 어려움을 겪었다. 굳이 문자열을 변형하지 않고 인오더의 인덱스와 포스트오더의 인덱스를 함수의 파라미터로 넘기면 헷갈리지 않는다는 것을 다른 사람 풀이를 참고해서 알게되었다.

편집 시간: 2022년 3월 1일 오후 7:13 코드 Algorithm/2252.py at main · Junroot/Algorithm 풀이 위상 정렬을 구현하면 쉽게 해결할 수 있는 문제다.

편집 시간: 2022년 4월 6일 오후 10:23 코드 Algorithm/2239.py at main · Junroot/Algorithm 풀이 단순 브루트로 문제를 풀 수 있다. (스도쿠의 칸수) * (한 칸에 들어갈 수 있는 숫자의 수) * (사용할 수 있는 수 찾는 과정) = 81 * 9 * 9 = 6516 밖에 되지 않기 때문이다.

오답 여부: o 편집 시간: 2022년 2월 24일 오후 2:29 코드 Algorithm/2206.py at main · Junroot/Algorithm 풀이 기본적으로 BFS로 풀면된다. 하지만 방문한 위치를 체크하는 방법에서 어려움을 겪었다. 잘못된 풀이1 처음에는 벽을 부수든 부수지않든 한 번 방문한 위치는 재방문하지 않도록 구현했다. 하지만 어떤 위치에 대해서 기존에는 벽을 부수고 갔지만, 같은 횟수로 이동해서 벽을 부수지 않고 갈 수 있는 방법이 있다면 큐에 담을 필요가 있었다. 잘못된 풀이2 잘못된 풀이1때문에 나는 큐에 담겨있는 것중 거리가 가장 짧고, 거리가 같다면 아직 벽을 부수지 않은 것을 먼저 꺼내서 처리하면 해결될 거라고 생각했다....

소프트웨어는 버그가 있기 마련이다. 절대적으로, 반드시 QA 부서가 필요하다. QA부서는 독립적이며 권한이 있어야한다. QA 팀장은 품질 테스트를 통과하지 못한 소프트웨어는 출시하지 못하게 막을 권한이 있어야 한다. 테스터를 고용하지 않는 가장 흔한 이유 버그는 프로그래머가 게을러서 생기니까요 버그는 프로그래머가 자신의 코드에서 버그를 발견해내지 못하는 바람에 새어나오는 것이다. 대개 버그는 다른 사람이 더 쉽게 찾을 수 있다. 우리 소프트웨어는 웹에 올려놓아서, 버그는 금방 고칠 수 있으니까요 웹에 올려놓았다고 해도, 일단 출시한 뒤에 버그를 수정하는 데 드는 비용을 얕잡아 보면 안된다....

오답 여부: o 편집 시간: 2022년 4월 4일 오후 6:27 코드 Algorithm/2166.py at main · Junroot/Algorithm 풀이 여러개의 삼각형으로 나누어서 면적을 합하면 되겠다고는 빠르게 생각해냈다. 하지만 아래와 같은 문제가 있었다. 좌표 3개가 주어졌을 때, 삼각형 면적 구하기 벡터의 외적을 사용할 생각을 전혀못했다. 두 벡터 a, b가 있을 때 두 벡터를 외적한 벡터의 크기는 |a||b|sinθ 라는 것을 완전히 잊고 있었다. 오목 다각형의 경우 삼각형의 면적을 단순히 모두 더해서 반환하면 될거라고 생각했다. 하지만 이는 볼록 다각형의 경우에만 해당한다....

편집 시간: 2022년 2월 7일 오후 8:41 코드 Algorithm/2164.py at main · Junroot/Algorithm 풀이 큐를 이용해서 해결할 수 있다.

편집 시간: 2022년 4월 29일 오후 8:36 코드 Algorithm/21611.py at main · Junroot/Algorithm 풀이 처음에는 구슬 정보를 하나의 리스트로 표현해서 처리해보려고했다. 하지만 이 방법은 블리자드가 일어나는 인덱스를 계산하는데 상당히 복잡해졌다. 두 번째 접근 방법으로 격자를 나타내는 이중 배열에서 문제의 조건들을 처리하도록 구현했다. 이 때 현재 위치에서 다음 위치를 계산하는 과정이 필요했는데 이를 그림으로 그려보니 규칙이 보였다. 이를 수식으로 구한 뒤 다음위치를 찾을 수 있는 로직을 완성했다. 추가적으로 블리자드가 일어난 뒤 중간에 빈 칸이 발생한 것을 앞으로 한칸씩 미는 과정을 굳이 구현할 필요가 없다....

편집 시간: 2022년 4월 29일 오후 8:29 코드 Algorithm/21610.py at main · Junroot/Algorithm 풀이 단순 시뮬레이션 문제다. 주의해야될 점을스자면 5번 과정에 기존에 구름이 있던 위치를 알아야되기 때문에 3번 과정을 제일 마지막에 하도록 처리한다. 그리고 구름이 이동하는 거리는 격자의 크기만큼 이동하면 같은 상황이 되므로 거리를 격자의 크기로 나눈 나머지만큼 이동시킨다.

부정적인 평가는 팀원 사기에 지대한 영향을 미친다. 긍정적인 평가라도 본인이 기대한 수준에 미치지 못한다면, 부정적인 평가만큼이나 사기를 떨어뜨린다. 부정적인 평가는 사기를 확 떨어뜨리는 반면, 긍정적인 평가는 아무런 영향을 미치지 못한다. 업무 완수나 성공적인 업무 수행으로 보상을 바라는 사람은 전혀 보상을 바라지 않는 사람보다 성과가 떨어진다.

오답 여부: o 편집 시간: 2022년 3월 29일 오후 4:15 코드 Algorithm/2098.py at main · Junroot/Algorithm 풀이 모든 경우를 탐색하면 O(N!). 즉, 최악의 경우 16!번 탐색해야되기 때문에 당연히 아닐거라고 생각했다. 하지만, 메모이제이션을 사용하면 O(N * 2^N) 만에 풀 수있다. 최악의 경우도 1,048,576번만 탐색하게 된다. 아직 메모이제이션을 사용했을때 시간복잡도 계산에 익숙하지 않은 것이 문제를 풀지 못 한 원인이 아닐까라고 생각한다. f(a, k): k에 담겨있는 노드들을 방문한 상태고 현재 위치가 a번 노드일 때 최소 비용...

직원을 고용하는 방식 이력서 실수가 많은 경우 버린다. 과거에 특별히 어려운 선별 과정을 거친 사람이 있는지 확인 전화 인터뷰 프로그래밍 문제 하나로 30분 정도 진행 대면 인터뷰 면접관은 최소 6명, 최소 5명은 함꼐 일하게 될 동료 6명 중 2명이라도 지원자를 별로라고 여긴다면, 그 사람은 고용하지 않는다. 여러 지원자를 동시에 인터뷰하지 않는다. 인터뷰는 최소 1시간 인터뷰를 마치면 지원자에 대한 결간은 칼같이 내려야 한다. 합불 선정 기준 잘 모르겠으면 불합격 기준에 미달하는 지원자를 채용하는 실수보다는 훌륭한 지원자를 놓치는 실수를 저지르는 편이 차라리 낫다....

가독성을 목표로 설계하라 개발자는 어떤 코드를 작성하는 것보다 읽는 데 많은 시간을 소모한다. 인식 부하 감소 기본적으로 ‘인지 부하’를 줄이는 방향으로 코드를 작성해라. 구현 A가 훨씬 가독성 좋은 코드다. 일반적인 관용구를 사용해서 이해하기 쉽도록 작성해야된다. 구현 A가 수정하기 더 쉽고, 디버깅도 간단하다. 구현 B는 showPerson() 호출에 null이 발생하면, showError()도 호출된다. 이처럼 잘못된 동작이 발생할 수 있다. 극단적이 되지 않기 위의 내용이 ’let은 절대로 쓰면 안 된다’를 의미하는 것은 아니다. let을 사용하면 좋은 경우 nullable 가변 프로퍼티의 안전 호출이 필요할 때 연산을 아규먼트처리 후로 이동시킬 때 데코레이터를 사용해서 객체를 랩할 때 인식 부하 비용이 발생해도 지불만한 가치가 있는지 고려해야된다....

편집 시간: 2022년 2월 21일 오후 2:09 코드 Algorithm/1991.py at main · Junroot/Algorithm 풀이 재귀함수를 이용하면 쉽게 구현할 수 있다.