220726 TIL

📝TIL, 느낀 점

✅ 공부

• Javascript
  • Westagram 피드 페이지, 댓글 기능 완성
    • 로그인 페이지는 간단해서 금방 만들었지만, 피드 페이지는 레이아웃이 나누어져 있어서, 생각보다 오래 걸렸다. css html 다루는게 쉽지 않다.
    • 실력을 늘리는 방법을 정확히 모르겠다. 뭔가 작은 능력들이 모여서 큰 능력이 만들어진다는 개념보단 그냥 프로젝트를 많이 해보면서 경험하는게 거의 유일한 방법인것 같은데… 맞..나??
    • 일단 많은 프로젝트를 하면서 경험을 쌓는게 우선이라 생각하고 그 방향으로 갈 예정
  • 공부 방법이나 클래스 명 정리하는 법, 레이아웃 짜는 법 등에 대해 전반적으로 멘토님께 질문드렸다.
    • 금요일에 진행하는 리팩터링 교육자료에 네이밍에 대한 내용, 레이아웃 짜는 과정 등에 대해 개략적으로 설명이 되어 있더라. 잘 읽어봐야겠다.
• CS 지식
  • DB
    • Q) 알러지들을 그냥 String형태로 “우유,대두” 이런식으로 한 컬럼에 넣어도 되지 않나요?
    • A) 그렇게 해도 됩니다. 다만 String이 아니고 JSON형태로 넣겠죠.
    • 근데 그렇게 하면 RDBMS의 장점인 데이터 안정성, 관계성 등을 포기한다는건데 그럼 차라리 No-SQL 쓰는게 맞지 않나 생각합니다.
• LeetCode
  • (LeetCode) 387. First Unique Character in a String (Easy)

😊 일상

🗺️ 좋은 글

<소프트웨어 장인> - 로버트 c. 마틴

페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다. 개발자가 테스트를 작성하거나 변수 이름을 짓는 순간 다른 개발자가 즉시 “이 부분은 이해가 안 됩니다. 어떤 의미죠? 변수명을 notLoggedIn이 아니라 guest로 바꾸면 어떨까요? 이 메서드는 하나가 너무 많은 일을 합니다. 몇 가지 private 메서드로 분할하면 어떨까요?”라고 말하며 유지보수 용이성과 명료성에 대해서 피드백을 한다.

같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

💡내 생각

• 내 코드를 다른 사람들에게 리뷰 부탁하며 배워봐야겠다.

🚀🚀개선 점 및 계획

• 종이에 전반적인 레이아웃과 클래스명을 대강 지어놓고 시작하는게 훨씬 좋은것 같다.
  • 1) 전체 구조가 한눈에 보여서 좋고
  • 2) 그때 그때 필요할 때 클래스명을 짓는거 보다 전체 구조에 맞게 미리 클래스명을 지정해두는게 맞는것 같다.
  • 3) CSS 작업할 때 HTML 문서를 파악하는데 걸리는 (어찌보면 쓸데없는 시간낭비) 시간을 현저히 줄일 수 있다.
• 사실 이 방법을 개발 입문 때 HTML/CSS를 배울 때 사용했던 방법인데, 효과적인 방법이라는걸 잊고 있다가 다시 작업을 하면서 이 방법이 생각났다. 아주 좋은 방법이므로 앞으로 계속 사용해야겠다.