30 여 년 의 프로 그래 밍 경험 을 가 진 프로그래머 의 총화
5515 단어 프로그래머 총화
1.고객 은 제품 을 접 한 후에 야 자신의 수 요 를 진정 으로 이해 할 수 있다.
이것 은 내 가 나의 첫 직장 에서 배 운 것 이다.우리 가 고객 에 게 제품 을 보 여줄 때 만 그들 은 어떤 것 이 필요 한 지 깨 달 을 수 있다.긴 문자 표 보다 기능 적 인 원형 디자인 을 제시 하 는 것 이 훨씬 좋다.
2.충분 한 시간 만 있 으 면 모든 안전 방어 시스템 이 실패 합 니 다.
안 보 방 어 는 현재 전 세계 가 주목 하고 있 는 큰 과제 이자 큰 도전 이다.해커 가 한 번 만 성공 하면 너 를 완전히 물리 칠 수 있 기 때문에 우 리 는 시시각각 그것 을 적극적으로 보완 해 야 한다.
3.안전 방어 의 실 패 는 조기 계획 에 달 려 있다.
해커 가 방어 시스템 을 완전히 파괴 할 것 이 라 고 가정 하면 미리 준 비 를 해 야 한다.이렇게 하면 그들 이 시스템 에 침입 하 더 라 도 가치 있 는 것 을 훔 칠 수 없다.왜냐하면 서버 에 대해 안전 설정 을 했 기 때문이다.예 를 들 어 데이터 베이스 에 있 는 내용 을 암호 화하 고 공격 을 받 을 수 있 는 모든 서버 를 격 리 했 기 때문이다.
아무리 강 한 방어 라 도 약 한 점 이 있다 는 것 을 기억 하 라.문 제 는 유비무환 이다.
4.좋 은 안전 방어 시스템 은 비용 에 신경 쓰 지 마 세 요.이것 은 전략 투자 이기 때 문 입 니 다.불합격 한 안전 방어 야 말로 낭비 되 는 자원 이다.
내 직장 생활 을 하면 서 안전 방어 가 얼마나 복잡 하고 비 싼 지 에 대한 불평 을 자주 들 었 다.그들 은 방어 에 실패 하면 회사 가 수 십 억 달러 가 넘 는 손실 을 입 을 수 있다 는 것 을 의식 하지 못 했다.몇 원 을 절약 하기 위해 기업 을 파산 시 키 는 것 은 어 리 석 은 일이 다.
5.복잡 한 것 을 간단하게 정리 하 는 것 은 어렵 지만 복잡 한 것 을 더 복잡 하 게 만 들 면 간단 하 다.
이것 은 프로 그래 밍,디자인,거의 모든 창조 분야 에 적용 된다.나 는 줄곧 자신의 코드 가 이해 하기 쉬 울 수록 좋 기 를 바 랐 다.만약 당신 의 코드 가 너무 복잡 하고 난해 하 다 면,그것 은 정상적으로 일 할 가능성 이 매우 낮 습 니 다.나 는 몇몇 프로그래머 들 이 천신만고 끝 에 코드 를 더욱 종 잡 을 수 없 게 만 드 는 것 을 다행히 보 았 다.
6.성공 은 실패 에서 비롯 된 학습 이다.실 패 는 잘못된 횡행 을 용인 하기 때문이다.
많은 프로그래머 들 이"프로그램 이 이렇게 어 려 운 데 실 수 를 하 는 것 은 정상 이 고 소프트웨어 가 나 빠 지 는 것 도 불가피 하 다"고 변명 한다.이런 이 유 는 많이 들 었 기 때문에,모두들 점차 이런 허튼소리 의 핑 계 를 받 아 들 였 다.그러나 우 리 는 프로그래머 로 서 이런 핑계 로 우리 의 진 보 를 방해 하지 말 아야 한다.실 수 는 한 번 만 저 지 를 수 있 고 교훈 을 받 아들 여야 한 다 는 것 을 명심 해 야 한다.프로그래머 들 은 다음 에 코드 를 한꺼번에 해결 하 기 를 원한 다 고 합 니 다.하지만 완벽 한 사람 은 없 지만 적어도 우 리 는 이 방향 으로 가 고 있다.
7.유일 하 게 변 하지 않 는 것 은 변화 자체 이다.이것 은 누구 도 바 꿀 수 없 는 법칙 이다.
계획 은 영원히 변 화 를 따라 잡 을 수 없다.내일 의 세상 이 오늘 과 같다 고 생각 하 는 것 자체 가 어 리 석 은 것 이다.특히 프로 그래 밍 세계 에 서 는 영원한 것 이 없다.사람 은 두 번 같은 강 에 발 을 들 여 놓 을 수 없다.
8.공 부 를 영원히 멈 추 지 마 세 요.일단 멈 추 면 기술 의 물결 이 당신 을 모래 위 에서 세 게 때 려 죽 일 것 입 니 다.
프로그래머 로 서 불 패 의 자리 에 서 는 유일한 방법 은 끊임없이 공부 하고 발전 하 는 것 이다.일단 네가 해이 해 지면,너의 모든 우 세 는 바람 에 사라 지기 때문이다.
9.전체 소프트웨어 업 계 는'백가쟁명'의 사상 에 세 워 졌 다.
제 직장 생활 을 하면 서 저 는 많은 프로그래머 들 이 여러 가지 일 에 대해 진실 하 게 생각 하 는 것 을 본 적 이 있 습 니 다.완성 시간 이 진실 하고 규모 가 진실 하 다 고 예상 하 는 등 입 니 다.그리고 누 군 가 는 실 수 를 거듭 하고 싸 우기 도 한다.이전에'통 하지 않 는 다'는 비판 을 받 았 던 기술 들 이 지금 은 사람들의 생활 의 자 리 를 굳건 히 차지 하고 있 으 며,지금 은 또 다른 하 이 라 이 트 를 향 해 돌진 하고 있다.
10.당신 에 게 어 울 리 는 것 이 꼭 그 에 게 어 울 리 는 것 은 아 닙 니 다.
소프트웨어 프로젝트 에서 우리 가 할 수 있 는 선택 은 매우 많다.어떤 것 은 영명 하고,어떤 것 은 엉망이다.하지만 당신 과 당신 의 현재 상황 에 맞 는 선택 은 다른 사람 에 게 전혀 적용 되 지 않 을 수도 있 습 니 다.우 리 는 자신 이 또 무슨 위대 한 창 거 를 하고 있다 는 말 을 자주 들 을 수 있 지만,그들 이 이것 이 유일한 좋 은 방법 이 라 고 말한다 면,나 는 이것 에 대해 코 웃음 을 칠 것 이다.
11.끊임없이 변화 하 는 이 세계 에서 평 가 는 가장 중요 한 기능 이다.
이 점 을 어떤 사람들 은 모 를 수도 있다.그러나 새로운 것 을 알 고 다른 사람의 노력 을 볼 수 있 고 일 하 는 방법 을 비교 한 후에 좋 은 것 을 선택 하여 사용 하고 싶다 면 당신 자신 뿐만 아니 라 당신 의 팀,당신 의 프로젝트,당신 의 회사 도 많은 이익 을 얻 을 것 입 니 다.하지만 이 를 잘 하지 못 하 는 사람 이 많 고,많은 책임자 들 이 이 를 엉망 으로 만 들 기도 한다.남 이 시 키 는 대로 하고 남 이 하 는 대로 자신 도 하 는 것 은 매우 쉽다.그러나 전방위 적 으로 문 제 를 보고 자신의 수요 에 따라 대응 하 는 가장 좋 은 방향 을 선택 하려 면 어렵다.소프트웨어 업계 에서 선택 을 하 는 것 은 필수 적 이지 만 평가 분석 을 해 야 할 때 머리 가 막막 하 다 면 최종 결 과 는 무 작위 로 하 나 를 고 르 거나 맹종 할 수 밖 에 없다.
12.검 은 고양이 든 흰 고양이 든 쥐 를 잡 으 면 좋 은 고양이 다.
당신 의 소프트웨어 가 고객 이 지정 한 기능 을 실현 할 수만 있다 면 그들 은 어떤 문 제 를 해결 해 야 하 는 지 에 관심 을 가지 지 않 을 것 입 니 다.시스템 에 문제 가 생 겼 습 니 다.이상 상황 이 발생 했 습 니 다.하드웨어 가 고장 났 고 프로그램 원숭이 가 여자 친구 에 게 차 였 습 니 다.해커 가 번 호 를 훔 쳤 습 니 다.사용 자 는 이런 것 에 대해 영원히 관심 을 가지 지 않 을 것 입 니 다.만약 의외 의 상황 이 발생 한다 면 솔직하게 말 하 는 것 이 좋 지만,당신 은 이런 상황 이 오래 지속 되 지 않도록 확보 하 는 것 이 좋 습 니 다.왜냐하면 당신 은 항상 최종 제품 을 고객 에 게 건 네 주기 때 문 입 니 다.
13.고객 의 의견 이 품질 을 결정 한다.
당신 이 얼마나 많은 지 표를 설정 하고 얼마나 많은 표를 검 사 했 는 지,얼마나 많은 코드 를 심 사 했 는 지,얼마나 많은 테스트 를 썼 는 지 는 관건 이 아니다.고객 이 소프트웨어 가 정상적으로 작 동 하 는 것 을 직접 보지 않 는 한.코드 품질,성능,디자인 과 가용성 에 대해 고객 의 의견 이 야 말로 품질 을 결정 하 는 유일한 요소 이다.
14.어떤 방면 에 대한 무 지 는 당신 을 패배 시 킬 수 있 습 니 다.왜냐하면 당신 은 이 방면 에 경험 이 없 기 때 문 입 니 다.
오늘날 에 도 불구 하고 나 는 계속 놀 라 고 있다.어떤 동료 들 은 아직도 충분 한 로그,붕괴 보고서 와 정 보 를 수집 하여 자신의 소프트웨어 를 통제 하지 못 하고 있다.이 방면 의 정 보 를 거들 떠 보지 도 않 는 녀석 들 은 대부분 제품 의 품질 을 과대 평가 할 것 이다.만약 당신 이 조치 와 결 과 를 기록 하지 않 고 흐리멍덩 하 게 나 날 을 보 내지 않 는 다 면,결국 당신 은 현재 상황 에 대해 아무것도 모 르 게 될 것 입 니 다.당신 의 고객 을 포함 하여.상세 하고 유용 한 로그 기록,프로그램 붕괴 추적,논평 과 의견 을 반복 적 으로 강조 해 왔 습 니 다.어쨌든 어떤 문제 가 발생 했 는 지 빨리 알 수 있 는 여러 가지 경로 와 방법 이 가능 합 니 다.하지만 나 도 많은 사람들 이"이런 일이 프로그래머 와 한 푼 의 관계 가 있 느 냐"고 생각 하 는 것 을 안다.
14.더 좋 은 방법 이 있 지만 시간 은 허락 하지 않 는 다.
평가 에서 가장 파악 하기 어 려 운 부분 은 언제 두뇌 폭풍 을 멈 추고 공 사 를 시작 해 야 하 는 지 하 는 것 이다.아마도 우 리 는 그 더 좋 은 방법 을 놓 칠 것 이다.그러나 오래 걸 리 려 면 가치 가 없다.하지만 이 는 정의 하기 어렵 지만 오늘 의 작은 선택 이 내년 의 더 좋 은 선택 을 이 길 수도 있다.Who knows?
다음 두 가 지 는 영업 사원 에서 인용 한 것 으로 그 는 나의 아주 오래된 동료 이다.어떤 것들 은 내 가 완전히 동의 하 는 것 은 아니 지만,우리 에 게 다른 각도 에서 문 제 를 볼 수 있다.
15.고객 은 어 리 석 은 사람 을 찾 아야 한다.
이것 은 내 가 가장 좋아 하 는 말 인 데,이 판매원 은 컨설팅 회사 에 취직 했다.그 는 기술 은 모 르 지만 돈 은 충분히 쓰 는 금 주 를 찾 아야 한다 고 생각한다.똑똑 한 사람 은 항상 많은 질문 을 한다.돈 이 없 는 사람 은 우리 의 서 비 스 를 살 능력 이 없다.나 는 내 가 프로그래머 라 서 매우 기쁘다,하하!
16.나의 일 은 고객 을 속 이 는 것 이 고,너의 일 은 나 를 지지 하 는 것 이다.
두 번 째 말 은 같은 영업 사원 에서 나 왔 다.그 는 항상 불가능 한 임 무 를 끊임없이 약속 하 는 것 을 좋아한다.그리고 우리 가 마침내 심혈 을 기울 여 잔업 을 해서 쫓 아 냈 을 때,그 는 우리 의 성공 의 열 매 를 거 두 러 왔 다.도전 은 확실히 사람 을 흥분 시 키 지만,매번 이런 불가능 한 임무 라면 너무 고통스럽다.제 제안 은 더 좋 은 영업 사원 으로 바 꾸 는 것 입 니 다![번역자 주:이것 은 전설의 PM 과 프로그래머 간 의'조화'관계 가 아 닙 니까?