지난 주에 저는 일관된 반환 값을 가진 메서드와 이 메서드를 사용하여 코드를 더 간단하게 만드는 방법에 대해 썼습니다. 그런데 어떻게 합니까? 올바른 리팩토링을 통해 코드 작업을 더 쉽게 수행할 수 있는 방법은 무엇입니까? 좋은 추상화를 좋게 만들고 나쁜 추상화를 나쁘게 만드는 것은 무엇입니까? 내 말은, 맹목적으로 코드를 재배열하고 고품질 소프트웨어로 끝날 수는 없습니다.
이유를 알 수 있다면 이러한 기술이 작동하면 코드에서 도움이 필요한 부분을 더 잘 이해할 수 있습니다. 그리고 가장 중요한 곳에 올바른 도구를 사용할 수 있습니다.
소프트웨어 개발에서 가장 어려운 문제는 무엇입니까?
<블록 인용>"컴퓨터 과학에는 캐시 무효화와 이름 지정이라는 두 가지 어려운 문제만 있습니다."
– 필 칼튼
물론입니다. 그 인용문은 어디에나 있습니다. . 그러나 실제 소프트웨어 개발에는 실제로 더 어려운 문제가 있습니다. 바로 복잡성 관리입니다. 소프트웨어 개발의 복잡성에는 몇 가지 다른 정의가 있습니다. 하지만 핵심은 프로그램의 복잡성은 작업하는 동안 염두에 두어야 하는 항목의 양입니다.
더 많은 소프트웨어를 작성할수록 한 번에 더 많은 내용을 머릿속에 저장할 수 있습니다. 그러나 최고의 개발자에게도 한계가 있습니다. 프로젝트가 너무 복잡하면 마음이 처리할 수 있는 작업에 과부하가 걸리고 프로그램의 다른 영역에 대해 잊어버리기 시작할 것입니다. 그리고 최악의 버그는 변경 사항이 동일한 프로젝트의 완전히 다른 부분에 어떤 영향을 미치는지 깨닫지 못한 채 프로젝트의 한 부분을 변경할 때 나타납니다.
가정을 통한 단순화
사진 메모리가 있고 프로그램의 다른 모든 부분이 어떻게 잘 맞는지 기억할 수 있다면 버그가 훨씬 적겠죠? 메모리는 구축하기 어려울 수 있습니다. 하지만 한 번에 한 가지에 집중할 수 있으므로 동일한 이점을 많이 얻을 수 있습니다.
소프트웨어 개발의 많은 모범 사례는 한 번에 염두에 두어야 할 사항의 수를 줄이는 것입니다. 몇 가지 예:
-
반환 값의 일관성 서로 다른 상황에서 서로 다른 종류의 데이터를 처리하는 대신 한 가지 종류의 데이터를 처리하는 방법만 생각하면 됩니다.
-
추상화 더 간단한 인터페이스 뒤에 코드를 숨기는 방법입니다. 좋은 추상화를 사용하면 추상화를 어떻게 해야 하는지 생각할 수 있습니다. 내부에서 어떻게 작동하는지 걱정할 필요가 없습니다.
-
테스트 다른 영역에서 작업하는 동안 한 영역에서 실수로 코드를 깨뜨리는 것을 방지할 수 있습니다. 실수로 부수는 것은 무엇이든 걸릴 것이라고 가정할 수 있습니다. 즉, 작업 중인 코드에만 집중하고 나중에 중단되는 모든 것을 수정할 수 있습니다.
-
테스트 주도 개발 예상대로 작동하는 코드를 작성하는 데 도움이 됩니다. 테스트를 통과하는 메서드의 가능한 가장 간단한 구현을 작성하는 데 집중할 수 있습니다. 너무 간단하고 실제로 예상한 대로 작동하지 않으면 테스트에서 이를 포착합니다.
이러한 기술을 올바른 방식으로 사용하면 몇 가지 좋은 가정을 할 수 있습니다. 이러한 가정을 사용하면 마음의 전면에 가까운 곳에 보관할 필요가 없습니다. 코드가 시스템에 미칠 수 있는 거의 무한한 결과에 대해 걱정할 필요가 없기 때문에 더 좋고 안정적인 코드를 작성할 수 있습니다.
반면에 잘못된 위치에서 이러한 기술을 사용하면 숨깁니다. 실제로 봐야 하는 코드. 코드를 숨기면 가정이 때때로 틀릴 수 있습니다. 이를 통해 더욱 결국 깨질 가능성이 높습니다!
이것이 바로 나쁜 추상화가 전혀 추상화되지 않는 것보다 나쁜 이유이며 마술처럼 좋아질 때까지 코드에서 "추출 메소드"를 던질 수 없는 이유입니다.
적절한 리팩토링, 적절한 위치
명확한 코드는 수행 중인 작업에 대해 미리 설명하는 코드입니다. 알아야 할 것을 보여주는 것은 알 필요가 없는 것을 숨기는 것만큼 중요합니다. 리팩토링을 수행하거나 소프트웨어 모범 사례를 사용할 때 최종 코드와 복잡성을 줄이는 데 얼마나 도움이 되는지에 대해 생각해야 합니다. 나머지 코드가 가정을 단순화하여 잘 만들 수 있도록 돕고 있습니까? 아니면 너무 단순한 인터페이스 뒤에 필수 지식을 묻고 있습니까?