대규모 재작업을 방지하기 위해 먼저 테스트 사례를 심사하는 개발 방법

안녕하세요.프라하 CEO의
TL;DR

유능한 사람은 완형을 보여준 후 상세하게 설명

30% 정도 완성된 시점에 완성된 인상을 주고 일치하지 않는지 확인

코드도 이미지를 검사한 후에 세부 사항을 실시하는 것이 좋지 않습니까

테스트 용례부터 보면 되지 않을까요?

일을 잘하는 사람이 왜 땡땡이냐
"일 잘하는 사람이 왜 땡이지?"이런 비즈니스 서적에는 이런 기교가 자주 있다.그것은
부탁받은 일은 30% 정도 완성됐을 때 의뢰인에게 살펴보고 일치하지 않는 부분이 없는지 확인하세요
자주 등장하는 것이 바로 발표의 예이다.
업무 능력이 떨어지는 유형
상사: "부장님께 이번 기획안을 설명하는 보고를 잘 해 주십시오. 발표는 일주일 후입니다."
부하: "알겠습니다!"
1주일 후~
부하: "됐습니다!"
상사: "이게 뭐야! 내 생각과는 완전히 달라!"
부하: "됐어!"
일 잘하는 타입
상사: "부장님께 이번 기획안을 설명하는 보고를 잘 해 주십시오. 발표는 일주일 후입니다."
부하: "알겠습니다!"
1시간 후~
부하: "이런 인상으로 만들고 싶은데, 어때요?"
상사: "이 근처에서 이런 느낌으로 조금만 바꿔 주세요."
부하: "그래."
3일 후~
부하: "그 다음에 메모를 하면 완성되지만 그림을 그리는 데 시간이 걸리니 미리 좀 봐주시겠어요?"
상사: "응응...이 그림 필요 없어? 반대로 이런 그림을 만들어 달라고."
부하:자
1주일 후~
부하: "됐습니다!"
상사: "상상했던 대로! 이 신인은 정말 대단해."
일을 잘하지 않습니까?
'중도 확인' 은 모든 작업의 기본이지만, 코드를 쓸 때 의외로 이 기본적인 상황을 소홀히 한 것을 발견하였다
사전에 한 번도 상의하지 않고 36 files changed의 귀신 PR에 대해 "댓글 달아주세요"라고 말하는 데 3일가량 걸렸다.한 마디만 더 해서 제출하면...

"기존 구조를 전혀 따르지 않고 다시 쓴다"

"스타일 잘 봤어요?"

"기존 통용 처리가 있으니 그걸로 하자"

는 반박을 받았다.
만약 이런 모델에 빠진다면, 아마도 업무 진전 방식을 재검토할 기회일 것이다!
중간에 코드를 확인해야 돼요.
말은 그렇지만

const newHoges = hoges.map(( // 途中まで書いた！

이렇게 중도에서 그만둔 상태에서 "절반을 완성했다! 확인해달라!"이렇게 제출해도 시청자에 의해 방영이 끝날 수밖에 없기 때문에 시청자들이 쉽게 이해할 수 있고 간결한 부분에서 제시해 주시기 바랍니다.
그래서 제가 제안하고자 하는 방법은'테스트용례만 있다'고 적힌 PR을 보여드리는 것입니다.
이런 인상입니다.

(hoge.test.js)
it('引数に1を渡したら2が返る', () => {})
it('引数に2を渡したら例外が発生する', () => {})
it('引数に42を渡したら全宇宙の真理とコンソールに出力される', () => {})

이런 상태에서 테스트 용례를 한 번만 검사하면 적어도 자신이 앞으로 실시할 기능의 규격에 대해 일치된 인식을 가져야 한다.
물론 시험용례에서 표현할 수 없는 요건과 비기능 요건도 있어 완벽한 식별 확인이 불가능한 경우도 있지만, 시험용례라는 완성도를 먼저 제시한 뒤 중도 확인하는 경우도 있고, 전혀 확인하지 않고 실장을 강행해 성대한 재작업을 할 때도 있다주위 사람들을 보면 전자가 더 안심하고 일을 맡길 수 있지 않을까요?
시험 내용은 안 써도 돼요?
테스트 용례를 한 번 보고 테스트 내용을 써도 되지만 테스트에 실패한 코드push에 대한 생각은 팀에 따라 다르기 때문에 팀과 상의하는 것이 좋다.
시험에 떨어질 때마다 슬랙은 통지를 받을 테니 그러지 마세요!반대로 "요건을 충족하지 못한 테스트가 계속 통과되면 시행을 잊어버릴 수 있으니 떨어져도 좋으니 테스트 내용을 적어줬으면 좋겠다"고 말했다.그렇게 말할지도 몰라.저는 개인적으로 시험에 떨어지면 통합이 안 되면 파이팅 할 수 있지 않을까요?생각
가는 길에 너에게 실복의 인상을 덧붙여 주겠다
'이런 인상으로 이루고 싶다'는 공유가 가능한 임시 설치를 더하면 시청자들에게 따뜻함과 행복함을 줄 수 있다.클래스 인터페이스와 방법의 의도만 쓰면 이 단계에서는 상세하게 설명하지 않습니다.다음에 어디에 어떤 코드를 쓸지 알려주는 게 목적이야.

class User {
    getAge() { return 20 } // todo: 今は定数だけど実際は生年月日から計算して年齢を返す
    addAddress(address: string) {} // todo: 有効な住所か判定します。住所一覧に新しい住所を追加します。5件以上は登録できないようにここで制御します
}

코드의 기초가 커지면'이 층에 이런 코드를 적어주세요','그 코드로 이 코드를 만지면 안 돼요'등 디자인과 관련된 중대한 지적이 늘어난다.수십시간이 걸린뒤에이런지적을 받으면성대한재작업이벌어지지만디자인등의관점은임시설치단계에서도충분히볼 수 있으므로적극적으로임시설치상태에서점검해주세요.
임시 설치에 맞추어 테스트 용례의 설치를 약간 추진하여 사용자가 코드의 사용 방법을 상상할 수 있게 하여 사용자를 더욱 따뜻하게 할 수 있다

it('addAddressの引数に渡した文字列（住所)がlistAddressで取得できる', () => {
    const user = new User()
    user.addAddress('hoge')
    // todo: user.listAddressしたら ['hoge'] が返ってくるイメージ
})

이런 느낌으로 먼저 테스트 용례만 보고 실복의 인상을 준 뒤 상세한 실복을 진행한다...이런 느낌으로 큰 틀의 완성도부터 천천히 상세한 내용을 매립하는 모습은 확실히 처음에 소개한'일 잘하는 모델'이다!
어려운 기능실장을 위임받았다면, 추진방법에 곤란을 느끼는 사람은 이런 작업의 추진방법을 의식해 볼 수 있다.