2010-05-18 2 views
4

누구나 재사용 가능성에 대해 이야기하기를 좋아합니다. 내가 일하는 곳에서 새로운 아이디어가 던져 지거나 테스트 될 때마다 항상 재사용 문제가 제기됩니다. "우리는 이것에 대한 투자를 극대화하고 재사용 할 수 있도록 노력하겠습니다." "재사용 성은 더 적은 작업으로 더 높은 품질을 제공 할 것입니다." 등등.재사용 대 유지 관리 용이성 및 테스트 용이성

내가 발견 한 것은 재사용 가능한 구성 요소 또는 아이디어가 도입되었을 때 모든 사람들이 즉시 두려워하고 나쁜 생각으로 씁니다. 일단 애플리케이션이 그것에 의존하게되면, 유지 보수가 불가능해질 것이며, 변경으로 인해이를 사용하는 모든 것에 대해 회귀 테스트가 필요하게 될 것이라고 그들은 말한다. 여기에있는 사람들은 오랫동안 사용되어 왔고 변화가 무너질 지 모르기 때문에 변화가 불가능한 많은 부양 가족과 뇌조를 가지고있는 하나의 구성 요소를 지적합니다. 이 불만

내 반응은 다음과 같습니다

  1. 그것은 많은 부양 가족이있는 구성 요소 에 변화가 느린 것이 좋은가, 그것이 에 디자이너가 정말 변화를 통해 생각 강제로하기 때문이다.
  2. 처음에는 구성 요소를 가져 오는 데 시간이 걸립니다. Corrollary : 항상 변경해야 할 필요성을 느낀다면 처음부터 다시 사용할 수 없었습니다. 그렇습니까?
  3. 소프트웨어 개발이 어렵고 작업이 필요합니다. 테스트도 그렇습니다. 너는 그걸해야 해.

불행히도 이러한 응답에서 사람들은 "느린" "시간"과 "노력"을 들었습니다.

"이 재사용 할 수있는"스위치를 사용하면 관리인이 브라우니 포인트를 획득 할 수 있도록 만들 수있는 기능이 있으면 좋겠지 만 모든 것이 그렇게 작동하지 않습니다. 재사용 할 수있는 무언가를 만드는 데는 시간과 노력이 필요하며 여전히 올바른 것으로 보장받을 수는 없습니다.

"재사용"요청을 처리 할 때 불만 이외에는 아무 것도 가져다주지 않는 것처럼 보이지 않으십니까?

답변

2
  1. 재사용 가능성은 실제로 재사용 될 경우에만 가치가 있습니다. 재사용 가능한 것을 작성하기 전에 실용적인 재사용 사례가 있는지 확인하십시오.

  2. 재사용 가능한 라이브러리가 자체의 임시 버전보다 유지 관리가 10 배 더 어렵더라도 재사용 가능한 라이브러리가 10 개 장소의 임시 버전 대신 사용되는 경우 전체 유지 관리 비용이 절약됩니다.

0

우리가 종종하는 일 중 하나는 버전을 사용하고 지속적인 재검사를 피하는 것입니다. 새로운 버전의 공통 코드가 있다고해서 곧바로 모든 것이 새로운 버전을 사용해야한다는 것을 의미하지는 않습니다. 다른 이유로 인해 무언가가 업데이트되면 새 버전의 공통 코드로 업데이트하십시오.

0

재사용 가능성은 유사한 동작 또는 "IS_A"관계의 용어로 재사용 가능한 코드를 만드는 것입니다. 코드 블록을 반복해서 사용하면서 코드 블록을 재사용하고 싶지만 유사한 특성이없는 코드 블록을 재사용하고 싶다면 느슨하게 결합하는 것이 좋습니다. 그러면 나중에 수정할 수있는 유연성이 향상됩니다.

관련 문제