20231201 TIL
오늘 프로젝트를 마무리하고 발표&피드백&KPT 작성까지 거쳤는데, 여기서 몇가지만 좀 뽑아봐야겠다.
1. Readme.md
아래 두 포스팅을 잘 참고해서 작성해 봐야 할 듯.
https://bulldogjob.com/readme/how-to-write-a-good-readme-for-your-github-project
2. 탭 활용에 대하여
사실 탭을 활용했을 때 편의성 측면에서 단점이 하나 있다.
버튼을 클릭해서 동적 요소를 생성하는 경우, 새로고침 후에 동적 요소가 나타나게 된다. 그런데 중간에 새로고침이 들어가다 보면, 동적 요소가 생성된 페이지가 아닌 우리가 웹 페이지에 들어갔을 때 처음 보는 화면으로 가게 된다.
요즘엔 많은 프레임워크들이 이런 문제들을 해결할 수 있게 도와주긴 한다. 간단하게 말하면 '그런 프레임워크들을 써서 작업하도록 하자!' 로 끝내면 되겠지만 그렇게 끝내면 이걸 적는 의미가 없음.
기능을 개발하는 것도 좋지만, 사용자의 편의성을 고려하지 않은 기능이라면 개발한 의미가 있을까 생각해 봐야 한다.
(조금 불편한 이야기일 수도 있지만, 사용자의 편의성을 고려한다는 의미는 무조건 사용자를 편하게 해준다는 의미가 아니다. 의도적으로 사용자를 불편하게 만드는 것으로 비즈니스의 목적을 달성하는 경우가 있다. 사용자의 편의성을 고려한다는 정확한 의미는, 사용자가 어떻게 하면 편해지고 어떻게 하면 불편해지는지 이 두 부분 다 알아야 한다는 것)
3. 암호화 & 권한
발표 중에는 채팅을 못봤는데 발표가 끝나고 나서 채팅 하나를 확인했다.
"이거 남들이 들어와서 아무렇게나 수정하면 어떻게해요?"
사실 일반적인 서비스를 만든다고 하면 무조건 고려해야 하는 부분이 맞다. 갑자기 어떤 사람이 쇼핑몰에 들어와서 20,000원인 옷값을 갑자기 2원으로 바꿔버렸는데 담당 개발자가 눈치챈 시점이 이미 늦었다면 그건 진짜 대참사가 맞다.
물론 이번 프로젝트 중에는 별로 고려하지 않은 부분이긴 하다. 그냥 페이지에 어떤 기능이 있다를 보여주는 것이 주 목적이었고, 보여주고 싶었던 기능들을 보여주려고 하면 개발기간이 더 걸릴 것 같아서 기획단계에서 그냥 제껴버림
하지만 '내가 서비스를 출시할 개발자라면' 의 관점에서는 절대 놓쳐서는 안된다. 그래서 채팅 쳐주신분께 감사한 생각이 든다.
4. Git Commit Message Convension
아래 포스팅을 잘 참고해 보자.
https://velog.io/@msung99/Git-Commit-Message-Convension
5. 기획단계에서 반성할 것들
솔직히 여기가 제일 많은듯. 그동안 기획자로 진행했던 프로젝트들이랑 비교하면 규모가 많이 작아서 "적당히 해도 되겠지 뭐~"하면서 방심했던 부분도 있을 것이고, 개발자 시점에서는 어떻게 규약을 정하는 게 좋을지까진 잘 몰랐던 것도 있겠다.
5-1 프로젝트 내의 명명 규칙 정하기
프로젝트를 진행하면서 변수명 등을 지정하는 규칙이 개인마다 다르다 보니, 오브젝트를 찾아 이벤트를 구현하는 코드를 짤 때 어려움이 있었다. 물론 모든 명명 규칙을 완벽하게 통일하는 것은 어렵겠지만, 자주 사용하는 변수, 클래스 같은 것들은 미리 정해두고 들어가면 더 좋을 것 같다.
5-2 화면 기획을 처음부터 상세히 했어야
내 개인 뿐 아니다 다른 조원들도 마찬가지였는데 코드한번 짜보고 싶다고 화면도 적당히 만들고, 어떤 기능이 들어가는지 대충만 써놓고 코딩부터 들어갔다. 이런짓 때문에 프로젝트 제출기한이 늦어지기라도 했으면 과거로 돌아가서 내 뒷통수부터 한대 때리고 시작할듯
중간에 보충하긴 했지만, 처음부터 기능들을 명확히 정해놓고 작업했으면 "이 기능이 들어갔던가 말았던가?" 같은 짓은 안했을 것 같다.
