저의 경력에서 "퍼스트 클래스 라이브러리 게시"업적을 잠금 해제하려고하는 웹 개발자이고, 글 머리 기호가 땀을 흘리고 있습니다 (밤새 스트레스를 받았습니다). 커뮤니티의 경험을 활용하여 가능한 한 원활하게 진행되도록 제안이나 권장 사항이 있는지 확인하고 싶습니다. 알고 있어야 할 특정 사항이나 문제점이 있습니까? 다시 물릴 수있는 빌드 프로세스에 특별한 것이 있습니까?

내가있는 곳은 다음과 같습니다.

• 라이브러리는 단위 테스트를 거쳤으며 코드 범위는 약 97 %입니다
• API가 잘 문서화되고 인텔리전스 지원을위한 XML 문서가 작성되었습니다.
• 공개 / 개인 클래스 접근자가 정확하고 올바른지 확인했습니다. 모든 게터 / 세터도 마찬가지입니다.
• 오류 처리는 내가 원하는만큼 우아하지는 않지만 마감 시한을 지키고 현재로서는 "그만큼 나아질 것"임을 인정했습니다.
• 친절한 로깅이 없습니다. Debug.Writeline은 광범위하게 사용되었습니다 ... 최근에 이것이 이것이 나의 경험이 없음을 알았습니다 :(

당신의 조언은 대단히 감사합니다!

라이브러리는 보고서를 생성하는 데 사용됩니다. 표준 모자-읽기 전용 데이터베이스에 연결하고 계산을 수행하고 형식을 지정하고 데이터를 응답 스트림으로 출력합니다.

나는 종료 한 프로그래머 중 한 명을 위해 프린지 리소스로 활용되었고,이 작업은 "당신의 이빨을 자르는"프로젝트로 나에게 주어졌습니다. 클래스 라이브러리는 회사의 다른 프로그래머가 프로덕션 코드를 작성하는 동안 사용할 수 있도록 릴리스 될 예정입니다.

API 잠금

API를 효과적으로 구축하는 기술은 구조에 관한 것만 큼 기대치를 관리하는 것입니다.

API를 말할 때 특히 공개 / 내부 클래스 / 메서드의 이름과 액세스 수준 (예 : 개인 / 공용 / 내부)을 언급합니다.

코드가 프라임 타임에 완전히 준비되지 않았을까 걱정이되면 항상 처음에 베타로 게시 할 수 있습니다.

자료 :

• 베타 (예 : 1.0 이전)

  • 여러 API 변경 사항이 포함될 수 있습니다
  • 버전 간 이전 버전과의 호환성 변경이 없을 수 있습니다
  • 광택이 없을 수 있습니다

• 공식 (1.0+)

  • 다음 주요 릴리스까지 API가 잠김
  • 도입 된 변경 사항은 이전 버전과의 호환성을 보장해야합니다

• 사소한 (ex 1.1)

  • 버그 수정 및 / 또는 기능 구현 포함
  • 정의 된 API에 추가 할 수 있지만 빼지 않을 수 있음

API를 배틀 강화해야한다고 생각되면 잠시 베타 버전으로 출시하십시오. 이는 사용 가능하지만 프로덕션 및 / 또는 미션 크리티컬 코드에는 사용해서는 안된다는 신호입니다.

많은 사람들이 호그 워시와 같은 번호가 매겨진 버전 관리 체계를 취급하지만 효과적으로 사용하면 구조를 정리할 때까지 약간의 흔들림 공간을 제공하는 데 사용될 수 있습니다.

사용 방법에 대한 귀하의 가정은 잘못되었습니다

디자인이 아무리 잘되어 있더라도 사람들은 남용하거나 다른 용도로 사용하는 방법을 찾을 것입니다.

이를 처리하는 한 가지 방법은 접근 자 (예 : 개인 / 공공 / 내부)를 사용하여 가능한 많은 구현을 잠그는 것이지만, 디자인이나 엔지니어링의 양은 사용자에게 코드를 공개하는 것만 큼 많은 통찰력을 제공하지 않습니다.

코드가 얼마나 '완벽'하다고 생각하든, 사용자는 그렇지 않다는 것을 증명할 것입니다.

이것이 완전한 재 작성보다는 기존 코드베이스를 사용하는 것이 항상 더 좋은 주요 이유라고 주장합니다. 기껏해야 완전한 재 작성이 부풀어 오를 것이지만 새로운 코드베이스가 원래 코드베이스만큼 많은 버그를 포함 할 가능성이 높습니다.

당신의 경우에 당신은 처음부터 전투 강화되고 있습니다.

나머지 기지를 다룬 것처럼 들립니다. API 문서는 매우 중요하며 향후 변경시 안정성을 보장하기 위해 테스트를 수행하는 것이 좋습니다.

로그를 전역 적으로 활성화 / 비활성화 / 필터링하는 방법이 필요하므로 프로덕션 용 코드가 릴리스되기 전에 일관성있는 로깅 체계를 구현하는 것이 중요합니다. BTW, 대부분의 경우 로깅은 실제로 라이브러리를 가져오고 Debug.WriteLine ()의 출력 호출을 Logging.Debug (), Logging.Info (), Logging.Error ()와 같은 것으로 변경하는 작업 만 포함합니다. 로거 자체는 구성, 필터링 및 광범위한 출력 구성표 (예 : 파일, 콘솔 등)에 대한 표준 구현 만 제공합니다.

그 외에는 코드를 꺼내어 사용하려고합니다. 적은 수의 사용자 만 시작할 수 있습니다.

내가 찾은 두 가지는 소프트웨어 릴리스의 핵심입니다.

• 당신이 풀어 놓은 것을 정확히 아십시오
• 기대치 관리

되돌아 가서 릴리스 한 내용을 버그 수정하고 사람들이 코드로 해결할 문제를 이해하기를 원합니다.

당신이 풀어 놓은 것을 알기

올바른 버전과 서명이되어 있는지 확인하십시오 (적절한 경우). 소스 컨트롤을 사용하여 공식적으로 출시 된 버전과 관련된 코드에 태그를 붙입니다. 이렇게하면 릴리스 한 소스 코드로 정확하게 되돌아 갈 수 있으므로 버그를 쉽게 식별 할 수 있습니다. 릴리스 된 버전이 다른 경우에도 도움이 될 것입니다.

최신 버전을 쉽게 파악하고 업데이트하십시오. 이것이 설치자인지 또는 단순히 일반적인 공유 위치에 놓는 지 여부는 누가 언제 배송 할 것인지에 달려 있습니다.

설명서를 포함하여 최종 릴리스를 검토 할 사람이 있는지 확인하십시오. 소프트웨어 출시에 대해 긴장하거나 흥분하는 것은 매우 쉽고 무언가를 놓칩니다.

기대치 관리

제한 사항을 문서화하고 개발자에게 합리적으로 명확하게 만듭니다. 찾은 것이 좋습니다. 사람들이 소프트웨어의 제한 사항을 알고있는 경우, 특히 수정 계획이있는 경우 사람들이 더 잘 이해합니다.

피드백이 좋은지 나쁜지를 기록하십시오. 내부 프로젝트이므로 모든 사람이 공통 버그 추적 시스템에 액세스 할 수 있으면 해당 프로젝트에 대해 버그를 제기하도록 요청하십시오.

앞으로는 가능하면 API를 변경하지 마십시오. 이것이 고객을 성가 시게 할 가능성이있는 것입니다. C #에서는 메소드 문서의 일부가 아니지만 예외도 API의 일부입니다. 수 추후에 발생되는 예외를 향상시킬 수 있지만 최종 사용자에게 이야기하고있을 것이다 어떤 영향을 볼 필요가있을 것이다.

유용한 배포에 대한 점검 목록이 있습니다. 데스크톱 개발을 수행하지만이 중 일부는 번역해야합니다. 그 중 일부는 다음과 같습니다.

일반:

• null이 아니어야하는 함수 매개 변수를 null로 검사합니다. 이것은 내가 일찍 실패하는 데 도움이됩니다.
• 불필요한 주석 및 주석 처리 된 파일을 제거하십시오. 이것들은 미래의 일을 야기합니다.
• "// TODO"주석을 검색하십시오. 때때로 나는 나 자신을 위해 메모를 남긴다. 때로는 잊어 버리기도합니다.
• 가능한 경우 프로덕션 데이터베이스를 사용하여 코드 테스트를 실행하십시오. 이를 통해 프로덕션 서버에서 모든 데이터베이스 변경 사항을 적용 할 수 있습니다.
• 다량의 벌채를 넣습니다. 특히 초기 배포의 경우. 사실 내 코드는 일반적 으로이 시점에서 일부 겔화되기 때문에 로깅을 저장합니다. 당신은 당신이 충돌하는 상황에 있고 싶지 않고 스스로에게 "현재 X의 가치가 무엇인지 알았다면"라고 말합니다. 미리 계획하십시오.
• Facades에서 타사 라이브러리 호출을 래핑하십시오. 따라서 향후 라이브러리를 쉽게 변경할 수있을뿐만 아니라 라이브러리에서 필요한 사항에 대한 점검 목록을 제공 할 수 있습니다.

.Net 특정 :

• 일회용 객체에서 Dispose ()를 호출하고 있는지 확인하십시오. Code Analysis 또는 FxCop을 사용하여이 경우를 쉽게 찾을 수 있습니다.
• 모든 이벤트 핸들러를 올바르게 연결 해제했는지 확인하십시오. 메모리 누수가 방지됩니다.