Mar 9, 2018 - POP_part26

법칙 - 프로그래밍 안티패턴

깨진 유리창 법칙

빌딩같은 건물에 수리되지 않은 깨진 유리창이 한 장이라도 있다면, 사람들은 빌딩 주인이 자기 건물에 관심이 없는줄 안다. 이렇게 되면 곧 다른 유리창도 깨진다. 그리고 건물 전체에 심각한 파손이 일어난다. 소프트웨어도 똑같은 현상이 일어난다. 소프트웨어에서 깨진 유리창 즉 나쁜 설계, 잘못된 의사결정, 나쁜코드를 방치하면 그것이 아무리 작은것이라도 소프트웨어 전체를 단기간에 부패시킨다.

나쁜코드는 사심을 끌어낸다. 깨진유리창이 조금이라도 있다면 나머지 코드도 엉망진창일테니 나도 적당히 대충작업하자라는 생각을 한다.

코드는 청결하게 유지한다 깨진유리창이 있음 발견즉시 복구시키자 수정할 충분한 시간이 없을때는 코드가 좋지 않다는 취지를 알기 쉬운 곳에 명시하자.

깨진 유리창 현상은 도덕성의 저하와 같은 습관적인 나태에 장기적으로 노출되고 이를 모방함으로써 악의 연쇄가 발생하고 있을 가능성을 시사한다.

엔트로피 증가의 법칙

엔트로피란 물리학 용어로 무질서한 정도를 나타낸다. 열역학 법칙에 따르면 모든 우즈의 엔트로피는 증가해 간단는 사실이 증명되어 있다.

코드는 무질서로 향한다 이건 자연스러운 경향이다. 그래서 유지보수하기 어려워진다.

코드 부패의 징후

  • 경직됨
  • 깨지기 쉬움
  • 이식성 없음
  • 다루기 어려움
  • 복잡함
  • 반복
  • 불투명함

애자일로 부패를 허용하지 않는다

팀문화로 부패를 허용하지 않는다

80:10:10

프로그램에 만병통치약은 없다. 고수준의 툴이나 언어를 사용해 소프트웨어를 개발하면 사용자 요구사항의 80%는 단기간에 개발할수 있지만 나머지 20%중 10%는 노력이 들어가야 되는거고 10%는 완전히 실현 불가능하자.

프로그램의 문제영역은 너무 넓다. 툴 사용은 적재적소에 만병통치약보다 전문약

조슈아 나무의 법칙

이름이 없는 것은 보이지 않는다.

어떤사람이 자기가 오래 거주하던 마을의 도서관을 찾았다. 이사람이 식물도감을 보다가 조슈아 나무라는 이름에 나무가 있는지 처음 알았다. 사진과 설명이 있었는데 자긴 오래동안 마을에서 보지 못했다.그런데 집으로 돌아오는길 가는 곳곳마다 조슈아 나무가 있는것이아닌가

이름을 앎으로써 존재를 안다.

유비쿼터스 언어(공통의 언어나 개념)를 사용하자

바벨탑 신이 노해서 언어를 여러개 만듬 혼란을 가중시킴 그래서 유비쿼터스 언어가 필요함

세컨드 시스템 증후군

두번째 배포는 기능 과다

익숙해지면 다기능주의로

사용자 고려

  • 사용자는 누구인가?
  • 사용자는 무엇을 필요로 하는가?
  • 사용자는 무엇이 필요하다고 생각하고 있는가?
  • 사용자는 무엇을 바라고 있는가?

세컨드 시스템 이후에도 똑같은 경향으로 기능이 너무 많이 생길수도 있다 사용자는 기존기능이 정확하게 동작하는것을 원한다.

기능이 증가한 소프트웨어를 피처 크립이라고 부른다 파멸로 향하는 첫걸음이다.

수레바퀴의 재발명

이미 있는데도 만든다. 표준 라이브러리를 따르자.

수레바퀴를 재발명하는 패턴

  • 수레바퀴를 모른다.
  • 수레바퀴를 만들고 싶다

수레바퀴 이외의 것에 주력하자

만들고 싶어서 만드는것은 프로그래머의 욕심이다.

수레바퀴를 재발명해야 할때

  • 비지니스 목적
  • 학습목적

야크의 털깍기

야크는 털이 많은 소같은 동물인데 여름이 오기전에 털을깍을때 몸통에 도달할려면 상당히 많은 털을 깍아야 된다. 이것을 비유하면서 어떤문제에 해결할려고 봤더니 다른 문제가 계속나와 몸통에 도달하지 못하는 경우를 비유

문제는 줄줄이 사탕식으로 나온다.

빨리빨리 처낸다.

참조


Mar 8, 2018 - POP_part25

법칙 - 프로그래밍 안티패턴

브룩스 법칙

일정이 늦어지고 있는 소프트웨어 개발 프로젝트에서 지연을 만회하기 위해 후반에 사람을 추가하면 오히려 지연이 한층 더초래 된다. 맨먼스(man month)로 프로젝트 일정을 환산하는데 man과 month는 교환 불가능이다. 이유는 다음과 같다.

  • 종속 관계에 따른 오버헤드가 발생한다.
  • 교육하는 데 시간을 빼앗긴다.

일정이 지연되었을때는 일정을 재조정하라. 이때는 사용자와 조율을 통해서 기능에 우선도를 부여하고 단계적으로 배포한다.

생산성과 출산의 유사성

  • 프로젝트에 프로그래머를 늘렸다고 해서 소화할수 있는 작업량이 늘어나고 개발기간이 줄어드는건 아니다.
  • 출산과의 유사성은 10명의 임신부를 모아 놨다고 해서 1개월 만에 아기를 출산할수 없어서 이다.

man과 month는 교환 불가능인다 man과 man도 다른의미로 교환 불가능이다. 프로그래머마다 질적인 차이가 있어서 이다. 프로그래머의 질적인 차이는 구체적으로 30배라는 설도 있다.

  • 가능과 불가능
  • 버그의 많고 적음
  • 실행 속도의 빠르고 느림
  • 코드의 읽기 쉬움과 어려움

콘웨이의 법칙

  • 아키텍처는 조직을 따른다. 하나의 컴파일러를 3개 팀이 편성되어 만들면 3단계의 컴파일러가 완성된다. 4개팀이 배벙하면 4단계의 컴파일러가 완성된다. 그래서 조직을 따른다.

  • 아키텍처는 의사소통을 따른다.

  • 아키텍처 설계 후에 조직을 편성하라. 아치텍처는 조직을 따라가지만 정답은 오히려 앞뒤가 반대이다. 조직에 상황에 따라 만들어진 아키텍처가 소프트웨어 관점에서 봤을때 최적일 리 없다.

  • 조직과 아키텍처의 상호 종속 돤계가 중요한데, 조직과 프로세스에도 궁합이 있다. 기술분야로 팀을 조직(데이터베이스팀, 웹서버팀, 테스트팀)하고 애자일프로세스를 실행하면 그 조직은 개고생하고 애자일이 무색하게 증분에 작은 배포를 거듭하는 방식은 현실적이지 못하다.

참조


Mar 5, 2018 - POP_part24

관점 - 프로그래머가 보는 시각

개밥먹기

자신이 개발한 소프트웨어를 직접 사용해 봐야 된다.이렇게 되면 사용자의 관점을 얻을수 있다. 본인이 사용해서 편리함을 증명해야된다.

고무오리

디버깅 기법이다. 발생한 문제를 누구한테 설명하므로써 문제의 원인을 스스로 깨닫고 자체 해결할수있다.자체 해결을 촉진한다. 무생물에게 먼저 적용하는게 효과적이다. 왜냐 하면 다른사람의 시간을 뺏을수도 있기 때문이다 만약 동료에게 설명하고 싶으면 취지를 설명하고 양해를 구해야 된다.

컨텍스트

컨텍스트의 2가지 측면

  • 코드의 읽고 쓰기에 사용
  • 생각의 도구로 사용

의도를 확실히 표현하면 흩어져 있던 정보가 이어진다. 프로그램의 달인이라고 불리는 사람들이 패턴을 자유자재로 사용하는것은 패턴을 많이 알고 있어서가 아니라 어떤상황에 어떤 패턴을 사용해야 되는지 알고있어서이다. 코드를 작성할때는 먼저 컨텍스트를 제시하도록 하자.

남에게 작업을 지시할때도 컨텍스트가 중요하다. 프로그램의 달인에게 지시를 할때는 레시피나 규칙은 불필요하다. 컨텍스트를 구축할만큼에 정보만 전달해도 문제가 없다. 달인에게는 달성해야할 목적만 전달하면된다. 하지만 초보자들에게는 구체적으로 세세하게 지시를 해야 된다 그렇지 않으면 나중에는 지시가 형편이 없었다는 이야기를 들을수가 있다.

팀은 하이컨텍스트 지향으로 가야된다. 하이컨텍스트란 어느 공동체에서 배경이나 가치관등 많은 공동인식이 깔린 상태를 가르친다. 하이컨텍스트 문화에서는 의사소통을 꼭 말로 하지않아도 되는 소위 척하면 척이 통용된다.

코드 공통화는 컨텍스트 지향으로 2가지 유의해야 할 점이 있다.

  • 공통화한 부분에 개별적인 변경이 필요해지는 경우가 있다.
  • 공통화한 코드 부분을 수정하는 경우 영향도가 높아진다.

아리스토텔레스의 지식 분류

  • 에피스테네 - 보편적 진리 와 보편적 정당성을 가진 지식 현대 용어로는 과학
  • 테크네 - 먼가 창출해내고 만들어 내는 노하우 현대 용어로는 엔지니어링
  • 프로네시스 - 지식이라기 보다 실천적인 지혜

디버깅할때도 컨텍스트에 따라서 각각으로는 문제가 없더라고 관계의 의해 문제가 발생하는 경우도 많다.

참조