GPT는 TDD를 하라고 하지만 나는 BDD가 훨 나은거 같음

[ㅆㅇㅆ(124.216)]

사람마다 어떤 방식의 개발을 선호하느냐는 개인 차이지만

나는 BDD로 문서화해보고 내가 생각하는 비즈니스 요구 사항과 사용자 기대를 문서화해서 그걸 바탕으로 만드는 BDD가 낫단 생각을 많이함

TDD가 나쁜 방식은 아닌데

무조건 실패하는 테스트를 한번이상 해봐야한다는게 너무 오래 걸려

[프갤러 1(183.96)]

TDD 그 책은 읽어봄? 창안자의 이론은 어케 생각함?

[ㅆㅇㅆ(124.216)]

켄트백 책은읽어봤고 TDD는 03년도 서적에 나온거임, 당연히 하면 코드의 품질은 오르지. 이론도 좋다고 생각함. 다만 그걸 교조적으로 적용하냐 안하냐는 개개인만의 차이가 있지. 창안자는 모두에 적용하라고 하지만 이는 좀.... 실제로 이에대한 설전이 있었고, 결론은 TDD는 좋다라는 걸로 대부분 끝났는데 나는 여전히 방법론이기때문에 무조건은 없다 생각 하긴함 다만 RGR(Red-Green-Refactor)는 좋다 생각함. 실패하는 테스트, 테스트 통과, 리팩토링은 당연히 하면 좋지만 이 자체만으로 정식적으로 피곤해서 품질은 오르는게 확실하지만 테스트 우선주의라는게 정신적으로 기빨림

[ㅆㅇㅆ(124.216)]

페어 프로그래밍도 유사함. 익스트림 프로그래밍 서적보면 페어프로그래밍은 생산성이 오른다! 하지만 프로그래머의 퇴사율도 올림. 따라서 프로그래머 개인의 정신적 피로도도 생각해야함

[익명(183.96)]

나는 켄트백 책 읽어보니까 개뻘소리 같던데... 물론 켄트백의 제안이 이제는 기본이 되어버린걸 감안해야 겠지만 책에서 제시되는 상향식 리펙토링 방법론은 진짜 본인 스스로가 경도되서 개소리하는 느낌이었음

[익명(211.235)]

ㄴ 상향식 리팩터링은 나는 아직도 가끔 하는데. 전혀 개소리 아님. 미틴 파울로의 리팩토링이나 읽어라

[ㅆㅇㅆ(124.216)]

뻘소리도 있지만 적용하고 안하고 코드 품질이 차이나는 걸 직접 겪어봤기때문에 결국 코드 품질면에서 그런거지. 결국 코드 품질에 대한 타협으로 상품성있는 상품을 먼저 내는 것인가 vs 내부적 코드 교통정리 우선인가에 따라 다른 느낌임

[익명(211.235)]

난 06년도에 tdd접하고 oop를 이해하는데 많은 도움됨. 그 이론이 지금이랑은 좀 안맞을거야 코딩 툴들이 좋아져서 오류를 잘 잡아주니까 하지만 옛날에는 코딩 툴이 빈약해서 편집증적으로 저런것도 있음. Tdd수련 좀 하면 리팩토링을 거의 실수없이 고칠수 있어서 도움 많이 되는것은 맞는데, 나는 tdd는 리팩토링을 다루기위한 도구로 봄.

[ㅆㅇㅆ(124.216)]

역시 형님입니다 동의합니다

[ㅆㅇㅆ(124.216)]

이런게 아무래도 과거의 경험과 지금의 경험차이로 인해서 생기는 문제인것 같아요

[ㅆㅇㅆ(124.216)]

환경의 차이인데 간과하기 쉽지. 형님의 조언 기억해두겠습니다

[익명(211.235)]

Tdd는 당시에 혁명이었고, 테스트 유닛으로 관리하는건 지금도 훌륭한 방법임. 다만 테스트는 비용문제가 커서, 실전에서는 잘 안쓰이는데 주니어들은 테스트 유닛을 써보면 좋음. 특히 레거시 코드를 다루면서 리팩토링 할때 좋음

[익명(211.235)]

머리로는 틀리지 않다는걸 알지만, 기존 코드를 수정을 해서 생기는 강박적인 불안감을 줄여주고, 테스트 가 실수를 잡아주니까 주니어들에게 추천

[ㅆㅇㅆ(124.216)]

기억해두겠습니다. 저도 일단은 비슷한 테스트 자체를 모아서 테스트를 자동화하는 식으로 해야하는데 선뜻 손이 가지 않네요

[ㅆㅇㅆ(124.216)]

일단 기본적으로 제네릭으로 컬렉션 테스트 같은것만 만들어놨는데 아직 감이 안잡힌다고 해야할까요. 이런 부분은 아무래도 독서가 아닌 경험적 영역에서 형성되는 것 같습니다. 경험으로만 엮일 수 있는 부분을 알려주셔서 감사합니다. 옵시디안에 기록해두고 공부해보겠습니다