레거시 코드란 무엇이며 어떻게 사용하나요?
출처: Dou 머지않아 프로그래머는 아마도 레거시 코드를 접하게 될 것입니다. 이러한 지식의 결과를 쉽게 하기 위해 저는 제 경험, 특히 레거시 Java 시스템 작업에서 얻은 몇 가지 실용적인 팁과 예를 선택했습니다.레거시 기능
레거시(Legacy)는 다른 사람의 코드로, 종종 너무 끔찍해서 어떻게 작업해야 하는지 명확하지 않습니다. 레거시 시스템으로 작업해야 하는 경우 이전 코드 외에도 다음과 같은 문제도 겪게 됩니다.- 오래된 기술로;
- 이기종 아키텍처;
- 문서가 부족하거나 아예 없는 경우도 있습니다.
-
수백만 달러를 벌거나 하루에 수천 명이 액세스하는 시스템을 무시할 수는 없습니다. 아무리 잘못 작성되었더라도 이 역겨운 코드는 생산 단계까지 살아남아 연중무휴로 작동합니다.
-
이 시스템은 실제 돈을 가져오기 때문에 이를 사용하여 작업하는 데에는 큰 책임이 따릅니다. 이것은 스타트업이 아니라 사용자가 내일 함께 일하게 될 것입니다. 이는 또한 매우 높은 오류 비용을 의미하며 여기서 요점은 고객의 주장이 아니라 실제 상황에 있습니다.
리버스 엔지니어링
레거시 코드를 성공적으로 사용하려면 리버스 엔지니어링 기술을 사용해야 합니다. 먼저, 코드가 어떻게 작동하는지 정확히 이해하려면 코드를 주의 깊게 읽어야 합니다. 문서가 없을 가능성이 높기 때문에 이는 필수입니다. 저자의 사고방식을 이해하지 못하면 예측할 수 없는 결과를 초래하는 변경을 하게 됩니다. 이로부터 자신을 보호하려면 인접한 코드도 조사해야 합니다. 동시에 폭뿐만 아니라 깊이도 움직입니다. 오류와 함께 호출된 메소드는 어디에 있습니까? 그것을 호출하는 코드는 어디서 오는가? 레거시 프로젝트에서는 무엇보다 "호출 계층"과 "유형 계층"이 더 자주 사용됩니다. 디버거를 사용하는 데 많은 시간을 소비해야 합니다. 첫째, 오류를 찾고, 둘째, 모든 것이 어떻게 작동하는지 이해해야 합니다. 문서화에 관해서는 산업 고고학에 의존하는 것도 나쁘지 않을 것입니다. 오래된 문서를 어딘가에서 찾아보고 상속받은 코드가 어떻게 작성되었는지 기억하는 사람들과 이야기를 나누는 것은 매우 유용할 수 있습니다. 이러한 기술을 사용하면 조만간 코드를 어느 정도 이해하기 시작할 것입니다. 하지만 노력이 낭비되는 것을 방지하려면 연구 결과를 즉시 문서화해야 합니다. 이를 위해서는 블록 다이어그램이나 시퀀스 다이어그램을 그리는 것이 좋습니다. 물론 게으르겠지만 반드시 이 작업을 수행해야 합니다. 그렇지 않으면 문서 없이 6개월 안에 처음처럼 이 코드를 파헤쳐야 할 것입니다.
코드를 다시 작성하지 마세요
개발 과정에서 가장 중요한 것은 시간 내에 자신을 다그치지 말고 전체 코드를 처음부터 다시 작성하려고 하지 않는 것입니다. 이 작업에 필요한 인력 수를 추정해 보세요. 고객이 이미 작동하는 작업을 다시 수행하는 데 그렇게 많은 돈을 쓰고 싶어할 가능성은 거의 없습니다. 이는 시스템 전체뿐만 아니라 시스템의 모든 부분에도 적용됩니다. 물론, 모든 것을 파악하는 데 일주일을 주고, 뭔가를 고치는 데 또 일주일을 줄 수도 있습니다. 그러나 그들은 시스템의 일부를 다시 작성하는 데 2개월의 시간을 주지 않을 것입니다. 대신 나머지 코드와 동일한 스타일로 새 기능을 구현하십시오. 즉, 코드가 오래된 경우 새롭고 아름다운 기술을 사용하려는 유혹을 받아서는 안 됩니다. 그러면 그러한 코드는 읽기가 매우 어려울 것입니다. 예를 들어, 우리가 겪었던 것과 같은 상황에 직면할 수 있습니다. 시스템의 일부는 Spring MVC로 작성되고 일부는 베어 서블릿으로 작성됩니다. 그리고 서블릿으로 작성된 부분에 다른 것을 추가해야 하는 경우 동일한 방식으로 서블릿에 추가합니다.비즈니스 이익을 존중합니다.
모든 작업은 우선 비즈니스 가치에 따라 결정된다는 점을 기억해야 합니다. 비즈니스 관점에서 특정 변경의 필요성을 고객에게 입증하지 않으면 이러한 변경은 발생하지 않습니다. 그리고 고객을 설득하기 위해서는 그의 입장에 서서 그의 관심사를 이해하려고 노력해야 합니다. 특히 코드를 읽기 어렵다는 이유만으로 리팩터링을 하려는 경우에는 허용되지 않으며 이를 감수해야 합니다. 정말 견딜 수 없다면 코드를 조용히 조금씩 재구성하여 비즈니스 티켓 전반에 걸쳐 작업을 분산시킬 수 있습니다. 또는 이를 통해 오류를 찾는 데 필요한 시간이 줄어들고 결과적으로 비용이 절감될 것이라고 고객을 설득하십시오.시험
모든 프로젝트에서 테스트가 필요하다는 것은 분명합니다. 그러나 레거시 시스템으로 작업할 때는 변경 사항의 영향을 항상 예측할 수 없기 때문에 테스트에 특별한 주의를 기울여야 합니다. 최소한 개발자만큼 많은 테스터가 필요합니다. 그렇지 않으면 자동화에 매우 능숙해야 합니다. 우리 프로젝트에서 테스트는 다음 단계로 구성되었습니다.- 검증: 기능의 구현된 기능을 별도의 분기에서 확인하는 경우입니다.
- 안정화: 모든 기능이 함께 병합되는 릴리스 브랜치를 검사하는 경우입니다.
- 인증은 하드웨어 특성 및 구성 측면에서 프로덕션과 최대한 유사한 인증 환경에서 약간 다른 테스트 사례에 대해 동일한 작업을 다시 실행하는 것입니다.
DevOps 공식화 및 출시
예를 들어 릴리스 절차는 다음과 같을 수 있습니다. 개발이 완료되고 2~3개의 테스트 단계가 완료되면 예상 출시 시간 36시간 전에 DevOps 팀에 이메일을 보냅니다. 그런 다음 데브옵스 팀에 전화를 걸어 환경의 모든 변경 사항에 대해 논의합니다(데이터베이스 및 구성의 모든 변경 사항에 대해 알려줍니다). 모든 변경 사항에 대해 문서(Jira의 티켓)가 있습니다. 그런 다음 릴리스 동안 이에 관련된 모든 사람이 모여서 모두가 지금 무엇을하고 있는지 말합니다. "데이터베이스를 업로드했습니다.", "이러한 서버를 다시 시작했습니다.", "우리는 프로덕션 환경에서 회귀 테스트를 실행했습니다. ” 문제가 발생하면 원본 릴리스 문서에 정확하게 설명된 릴리스 롤백 절차가 시작됩니다. 이러한 문서가 없으면 우리는 확실히 무언가를 잊어버리거나 혼란스러워질 것입니다.코드 품질 제어
마지막으로 코드 검토는 어떤 이유로든 모든 프로젝트에서 사용되지 않는 관행입니다. 두 명 이상의 사람이 모든 코드 조각을 검토하는 것이 좋습니다. 아주 강한 팀이라도 코드 리뷰 과정에서 늘 버그가 발견되고, 여러 사람이 보면 발견되는 버그의 수가 늘어난다. 게다가 세 번째나 네 번째 리뷰어가 최악의 결과를 찾아내는 경우도 있습니다.기술 문서 작성을 더욱 쉽게 해주는 도구
출처: Dzone 대부분의 프로그래머는 기술 문서 작성을 좋아하지 않습니다. 심리학 전문가인 Gerald Weinberg는 문서를 "프로그래밍의 피마자유"라고 불렀습니다. 개발자는 문서를 읽는 것을 좋아하지만 직접 작성하는 것은 싫어합니다.
지침이 부족하거나 빈 로드맵이 있으면 소프트웨어의 다양한 부분이 어떻게 작동하는지에 대한 정보가 부족합니다. 이는 문서가 없으면 제품의 정확성과 유용성에 의존할 수 없기 때문에 궁극적으로 코드 최종 사용자의 경험을 악화시킵니다. 프로그래머가 문서 작성 습관을 더 쉽게 형성할 수 있도록 현재 거의 모든 사람이 사용할 수 있는 네 가지 훌륭한 도구에 주목할 것을 권장합니다.
GO TO FULL VERSION