사실 저도 엄격하게 컨벤션을 지키는 타입은 아니고, 적당히 적당히~하는 편이었는데
어쩌다 컨벤션이 전혀 안지켜진 코드를 보게 되었습니다...
한 클래스 안에 파스칼 케이스, 스네이크 케이스, 카멜 케이가 뒤섞여 있는것은 양반이고 Abc_def_GH 같은 작명법에 전혀 규칙이라고는 안보였습니다...
url도 restful에서 굳이 쓰지 말라는 동사를 넣는 것은 기본에 모든 메서드는 POST로 통일 되어있고... url 경로도 왜 이렇게 했는지 이해할 수 없어요... (ex. /board/create_board)
보안문제 때문에 delete, update는 POST로 퉁치는 경우가 있다고는 들었는데 조회까지 POST쓰는건 못들어봤어요...
가독성은 둘째치고 너무 근본없어 보이더라구요...
네... 이번에 입사한 저희 회사 코드입니다ㅠㅠ
하지만 이와는 별개로 url 상에서 동사를 쓰는 점과 조회를 POST 로 하는 경우는 어쩔 수 없는 경우가 한번씩 있습니다.
모든 엔드포인트를 restful 하게 만들 수 있다면 좋겠지만 그렇게 하기에 restful 의 표현 한계가 너무 명확해서요. POST 조회의 경우에도 지원해야 하는 조회 조건이 query params 로는 도저히 감당히 안될만큼 복잡한 경우에는 어쩔 수 없구요
대략적인 설명을 들었는데, restful api를 프론트와 백을 분리하면 restful인걸로 이해하고 있는것 같아요...
개인적으로는 이미 개발 완료된 코드도 계속 리팩토링 합니다만, 그렇지 못 했다면 나름의 이유가 있을지도 몰라요.
그게 이어져 온것 같습니다 ㅎㅎ...
레거시 코드도 BOOL 쓰다가 bool 로 바꾸면서 수정하다보니 짬뽕이 되어 버리고 있습니다.
사실 기능상으로는 전혀 문제가 없지만 코드 퀄리티가 떨어져 보이더라구요... ㅠ
아예 linter와 precommit 등을 githook과 pipeline에 연동하는등 좀 강제성이 있는게 좋은것 같습니다.
컨벤션을 맞춰야 할거 같은데 신입 개발자의 말을 들어 줄까요...? ㅠㅠ
front에서 back으로 보낼 때, 다같이 맞춰서 snake로 보낼지, 아니면 back에서 camel을 snake로 변경할지
뭐 별거아니지만, 이런 부분에 대해 합의가 없으면 계속 규칙없이 만들어지는거 같아요
저도 포폴 하면서 조금 애매하긴 한것 같다고 저도 생각하긴 했습니다.
프론트는 둘째치고 DB에서는 스네이크 케이스가 주로 사용되는데,
JPA에선 알아서 변환해주는 걸로 알고 있는데, 마이바티스에서는...
그래도 혼용해서 쓰는건 아닌거 같아욬ㅋㅋ쿠ㅜㅜㅜ
제가 이번에 리팩토링한(이라 쓰고 사실상 새로만든) 코드는 메인함수에 모든게 들어가있으며
변수명은 temp1, temp1_temp.. 함수는 tmp_func1,2,3() 이런식에 주석, 문서 다 없는 코드도 있었네요. ㅎ..
윗분들 말씀처럼 근본없는 코드도 보다보면 나름 그렇게 만든 이유가 있겠지만,
보통은... 이유가 없거나, 귀찮아서.. 같은 이유가 많..
그것보다는 아마 당장 수정하고 보수하지 않는건 예전부터 이어오는 코드에
그걸 수정하고 고치는 동안 새로 만드는 것이 낫다고 판단해서 인 것 같네요.
현 시점에선 신규 개발 필요없이 그냥 버그 생긴걸 고치는 수준에 돌아가는걸로 만족하는 프로젝트일지도요...