리팩토링은 그만한 가치가 있었습니다.

리팩토링으로 다음 단계가 더 쉬워집니다.

이번 주 작업은 내 OpenSSG 코드를 리팩토링하는 것입니다. 그러나 2주 전에 대부분의 코드를 리팩토링했습니다. 이제 나는 내 지식을 향상시킬 것이 많지 않습니다. 책Clean Code을 읽은 이후로 리팩토링에 큰 관심을 갖게 되었습니다. 관리하기 쉬운 방식으로 코드를 분해하고, 누구나 코드를 더 쉽게 이해할 수 있도록 더 나은 이름을 지정하고, 오류를 줄이고 단위 테스트에서 오류를 찾는 기능을 만드는 것의 아름다움을 보았습니다. 협동조합을 하다보니 리팩토링의 중요성을 더 실감하게 되었습니다. 지금은 잊고 있었던 것을 배우려면 Clean Code를 다시 읽어야 할 것 같다.

여러 인수를 전달하는 대신 개체 보내기

기능을 구현하는 동안 코드를 리팩터링하는 위치와 방법을 찾기가 쉽지 않습니다. 그러나 나는 내 OpenSSG를 테스트했을 때 뭔가 옳지 않고 오류가 발생하기 쉽다는 것을 알았습니다. 첫 번째 문제는 너무 많은 오버로딩 함수였습니다. 그들은 거의 비슷한 일을 하고 있었습니다. 선택적 작업만 달랐습니다. 한 곳을 고칠 때, 같은 고침을 추가하기 위해 모든 곳을 세심하게 찾아야 했습니다. 내가 놓친 곳을 찾는 것은 실수하고 시간이 많이 걸리는 일이 될 가능성이 큽니다. 리팩토링을 설명하는 한 기사를 기억합니다. 전략 중 하나는 인수를 하나의 개체로 전달하는 것입니다. 그래서 Options 클래스를 만들었고 많은 문제를 해결했습니다. 이전 코드를 유지하면서 리팩토링된 코드를 추가하기 위해 편집기에서 같은 파일을 동시에 열었습니다. 그래서 FileUtilities 클래스를 도입하여 거대한 Options 클래스를 얼마나 줄일 수 있을지 몰랐습니다. 새 코드가 제대로 작동하는지 확인한 후 기꺼이 오버로드 함수를 제거했습니다. 나는 이 프로세스가 많은 골치 아픈 코드를 줄인 것을 볼 수 있었습니다.

함수 내부에 자세한 논리를 숨기고 함수에 좋은 이름을 부여하십시오.

그런 다음 더 읽기 쉽고 관리하기 쉽도록 함수를 만들 수 있는 전체 파일을 살펴보았습니다. 올바른 옵션이 제공되는지 확인하기 위해 모든 로직을 포함하는 함수arArgsValid(String[])를 만들었습니다. 그리고 hasTitile(String[]) 와 같은 더 많은 검사 기능을 만들려고 노력했습니다. 내 생각에 boolean 반환 함수는 논리를 내부에 숨기고 좋은 함수 제목을 표시할 때 더 명확해 보입니다. 또한 FileUtilities 외부의 일부 구문 분석 논리를 잘라낸 다음 이름을 Parser 클래스로 지정했습니다. FileUtilities 에서 파일 쓰기를 하지 않는 것을 잘라내고 Parser 클래스로 옮겼습니다. 이것은 또한 많은 코드를 줄였습니다. 그리고 내 코드가 훨씬 좋아 보입니다. 그리고 각 파일 크기가 더 가깝습니다.

❯ wc -l src/*                                                                                                                                                                                                ─╯
     227 src/FileUtilities.java
     168 src/OpenSSG.java
      70 src/Options.java
      90 src/Parser.java
       6 src/Release.java
     561 total

더 나은 리팩토링을 위한 지속적인 여정

마지막으로 모든 변수를 확인하여 모호하거나 오해할 수 있는 부분이 없는지 확인했습니다. 나는 보통 이름을 올바르게 지정하려고 노력합니다. 하지만 코드 전체를 변경하고 지속적으로 테스트할 때 이름 바꾸기 작업은 나중을 위해 제쳐두었습니다. 지금은 기능을 더 만들어야 하나 말아야 하나 하는 생각이 들지만 꽤 만족스럽습니다. 지금은 명확한 대답이 없습니다. 리팩토링을 더 잘하기 위해 더 많은 코드와 책을 계속 읽어야 합니다.