본문 바로가기

강의

(63)
5.8 로그와 로그 메시지 로깅 (Logging) 로깅은 프로그램을 실행하는 동안 발생하는 이벤트를 이해하는 데 중요하다. 예를 들어 모델을 밤새 실행했는데 다음 날 아침 결과가 예상과 다를 경우 로그 메시지를 통해 발생한 결과에 대한 컨텍스트를 더 잘 이해할 수 있다. 로그 메시지 로깅은 소프트웨어를 실행하는 동안 발생한 이벤트를 설명하기 위해 메시지를 기록하는 프로세스이다. 몇 가지 예를 보고 좋은 로그 메시지 작성을 위한 팁을 소개한다. 팁: 전문적이고 명확해야 한다. Bad: Hmmm... this isn't working??? Bad: idk.... :( Good: Couldn't parse file. 팁: 간결하고 일반적인 대문자를 사용한다. Bad: Start Product Recommendation Process B..
5.7 테스트 중심의 개발 및 데이터 과학 테스트 중심 개발 테스트 중인 코드를 작성하기 전에 테스트를 작성한다. 처음에는 테스트가 실패하며, 테스트를 통과하면 작업 구현이 완료된다. 테스트에서는 기능을 사용하기 전에 다양한 시나리오와 에지 케이스가 있는지 확인할 수 있다. 기능 구현을 시작할 때 테스트를 실행하여 기능을 조정할 때 작동 여부에 대한 즉각적인 피드백을 얻을 수 있다. 코드를 리팩터링하거나 추가할 때 테스트를 통해 코드를 변경하는 동안 나머지 코드가 손상되지 않았는지 확인할 수 있다. 테스트를 통해 하드웨어 및 시간과 같은 외부 매개 변수에 관계없이 기능 동작을 반복할 수 있는지 확인할 수도 있다. 데이터 과학을 위한 테스트 주도 개발은 비교적 새로운 것이며 많은 실험과 혁신을 경험하고 있다. 다음 리소스를 탐색하여 자세히 알아볼 ..
5.2 테스팅 & 도구 테스팅 배포 전에 코드를 테스트해야 한다. 큰 영향을 미치기 전에 오류와 잘못된 결론을 파악하는 데 도움이 된다. 오늘날 고용주들은 자신의 코드를 테스트하는 것을 포함하는 산업 환경에 적합한 코드를 준비할 수 있는 기술을 갖춘 데이터 과학자를 찾고 있습니다. 테스팅과 데이터 과학 데이터 과학에서 발생할 수 있는 문제가 항상 쉽게 감지되는 것은 아니다. 값이 잘못 인코딩되거나, 기능이 부적절하게 사용되거나, 예상치 못한 데이터 손상 가정이 있을 수 있다. 이러한 오류를 탐지하려면 코드 품질뿐만 아니라 분석 품질과 정확성도 확인해야 한다. 예상치 못한 놀라움을 피하고 결과에 자신감을 가지려면 적절한 테스트가 필요하다. TDD(Test-driven Development): 작업을 실행하기 위한 코드를 작성하기..
4.24 모델 버전 관리 이전 예에서는 각 커밋이 해당 모델에 대한 점수로 문서화되어 있음을 알 수 있었다. 이것은 모델 버전을 추적하는 데 도움이 되는 간단한 방법이다. 데이터 과학의 버전 제어는 까다로울 수 있다. 대량의 데이터, 모델 버전, 시드 및 하이퍼 파라미터와 같이 추적하기 어려운 부분이 많기 때문이다. ML 모델의 버전 관리 기계 학습 작업(현재 유행어 패턴 xxOps에서는 mlOps라고 함)은 기존 소프트웨어 개발 작업(devOps)과는 상당히 다르다. 그 이유 중 하나는 ML 실험에서 코드(작은 일반 파일) 외에도 큰 데이터 집합과 모델 아티팩트가 요구되기 때문이다. 1. ML 모델은 확장성, 보안, 가용성, 사실상 무제한의 스토리지 공간으로 지속된다. 2. ML 모델은 버전 제어 하에 있다. 즉, 특정 버전의..
4.23 VC 시나리오 #3 1단계: 문서 분기에 대한 변경 사항을 적용하고 개발 분기로 전환한 다음 이전에 친구 그룹 기능에 대해 병합한 변경 사항을 포함하여 이 개발 분기에 대한 클라우드에서 최신 변경 사항을 가져온다. - 변경사항 커밋 - develop으로 전환 - 최신 변경사항을 Pull 2단계: Andrew는 자신의 문서 분기를 로컬 리포지토리의 develop branch에 병합한 다음 변경 사항을 위로 푸시하여 원격 리포지토리의 develop branch를 업데이트한다. - 작업한 브랜치를 develop으로 병합한다. - 오리진 브랜치로 푸시한다. 3단계: 팀에서 귀하의 작업과 Andrew의 작업을 검토한 후 개발 지점의 업데이트를 마스터 지점으로 병합한다. 그런 다음 변경 사항을 원격 리포지토리의 마스터 분기에 푸시합니..
4.22 VC 시나리오 #2 1단계: 변경한 내용과 코드가 얼마나 잘 수행되었는지에 대한 메시지를 보고 커밋 기록을 확인한다. - 로그 확인 2단계: 이 커밋에서 모델이 가장 높은 점수를 받은 것 같으므로 살펴본다. - 커밋 번호를 확인한다. 코드를 검사한 후 어떤 수정 사항이 잘 수행되었는지 확인하고 해당 코드를 모델에 사용한다. 3단계: 이제 변경 사항을 개발 부서에 다시 병합하고 업데이트된 권장 엔진을 푸시할 수 있다. - develop으로 돌아와 분기를 병합하고 푸시한다.
4.21 VC 시나리오 #1 1단계: 이 저장소의 로컬 버전이 랩탑에 있으며, 최신 버전을 얻으려면 개발 지점에서 가져와야 한다. - develop 브랜치를 체크아웃하여 변경 - 최신 변경사항을 Pull하여 가져옴 2단계: 이 기록 정보 기능에 대한 작업을 시작하면 기록 정보라는 새 분기를 만들고 이 분기에서 코드 작업을 시작한다. - 새 브랜치를 생성한다. - 기능 작업 후 commit -m '기능' 포맷으로 커밋한다. 3단계: 그러나 작업 중간에 다른 기능을 사용해야 합니다. 따라서 이 인구통계학적 분기에 대한 변경 사항을 적용하고 개발 분기로 다시 전환한다. - 지금까지의 작업 커밋 - 다른 분기로 전환 4단계: 이 안정적인 개발 분기에서 새 기능에 대한 다른 분기를 만든다. - 새 분기 생성 5단계: 새 분기에 대한 작업을 ..
4.15 문서화 문서화 추가 텍스트 또는 소프트웨어 코드에 포함된 설명된 정보 설명서는 코드의 복잡한 부분을 명확히 하고 코드를 더 쉽게 탐색할 수 있도록 하며 프로그램의 여러 구성 요소가 사용되는 방법과 이유를 신속하게 전달할 수 있다. 프로그램의 여러 레벨에 따라 다양한 유형의 설명서를 추가할 수 있다. 인라인 코멘트 - 라인 레벨 문자열 - 모듈과 기능 레벨 프로젝트 문서 - 프로젝트 레벨 인라인 코멘트 인라인 주석은 코드 전체에서 해시 기호를 따르는 텍스트다. 코드의 일부를 설명하는 데 사용되며, 향후 기여자가 작업을 이해하는 데 도움을 준다. 코멘트는 종종 복잡한 코드의 주요 단계를 문서화한다. 코멘트가 코드를 설명하면 독자는 코드를 이해하지 않아도 된다. 그러나 다른 이들은 이것이 잘못된 코드를 정당화하기 위..

LIST