세상엔 배울 게 많다

velog 블로그에서 tistory로 이전한 데이터 입니다. - 2020-09-20 콘웨이 법칙이란? 시스템은 조직의 모습을 반영한다. “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” 콘웨이 법칙은 팀간 커무니케이션 구조, 서비스를 위해서 어떠한 과정과 절차가 있어야하는지 스스로 생각하게 해주는 법칙이다. 반면에 조직 커뮤니케이션 구조가 복잡하다면 시스템에 반영을 하게 되고 결국 더 어렵게 만든다는 관점도 존재한다. 나같은 경우 "구름"에서 사내 프로그램을 만들면서 효율적인 업무 추구를 지향하..

velog 블로그에서 tistory로 이전한 데이터 입니다. - 2020-09-20 디미터의 법칙이란? 소프트웨어 개발 가이드라인 중 하나 최소 지식 원칙 모듈 사이 결합도를 줄여 코드 품질을 높이자 아래 예시를 보자, Class 남자 { public String 데이트_코스_고르기(여자 여자친구) { if(여자친구.배.비어있다) { return 식당; } else { return 수족관 } } }여기서 "여자친구.배.비어있다"에 주목하면 남자가 여자친구의 배가 비어있는지 확인하는데 배가 Object에서 int로 바뀐다면? 여자친구 class가 수정될 때, 남자도 함께 수정해야된다. 디미터의 법칙에는 규칙이 있다. 규칙은 위키에서 확인하자. 원칙으로는 잘 설명하기 어려워 코드를 직접보면, Class 남자..

velog 블로그에서 tistory로 이전한 데이터 입니다. - 2020-9-20 1. 파레토 법칙(Pareto principle) 파레토 법칙은 80:20 법칙으로 알려져있는데 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 말한다. 이 법칙은 통계, 품질관리 등 여러 곳에서 사용되지만 나는 개발자니까 소프트웨어 측면으로 말해본다. 개발자마다 20:80 법칙을 바라보는 시각과 사용하는 용도가 다르다. 다른 개발자분들은 어떻게 생각하는지 찾아봤을 때, 개발자 1 엔터프라이즈용 개발을 할 떄, 고객의 요구사항에 맞춰 구축한다고 할 때, 소프트웨어 자체 결함보다 고객 관점이 잘못되어 있거나 조직의 비 논리적인 관행 등으로 프로세스가 잘못되어 있는 경우가 많았다고 합니다. 프로세스가 잘못되어 있는..

velog 블로그에서 tistory로 이전한 데이터 입니다. 2020-9-13 들어가기 전, 학부시절에 코드만 돌아가면 ㅇㅋ? 라는 생각을 주로 했다면 이제는 바뀔 때가 되었다고 생각한다. 왜냐하면 개발자로 살아간다면 코드는 계속 만들게 될텐데 계속 규모가 커지는 코드만 작성할 수는 없기 때문이다. 점진적인 개선이 왜 필요할까? 처음부터 우아한 코드를 한번에 만들어 낼 수 없다. 책에서는 프로그래밍은 과학보다 공예에 가깝다고 한다. 깨끗한 코드를 작성하려면 지저분한 코드를 작성한 뒤에 정리해야 한다는 것이다. 하지만, 쉽게 따르기엔 너무 어렵다. 무조건 돌아가는 프로그램을 목표로한 초기 개발자(나)는 프로그램이 '돌아가면' 다음 업무로 넘어간다. 하지만 이는 곧 자살행위와 같다. Proto..

velog 블로그에서 tistory로 이전한 데이터 입니다. 들어가기 전, 대다수가 가장 원하는 "깔끔한 코드" 하지만 과연 내 코드가 깔끔한 지 쉽게 알 수가 없다. 정확한 의사를 표현해 코드리뷰를 받으면 낫다고 판단했다. 깔끔한 코드를 구현하자 켄트 벡이 제시한 단순한 설계 규칙 (아래로 갈수록 우선순위 낮음) 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머의 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다 단순한 설계 규칙을 따르면 저절로 소프트웨어 품질을 크게 높여줄 것 같다고 생각한다. 왜 그게 가능할까? 아마도 "모든 테스트를 실행한다" 부터가 SRP를 지킨 코드이기 때문이라고 본다. 1. 모든 테스트를 실행하라 설계를 해서 코드를 작성하면 당연히 의도대로 돌아가야 한다. 하지만 검증..

velog 블로그에서 tistory로 이전한 데이터 입니다. 들어가기 전, Clean Code 11장 시스템을 읽으면서 중요하다고 생각하는 점을 적어봅니다. 의사결정을 최적화 하라 EJB2에서 EJB3로 넘어오면서 많은 게 바뀌었다고 생각한다. 요즘 Spring을 개발할 때, EJB3 형태로 XML 설정과 Annotation을 이용해 손쉽게 개발하느라 이전의 형태를 보고 많이 놀랬다. 이전코드에서 TDD를 실천해온 개발자들이 정말 대단하다. EJB2때, 목적에 따라 코드를 수정해야 되는데 테스트 케이스를 작성한다면 모든 코드를 건드리게 된다. 위험성이 높다. 소프트웨어를 개발할 때, BDUF(Big Design Up Front)를 추구 하지말자. 오히려 아키텍처의 틀을 정해버리는 행동으로 향후 지속적인 ..