디비 스키마.
내가 다니는 회사 팀 리더는 맨날 코드리뷰만 졸라하는데
나랑 관점이 너무 다르다.
나는 코드 오류야 말로 가장 작은 오류라고 생각함.
디비 스키마 짜는 것이야말로 가장 중요하다 생각하는데 지금 리더는 말로만 알았다하고 너무 생각이 다르다.
+쿼리 최적화
디자인패턴.
사실 날 코딩이 제일 편함.
그렇지만 미래의 나를 위해, 혹은 현재의 협업자를 위해
일관된 패턴을 약속하고 그 기준을 지키려는 노력이 필요.
지금 회사는 이것도 없음. 좆소라서 그런 듯.
그 다음이 코딩...
난 코딩이 제일 중요도에서 낮다고 본다.
가장 중요한 건 디비 뼈대. 그리고 뼈에 살 붙이기직전에 어떤 식으로 살을 붙일지에 대한 룰.
이라 생각함.
이직하고싶다.
내가 다니는 회사 팀 리더는 맨날 코드리뷰만 졸라하는데
나랑 관점이 너무 다르다.
나는 코드 오류야 말로 가장 작은 오류라고 생각함.
디비 스키마 짜는 것이야말로 가장 중요하다 생각하는데 지금 리더는 말로만 알았다하고 너무 생각이 다르다.
+쿼리 최적화
디자인패턴.
사실 날 코딩이 제일 편함.
그렇지만 미래의 나를 위해, 혹은 현재의 협업자를 위해
일관된 패턴을 약속하고 그 기준을 지키려는 노력이 필요.
지금 회사는 이것도 없음. 좆소라서 그런 듯.
그 다음이 코딩...
난 코딩이 제일 중요도에서 낮다고 본다.
가장 중요한 건 디비 뼈대. 그리고 뼈에 살 붙이기직전에 어떤 식으로 살을 붙일지에 대한 룰.
이라 생각함.
이직하고싶다.
도메인 설계는 중요하다고 생각하지만 RDB만 주구장창 잡고 있을게 아니면 1은 좀 유연해질 필요도 있지 않을까요
스키마는 이미 개발에 들어간 순간부턴 건들기도 힘들잖아요
그리고 코드리뷰가 코드의 오류를 발견하는 목적도 있지만 2의 목적을 달성하기 위함이 큰 거 같은데
조오금 일반화를 시켜서 적합한 자료구조는 중요하다구 생각합니다
ㄴ그니까 가장 중요하죠. 코드야 고생스럽게 고쳐나가는게 가능하지만, 스키마는 서비스 중단하지않는 이상 현업에서 실서비스중인 스킴을 변경하는 것은 거의 불가능. 컬럼추가하는 정도야 어쩔 수 없지만. 아에 뼈대가 ㅄ처럼 돠어있는데 주구장창 코드 오류만 지적하는 사람이 많음.
설계 단계에서의 중요성은 매우 크다는 거에 동감합니다 ㅇㅇ 개발 입장에서도 꼬인 스키마 때문애 돌아가는 경우가 너무 많아서
거긴 코드리뷰 어떻게 돌아가요? 남들은 어찌하나 궁금하네 거기서 지적하는 오류라는 건 어떤거에요?
거의 뭐... 중복코드 줄이고... 불필요한 디비호출 발견하고... 이상하게 쓰인 루프문... 개선하고.... 필요하면 새로운 클래스로 분기하고... 머 그러고있습니다.
웹땔감dz//거에요->거예요 (받침 있으면 이에요 없으면 예요 이로 끝나면 받침 없으므로 예요 요 떼서 말 되면 에요 아니에요는 예외 인명엔 예요(예 : 길동이예요) 성까지 쓰면 이에요(예 : 홍길동이에요)) [리듬 맞춤법 봇♬]