Frontend 세미나 0 과제 공통 피드백

[woohm402]

다들 세미나 0 과제 진행하시느라 수고 많으셨습니다!

채점이 다 끝나진 않았지만 일찍 제출해주신 분들 기준으로 채점이 반 정도 진행되었습니다. 대부분 처음 해 보시는 언어가 무려 세 개였을 텐데, 잘 해 주셨고, 아주 수고하셨습니다 :)

채점 중에 발견된 공통 피드백 목록 전달드립니다. 틀린 내용에 대한 이야기이기 때문에 말투가 다소 까칠? 할 수 있는데, 미리 양해 부탁드립니다 🙏

---

피드백

대부분 분들이 틀리신 내용

• 코드 컨벤션을 잘 지켜주셔야 합니다.
  • 인덴트를 잘 지켜주시기 바랍니다.
    • 정말 별 거 아닌 것 같지만, 인덴트는 코드 가독성의 근본이 되는 단계이고, 현업에 나가 보면 생각보다 "아주" 중요하고, 기본 중의 기본으로 취급됩니다. 실제로 printf("hello"); 라고 안 짜고 printf("hello"); 라고 짜는 사소한 것마저도 코드 리뷰에서 걸립니다.
    • 인덴트는 prettier 나 IDE에서 기본적으로 제공하는 기능 등을 이용하면 자동으로 적용되기 때문에, 수동으로 하나하나 건드리기 귀찮으신 분들은 한번 알아보시는 걸 추천드립니다.
    • 이 부분은 앞으로 어디서 어떤 일을 하시든, '코딩'을 하시게 된다면 아주 중요하게 다뤄지는 부분입니다.
  • 변수명 등 네이밍을 잘 해 주시기 바랍니다.
    • 이유는 위의 인덴트의 내용과 비슷합니다.
    • html의 class는 보통 kebab-case 형식으로 이루어지고, camelCase를 사용하는 곳도 어느 정도 있는 것 같습니다.
    • 자바스크립트는 보통 camelCase를 사용합니다. (React Component 이름은 PascalCase를 사용합니다)
    • 변수명은 항상 의미있게 지어주시기 바랍니다. 가령 a 같은 변수는 아주 나쁩니다. '이름을 입력하는 인풋' -> nameInput 등이 적합하겠죠.
  • 또한 대부분의 개발자가 애용하는 컨벤션이 있는데, 이걸 따라 주셔야 합니다. 더해서 각 팀에서 정하는 컨벤션도 따라 주셔야 합니다. 협업의 단계로 들어갔을 때, 취향 차이로 인해 깃에 체인지가 생긴다든가.. 하는 상황은 매우 좋지 않습니다. 다른 팀원들과의 불필요한 논쟁이 생기고, 코드를 컨트롤하기 어려워집니다. 그러면 연봉에도 영향이 가겠죠 아무튼 요지는, 일단 여러분은 팀에 속해 있지 않기 때문에 개인의 취향대로 구현해 주시면 됩니다. 하지만 필수적으로 본인 코드 안에서는 통일된 방식을 사용해 주세요. 그리고 여유가 되신다면, 일반적인 프론트엔드 개발자가 사용하는 방식을 찾아봐 주세요. 참고차 리액트 컨벤션 중 가장 유명하고 널리 사용되는 에어비엔비 자바스크립트 컨벤션과 에어비엔비 리액트 컨벤션 링크 드립니다.
  • 간단하게 아래 예시를 들 수 있을 것 같습니다.

<!-- BAD -->
<div class= "example">
<p class = "example2" >대충 내용</p></div>

<!-- GOOD -->
<div class="example">
  <p class="example2">
    대충 내용
  </p>
</div>

반 정도 분들이 틀리신 내용

• PR을 잘 날려 주시기 바랍니다.
  • 절차를 정확하게 지키셔서,
    1. 메인 브랜치에서 브랜치 분기 (브랜치 이름은 자유이나, assignment-1 이나 뭐 그런 식이 좋을 것 같습니다)
    2. 해당 과제의 내용 작업
    3. 메인 브랜치로 PR
    4. 세미나장 또는 TA의 리뷰 받고
    5. 머지
  • 이 과정을 꼭 지켜주시기 바랍니다. 세미나 0의 경우는 큰 의미 없었지만 세미나 1 과제부터 세미나 5 과제까지는 한 레포에서 계속 진행될 예정이기 때문에, 꼭 지켜주셔야 합니다!
• 엔터키 입력을 keyCode === 13 으로 구현해 주신 분들이 많았는데, keyCode 속성은 deprecated 되었습니다.
  • MDN 을 참고하시기 바랍니다.
  • 내가 모르겠는 내용에 대해 구글링을 했더니 해답이 있고 그걸 적용했더니 잘 된다! 까지 가셨으면, 절대 거기서 멈추시면 안 됩니다. 그게 왜 되는지, 내가 뭘 짠 건지에 대한 공부를 항상 해 주셔야 합니다. 특히 프론트엔드의 경우 막 짜도 돌아는 가는 경우가 많아서, 잠재적 버그 덩어리인 코드가 생기게 됩니다.
  • 세미나 1 과제부터, deprecated된 속성이나 라이브러리 등을 사용하시는 경우는 오답으로 간주될 수 있습니다.
• '같다'에 대한 비교는 분명한 이유가 있지 않다면 == 말고 ===를 사용해 주세요.
  • ==는 타입에 대한 비교를 하지 않습니다. 자바스크리트에서 ==는 아주 위험한 연산인데, 가령 0 == '' 가 true입니다.
  • 따라서 ==는 잠재적인 버그를 아주 많이 담고 있을 수 있습니다. 실제로 제가 프론트엔드 개발 일을 하면서 겪은 ==로 비교하는 상황은 x == null 말고는 없었습니다.
  • 때문에 ==를 이용해 비교를 하실 거라면, 무슨 코드를 짠 건지 확실히 알고 해 주셔야 합니다.
• css 선택자로 태그를 막 사용하는 건 좋지 않습니다.
  • css를 작성하실 때, html 원소에 class 속성을 따로 주기 귀찮기도 하고 코드 가독성도 좀 떨어져 보이는 등의 이유로, 프론트엔드 개발자라면 p { width: 180px; color: blue; } 처럼 class 를 따로 작성하지 않고 태그를 css 선택자로 사용하고픈 욕구가 막 생기게 됩니다.
  • 하지만 코드의 의미를 생각해 봤을 때 이는 내 어플리케이션의 모든 p태그의 디자인을 아래와 같이 세팅해 라는 의미를 가집니다.
  • 때문에 예상치 못한 다른 element에 스타일이 적용될 수 있고, 이를 고치기 위해 그 element에서 또 다른 className을 적용하고, ... css가 왜 그렇게 적용되었는지 디버깅하는 건 더 어려워지고, 그렇다고 예전 걸 바꾸자니 다른 element에서 버그가 생길까봐 무섭고.. 하는 악순환이 생깁니다.
    • 말로 설명하기가 쉽지는 않은데, 이 상황을 직접 겪게 되신다면 "아 처음부터 다시 짜고 싶다" 하는 생각이 드실 거예요
  • 때문에 css 선택자는 항상 class나 id를 사용하시는 게 코드 유지보수에 용이합니다.
  • 실제로 Css Module이라는 기술이 있는데, 이 기술은 극단적으로 모든 className 을 unique하게 만들어버립니다. 개인적인 취향이지만, 저도 프로젝트를 진행할 때 이 기술을 이용합니다.
  • 물론 li { list-style-type: none; } 처럼 의도적으로 앱 전체에 적용하는 스타일은 문제가 되지 않습니다.
    • 이런 경우 global.css 등의 파일을 만들어 거기에 "전체에 적용할 스타일"을 몰아넣는 구조가 일반적입니다.

기타

• 세미나 0의 취지 상 코드 퀄리티가 낮아도 스펙에 맞게 잘 돌아가면 통과를 드렸습니다. 세미나 1 과제부터는 코드 퀄리티도 어느 정도 채점에 반영될 예정입니다. 때문에 과제 진행 중 본인의 코드가 좋은 구조인지 모르겠다면, 이슈를 올리거나 하셔서 같이 고민해 보시는 게 좋을 것 같습니다.
• 본 이슈에서 언급드린 모든 내용은 다음 과제의 스펙입니다! 즉 본 이슈에서 말씀드렸는데 다음 과제에서 지켜지지 않은 내용은 과제 스펙이 지켜지지 않은 것으로 간주됩니다.

---

그럼 다들 세미나 1 과제도 화이팅입니다! 😄

본 피드백에 대해 질문이 있으시다면 댓글로 편하게 질문 주세요!