실용주의 프론트엔드 개발 리뷰 Part.7

실용주의 프론트엔드 개발을 읽고 느낀점을 써봤습니다.

1. 에러 처리 정리

• 같은 타입으로의 반환

  • 함수가 실패하더라도 같은 타입으로 반환하는 안전망을 까는 것이 좋은것인지는 모르겠다.
  • 정말 then()을 통해 빈 값이 돌아오는지, 중간에 오류가 나서 빈 값을 리턴하는지 캐치하기가 쉽지 않아 보인다.

• 에러 처리의 주체

  • 프론트? 서버? 누가 할지에 따라, 코드를 짜는데에도 영향을 미친다고 생각한다.

• 하나의 이벤트를 실행할 때, 여러 함수로 쪼개는 것이 좋아보인다.

  • Ex) “클릭시 파일을 다운로드 한다.” 라는 이벤트를 실행시킬때,
  • “클릭한다”라는 컨테이너 함수와 “파일을 다운로드 한다”라는 함수로 나누어서 처리를 하는 방법
  • “파일을 다운로드 한다”함수를 좀 더 재사용성있게 다룰 수 있고(더 쪼개거나), 실패에 대한 케이스를 정리하는데에도 편할 것 같다.

2. 소프트웨어의 핵심 비기능 요구사항

• 개발자에게 개발 하는 것도 중요하지만, 요구사항을 파악하는 것도 중요하다고 생각한다.

  • A 기능을 만들어 달라 했는데, 이해를 잘못해서 A+를 만들어 버린다면…;
  • 리팩토링, 재사용성 등을 고려해서 개발하는 것도 중요하다.

• 다른 개발자가 보고, 이해하고, 수정하기 쉽게 개발하는 방법을 고민해야 겠다.

  • 변경 용이성
  • 상호 운용성
  • 효율성
  • 신뢰성
  • 테스트 용이성
  • 재사용성

3. 재사용 가능한 코드 개발

• 기존 코드를 볼떄마다 느끼는 거지만, “왜 내가 이렇게 코드를 만들었지?” 라는 생각(후회)가 든다.

  • 고치기라도 쉬우면 다행이지, 나도 이해못하는 코드는 GG

• 기능 개발을 하는데 있어서, 기획 내용이 부족하다보니 요구사항 분석 및 정리를 하나하나 작성하고 있다. 하다보니 여러가지 장점을 느낄 수 있었다.

  • 자체 QA를 하는데 편하다. -> 완벽도가 높아짐.
  • 해당 기능에 대해 완벽하게 이해할 수 있다. -> 다른 사람에게 설명하기 편해짐
  • 개발하는데 있어서 좀 더 재사용성을 고민하게 된다. -> 중복되는 기능들을 처리하기 쉬워짐
  • 히스토리가 남는다. -> 다른 사람이 이 기능을 보더라도 왜 그랬는지 문서만 보면 됨.

결론

• 에러처리의 주체를 정하고 일관성 있게 가는것이 좋다고 생각한다.
• 재사용성에 대한 고민은 항상 가지고 있어야 한다.
• 기획이 부족할 수록 개발 관련 문서를 잘 남기자. 그래야 내가 편하고, 당당해진다.