특정 조건에서 프로그래머의 관심을 끄는 방법은 무엇입니까?


13

예를 들어 보자.

exportDB 스키마에 크게 의존 하는 메서드가 있다고 가정 해 봅시다 . “무겁다”는 말은 특정 테이블에 새 열을 추가하는 경우가 많고 (매우 자주) 해당 export메소드가 변경됨 을 나타냅니다 (보통 내보내기 데이터에도 새 필드를 추가해야 함).

프로그래머는 종종이 export방법 을 변경 해야한다는 것을 확실하지 않기 때문에 방법 을 변경 하는 것을 잊어 버립니다 . 내 목표는 프로그래머 가 메소드 를 보는 것을 잊었는지 또는 내보내기 데이터에 필드를 추가하고 싶지 않은지를 결정하도록 명시 적으로 결정하도록하는 것 export입니다. 그리고이 문제에 대한 디자인 솔루션을 찾고 있습니다.

두 가지 아이디어가 있지만 둘 다 결함이 있습니다.

스마트 한 "모두 읽기"래퍼

모든 데이터를 명시 적으로 읽도록하는 스마트 래퍼를 만들 수 있습니다.

이 같은:

def export():
    checker = AllReadChecker.new(table_row)

    name    = checker.get('name')
    surname = checker.get('surname')
              checker.ignore('age') # explicitly ignore the "age" field

    result = [name, surname] # or whatever

    checker.check_now() # check all is read

    return result

따라서 읽지 않은 다른 필드가 포함되어 checker있는지 확인 table_row합니다. 그러나이 모든 것은 무겁게 보이고 성능에 영향을 줄 수 있습니다.

방법을 확인하십시오 ”unittest

마지막 테이블 스키마를 기억하고 테이블이 변경 될 때마다 실패하는 unittest를 만들 수 있습니다. 이 경우 프로그래머는 " export방법 을 확인하는 것을 잊지 마십시오"와 같은 것을 보게 될 것 입니다. 경고 프로그래머를 숨기려면 새로운 필드를 추가하여 테스트를 수동으로 체크 아웃 export하고 수동으로 (다른 문제) 해결하십시오.

다른 아이디어가 있지만 구현하기가 너무 어렵거나 이해하기가 어렵습니다 (프로젝트가 퍼즐이되기를 원하지 않습니다).


위의 문제는 때때로 발생하는 더 광범위한 종류의 문제의 예일뿐입니다. 일부 코드 및 / 또는 인프라를 바인딩하려고하므로이 중 하나를 변경하면 즉시 프로그래머에게 다른 코드를 확인하라는 경고가 표시됩니다. 일반적으로 일반적인 논리 추출 또는 안정적인 단위 테스트 작성과 같은 간단한 도구가 있지만 더 복잡한 경우를위한 도구를 찾고 있습니다.


export스키마를 기반으로 생성 할 수 있습니까 ?
coredump

그것은 자동으로 생성 될 수 없기 때문에 프로그래머에게 코드 를 보고 결정 하도록 요청 해야합니다 .
Vadim Pushtaev

내보내기 클래스에 두 개의 필드 이름 목록 (내보내기 및 dont-export)을 추가하고 해당 두 목록이 함께 데이터베이스의 전체 필드 세트를 포함하는지 확인하는 단위 테스트를 수행하는 솔루션입니까?
Sjoerd Job Postmus

export현실적으로 필요한 모든 것이 있는지 확인하는 테스트를 자동 생성 할 수 있습니까 ?
biziclop

1
소스 코드의 주석이 너무 단순한 솔루션입니까? 알림이 없기 때문에 일반적으로 상황이 누락됩니다. 댓글로 해결하십시오.
gbjbaanb

답변:


11

단위 테스트 아이디어를 제대로 따르고 있지만 구현이 잘못되었습니다.

이 경우 export스키마에 관련된 스키마가 변경 될 때, 두 가지 경우가 있습니다 :

  • 중 하나는 export이 스키마에 약간의 변화에 영향을받지 않았기 때문에 아직 완벽하게 잘 작동

  • 아니면 부러집니다.

두 경우 모두이 가능한 회귀를 추적하는 것이 빌드의 목표입니다. 통합 테스트, 시스템 테스트 또는 기능 테스트 또는 기타 테스트와 같은 여러 가지 테스트 는 이전 커밋 이후 변경 여부에 관계없이 export프로 시저가 현재 스키마 와 작동 하는지 확인합니다 . 이러한 테스트가 통과되면 훌륭합니다. 그들이 실패하면, 이것은 개발자에게 무언가를 놓쳤을 수도 있다는 표시이며, 어디를 볼 것인지에 대한 명확한 표시입니다.

구현이 왜 잘못 되었습니까? 몇 가지 이유가 있습니다.

  1. 단위 테스트와는 아무런 관련이 없습니다 ...

  2. ... 실제로는 테스트조차되지 않습니다.

  3. 최악의 부분은 "테스트"를 수정하기 위해서는 실제로 "테스트"를 변경해야한다는 것입니다. 즉, "테스트"와 완전히 관련이없는 작업을 수행하는 것 export입니다.

대신 export절차에 대한 실제 테스트를 수행하여 개발자가를 수정해야합니다 export.


보다 일반적으로, 한 클래스의 변경이 항상 또는 일반적으로 완전히 다른 클래스의 변경이 필요한 상황이 발생하면 이는 설계를 잘못하고 단일 책임 원칙을 위반하고 있다는 좋은 신호입니다.

클래스에 대해 구체적으로 이야기하지만 다른 엔터티에도 적용됩니다. 예를 들어, 데이터베이스 스키마의 변경 사항은 많은 ORM에서 사용하는 코드 생성기를 통해 코드에 자동으로 반영되거나 최소한 쉽게 현지화되어야 Description합니다. Product테이블 에 열을 추가 하고 ORM 또는 코드 생성기를 사용하지 않는 경우, 적어도 모든 코드베이스를 검색 하고 프레젠테이션 계층에서 클래스의 발생을 찾을 필요없이 DAL 클래스 내 에서 단일 변경을 기대합니다 .Data.ProductProduct

변경 사항을 한 위치로 합리적으로 제한 할 수없는 경우 (단순히 작동하지 않거나 많은 양의 개발이 필요하기 때문에) 회귀 의 위험이 있습니다. class를 변경 하고 코드베이스의 어딘가에서 A클래스 B가 작동을 멈 추면 회귀입니다.

테스트는 회귀 위험을 낮추며 훨씬 중요한 회귀 위치를 보여줍니다. 따라서 한 위치에서 변경하면 코드베이스의 완전히 다른 부분에서 문제가 발생한다는 것을 때 회귀가이 수준에 표시되는 즉시 경보를 발생시키는 테스트를 충분히 수행해야합니다.

모든 경우에, 그러한 경우에만 의견에 의존하지 마십시오. 다음과 같은 것 :

// If you change the following line, make sure you also change the corresponding
// `measure` value in `Scaffolding.Builder`.

절대 작동하지 않습니다. 개발자는 대부분의 경우이 내용을 읽지 않을뿐만 아니라 관련 라인에서 제거되거나 멀리 떨어져서 이해하기 어려워 질 수도 있습니다.


그렇습니다.“테스트”는 실제로 테스트가 아니며, 일종의 함정이며, If you change the following line...자동으로 작동하며 무시할 수없는 것입니다. 나는 누군가가 실제로 그러한 함정을 사용하는 것을 본 적이 없으므로 의심의 여지가 있습니다.
Vadim Pushtaev

1
문제는 클래스 B가 작동을 멈추지 않는다는 입니다. 아마도 제대로 작동 하지 않을 있습니다. 그러나 미래를 예측할 수없고 미래를 예측하는 테스트를 작성할 수 없으므로 개발자에게 새 테스트를 작성하도록 상기시켜줍니다.
Vadim Pushtaev

@VadimPushtaev : 테스트와 관련하여 "부적절하게 작동하기 시작"하고 "작동 중지"는 정확히 동일합니다. 미래를 예측할 수는 없지만 요구 사항을 정확히 알고 실제 제품이 해당 요구 사항을 충족하는지 테스트 할 수 있어야합니다.
Arseni Mourzenko 2016 년

그래, 그거야 실제로 개발자에게 새로운 요구 사항에 대해 생각하게 하고 싶습니다 . 손을 흔들고 싶을뿐입니다.“안녕하세요. 관리자에게 물어보십시오. 일반적인 문제입니다.”
Vadim Pushtaev

어쨌든 감사합니다. 당신의 대답은 저의 생각을 정리하는 데 도움이되었고 지금은 특정한 계획을 가지고 있습니다.
Vadim Pushtaev

3

변경 사항이 지정되지 않은 것 같습니다. 우편 번호가없는 곳에서 거주한다고 가정하면 주소 표에 우편 번호 항목이 없습니다. 그런 다음 우편 번호가 소개되거나 우편 번호가있는 곳에 사는 고객을 상대하기 시작하여이 열을 테이블에 추가해야합니다.

작업 항목에 "주소 테이블에 우편 번호 열 추가"라는 메시지가 표시되면 내보내기가 중단되거나 최소한 우편 번호가 내보내지지 않는 것입니다. 그러나 우편 번호를 입력하는 데 사용되는 입력 화면은 어떻습니까? 모든 고객과 그들의 주소를 나열하는 보고서? 이 열을 추가 할 때 변경해야 할 많은 것들이 있습니다. 이러한 것들을 기억하는 일은 중요한 일입니다. 개발자가 기억하는 데 "무작위"를 부여하는 임의의 코드 아티팩트에 의존해서는 안됩니다.

의미있는 열 (즉, 캐시 된 총 또는 비정규 화 된 조회 또는 내보내기 또는 보고서 또는 입력 화면에 속하지 않는 다른 값이 아닌)을 추가하기로 결정한 경우 작성된 ​​모든 작업 항목에 모든 변경 사항이 포함되어야합니다. 필요-열 추가, 채우기 스크립트 업데이트, 테스트 업데이트, 내보내기, 보고서, 입력 화면 등 이들은 모두 같은 사람에게 배정 (또는 수령) 될 수는 없지만 모두 완료되어야합니다.

때때로 개발자들은 더 큰 변화를 구현하기 위해 열 자체를 추가하기로 선택합니다. 예를 들어 누군가 구현 방법에 대한 생각없이 입력 화면과 보고서에 무언가를 추가하기 위해 작업 항목을 작성했을 수 있습니다. 이런 일이 많이 발생하면 작업 항목 추가자가 구현 세부 사항을 알아야하는지 (모든 올바른 작업 항목을 추가 할 수 있도록) 개발자가 작업 항목을 인식해야하는지 여부를 결정해야합니다. 가산기는 때때로 물건을 남기지 않습니다. 후자라면 "스키마를 바꾸지 말고 그에 영향을 미치는 다른 것을 멈추고 생각하십시오"라는 문화가 필요합니다.

개발자가 많고이 문제가 두 번 이상 발생한 경우 팀장 또는 다른 선임 직원이 스키마 변경에 대한 알림을 받도록 체크인 알림을 설정합니다. 그런 다음 해당 담당자는 스키마 변경의 결과를 처리하기 위해 관련 작업 항목을 찾을 수 있으며 작업 항목이 누락 된 경우 작업 항목을 추가 할 수있을뿐만 아니라 계획에서 빠진 사람을 교육 할 수 있습니다.


2

거의 항상 내보내기를 만들 때 해당 가져 오기도 만듭니다. 내보낼 데이터 구조를 완전히 채우는 다른 테스트가 있으므로 완전히 채워진 원본을 내 보낸 다음 가져온 사본과 비교하는 왕복 단위 테스트를 작성할 수 있습니다. 동일하면 내보내기 / 가져 오기가 완료됩니다. 동일하지 않으면 단위 테스트가 실패하고 내보내기 메커니즘을 업데이트해야한다는 것을 알고 있습니다.


이를 통해 모든 객체가 db에서 저장되고 다시로드되는지 확인할 수 있습니다. 기존 db-field에 해당 객체 필드가없는 경우는 다루지 않습니다.
k3b

@ k3b 맞습니다. 적어도 내 시스템에서는 일반적으로 무언가가 더 이상 사용되지 않지만 내보내기 메커니즘의 범위를 벗어난 스키마에서 제거되지 않은 경우 일반적으로 발생합니다. 단위 검사는 객체 지속성을 검사하여 객체의 각 필드가 지속되지만 사용하지 않는 열은 시스템 기능에 관찰 가능한 영향을 미치지 않으므로 테스트하지 않습니다.
Pete Kirkham
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.