다음은 하 이 버 네 이 트 개발 에 대한 개인 적 인 생각 입 니 다.바로 이런 작업 들 이 하 이 버 네 이 트 를 이렇게 신속하게 인 기 를 끌 었 습 니 다.1.빠 른 버 전 발 표 는 활발 한 개발 속 도 를 유지 하고 버 전 발 표를 자주 하 며 심지어 며칠 안에 이전 버 전에 서 다음 버 전 으로 개발 합 니 다.이렇게 하면 소프트웨어 가 Bug 에서 멀리 떨 어 질 수 있 는 가장 좋 은 방법 이 고 사용 자 를 안심 시 킬 수 있 으 며 Hibernate 의 개발 이 매우 활발 하 다 고 확신 할 수 있 습 니 다.또한 이렇게 하면 어떤 기능 이 사용자 가 진정 으로 필요 로 하 는 지 알 수 있 습 니 다.2.회귀 테스트 는 현재 전체 자바 커 뮤 니 티 에서 자동 회귀 테스트 를 매우 중시 할 것 이 라 고 생각 합 니 다.만약 에 소프트웨어 의 기능 과 디자인 이 비교적 큰 수정 이 있다 면 종합 적 인 test suite 는 소프트웨어 의 유지 가능성 과 안정성 에 있어 너무 중요 하 다.우 리 는 소프트웨어 의 새로운 기능 에 대해 회귀 테스트 를 하지 않 았 다 면 우 리 는 그것 을 해 서 는 안 된다 는 의식 을 가 져 야 한다.3.한 가지 기능 을 최선 을 다 하거나 하지 않 거나 하려 면 최선 을 다 해 야 한다.그것 은 우리 가 가장 좋 은 기능 을 할 수 없다.우 리 는 전혀 하지 않 고 다른 소프트웨어 에 던 져 서 하 자.4.과도 한 디자인 이 대량의 시간 과 정력 을 낭비 하여 소프트웨어 기능 을 하 는 추상 적 이 고 소프트웨어 의 유연성 을 확대 하 는 것 을 피하 기 위해 시간 을 좀 더 들 여 사용자 가 직면 하 는 실제 문 제 를 해결 하 는 것 이 좋 습 니 다!간단하게!소프트웨어 가 달 릴 수 있 으 면 OK 입 니 다.사용자 가 전혀 관심 이 없 는 문 제 를 해결 하려 고 하지 마 세 요.당신 의 소프트웨어 디자인 이 우아 하지 않 아 도 상관 없어 요.어차피 initial 단계 잖 아 요!나중에 refactor 에서 당신 이 주목 해 야 할 문 제 는 제때에 유용 한 기능 을 만들어 내 는 것 입 니 다.5.집권 은 민주 투표 로 결정 해 야 하기 전에 적어도 소프트웨어 의 윤곽 을 다 만 들 었 다.소프트웨어 개발 은 한두 명의 깨 어 있 는 사람 이 이 끌 어야 한다.그러면 소프트웨어 개발 의 일관성 을 확보 하고 큰 차이 가 생기 지 않도록 개발 팀 이 화력 을 집중 하여 실현 하고 자 하 는 기능 을 가장 잘 할 수 있다.나 는 OSS 소프트웨어 의 가장 큰 위험 은 의견 이 일치 하지 않 고 노점 이 너무 커서 결국 아무것도 하지 못 한 것 이 라 고 생각한다.(번역 자 는 매우 찬성 합 니 다.성공 한 OSS 소프트웨어 는 모두 어떤 소 가 소프트웨어 를 다 만 든 후에 발표 한 다음 에 모두 가 그 안에 기능 을 추가 하고 소 사람의 지도 아래 계속 발전 합 니 다.소인 이 부족 한 OSS 소프트웨어 는 모두 성공 적 이지 않다.예 를 들 어 Mozilla)6,문 서 는 문서 보다 더 중요 한 것 이 없다.만약 당신 의 사용자 가 당신 의 소프트웨어 에 이런 기능 이 있다 는 것 을 모른다 면,이 기능 이 없 는 것 과 같 습 니 다.차라리 그것 을 없 애 버 리 면 소스 코드 에 복잡 도 를 증가 시 키 지 않도록 할 수 있 습 니 다.7.표준 화 된 기준 을 피 하 는 것 은 소프트웨어 의 호환성 과 이식 성 을 가 져 올 수 있 고 나 쁜 기준 은 소프트웨어 혁신 을 질식 시 킬 수 있 습 니 다!"XXX 표준 을 지원 하 는 것 은 실제 사용자 의 수요 가 아니다.특히 이 XXX 표준 은 그 자리 에서 정 치 를 도모 하지 않 는 이른바 전문가 위원회 에서 제정 한 것 이다.(번역자:혹시 Sun,IBM 등 몇 개의 big name?)가장 좋 은 소프트웨어 는 끊 임 없 는 시도,끊 임 없 는 실수,끊 임 없 는 경험 이 쌓 이 는 과정 에서 생 긴 것 이다.사실상 의 기준 은 종종 사용자 의 수요 에 더욱 가깝다.8,10 분 안에 하 이 버 네 이 트 를 뛰 어 올 리 는 잠재 적 인 하 이 버 네 이 트 사용자 들 은 하 이 버 네 이 트 를 다운로드 했다.처음 사용 할 때 30 분 정도 의 시간 을 들 여 설치,설정,troubleshooting 을 설치 할 수 없 었 고 그들 은 하 이 버 네 이 트 에 대한 흥 미 를 잃 었 다.우리 의 구 호 는 새로운 사용자(충분 한 JDBC 지식 이 있다 고 가정)가 5 분 안에 하 이 버 네 이 트 의 데 모 를 달 리 는 것 이다.그들 은 1 시간 안에'Hello World'식 의 가장 간단 한 하 이 버 네 이 트 프로그램 을 쓰 고 정상적으로 운행 할 수 있다.9.개발 자의 책임감 사용 자 는 항상 문제 에 부 딪 히 는 것 을 피 할 수 없 으 며 개발 팀 은 도움 을 줄 의무 가 있다.사용 자 는 문서 의 빈틈 을 알 게 해 주 었 고,사용 자 는 테스트 용례 의 작은 버그 를 알 게 해 주 었 다.그 밖 에 사용자 가 우리 의 Hibernate 를 사용 하지 않 습 니 다.우 리 는 그것 을 개발 해서 무엇 을 합 니까?시간 을 낭비 하 는 것 이 아 닙 니까?bug 에 관 한 농담 이 있 습 니 다.사용 자 는 새로운 기능 을 발견 하 는 bug(번역 자 는 Windows 사용자 들 이 모두 그런 것 같 습 니 다)를 전혀 개의 치 않 습 니 다.bug 를 신속하게 고 칠 수만 있다 면."책임감 은 버그 복구 가 1 주일 안에 이 루어 져 야 한 다 는 것 을 의미한다.bug 보고 서 를 받 고 bug 복구 코드 를 CVS 에 제출 할 때 까지 평균 24 시간 정도 하 는 것 이 이상 적 인 목표 입 니 다.10.사용 하기 쉽 고 업데이트 가능 한 위 키 페이지
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
