전체 Java 코드 기반을 다시 포맷하는 것이 안전하다고 경영진을 설득하는 방법

https://stackoverflow.com/questions/2420174

19-09-2019
|

문제

회사의 코딩 표준에 따라 코드를 배치하기 위해 대규모 코드 기반의 모든 .java 파일을 일괄적으로 다시 포맷하는 것이 안전하고 기능에 영향을 미치지 않는다는 것을 경영진에게 어떻게 증명할 수 있습니까?

대답은 비기술적인 사람과 기술적인 사람 모두를 달래야 합니다.

편집하다:2010-03-12기술적인 부분에 대한 설명reformat = 공백만 변경 - "가져오기 구성" 또는 "멤버 변수, 메서드 등의 재정렬"이 없습니다.

편집하다:2010-03-12 수많은 답변에 감사드립니다.mrjoltcola의 답변은 단순히 편집증에 대한 진술이고 내 질문에 대한 답변을 제안하지 않기 때문에 많은 독자들이 mrjoltcola의 답변에 투표했다는 사실에 놀랐습니다.게다가 같은 기고자가 이 질문을 반복하는 댓글도 있습니다.WizzardOfOdds는 이 관점을 지지했습니다(그러나 이를 보기 위해 모든 댓글을 읽지 않았을 수도 있습니다).-jtsampson

편집하다:2010-03-12 John Skeet의 답변은 MD5 제안에 따라 적절했지만(디버깅을 끄려면 -g:none 참고) 내 답변을 곧 게시할 예정입니다.기술적인 측면만 다루었지만.-jtsampson

2010-03-15 아래에 내 답변을 추가했습니다."안전하다"는 의미는 Java 코드의 기능이 영향을 받지 않는다는 의미입니다.Java 컴파일러에 대한 간단한 연구를 보면 이것이 사실임을 알 수 있습니다(몇 가지 주의 사항 있음).이러한 경고는 "공백에만 해당"되었으며 여러 포스터에서 지적되었습니다.그러나 이것은 BizOps에 설명하고 싶은 내용이 아닙니다.내 목표는 "이 일을 정당화하는 방법" 유형의 답변을 이끌어내는 것이었고 몇 가지 훌륭한 답변을 얻었습니다.

몇몇 사람들은 소스 제어와 이에 수반되는 "재미"에 대해 언급했습니다.나는 그 상황이 이미 (내 맥락에서) 잘 이해되었기 때문에 특별히 언급하지 않았습니다."주유소" 효과를 조심하세요.아래 내 답변을 참조하세요.

해결책

단지 재구성이라면 컴파일러 출력을 변경하지 않아야합니다. 해시를 가져 가기 (MD5 개혁 전후의 빌드의 충분히 좋을 것입니다. 모든 파일에 대해 동일하다면, 즉 행동이 변경 될 수는 없다는 것을 의미합니다. 테스트 등을 실행할 필요가 없습니다. - 출력이 바이트의 바이트 인 경우 테스트가 어떻게 실패하는지 알기가 어렵습니다. (물론 그것은 쇼를 위해 테스트를 실행하는 데 도움이 될 수 있지만, 동일한 바이너리가하지 않을 것이라는 것을 증명하지는 않을 것입니다.)

편집 : 주석에서 지적한 바와 같이, 바이너리에는 줄 번호가 포함되어 있습니다. 컴파일하는지 확인하십시오 -g:none 디버그 정보를 생략합니다. 그런 다음 라인 번호 변경에도 괜찮을 것입니다. 그러나 변경하는 경우 이름 그것은 더 심각한 변화이며, 실제로 깨진 변화 일 수있는 변화입니다.

나는 당신을 가정하고 있습니다 ~할 수 있다 어떤 사람을 돌보지 않고 개혁과 재건 - 재구성 된 코드를 소스 제어로 다시 확인하면 우려의 사례가 필요합니다. 나는 아니에요 생각한다 Java 클래스 파일에는 빌드 날짜 등을 제공하는 것이 있습니다. 그러나 "서식"이 필드 순서 등을 변경하는 경우 ~할 수 있다 큰 영향을 미칩니다.

다른 팁

비즈니스 환경에서는 두 가지 과제가 있습니다.

인위적인
정치적인

기술적 관점에서 보면 리포터는 성숙한 기술입니다.해싱/체크섬과 결합하여 언어가 공백을 구분하지 않는 한 기술적으로 안전합니다.또한 주요 포크가 병합되기를 기다리고 있지 않은 가동 중지 시간 중에 이 작업을 수행해야 합니다.실제 변경 사항은 다시 포맷하는 것과 분리할 수 없으므로 별도로 수행하십시오.포크 작업을 하는 사람에게는 병합이 매우 어려울 수 있습니다.마지막으로, 완전한 테스트 사례 적용 범위를 구현한 후에만 이를 수행하겠습니다.이유 2 때문에...

정치적으로 경영진을 설득하는 방법을 모른다면 그것이 안전하다는 것을 어떻게 알 수 있습니까?더 구체적으로 말하면 그것은 당신에게 안전합니다.상점의 프로세스를 제어하는 신뢰할 수 있는 선배 개발자에게는 더 쉬운 일이지만 대규모의 정치적, 관료주의 조직에서 일하는 개발자의 경우 모든 작업을 다루어야 합니다. 기지.

2010년에 제가 했던 주장은 어쩌면 너무 영리한 것일 수도 있습니다. 하지만 파서, 재포맷기, 예쁜 프린터는 단지 소프트웨어일 뿐입니다.특히 C++인 경우 코드베이스에 의해 발생한 버그가 있을 수 있습니다.모든 곳에서 단위 테스트가 없으면 대규모 코드베이스를 사용하여 최종 결과가 동일하다는 것을 100% 확인하지 못할 수도 있습니다.

개발자로서 저는 편집증이 있어서 그 아이디어가 저를 불안하게 만듭니다. 하지만 다음을 사용하는 한:

소스 제어
적절한 테스트 범위

그렇다면 당신은 괜찮습니다.

그러나 다음 사항을 생각해 보십시오.경영진은 이제 당신이 "대량 변경"으로 백만 라인 프로젝트를 방해하고 있다는 것을 알고 있습니다.이전에 발견되지 않은 버그가 재포맷 후에 보고됩니다.이제 당신이 이 버그를 일으킨 유력 용의자입니다."안전하다"는 것은 여러 가지 의미를 갖습니다.귀하와 귀하의 직업에 안전하지 않을 수도 있습니다.

진부하게 들리겠지만, 몇 년 전에 이런 일이 있었던 것으로 기억합니다.재구성과 재부팅만 수행한 야간 유지 관리 기간 다음 날 버그 보고서가 도착했습니다. IIS 섬기는 사람.며칠 동안 내가 망쳤거나 새로운 코드를 배포했다는 이야기가 돌았습니다.직접적으로 말한 사람은 없지만 부사장님이 그렇게 말씀하시는 모습을 보았습니다.우리는 마침내 코드에 이미 있었고 이전에 푸시되었지만 QA 담당자가 최근 테스트 케이스를 변경할 때까지 나타나지 않았던 버그를 추적합니다. 그러나 솔직히 일부 사람들은 그 부분을 기억하지도 못합니다.그들은 다음날 새로운 버그가 발견된 것을 기억할 뿐입니다.

편집하다:에 대한 응답으로 jtsampson의 편집.귀하의 질문은 그것을 수행하는 방법에 관한 것이 아닙니다."안전하다고 경영진을 설득하는 방법"이었습니다.아마도 당신은 그 대신에 "안전합니까?"라고 물어봤어야 했을 것입니다.그렇다면 어떻게 해야 안전하게요." 내 말은 당신이 방법도 모르고 안전하다고 생각했다는 점에서 당신의 질문이 아이러니하다는 것을 지적하고 있었습니다.재포맷의 기술적인 측면은 높이 평가하지만, 사소하지 않은 일에는 위험이 수반되며 올바른 사람을 배치하지 않으면 문제가 발생할 수 있음을 지적하고 있습니다.이 작업이 프로그래머의 다른 작업을 방해하고 며칠 동안 다른 작업을 방해하게 됩니까?다른 코더의 커밋되지 않은 개정판과 충돌합니까?소스가 수정 중인가요?다음과 같이 공백을 구분하는 내장 스크립트가 있습니까? 파이썬?무엇이든 예상치 못한 부작용이 있을 수 있습니다.우리 환경에서는 지점에서 작업하는 사람이 없는 시간대를 확보하기가 어려울 것이며 대량 재포맷으로 인해 병합이 꽤 보기 흉해집니다.그러므로 나는 수동으로 또는 자동으로 대량 재형식화하는 것을 싫어합니다.

실용적인 접근법을 사용하십시오.

응용 프로그램을 구축하십시오.
응용 프로그램을 저장하십시오.
코드를 재 포장하십시오.
응용 프로그램을 구축하십시오.
바이너리를 차별화합니다.

나는 네 단어를 사용할 것입니다.

소스 제어. 단위 테스트.

글쎄, 그것은 전혀 안전하지 않으며 당신은 그들을 설득 할 것 같지 않습니다. 많은 개발을 관리 한 사람으로 말하면 나는 수익에 의존하는 상업 코드베이스에서 결코 그것을 고려하지 않을 것입니다. 나는 당신이 좋아하는 방식으로 코드 형식의 장점이 없다고 말하는 것은 아니지만, 서식에 일부 코드 변경이 포함되지 않을 가능성은 NIL입니다. 즉, 거의 이득이 거의없는 위험이 있다는 것을 의미합니다. 당신이 그것을해야한다면, 당신이 코드를 수정 할 때 단편적으로 행동하십시오. 큰 타격으로 그것을하지 마십시오. 프로그래머로서 당신에게 좋은 결정 일지 모르지만 관리로서 그들에게는 끔찍한 결정이 될 것입니다.

우리는 여기서 어떤 경영진에 대해 이야기하고 있습니까? 그들은 코드 형식이 무엇인지, Java가 공백을 어떻게 다루는 지 이해할만큼 기술에 정통합니까? 그렇지 않은 경우, 나는 그들이 그러한 기술적 결정을 내릴 자격이 없다고 생각합니다 (즉, 그러한 질문은 코드를 담당하는 사람에게 위임해야합니다).

그러나 그들이 당신의 "건축가"또는 비슷한 사람을 설득하려고한다면, 그것은 타사 도구를 신뢰하는 것입니다. Formatter를 코딩하지 않았기 때문에 할 수있는 일이 많지 않은 것 외에는 평판이 좋은 형식을 제안하십시오.

사이드 트랙으로 일화를 공유하겠습니다. 우리 건축가는 한 번에 모든 파일을 재구성하기로 결정했습니다. 수천 개의 Java 파일 중 하나는 아직 발견되지 않았습니다 (그리고 이것은 반년 전이 전였습니다). 이것은 Java 소스 코드에 대한 Eclipse의 Formatter를 신뢰하게 만듭니다. 이 형식의 이점은 다음과 같습니다.

일부 형식화 된 클래스는 이제 읽기가 더 쉽습니다.
모든 곳에서 동일한 형식.

그러나 그것은 또한 부정적인 측면을 가졌습니다.

코드 포피터는 완벽하지 않습니다. 때로는 수동으로 포맷 된 코드가 더 잘 읽습니다. 특히 형성자는 특히 나쁜 코드 (너무 긴 줄, 너무 많은 중첩 IFS 등)로 어려움을 겪고 있습니다.
때때로 패치 해야하는 이전 버전과 같은 다른 코드 분기가 있습니까? 코드 스타일이 다른 브랜치간에 병합되는 것을 잊을 수 있기 때문입니다 (적어도 SVN을 사용할 때).
모든 파일 (그리고 때로는 거의 모든 줄)을 만지고 모든 파일의 기록을 한 번에 망치고 있습니다. 추적 성을 아프게합니다.
실제로 각 개발자가 자신의 코드 형식을 가지고 있다는 점에서는 작은 이점이 있습니다. 그 형식을 배우기 시작하고 즉시 코드의 저자를 식별 할 수 있습니다.

나는 개인적으로 부정적인 것이 긍정적 인 것보다 중요하다고 생각합니다. 그것은 좋은 생각처럼 들리지만 실제로는 당신이 생각만큼 많이 얻지 못합니다. 끔찍한 형식의 코드를 발견하면 해당 클래스 나 그 방법 만 재 포장하여 큰 목표를 향한 작은 단계로보십시오.

개혁 후 단위 테스트가 통과됩니까? 그렇다면 아이디어를 경영진에게 팔았습니다!

테스트되지 않은 코드로 돌아 다니면 훨씬 어려운 사례가 생길 것입니다.

당신은 원합니다 "회사의 코딩 표준을 준수하는 코드" sic] 그리고 경영진을 설득하고 싶습니까?

사소한 : 설치 체크 스타일, 프로세스의 일부로 만들고, 코딩 가이드 라인을 공급하고, 전체 코드베이스를 비참하게 보여줍니다. 실패합니다 ~에 체크 스타일.

이것은 기술 사료 불일치의 좋은 예입니다.

기술인은 코드를 읽기 어렵게 만들 수 있지만, 그렇지 않으면 예외적으로 나쁜 이유는 평균 프로그래머의 전형적으로 섬세한 감성과 미학을 화나게하기 때문입니다.

비즈니스 사람들은 위험을 관리하기를 원합니다. 이점이 있고 없으면 위험을 수행 할 수 있습니다. 사업 정직한 소스 코드로 향후 개발을 수행하는 것이 더 저렴하고 빠르거나 덜 위험 할 것이라고 주장하지 않는 한 여기서 혜택을 누리십시오.

거의 정의에 따라 모든 변경 사항에는 위험이 첨부됩니다. 여기의 위험은 원격이지만 거의 상승없이 경영진의 관점에서 볼 수 없음 (경영의 관점에서)이 아닙니다.

고려해야 할 또 다른 문제가 있습니다. 이런 종류의 변화는 소스 제어와 혼란을 초래할 수 있습니다. 가장 최근의 라인으로의 변화는 재구성이 될 것이기 때문에 누가 변경되는지 추적하기가 어려워 지므로 간단한 "비난"또는 "주석"명령보다 다소 지루한 개정을 비교해야합니다.

또한 여러 활성 분기가있는 경우 코드의 개혁이 합병과 혼란을 야기합니다.

순수한 서식 변경은 편집 된 내용에 차이가 없으므로 런타임시 코드의 동작에 차이가 없다는 점에서 안전합니다.

나중에 소스 컨트롤을 다룰 때 코드의 대량 재구성이 "재미"로 이어질 수 있다는 것을 기억할 가치가 있습니다. 여러 동료가 코드를 체크 아웃하고 한 팀원이 와서 개혁을하면 모든 사본이 오래된 것입니다. 더 나쁜 것은, 그들이 작업 사본을 업데이트 할 때, 모든 충돌 방식이 나타날 것입니다. 이러한 형식의 변화는 코드의 막대한 부분에 영향을 미치고 악몽이 될 수있는 해결이 있기 때문입니다.

코드 개혁은 단어로 문서를 재구성하는 것과 동일합니다. 레이아웃과 가독성이 변경되지만 내용은 변경되지 않습니다.

모든 파일이 동일하게 형식화되면 코드가 더 많아집니다. 읽을 수 있습니다, 유지 보수는 조금 더 쉽고 저렴합니다. 또한 코드 리뷰가 더 빠르고 효과적 일 수 있습니다.

또한 좋은 형식 스타일이 주어지면 숨길 수 없으므로 버그는 더 쉽게 찾을 수 있습니다. 상상의 버팀대가없는 진술과 그 상상의 버팀대 내에서 2 개의 진술이 있는지 생각해보십시오.

똑똑하고 코드를 확인하고 재구성하기 전에 코드를 확인하십시오. 따라서 다른 변경없이 다시 돌아가서 다시 확인하고 다시 체크인하고 태그를 지정하는 상태가 있습니다.

경영진을 위해 이러한 질문에 답변하면 안전한 변화라고 설득하는 데 큰 도움이 될 것입니까?

좋은 서식이 중요한 이유는 무엇입니까?
어떤 변화가 이루어질까요? (대답 할 수 없다면, 당신은 그것이 안전하다는 것을 알기 위해 재식에 대해 충분히 알지 못합니다)
우리의 단위 테스트 스위트가 변경에 악영향이 없다는 것을 증명할 것인가? (답을 힌트를 힌트해야합니다)
기존 코드가 소스 리포지토리에 태그를 지정하여 빠른 롤백 옵션이 있습니까? (대답을 더 나은 힌트 yes 예)

그것에 대해 그것을 다루고 있습니다.

사실, 나는 아마도 그들의 편에있을 것입니다. 생산으로 돌아 가기 전에 철저히 테스트 될 때 수정 또는 향상을 위해 개방 할 때 개혁 단위. 그들은 처음으로 올바르게 형식화되어야했지만 생산중인 경우 스타일을 위해서만 그들을 재구성하는 데 불필요하고 무모하게 보입니다.

일관성은 좋지만 "어리석은 일관성은 작은 마음의 호고 블린"입니다.

매니저 모자를 입고있어 ...

하나의 그랜드 프로젝트로서, 나는 논쟁에 관계없이 당신이 그것을 할 수 없을 것입니다. 그러나 이러한 서식 변경 사항을 포함하도록 기존 파일을 수정하기 때문에 변경 사항에 대한 더 긴 추정치가 열려 있습니다. 그래도 포맷 변경을 자체 체크인을 변경해야합니다.

모든 답변에 감사드립니다.

경영을 설득하는 나의 마지막 주장; 모든 응답의 비트가 포함되었습니다. 도움을 주셔서 감사합니다.

전문인:

Reformat은 공백 변경으로 구성됩니다 (가져 오기 재정의 없음, 멤버/방법 없음)
Reformat은 [도구 및 프로세스 지정]을 사용합니다.
개혁은 [병합 충격을 최소화하기 위해 코딩주기 내에서 시간을 지정합니다].

개혁 전과 후에 :

모든 단위 테스트가 통과됩니다
모든 통합 테스트가 통과됩니다
모든 기능 테스트가 통과됩니다
모든 SOAP-UI 테스트가 통과됩니다
바이트 코드는 동일합니다 (Javac (-g : none)에 따른 .class 파일의 MD5).

사업:

목적 : 소스 파일이 코드의 논리적 구조를 정확하게 나타내는 회사 표준을 준수합니다.

개혁 변경 대 코드 변경 (위와 같은 단어 문서 예)
Reformat은 [일반 프로세스]를 사용합니다.
Reformat은 [영향을 최소화하기 위해 비즈니스주기 내에서 시간을 지정합니다

파일럿 테스트 :

확인 된 "형식 배치"는 "Code에 따라 형식"보다 합병 충돌이 줄어 듭니다. .
실행 가능한 코드 (4K+ .class 파일)가 동일하게 유지된다는 것을 확인했습니다. (MD5 테스트)
확인 된 기능은 영향을받지 않습니다 (자동 테스트/연기 테스트)
확인 된 Formatter 설정에는 공백 변경 만 포함됩니다.

메모: 필자의 경우 파일럿 테스트는 자동화 된 도구를 사용하여 "코드로 형식"(위의 답변에 의해 규정 된대로)을 사용하여 개발자의 하위 집합에 의해 6 개월 동안 실행되었습니다. 일부는 개혁이 더 많은 합병 갈등을 일으킨다 고 인식했지만 실제로는 그렇지 않았습니다.

이 인식은 개혁의 시간적 우연의 일치에 기초했다. 예를 들어, 자동차에 대해 전혀 모르는 사람을 고려하십시오. 어느 날 브레이크가 실패합니다. 그들은 원인에 어떤 영향을 미칩니 까? 물론 가스. 그들이 자동차에 마지막으로 넣은 것이 었습니다 ( "주유소"효과?). 그러나 분명히 브레이크와 연료 시스템은 서식 및 코드 변경과 마찬가지로 이질적인 시스템입니다. 우리는 빌드 프로세스의 맥락에서 부적절한 체크인이 잘못이라는 것을 알았습니다.

마지막으로 나는 누군가가 비즈니스에 ROI를 보여주기가 어렵 기 때문에 누군가가 일반적인 코드와 관련된 생산성 이득을 보여주는 연구와 좋은 링크를 제공하기를 바랐습니다. 내 경우에는 회사 표준이기 때문에 나는 내 편에 "준수"를 가졌다. 나는 "당신이 코딩 할 때 형식"대 "배치 형식"에 더 많은 시간이 걸렸다는 것을 보여 주어야했다.

사용중인 경우 식 개발 플랫폼으로서 모든 코드를 로컬로 작업 공간에로드 할 수 있습니다. 경영진에게 문제 탭을 표시하여 문제가 없음을 보여줍니다.

그런 다음 각 프로젝트를 하나씩 마우스 오른쪽 버튼으로 클릭하고 포맷하십시오. 다시 한 번 문제가 발생하지 않음을 보여줍니다.

저장소에 전혀 해를 끼치 지 않고 로컬 워크 스테이션에서이를 수행 할 수 있습니다.

솔직히 경영진이 소스 코드를 형식화하는 것을 두려워 할 정도로 기술이 아닌 경우, 형식이 여전히 정상임을 보여주기에 충분한 문제 탭에 문제가 나타나지 않음을 보여줍니다.

말할 것도없이 당신은 아마도 기존 버전이 소스 컨트롤에 태그가 붙어있을 것입니다.

생각의 학교는 묻지 않고 그것을하는 것입니다. 그런 다음 "보라!"

물론 당신이 그것을 모두 망쳐 놓으면 해고 될 것입니다. 당신은 당신의 선택을합니다 ...

또는 소스 제어 (또는 간단한 백업)를 사용하면 언제든지 롤백 할 수 있습니다.

코드에 충분한 100% 코드 커버리지가 있으면 위험이 약간 낮아질 수 있다고 생각합니다.

그러나 경영진이 코드 기반이 안전하다는 데 동의하더라도, 직원에게 직원에게 지불하는 데 시간을 내야하는 데 시간을 보내야한다고 생각합니다. 수명주기.

우리는 현재 직장에서 Jalopy를 사용합니다. 그것은 매우 견고한 제품이며 실제로 깔끔한 출력을 생성합니다. 여기에서 가장 선임 개발자는 CVS에서 SVN으로 마이그레이션했을 때 모든 코드 기반을 재구성했으며, 처음부터 끝까지 작동하는지 확인하기 위해 일부 테스트를 수행해야했으며 이제는 확인을 위해 고리가 있습니다. 코드는 올바르게 형식화되어 있습니다.

즉, 나는 그러한 도구가 없기 때문에 어떤 도구가 바보 (또는 잘못) 증거라고 확신 할 수 없다고 생각합니다. 혜택이 시간의 가치가 있고 (매우 작은) 위험이라고 생각한다면,이를 수행 할 때 가장 큰 이점을 경영진에게 설득하십시오. 저에게 가장 큰 장점은 다음과 같습니다.

모든 개발자는 동일한 형식 설정을 가지고 있습니다.
소스 코드의 서식은 SCM의 후크로 체크인시 확인됩니다.

위의 작업을 수행하는 경우 코드가 이미 형식화되어 있으면 SCM의 개정을 비교할 때 변경 사항을 형식화하는 것이 아니라 프로그램의 논리에 실제 변경 사항이 표시됩니다.

단위 테스트의 적절한 커버리지가 있으면 테스트 결과가 충분합니다.

단 하나의 특정 헤드 업 : 회사 정책에 알파벳 회원 분류가 포함 된 경우 정적 필드의 순서가 중요하다는 점에 유의하십시오. 따라서이 작업을 수행하는 온도 또는 정리 규칙을 포함하면 코드를 중단 할 수 있습니다.

기술적으로, 컴파일의 첫 번째 단계에서 어휘 분석기는 소스에서 모든 주석과 공백을 제거합니다.이는 컴파일러가 코드의 의미를 인식하기 오래 전입니다.따라서 공백이나 주석은 프로그램 논리의 어떤 것도 변경할 수 없습니다.반대로, 언어가 어떤 용도로 사용될 것이며, 몇 개의 공백이나 개행 문자를 추가하면 언어의 의미가 변경된다면 누가 언어를 사용하겠습니까?

비즈니스 측면에서는 이를 위해 전문적인 도구를 사용할 수도 있습니다.나는 그들이 훌륭하게 작동한다고 웹사이트에 광고한다고 확신합니다.

최종 참고사항:경영진을 설득해야 한다면 더 똑똑한 사람들과 함께 일할 수 있는 방법을 찾아야 할까요?

나는 경영진에게 코드가 작동한다고 믿기위한 현재의 근거가 무엇인지 묻습니다. 그런 다음 동일한 도구 (테스트, 문서, 작은 목소리 ...)가 개혁 된 코드에서 정확하게 작동 함을 보여줍니다. 나는 그들의 대답이 "테스트"가되기를 원합니다 ...

나는 이전 답변이 모두 괜찮다는 것을 알고 있지만 여기에 또 다른 가능한 답이 있습니다. CRC 개혁 전후에 편집 된 버전에서. 컴파일은 공백, 탭, 라인 피드 등을 무시하기 때문에 컴파일 된 버전은 원본과 동일해야하며, 이는 반 기술 관리자에게 모든 것이 잘된다는 것을 증명할 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow