인터넷을 하다가 해외의 포럼에서 발견한 글이다.
https://www.quora.com/What-are-the-golden-rules-of-programming/answer/James-Liu-20
- Make it readable to others. Others care.
읽을 수 있게 만들자. 남들이 신경쓴다. - Don’t do fancy code tricks. No one cares.
멋진 코드를 작성하려고 하지마라. 아무도 신경 안쓴다. - Users are almost never right. Go shadow them and get the real story.
사용자들은 대부분 옳지 않다 (본인들이 옳은 줄 알지만 그렇지 않다). 직접 가서 숨겨진 진짜 요구를 파악해라. - Understand 100% of the problem, design to solve 90% of it.
문제를 100% 이해하고, 90%를 해결할 수 있도록 설계해라 - The last 20% effort is 80% of the engineering cost.
마지막 20%의 노력은 80%의 비용을 절감하게 된다. - When designing, make it survive 3–5 years. You should be rewriting it by then anyways.
설계할때 3-5년간 살아남을 수 있게해라. 어차피 그 후에 다시 만들게 될 것이다. - Software engineering is a process. Don’t overfit the initial requirements, you need to stay flexible for future readiness.
소프트웨어 엔지니어링은 과정이다. 초기 요구사항에 너무 맞추지 말고, 미래를 대비해서 유연하게 만들어라. - First pass is to solve it. Second pass is to clean up and learn. Third pass is to deep design using what you’ve learned.
첫번째 단계는 문제를 해결하는 것이다. 두번때는 정리하고 배워가는 것이다. 세번째는 배운 것을 활용해 더 깊이 있게 설계하는 것이다. - CPU is cheap. Don’t over optimize.
CPU는 싸다. 최적화에 과한 공을 들이지 마라. - Focus on enabling people to do more. 1 hour of work should become 10 hours of output when you enable humans.
사람들이 더 많은 일을 할 수 있도록 집중해라. 1시간의 작업이 사람이 일했을 때 10시간의 분량이 될 수 있도록 해야 한다. - When prioritizing consider the models of (1) attacker (2) defend it (3) bandaid it (4) clean it up. Each one has an associated operational cost, solve permanently cost, and a cost to perform. You need to pick your battles.
우선순위를 정할 때 1. 공격하기 2. 방어하기 3. 임시처리하기 4. 정리하기 의 순서로 해라. 각각은 운영비용, 영구적해결 비용, 수행 비용과 연관된다. 어디에 집중할 것인지 선택해야 한다. - If only you can fix it, then only you will babysit it, forever. You can’t move on to more interesting things.
만약 나만 해결할 수 있는 것이라면, 결국 그것을 나 혼자 돌봐야하게 될 것이다. 다른 더 흥미로운 일로 넘어갈 수 없게 된다.
너무나도 공감되는 내용들이다. 갑자기 생각난 또 한 문장이 있다. "똥은 빨리 싸도 똥이다. "