버그
찾기 어려운 버그.
쉽게 가자면 그 버그 그대로 가면 된다. 웬만해서는 찾지 못할 버그.
어렵게 가자면 버그 수정하고 그와 연계된 코드들 수정하고 시간들여서 하면 된다.
유연성 vs 정합성.
이번 건 DEMO를 위한 거라 시간도 촉박하고 DATA의 정합성보다는 유연성에 초점을 두고 개발을 하면된다.
근데 중요한 건 모든 프로젝트가 그렇듯이 CTRL + C -> CTRL + V 가 만연하고 시간에 쫒기기 때문에 다음에도 내가 하지 않으면 ( 내가 하더라도 시간이 있지 않으면 ) 버그 리포트가 나오기 전까지는 수정을 하지 않을 거다. 버그 리포트가 나오더라도 그때 즈음이면 연계된 코드들이 더 많을 테고 수정하는 데도 시간이 더 많이 걸릴거다. 그러면 결국 그대로 가거나 많은 리소스를 투자해서 수정하겠지.
하지만 결국 제품이 되었을 때 중요한건 DATA의 정합성. DATA 가 나오는데 내가 원했던 DATA가 아니라면 그건 분명 문제.
정말 이럴때는 무얼 선택해도 찝찝하다. 시간도 없도 코드도 복잡하고 DATA는 옳지 않고.
참 옳지 않다.
찾기 어려운 버그.
쉽게 가자면 그 버그 그대로 가면 된다. 웬만해서는 찾지 못할 버그.
어렵게 가자면 버그 수정하고 그와 연계된 코드들 수정하고 시간들여서 하면 된다.
유연성 vs 정합성.
이번 건 DEMO를 위한 거라 시간도 촉박하고 DATA의 정합성보다는 유연성에 초점을 두고 개발을 하면된다.
근데 중요한 건 모든 프로젝트가 그렇듯이 CTRL + C -> CTRL + V 가 만연하고 시간에 쫒기기 때문에 다음에도 내가 하지 않으면 ( 내가 하더라도 시간이 있지 않으면 ) 버그 리포트가 나오기 전까지는 수정을 하지 않을 거다. 버그 리포트가 나오더라도 그때 즈음이면 연계된 코드들이 더 많을 테고 수정하는 데도 시간이 더 많이 걸릴거다. 그러면 결국 그대로 가거나 많은 리소스를 투자해서 수정하겠지.
하지만 결국 제품이 되었을 때 중요한건 DATA의 정합성. DATA 가 나오는데 내가 원했던 DATA가 아니라면 그건 분명 문제.
정말 이럴때는 무얼 선택해도 찝찝하다. 시간도 없도 코드도 복잡하고 DATA는 옳지 않고.
참 옳지 않다.
