리팩터인가, 리라이트인가. 그것을 어떻게 판단할까. (레거시 소프트웨어 개선 가이드)

1974 단어 리팩토링신인 프로그래머 응원프로젝트 관리디자인
리팩터인가, 재작성 (개조)?

이 큰 주제에 대해이 책에서 언급되었습니다.

레거시 소프트웨어 개선 가이드 (Object Oriented Selection) 리팩터인지 리라이트인지 결론 결론에서 말하면 "리라이트하고 싶은 욕구와 싸우고, 어떻게든 리팩터로 해결할 수 없는지 생각할 수 있어. 최선을 다해 아무래도 안 된다면 리라이트를 검토해도 좋다" 라는 것이었습니다. 재작성 위험 먼저 밝혀두고 있지만, 완전한 재작성은 거의 항상 좋지 않은 아이디어라고 나는 믿고 있다. 하지만 "당신도 믿으라"고 말하는 것은 아니다. 가능하면 납득해 주셨으면 한다. 이하에, 리라이트에 대한 상세한 반론을 쓴다. 에서 시작하는 "리라이트에 대한 반론"이 다음과 같습니다. (대부분 요약되어 있습니다) 위험 대규모 개발 프로젝트에서 몇 달 또는 몇 년이 걸리면 다음과 같은 위험이 있습니다. 잠재적 인 무수한 버그가있을 수 있습니다. 계획보다 오랜 시간이 걸리고 예산을 초과할 수 있음 새로운 아키텍처가 현재 생산 수준을 충족하는지 확실하지 않고 도중에 불가능하다는 것을 알 수 있습니다. 오버헤드 새로운 제품을 설정하려면 많은 구현이 필요하며 기술자는 오버 헤드를 과소 추정하기 쉽습니다. 재 작성시 현재 제품에 대한 대응책이 어렵습니다. 다음 세 가지 중 어느 것도 현실적이지 않습니다. 본래 소프트웨어의 개발을, 재기록 기간은 동결한다 사양 변경을 허락해, 재기록 기간 항상 따라잡도록(듯이) 한다 사양 변경은 허용하지만 재 작성은 어떤 변경도 구현하지 않습니다. "똑바로 신천지"는 오래 지속되지 않는다. 재 작성에서는 다음과 같은 자체가 발생하기 쉽습니다. 신선하고 멋진 디자인으로 시작 구현해 보면 모델의 미비를 눈치채고, 헬퍼 코드를 추가 낡은 코드에 있던 불필요하다고 생각한 코드가 사용되고 있는 것이 판명되어, 지원 기능을 구현한다 DB에서 존재할 필요가 없는 데이터를 만나고 불필요한 검사를 구현한다. 이 시점에서 새 코드로 바꾸려는 코드가 놀랍게 비슷하다는 것을 알 수 있습니다. 재 작성 조건 이에 대해, 재기록을 해 좋은 조건으로 이하의 것을 들 수 있습니다. 리팩토링을 시도했지만 실패했습니다. 일단 리팩토링에 어느 정도의 시간과 노력을 쏟고 나서 검토해야 한다 패러다임 시프트 기술의 근본적인 변화가 있었을 때. 가장 일반적인 변화는 언어 변경. COBOL에서 Java로 이식하는 것처럼. 세 번째 길 또, 리라이트를 할 때에도 이하의 것을 검토해야 한다고 쓰여져 있습니다. 세 번째 길로서 증분적인 재작성 모든 재 작성은 비용도 위험도 너무 커서 재 작성 단위를 나눕니다. 기능을 분할하고 각각을 컴포넌트로 분할하고 재작성하는 접근법을 시도한다. 자세한 것은 책의 5장 「리어키테크팅」에 기재되어 있다. 감상 자신의 프로젝트 경험을 감안했을 때에, 마음이 당하는 것이 매우 많이 되돌아 와 여러가지 생각하는 계기가 되었습니다. . 「리라이트 하지 않아도 리팩터로 이것만 할 수 있다」라고 하는 것은 든든한 메시지군요. 이 책에는 그 상세도 써 있기 때문에, 그쪽도 참고로 하고 싶습니다.
미니맵에서 비교하는 좋은 코드와 나쁜 코드
레거시 코드 개선 가이드 용어집

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage