오늘은 월간 백엔드 회고와 스터디, 그리고 나만의 고민과 삽질이 있었다.
MDN 기여.....?
오늘은 월간 회고 & 스터디로, MDN 기여가 스터디의 주제였다.
대충 이러한 목적과 CTO님이 팀리드를 할 수 있게 되었을 때, MDN 기여를 하는 것이 꿈이었다며 해보자고 해서 ㅋㅋ
세부적인 방법이 적혀있었고, 나는 isArray()를 맡아서 최신화 작업을 하고 있었는데
조금 신기한 부분이 있어서 그 부분에 대해서 포스트를 따로 빼가지고 작성을 해볼 것 같다.
왜 이렇게 일하는거에요?
MDN기여가 끝나고 바로 종료를 하시려길래, 잡고 회고와 개선점(피드백) 시간을 달라하고 따졌다.
왜 이렇게 일을 하는거냐고.
지금 일처리 방식이 상당히 미묘한 부분이 있어서 대놓고 태클을 걸었고
열심히 반박을 당했다(?)
그러면서 흐음.....그렇구나 라는 생각과 함께 이게 정상이라고 생각하는지 의문을 가졌는데
업무가 끝나고 술자리에서 다양한 상황이 겹쳐있기에 일부로 강하게 나갔다고 하셨다. (이것은 비밀:>)
물론 나는 회사의 프로세스라고 잡혀있던 이해가 안가면 일단 물어보는 타입이고
개선점 타협점 등 다양한 요소를 가지고 안건을 던지는 사람이다.
어떻게 보면 회사의 입장에서는 조금 더 발전할 수 있게 만드는 사람이고
어떻게 보면 맨날 태클만 거는 사람이라고 볼 수 있어서, 호불호가 갈리는 유형의 사람이다.
근데 CTO님은 내가 이런 사람인걸 알고 뽑았고, 이런 것을 하길 바라셔서 나야 열심히 태클을 걸 생각이다.
CTO : 뮤님 태클 거는걸로 업무평가 각
나 : 리더님 저분좀 말려봐요
리더 : (이마짚음)
클린 코드란 무엇인가?
코드를 짜다가 의문이 생기더라.
해당 API를 사용하는 매니저분들이 편하도록 코드를 작성하려고 했더니
반복문, 조건문이 수없이 많이 들어가는 코드가 짜졌다.
그래서 머리를 감싸쥐고 있다가, 리더님한테 물어봤다.
저희가 짜는 코드라는 것은 어떻게 짜는 것이 좋을까요?
- 최대한 깔끔한 코드, 읽기 좋은 코드
- 코드가 조금 더럽더라도 사용자들의 편의성을 모두 갖춘 코드
결론은 당연히 후자였다.
그리고 짜는 사람마다 다른데 후자로 짜도 깔끔하게 짤 수 있다고 ㅋㅋ
(난 바보다)
흔히들 이야기를 하는 것이 있다.
완벽한 코드란 존재할 수 없다, 그러니 일단 정상적으로 작동하게 만들고 리팩토링해라.
딱 맞더라, 나도 일단 좀 더럽지만 작동하게 코드를 짜놓고 조금 빤히 보다보니 상당수를 줄일 수 있었다!
MySQL의 varchar Type은 null이 없다.
비즈니스 로직을 짜는데 이해가 안되는 부분이 발생했다.
값이 비어있는데 IS NULL | NULL 모두 스킵을 하는 것이였다.
그래서 찾아보니 MySQL에서 varchar Type에서 Nullable로 값이 없다면
Null이 아닌 ""로 인식을 한다는 것이였다.
이마를 부여잡고 아래처럼 고쳤다^^;;
CASE WHEN LENGTH(address) = 0 OR address = "-" THEN "${data.address}" ELSE address ENDDB를 쓰는게 좋을까? Node를 쓰는게 좋을까?
위에 SQL 코드는 조건문을 최대한 제외하려고 구성을 한 것이다.
기존의 로직은 if문이 상당히 많았다.
왜냐하면 세부주소가 비어있는지 검증을 해야했고
세부주소에 값을 넣느냐 안넣느냐로 구분을 했어야 했기에
if 중첩과 다양한 ORM 메소드들이 필요했는데, 그것을 위의 SQL 코드로 모조리 다 날려버릴 수 있었다.
그래서 조금 고민이 들더라
DB는 생각보다 스케일업을 하는 것이 어렵다고 들었던 것 같기도하고.. (아웃은 답이 없다)
그리고 Node가 싱글스레드라서 단순 연산은 상당히 빠르다.
문제는?? 보는 코드가 너무 더러워진다는 것인데... 이래서 조금 고민이 들더라
내일은 인천 창고로 출장을 가는 날이다.
이유는 단순하다!
도메인 로직을 짜는데 내가 이해가 안돼
직접 봐야겠다.
