내일배움캠프 TIL 23/10/27

DRY 원칙

이 원칙은 Andy Hunt와 Dave Thomas가 쓴 The Pragmatic Programmer에서 공식화 되었습니다. "모든 지식 조각은 시스템 내에서 하나의 모호하지 않고 권위 있는 표현을 가져야 합니다"라고 (Every piece of knowledge must have a single, unambiguous, authoritative representation within a system")하여 정보의 반복을 줄이려는 소프트웨어 개발의 기본 원칙입니다. Don't Repeat Yourself

DRY 원칙의 장점

• 코드가 단순해지며, 한번만 작성할 수 있다
• 한 곳에서만 코드를 변경하고 모든 인스턴스들에서는 변경사항만 확인할 수 있다
• 시간과 노력이 절약되고 유지 관리가 쉬우며 버그 가능성도 줄어 든다

그래서 갑자기 DRY원칙을 거론한 이유는?
CSS가 자꾸 꼬이는 이유가 궁금했기 때문!
처음 쓸 때야 폰트 스타일도 수정해보고 마진값도 줘가며 위치를 맞춰줬는데 어느새 시간이 지나면 뒤엉켜있는 것을 확인할 수 있고, 다른 사이트에서 css형태를 복붙해도 원하는 형태가 되지 않거나 분명히 복붙한 값이 있는데 마진값이나 색깔에는 전혀 영향을 못주는 형태를 매우매우 빈번하게 겪을 수 있다. 애초에 CSS는 사람이 보기 좋은 형태가 아니고 DRY원칙도 거의 무시하기 때문에 CSS 예시를 보거나 직접 사용할 때도 코드의 비효율적인 반복이 지속적으로 발생한다. 그래서 나온 것 중 하나가 SASS(Syntactically Awesome Style Sheets), 문법적으로 awesome한 스타일 시트 또는 Sassy(쿨하다는 느낌?)한 CSS를 지향하며 만든 CSS 전처리기가 있다. 전처리기는 CSS가 만들어지기 전에 이런저런 일들을 먼저 처리해 주는 역할을 한다. 이러한 전처리기는 SASS 외에도 Less나 Stylus도 빈번하게 사용되는 것 같다. 뭔가 이러한 전처리기 문법들을 당장 다 살펴볼 수는 없겠지만, 나에게 중요한 건 이러한 전처리기를 사용하기 위해선 컴파일러를 설치해 컴파일링을 해 줄 필요가 있다는 것(각 처리기마다 사용방법이 다양하다)과 css를 검색하면서 많이 본 SCSS는 무엇인가하는 것

SASS vs SCSS

사실 SCSS = Sass라고 봐도 무관하다고 한다. 신경 쓸 차이점은 '문법이 살짝 다르다'는 정도. 파일의 확장자도 변경된다는 점이 눈에 띄는 차이점.

캠프에서도 프론트엔드 쪽에 너무 신경쓰지 말고 시간을 많이 쓰고 싶진 않지만, 눈에 보이는 부분이라 자꾸 신경이 쓰이는 건 어쩔 수 없는 것 같다. 이번 팀프로젝트는 금요일에 발표까지 완료되었고 내가 발표를 진행했는데, 발표 시작 10분전에 critical한 에러가 발생해서 매우매우 당황했다. 발표 스크립트를 짜놨는데도 제대로 활용하지 못했고 user쪽 에러가 발생해서 user 모델의 사용(로그인,로그아웃,회원가입 등등)을 일부러 배제한 것 외에도 기능 소개를 많이 빠트려서 팀원들이 고생한 걸 제대로 못보여준 것이 많이 아쉽다. 이외에도 kPT 회고를 작성했는데
https://velog.io/@alswo9872/%EB%A8%B8%EC%8B%A0%EB%9F%AC%EB%8B%9D-%EB%B0%A5%EC%B9%9C%EA%B5%AC-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-KPT-%ED%9A%8C%EA%B3%A0 에서 참고해보시면 좋을 것 같다.