단순성을 유지하는 동시에 미래에 있을 기능 개선에 대처할 유연성까지 갖춘 소프트웨어 코드라면 '올바른 방법'이라고 볼 수 있다.
어느 분야든 기본을 제대로 이해해야 그다음 수준도 쉽게 배운다.
소프트웨어 설계의 기본 원칙
구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다.
유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.
이렇듯 펄에서는 역사적 문제가 진보를 막는 일이 비일비재하다.
앞으로 나올 많고 많은 버전에서 그 기능을 지원하고 싶은 생각이 없다면 추가하지 않는 게 이상적인 결론이다.
복잡성은 감옥이고 단순성은 자유다.
설계가 간단히 지원할 수 없는 기능은 절대 추가하지 않는다는 방침을 준수
미래를 고려하지 않으면 코드가 엉망으로 설계되고 너무 복잡해진다.
목표를 '유연하게' 혹은 '포괄적으로'처럼 추상적으로 잡지 말고 '쉽게 이해하고 수정할 수 있게'처럼 구체적으로 잡아야 한다.
미래에 관한 예측을 근거로 하여 설계에 관한 결정을 내리라는 뜻으로 오해하는 사람은 없기를 바란다.
HTML. 애초에 아주 엄격하게 설계되지 않았기 때문에 웹 브라우저 디자이너들이 엄청나게 고생해야 했다. 결국 표준화가 되긴 했지만 그렇게 되기까지 HTML 코드는 대부분 아주 엉망이었고 지금도 크게 좋아지지는 않았다. 애초에 엄격하게 만들지 않았기 때문에 이제 와서 하위 호환성을 깨뜨리고 엄격하게 만드는 건 불가능하다.
컴퓨터가 사용자의 입력에 대해 '추측'하거나 '안 되는 걸 되게 하려해서는' 안 된다
사용자에게 선택지를 줄 뿐 앞서 나가서 추측을 바탕으로 무언가를 해서는 안 된다.
코드베이스의 문제를 해결할 때는 증상이 멈췄다고 할 일이 끝난 게 아니다. 문제가 완전히 사라져서 다시는 발생하지 않아야 임무를 완수한 것이다.
소프트웨어에서 가장 신경 써야 할 부분은 미래다.
디버깅을 완료하려면 문제의 원인을 이해할 때까지 데이터를 수집해야 한다.
- 데이터를 수집하려면 각종 metric, monitoring system이 있어야 하고, 그러려면 결국 logging이 바탕이 되어야 한다
멋지게 시작했다가 한순간에 분쟁 거리로 전락한 게 아니라 양측이 문제를 다르게 인식하고 있다는 지점에서 이미 분쟁의 싹이 움트기 시작
생산성 담당자가 쌓은 개인적인 신뢰가 엔지니어링 생산성 업무에서 가장 중요하다.
- "개인적인 신뢰가 (모든) 업무에서 가장 중요하다."로 바꿔도 큰 무리가 없다
무엇이든 점점 개선하는 문화가 조성된 조직에서는 누군가 따로 손대지 않아도 시간이 지남에 따라 문제가 저절로 해결되는 경향이 있다.
자기 눈에만 보이는 문제 말고 사람들이 인지하고 있는 문제를 해결하라.
소프트웨어 엔지니어링 관리자는 넓은 영역에 영향을 미치는 광범위하고 전면적인 해결책을 제안하고 싶겠지만 그런 방식으로는 실질적인 문제 해결이 어렵다... 광범위한 해결책을 모든 문제에 일괄적으로 적용해본들 대부분의 문제에 맞지 않는다.
1단계: 문제 목록
2단계: 회의
문제를 정확하게 묘사하는 게 중요
3단계: 버그 리포트
버그 리포트의 주인공은 해결책이 아니라 문제
4단계: 우선순위 선정
문제끼리 서로 연관이 있는 경우가 있기 때문에 그런 고리의 시작점을 찾아내는 게 핵심이다... 어떤 상황에서든 올바른 순서로 올바른 조치를 취하는 것이 좋은 소프트웨어 설계의 핵심이다.
5단계: 과제
6단계: 계획
일반 개발 업무를 중단하고 코드 품질 개선 작업만 하지 마라. 대신 일정 수준의 코드 품질 개선 작업을 꾸준히 수행하여 코드베이스의 품질이 나빠지지 않고 전체적으로 꾸준히 개선되게 하라.
소프트웨어 엔지니어링의 근간에는 인간이 있다.
개발자 말고 코드에 대해 이야기하는 게 중요하다.
- 문제에 대해 말할 때는 사람이 아니라 문제 그 자체, 현상 혹은 상황에 대해 이야기하는 게 필요하다. 역시 개발뿐만 아니라 모든 업무에 해당하는 이야기
회원 간에 이루어지는 개인적인 교류, 다른 이들이 자신에게 표현하는 고마운 마음이나 비난 등은 사실 커뮤니티 회원 확보를 좌우하는 가장 중요한 요인이다.
비정상적일 정도로 과한 친절을 베풀어라. 그리고 못되게 굴지 마라.
코드 한 줄에 담긴 ISAR
- Input, Structure, Action, Result
프라이버시 문제를 이야기할 때는 '일어날 가능성이 아주 낮은 상황에서 이 정보가 매우 위험하게 쓰일 염려가 있습니다.'라는 관점에서 벗어나 현실에서 득실 균형점을 찾는 게 현명하다.
'관찰 주기' 혹은 'ODA Observation, Decision, Action'
기존 연구에 따르면 개발자의 주의가 흩어지기 시작하는 시간이 대략 2초에서 30초 사이
- 개발자의 주의가 아니라 인간의 주의가 흩어지기 시작하는 시간으로 써도 괜찮을 듯
테스트 속도를 신경 써야 하는 이유
개발자의 코드 작성 속도에 영향을 끼친다
필요한 시점이 지난 뒤 결과를 전달하는 테스트는 아무 쓸모가 없다... 느린 테스트는 소프트웨어 엔지니어링 조직 내 많은 프로세스에 영향을 미친다. 이럴 때는 그냥 테스트 속도를 빠르게 만드는게 가장 간단한 해결책이다.
필요하다면 '느린' 테스트 스위트를 별도로 만드는 것도 좋은 방법이다.
새로운 버전을 출시할 때마다 조금씩 나아지는 모습을 보인다면 사용자 대부분이 그대로 남아 있을 것이다.
이해에 도달할 유일한 길은 행동이다.
진짜 똑똑한 사람이라면 사용자에게 자신의 프로그램이 아주 뛰어나다는 걸 보여주어야 한다. 너무 뛰어나서 그 프로그램이 깔려 있는 줄도 모를 정도여야 한다. 그래야 정말 탁월한 것이다.
진정한 겸양의 미덕을 갖춘 개발자라면 사용자의 세계에 자신의 정체성을 드러내지 않는다.
소프트웨어 세계에서 소프트웨어 개발자의 과제는 사용자의 문제를 해결하는 것이다. 사용자는 문제를 알려주고 개발자는 문제를 고친다. 이 역할이 뒤바뀌면 문제가 뒤따른다.
성공에 이르는 길은 혁신이 아니라 실행이다.
크게 성공한 이들은 어떤 아이디어를 처음 낸 사람이 아니라 그 아이디어를 정말 훌륭하게 실행한 사람이란 걸 알 수 있다.
진짜 훌륭한 프로그램은 사용자의 의사를 정확히 수행한다.
이 원칙을 조금 더 세분화하면 훌륭한 프로그램은
사용자의 명령을 정확하게 따른다.
사용자가 예상한 대로 작동한다.
사용자의 의도 전달을 막지 않는다.