팀의 리팩토링 우선 순위를 어떻게 정할 수 있습니까?

매일 작업하는 코드베이스에는 자동화 된 테스트, 일관성없는 이름 지정 및 "이 이유는 무엇입니까?", "필요한지 확실하지 않음"또는 "이 방법의 이름이 잘못되었습니다"와 같은 수많은 주석이 없으며 코드가 소스 컨트롤을 사용한다는 사실에도 불구하고 "변경 로그" 우리의 코드베이스는 리팩토링을 사용할 수 있습니다.

우리는 항상 버그를 수정하거나 새로운 기능을 추가하는 작업을 수행하므로 코드를 더 효율적이고 모듈화하기 위해 코드를 리팩토링 할 시간을 허비하지 않으며 우선 순위가 높은 것으로 보이지 않습니다.

작업 목록에 추가되도록 리팩토링의 가치를 어떻게 증명할 수 있습니까? 내가 가기 전에 리팩터링하여 허가보다는 용서를 구하는 것이 가치가 있습니까?

"허가보다 용서를 구하는 것이 낫다"는 것이 사실입니다.

왜 걱정합니까? 가장 끔찍한 부분을 리팩터링하십시오.

가장 비싼 오류가 무엇인지 이미 알고 있습니까?

그렇지 않은 경우 1 단계는 비용이 많이 들고 복잡하며 오류가 발생하며 버그가 많은 문제 코드를 긍정적이고 명확하게 정의하는 것입니다.

문제점 티켓 수, 디버깅 시간 및 기타 매우 구체적이고 측정 가능한 비용을 식별하십시오 .

그런 다음 고비용 문제 목록에서 무언가를 수정하십시오 .

용서를 구해야 할 때 비용 절감을 가리킬 수 있습니다.

모르는 경우 리팩토링을 수행 하려면 전후 테스트가 일치하는지 확인하기 위해 단위 테스트가 필요합니다 . 이상적으로는 자동화 된 코딩 테스트 (예 : 단위 테스트) 여야합니다.

이것은 한 가지를 선택하는 것을 의미 합니다. 단위 테스트를 작성하십시오. 한 가지 수정하십시오. 두 가지 개선되었습니다. (1) 테스트를 작성하고 (2) 코드를 수정했습니다.

반복합니다.

보이 스카우트 규칙을 따르십시오. 캠프장 (코드)을 찾은 것보다 조금 더 잘 두십시오. 나는 "그들이 거기에있는 동안"작은 코드 개선을 위해 작성된 글을 한 번도 들어 본 적이 없다.

아마도 지나치게 냉소적 인 관점을 취하겠습니다.

리팩토링은 삼키기 어려운 약입니다. 책임과 비난을 받으면 노동의 결실은 종종 깨끗한 코드 기반을 구축하는 다른 사람에게갑니다.

그러한 엔지니어링 관행이 회사의 문화가 되었다면 더 높은 수준에서 싸워야 할 수도 있습니다. 리팩토링을 위해 싸우는 것이 아니라 공학적 우수성을 위해 싸우는 것입니다. 그것은 경영진이 직면 할 때에 만 일어날 수있는 변화입니다. 이 시나리오에서 그들은 아마도 모범 사례를 찾기 위해 외부를 살펴볼 것이며, 당신의 모든 훌륭한 아이디어는 어쨌든 포함됩니다.

엔지니어링 업무를보다 진지하게 받아들이는 다른 회사에 가입하는 것을 고려하십시오.

나는 여기에 많은 포스터가 경영상의 문제를 확신하고있는 것처럼 보이는데, 그 질문에 대해서는 언급하지 않았다.

나는 그것보다 더 나아갈 것이다 : 내 의견으로는 거칠고 코드베이스는 거의 직접 관리의 결함이 아니다. 경영진은 개발자가 작성한 코드를 작성하지 않았습니다 (현재 회사의 일부 경영진이 실제로 초기 코드베이스를 작성한 일부 예외가 있습니다). 따라서 문화 문제는 개발자들에게 있습니다. 만약 문화가 바뀌기를 원한다면, 그들 스스로 변화해야합니다.

나는이 실현과 태도의 변화를 "나의"개발자들에게 전하려고 노력한다. 그들이 "언제 리팩터링 할 시간이 있습니까?" 코드베이스를 건강하게 유지할 수 있다고 믿는 유일한 방법은 세 가지입니다.

1. 건강한 코드 만 추가하십시오.
2. 건강하지 않은 코드는 최대한 빨리 수정하십시오.
3. 마감 기한 이유로 1 또는 2를 수행 할 수없는 경우, 항상 "마감 기한 직후 수정"문제 목록을 갖고 마감 기한 후에 해당 목록을 통과하지 못한 것에 대한 변명은 수락하지 마십시오.

개발자의 다음 발언은 "언제나 그렇게 할 시간이 있습니까? 지금은 시간이 없습니까?"입니다. 정답은 (IMHO에게도) "하지 않을 시간이 없습니다"뿐입니다. 코드베이스를 건강하게 유지하지 않으면 처리 시간이 점점 길어지고 예측할 수없는 일정이 생기고 버그가 점점 더 나 빠지고 가치가 낮아집니다.

개발 팀에서 가장 큰 태도 변화는 "품질"이 특정 시점 ( "리팩터링 할 시간이있을 때")에서 수행하는 작업이 아니라는 것입니다. 항상 수행해야하는 작업입니다.

마지막으로 경고의 이야기. 눌려지면 이런 일이 발생하지 않을 것입니다. 제가 근무한 회사에서 10 년 전부터 시작된 대규모의 레거시 코드베이스가있는 오랜 응용 프로그램이있었습니다. 저를 포함한 많은 개발자들은이 레거시 코드베이스가 최신이 아니라 나쁘거나 오래되었다고 생각했습니다. 그래서 우리는 큰 리팩토링 프로젝트를 성공적으로 수행하고 모든 것이 더 좋을 것이라고 생각한 재 작성 프로젝트를 시작했습니다.
우리는 새로운 라이브러리, 새로운 언어 기능을 사용하여 거의 모든 것을 새롭고 현대적인 방식으로 구현하기 위해 열심히 노력했습니다. 결국 우리는 새롭고 개선 된 코드 기반으로 오랜 응용 프로그램의 새로운 릴리스를 허용하기 위해 모든 것을 하나로 모으기 위해 많은 노력을 기울였습니다.
예상대로 새 릴리스에는 아직 익숙하지 않은 새 라이브러리와 예상하지 못한 코드의 일부 상호 작용으로 인해 일부 문제가 발생했습니다. 그러나 마침내 이전 릴리스와 동일한 표준으로 릴리스를 출시하고 문을 열었습니다. 우리는 "성공"에서 한숨을 쉬었다. 그런 다음 하위 그룹의 개발자가 경영진으로 돌아와 새로운 코드 리팩터링 프로젝트를 요구하면서 새로운 리팩토링 프로젝트를 요청했습니다.

이야기의 도덕 : 종종 상황이 거의 깨지지 않는 경우가 많으며 '다시 시작'한다는 것은 알려진 문제 세트를 거의 알려지지 않은 문제 세트와 교환한다는 의미입니다. 한 번에 한 부분 씩 리팩터링하십시오!

누군가가 한 번 인터뷰를 할 때 회사 인터뷰도 잊지 말아야한다고 말했습니다. 내가 일하고 싶은 곳입니까? 그들은 코드 리뷰를합니까? 자동 통합 테스트가 있습니까? 단위 테스트? 그들은 쌍 프로그래밍에 대해 어떻게 생각합니까? 개인적으로 나는 다른 직업을 찾게되었는데, 이번에도 몇 가지 질문을하는 것을 잊지 마십시오.

솔직히 다른 회사를 찾으십시오. 이러한 개발 과정의 개선에는 많은 문화적 도약이 필요하므로 모든 사람들이 같은 페이지에 들어가기까지는 많은 시간이 걸리고 그렇게 많은 관심을 가지지 않을 것입니다.

당신이 여전히 당신과 싸우고 있고 아직 끝나지 않았다고 생각되면 마지막으로 밀어 넣으십시오. 같은 생각을 가진 팀원들로부터 많은 지원을 받고, 자신의 신념에 반대 할 수있는 사람을 행복하게, 우회하고 우회하고 관심있는 사람을 멀리하는 상사에게 피로를 말하고, 새로운 리팩토링 시간을 계획하십시오 프로젝트 / 기능.

당신이하는 일에 대해 열정을 갖고 회사에 관심을 가지면, 그것은 당신 편에서 훌륭한 노력이 될 것입니다. 그것이 감사하지 않으면, 자신을 존중하고 구식 프로그래머가되기 전에 구제하십시오.

이런 상황에서 상황을 개선하기 위해 한 가지 연습을 소개해야한다면 코드 검토 일 것입니다. 코드 리뷰는

• 일반적으로 개발자는 코드 개선, 버그 감소 등의 요소로 직관적으로 받아들입니다.
• 협력적이고 민주적 인
• 타임 박스를 제대로 작성하면 시간이 많이 걸리지 않습니다
• "정상적인"개발 중에 그렇게 할 시간이 없다면 리팩토링을 수행하기에 좋은 곳
• 코드 디자인, 단위 테스트 측면에서 모든 종류의 모범 사례를 점차적으로 도입하는 매우 효과적인 트로이 목마 ...

처음에는 큰 / 복잡한 코드 부분을 커밋 할 때만 체계적으로 코드 검토를 수행 할 필요가 없습니다.

물론 코드 검토를 도입하기 전에 공식 승인이 필요하다고 생각되면 코드베이스가 그대로 남아 있으면 코드베이스가 무너질 가능성이 있음을 먼저 상사에게 납득시켜야 할 수도 있습니다.

다음은 그러한 상황에서 내가하는 일입니다 (개발자로서 15 년 동안 거의 매일 그러한 코드를 보았습니다)

1. 예를 들어 리드-내가 만지는 코드를 리팩터링해야합니다. 나는 주석이 달린 오래된 코드와 주석의 큰 단락을 무자비하게 삭제합니다.
2. 코드 검토를 승인하지 않으면 코드 변경을 검토하라는 요청을받을 때마다 리팩토링을 요청하십시오.
3. 사람들은 코드가 더 얇아지고, 더 읽기 쉽고, 버그가 적을 때 변화를 느리게 본다. 시간이 걸리지 만 팀 전체가 천천히 연습을 인정하고 채택합니다.

경영진은 코드 리팩토링을위한 시간을 따로 따로 설정하지 않으며 (자원이 충분하지 않습니다!) 느리고 꾸준하게 수행하는 것이 올바른 방법입니다.

경영진이 "기술 부채"에 대한 조사를 수행하도록합니다. 또한 "깨진 창 이론"을 참조하십시오.이 두 가지 효과는 효율성, 품질 및 사기에 직접적인 영향을 미칩니다.

"깨끗한 작업장은 안전하고 생산적인 작업장입니다."

상황이 처리되지 않으면 결국 경제적으로 실현 불가능한 시점으로 돌아갈 수없는 지점을 넘어서게됩니다. 그 전에 발생하는 이점을 점진적으로 처리함으로써 혜택이 반등하여 문제를 해결할 수있는 더 많은 연료를 제공합니다.

문제가 더 일반적인 것 같습니다.
리팩토링 문제는 증상의 일부이자 잠재적 인 완화입니다.

소프트웨어 책임자와 팀은 팀의 시간을 할당

내 경험으로는 "모두 소프트웨어 관리자"라고 부르는 문제가 발생한 것 같습니다. 제품 관리자, 프로젝트 관리자 및 때때로 시스템 엔지니어 및 테스터는 이미 숙련 된 소프트웨어 관리자가있는 개발자를 미세 관리하려고 시도하는 것으로 악명 높을 수 있습니다. 팀원 중 자신의 역할을 관리하는 팀원이 몇 명일 수도 있습니다.

소프트웨어 관리자 인 경우 원하는 리팩토링을 지정하거나 팀이 승인을 위해 리팩토링을 제안하도록하십시오. 소액 관리하지 않기 위해 리팩토링 할 코드의 연령 / 저자 / 크기 / 컨텍스트에 대한 지침이있을 수 있으며, 이는 자유롭게 리팩터링 될 수 있고 승인이 필요합니다. 팀원이 자신의 기능에 포함되지 않은 복잡한 이전 ​​코드의 네 가지 큰 클래스를 대규모로 리팩토링하려는 경우 그의 2 주 전환이 문제이므로 아니오라고 말할 기회가 필요합니다.

몰래 들어올 수는 있지만 분석, 디자인, 코딩, 여러 형태의 테스트 (최소한 단위 및 통합), 리팩토링 및 위험을 역사적으로 판단하여 부족한 시간으로 신중하게 추정값을 작성하는 것이 좋습니다. 작업과 관련된 경험 또는 명확성. 팀의 작업에 대해 너무 개방적이거나 팀 구성원이있는 경우 커뮤니케이션 채널을 좁혀서 사용자를 안내하고 방법이 아닌 리소스와 결과를 논의하는 것이 현명 할 수 있습니다.

초기 프로젝트 선택은 리팩토링을위한 악순환을 만듭니다

소프트웨어 유지 관리가 어렵습니다. 조직의 다른 사람들이 귀하의 비용으로 선택을하는 경우에는 두 배가 어렵습니다. 이것은 잘못된 것이지만 새로운 것이 아닙니다. 그것은 그가 이론 W라고 기술 한 관리 모델을 제시 한 우리의 위대한 소프트웨어 작가 중 한 사람인 Barry Boehm에 의해 해결되었습니다.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

종종 소프트웨어 개발자들은 Theory-X 관리 접근 방식에 따라 노동자들이 기본적으로 게으 르며 제출에 얽매이지 않으면 수행하지 않을 것이라고 말합니다. Boehm은 제안 된 모델을 다음과 같이 요약하고 대조합니다.

"이론 관리자는 관리자를 독재자 (이론 X), 코치 (이론 Y) 또는 촉진자 (이론 Z)로 특성화하는 것이 아니라 다양한 구성 요소와 프로젝트 솔루션 패키지 관리자 사이의 협상자로서 관리자의 주요 역할을 특성화합니다 그 외에도 관리자는 목표 설정자, 목표를 향한 진행 상황을 모니터링하고 일상적인 상실 또는 상실 프로젝트 충돌을 찾아내는 활동가입니다. "상생적인 상황으로 바꾼다"

빠르고 더러운 경우가 많습니다

Boehm은 유지 관리 팀의 개발자에게 상황이 그렇게 비참한 이유를 지적합니다.

"빠르고 조잡한 제품을 구축하는 것은 소프트웨어 개발자와 고객에게 저렴한 단기"승리 "가 될 수 있지만 사용자와 관리자에게는"손실 "이 될 것입니다." Boehm의 모델에서 고객은 최종 사용자가 아닌 계약 관리자입니다. 대부분의 회사에서 제품 관리자를 고객 대리자 또는 기능 목록을 위해 제품을 구매 한 사람으로 생각하십시오.

내 솔루션은 코드가 최소한 코딩 표준을 충족하도록 리팩터링 될 때까지 원래 개발 팀 (또는 최소한 원래 리드)을 해제하지 않는 것입니다.

customer의 경우, 제품 관리자를 고객 대리자로 간주하는 것이 합리적이라고 생각하고 신속하고 더러운 것을 제공 한 것에 대한 보상을받은 사람들의 그룹을 확실히 확장 할 수 있으므로 잘못된 방식으로 일을 수행 할 큰 구성 요소가 있습니다.

리팩토링은 협상 할 수 없습니다

소프트웨어 관리자로서의 역할을 포기하지 마십시오. 프로세스 및 제품 개선에 팀의 시간을 사용할 권한과 재량이 있어야합니다. 이 역할에서 팀을보다 전문적으로 만들기 위해 선택을 협상해야 할 수도 있습니다. 그러나 프로세스와 관련하여 마케팅과 협상하지 마십시오. 경험상 게임에서 패배하기 때문입니다. 엔지니어링 관리와 협상하십시오. 그것은 당신이 비전을 가지고 있음을 보여줍니다. 전문 소프트웨어 팀을 구축하는 것은 그들의 역할의 확장이며, 윈윈으로 보일 가능성이 훨씬 높습니다.

항상 기다릴 수 있습니다. 결국, 팀은 충분한 기한을 그리워하고, 버그 - 충분한 소프트웨어를 생산합니다, 그 관리는 손을 던질 것이며, 하나님의 말 뭔가 더 나은 변화를했다!

좋아요, 그건 위험한 제안입니다. 그러나 몇 년 전 우리 가게에서 무슨 일이 있었는지 사실이다 (어려움의 부분은 관리와 통신에 있었다 약 , 마감,하지만 그건 또 다른 이야기), 및 코드 소유권 공유 우리는 이제 수십 자동화 된 테스트의 수천을 가지고있는 이유의 많은입니다 리팩토링의 자유, 죽은 코드를 삭제하려는 의지, 그리고 우리가 가진 최고 품질의 릴리스.

아마도 가장 놀랍게도 그 과정에서 직무를 잃은 사람은 아무도 없었습니다. 상사에게 우리를 대신하게 될 것입니다. 외부에서 누군가 말을 할 때 항상 더 설득력있게 들립니다.

시간을 찾는 방법에 대한 대답은 왜 코드를 리팩토링 하려는지에 달려 있다고 생각합니다.

작동하는 경우 특수 리 팩터가 필요 없으며 코드의 해당 부분을 만질 때 수행 할 수 있습니다. 따라서 특별한 시간이 필요하지 않습니다.

팀 개발 속도가 느리면 팀 리더와상의하여 리팩토링을위한 특별한 작업을 작성해야합니다.

리팩토링이 "좋은 코드보기"또는 사용자 의견에 대한 의견뿐만 아니라 무언가를 개선 할 수있는 경우, 실행 속도 및 기타 경우와 동일합니다.

나는 당신이 일하는 코드베이스와 매우 비슷한 소리로 설명하는 방식에 약간 웃었습니다. 그래서 우리의 상황은 매우 비슷하다고 생각합니다. 운 좋게도 상황에 따라 코드베이스를 개선하는 가장 좋은 방법은 전체 코드베이스를 리팩토링하는 대신 최신 웹 개발 프레임 워크를 사용하여 모듈화하는 것입니다. 이 방법으로 메인 애플리케이션의 번거로운 지점을 별도의 모듈로 다시 작성한 다음 메인 앱에 통합 할 수 있습니다 (그러나 여전히 독립적 임). 이것은 작업중 인 전체 (아마도 큰?) 코드베이스를 리팩토링 할 필요가 없기 때문에 제기하려는 접근법 일 수 있습니다.

물론, 코드베이스가 내가 작업하는 것만 큼 나쁘지 않다고 말하는 것에서 약간 벗어날 수 있습니다.이 경우 나는 왜 최적화를 거의하지 않습니까? 우리 팀의 개발자는 어리 석거나 오래된 주석과 그 자연의 것들을 제거하는 데 아무런 문제가 없으며 일반적으로 개발자가 필요에 따라 최적화 할 수있는 권한을 부여 받았기 때문에 경영진의 의견이 필요하다고 생각하지 않습니다.

코드 기반이 실제로 깨지기 쉬운 경우 조심해야하며 이것이 중요한 리팩토링을 추구하지 않는 이유 일 수 있습니다. 이로 인해 몇 개월이 걸리는 프로젝트가 될 수 있고 프로젝트 분기가 필요할 수 있습니다. 고객을 잃을 수있는 즉각적인 버그 수정과 같은 다른 개발 작업을 피하고

다른 사람들이 당신이 그만두라고 말하는 한, 모든 것이 고려됩니다. 경영진이 사물을 보는 방법에 달려 있다고 생각합니다. 상황을 이해하고 어떤 것들이 최적의 것보다 더 오래 걸릴 수 있다는 것을 깨달으면 업무 환경에 이르기까지 지속적으로 업무의 잔고에 대해 알게되면 시간이 지남에 따라 해로울 수 있습니다. 운 좋게도 기본적으로 응용 프로그램이 쓰레기라는 것을 인식하는 관리를하지만, 많은 고객이 있고 돈을 가져옵니다. 따라서 단기적으로도 여전히 가치가 있고 버그를 수정할 가치가 있습니다. .

주요 문제는 코드가 충분한 가시성을 얻지 못한다는 것입니다.

Jenkins 와 같은 지속적인 통합 도구와 순환 복잡성, 명명 표준, 코드 길이 등을 측정하는 정적 코드 분석 도구를 사용하여 제안합니다.

프로그래머가 변경 사항을 커밋하면 Jenkins는 단위 테스트를 실행하고 정적 코드 분석 도구를 실행하며 교통 신호와 같은 색상 상태로 모든 사람이 볼 수있는 웹 보고서를 생성합니다.

코드 품질이 모든 사람 (특히 팀 리 드러 및 보스)에게 표시되고 버전 제어 및 단위 테스트가 필요한 경우 직원들은 리팩토링을 권장합니다.

코드는 많은 작은 변화를 통해이 방법을 천천히 얻었습니다. 그런 식으로 수정해야합니다.

코드를 향상시키고 장기적인 유지 관리를 위해 모든 추정치를 10 % 늘립니다. 누군가가 불만을 품고 있다면 매주 자동차 엔진의 오일을 점검하는 것이 더 좋은지 또는 엔진이 완전히 잠길 때까지 기다리는 것이 더 좋은지 물어보십시오.

회의를 열고 일관된 코딩 표준을 결정하십시오.

진행할 기본 규칙을 소개합니다.

새로운 코드가 클래스에 도입 될 때마다 클래스가 작동 함을 증명하기 위해 자동화 된 테스트를 작성해야합니다 (새 코드 만이 아님).

버그가 수정 될 때마다 (고정 코드 만이 아니라) 클래스가 작동하는지 증명하기 위해 자동화 된 테스트를 작성해야합니다.

프로그래머가 파일을 수정할 때마다 해당 파일의 모든 컴파일러 경고를 수정하고 새 코딩 표준을 충족하도록 코드를 업데이트해야합니다.

얼마 후 가장 많이 사용 된 코드는 최신 상태이며 자동화 된 테스트로 처리됩니다. 이전 코드는 변경 될 때 업데이트되며, 변경되지 않으면 걱정할 필요가 없습니다.

중요한 것은 이러한 habbits를 표준 코딩 작업으로 빌드하는 것이므로 '실제'작업에서 많은 시간을 소비하지는 않지만 실질적인 이점을 제공합니다. 오래된 코드를 리팩토링하여 프로젝트를 만들려고하지 마십시오. 그것은 비 기술자에게 많은 시간을 낭비하는 것처럼 보일 수있는 끔찍하고 지루하며 어리석은 고통입니다!

필요한 리소스 (시간)를 얻는 방법은 능력과 욕구를 맞추는 데 집중하는 것입니다. 상사는 목표 (일반적으로 새로운 기능에 대한 이익 또는 배달 시간)에 의해 주도되며 엔지니어는 시간을 낭비하고 목표를 달성함에 따라 리팩토링을 봅니다. 리팩토링에 시간을 보내면 목표를 달성하고 초과 할 것이라고 확신시킬 수있는 방법을 찾아야합니다.

따라서 첫 번째 단계는 상사가 어떤 고통을 느끼고 있는지 알아내는 것입니다. 그의 가장 큰 문제가 무엇인지 확인하십시오. 그런 다음 자신이하려는 문제가 그의 문제 해결과 어떻게 조화를 이루는 지 확인하고이를 수행하기위한 강력한 비즈니스 사례를 제시하십시오. 결함 추적 및 프로젝트 계획 시스템 (시간 초과)을 사용하여 문제가있는 위치에 대한 증거를 제공하십시오. 감정이 아니라 사실이 필요합니다. 메트릭 (버그 수 / 모듈, 수정 비용)이 없으면 리팩토링은 프로그래머의 비용으로 플레이하는 프로그래머 일뿐입니다. 상사가 강력한 비즈니스 사례를 보여줄 수있는 경우 필요한 리소스 만 제공합니다.

크랩 코드는 수정하기에는 너무 비싸지 않습니다. 자동 회귀 테스트가 없으면 리팩토링 된 코드 테스트 비용이 매우 높습니다.

실제로 리팩토링이 실제로 필요한 코드가 잘못된 경우가 많았지 만 처음부터 이해할 수없는 요구 사항에는 문서화되지 않은 기능과 복잡성이 많이있었습니다. 사소한 일이 아니며 내 경험은 새로운 기능을 추가하는 것보다 리팩토링 작업 비용을 추정하기가 훨씬 어렵습니다.

나는 계속해서 보스 뒤에서 그것을하지 않을 것입니다. 그것을 고치십시오.

이상하게도 아무도 언급하지 않습니다.

우선 순위를 높이려면 다음과 같이하십시오. 좋은 리팩토링 도구를 사용하십시오.

훌륭한 리팩토링 도구가 있습니다 (적어도 .NET afaik의 경우). 아, 다른 사람들이 이미 지적했듯이 미리 단위 테스트를 작성하는 것을 잊지 마십시오 .

행운을 빕니다!