아니 ㅋㅋ 어차피 버릴 코드를 테스트해서 뭐하냐
프로그램에서 라이브러리처럼 잘 안 바뀌는 저수준 코드들은 빡센 테스트나 심하면 증명까지도 할 수는 있는데
유스케이스에 가깝고 계속 변하는 고수준 코드들은 의미가 없음
TDD도 하지 말고 그냥 짜고 확인만 함
증명이고 테스트고 변하지 않는 무언가를 검증하는데
문제는 사용자가 써보기 전에는 뭐가 바뀌고 뭐가 고정되는지 확실하지가 않음
극단적으로는 A/B 테스트가 있음. 한쪽은 버려지는데 테스트를 넣겠냐구 ㅋㅋ
너무 많이 변하고 고수준이라서 테스트 짜는 게 수지가 안 맞는 경우는 그냥 어쩔 수 없는 거 같음
1)잘 검증된 부품들을 2)실수하기 어려운 방식으로 조합해서 유스케이스를 해결하는 코드를 짜는 것 밖에 답이 없는 거 같음.
그나마 빠르고 버그도 적은 방법이라 생각함
(물론 설계가 저런 조합이 가능해야 하고)
그러다가 어플리케이션이 좀 성숙하면 회귀테스트나 앱 전체를 검증하는 PBT도 넣고 그러면 될 듯...
테스트, 증명은 플머의 생각이 코드로 제대로 표현됬는지 확인하는 툴이라서
걍 생각 자체가 현실에 맞지 않을 때는 그냥 시간낭비가 됨
근데 어지간한 쌉고인물 도메인 전문가가 아닌 이상
사람 생각이란 게 현실이랑 늘 달라서 매번 대가리를 깨버리더라고
프로그램에서 라이브러리처럼 잘 안 바뀌는 저수준 코드들은 빡센 테스트나 심하면 증명까지도 할 수는 있는데
유스케이스에 가깝고 계속 변하는 고수준 코드들은 의미가 없음
TDD도 하지 말고 그냥 짜고 확인만 함
증명이고 테스트고 변하지 않는 무언가를 검증하는데
문제는 사용자가 써보기 전에는 뭐가 바뀌고 뭐가 고정되는지 확실하지가 않음
극단적으로는 A/B 테스트가 있음. 한쪽은 버려지는데 테스트를 넣겠냐구 ㅋㅋ
너무 많이 변하고 고수준이라서 테스트 짜는 게 수지가 안 맞는 경우는 그냥 어쩔 수 없는 거 같음
1)잘 검증된 부품들을 2)실수하기 어려운 방식으로 조합해서 유스케이스를 해결하는 코드를 짜는 것 밖에 답이 없는 거 같음.
그나마 빠르고 버그도 적은 방법이라 생각함
(물론 설계가 저런 조합이 가능해야 하고)
그러다가 어플리케이션이 좀 성숙하면 회귀테스트나 앱 전체를 검증하는 PBT도 넣고 그러면 될 듯...
테스트, 증명은 플머의 생각이 코드로 제대로 표현됬는지 확인하는 툴이라서
걍 생각 자체가 현실에 맞지 않을 때는 그냥 시간낭비가 됨
근데 어지간한 쌉고인물 도메인 전문가가 아닌 이상
사람 생각이란 게 현실이랑 늘 달라서 매번 대가리를 깨버리더라고
그런 의미에서는 테스트랑 증명도 차이 많이남. 테스트는 인터페이스만 유지되면 재사용할 수 있지만 증명은 구현이 바뀌면 다시 해야됨.
뭐임 왜그럼 어째서인데스
cpu 바뀌면 새로 짜야 함?
그건 증명 대상이 뭐냐에 따라 다름. 특정 cpu를 타겟팅한 프로그램에 대한 증명이라면 cpu 바뀌면 새로 해야 하지만, 증명 대상이 cpu와 무관한 하이레벨 프로그램이라면 상관 없지.
당연한 소리지만 구조화를 잘 해두면 일부의 증명만 수정해도 되긴 함.
증명 대상이라는 게 결국 증명 코드가 의존하는 인터페이스 아님?
어떤 A라는 대상에 대한 증명은 A의 인터페이스(혹은 A의 타입)가 아니라 A의 정의에 직접 의존함. 그래서 A를 수정하면 A에 직접 의존하는 증명들은 전부 새로 해야 함. 모든 코드를 첨부터 작성하는걸 막으려면 A와 A의 성질에 관한 증명들을 하나의 모듈 M으로 묶어두고, 이 모듈 바깥의 코드들은 M의 인터페이스에만 의존하는 식으로 작성해야 함. 그러면 코드가 깨지지 않는 최소 수정 단위는 M이 되겠지.
원래 구현과 증명은 하나임. 그럴 수 밖에 없는게 구현을 하면서 프로그래머가 생각한 논리를 명시적으로 작성해 놓은게 증명이니까.