답변:
다음과 같이 바꾸어 보자.
좋은 자동 코드 생성기의 비용은 가치가 있습니까?
예.
열악한 자동 코드 생성기의 비용이 다른 사람을 위해 더 많은 작업을 생성하지만 그만한 가치가 있습니까?
절대적으로하지. 열악한 코드에 대한 변명은 없습니다. 누군가가 영리하고 자동 코드 생성을 사용하려면 생성 된 코드가 올바른 코드인지 확인하는 데 시간이 걸립니다. 그렇지 않으면 요점이 무엇입니까? 그것은 단지 벅을 막대 아래로 밀어 내고 있으며 코드 생산과 관련하여 벅은 그것을 작성한 개발자에게 멈춰야합니다.
생성기에 의해 생성 된 코드는 손으로 유지해서는 안됩니다. 이를 변경해야하는 경우 생성기 및 / 또는 해당 설정을 조정하고 다시 실행해야합니다. 이를 고려하면 생성 메커니즘 자체가 명백한 한 결과 코드가 이해하기 쉽고 문서화되지 않은 것은 중요하지 않습니다. 코드가 생성되었다는 사실과 생성기가있는 위치 및 작동 방식을 문서화해야합니다.
비유 : 컴퓨터의 프로세서가 항상 기계 코드를 실행하는 동안, 고급 언어와 컴파일러를 사용하여 기계 코드를 작성하는 방법을 알고 있다면 그것에 대해 아무것도 알 필요가 없습니다. GCC는 때때로 하위 기계 코드를 생성하지만 완벽하게 작동하는 한 누가 신경 쓰는지 들었습니다. 데이터베이스 추상화 계층은 DB 엔진과 함께 작동하기 위해 SQL을 생성하지만 추상화 계층이 명확하고 작동하는 한 누가 SQL의 모양을 관리합니까?
코드 생성기를 올바르게 사용하면 생성뿐만 아니라 유지 관리 비용도 확실히 절약 할 수 있습니다.
코드 생성기는 일종의 컴파일러입니다. 컴파일러 출력이 얼마나 예쁜지 걱정하지 않고 소스 코드로 작업하면됩니다. 그것을 사용하고 수동으로 수정하는 것은 인간이 이해할 수있는 형태로 처음부터 새로 작성하는 것보다 어렵 기 때문에 많은 작업없이 코드 생성기를 다시 사용할 수 없다는 것을 의미합니다. 이해할 수없는 동일한 코드를 정확하게 변경합니다.
따라서 빌드 프로세스의 일부이고 문서화되어 있으면 괜찮을 수 있습니다. 생성기에 대한 입력은 소스 코드이며 생성되는 것은 중간 결과이며 엉망이 아닙니다.
그러나 누군가가 소스로 사용해야하는 이해할 수없는 코드를 생성하기 위해 하나를 사용하는 경우 그 사람은 잘못된 코드를 생성합니다. 사람이 기계적으로 또는 손으로 잘못된 코드를 생성하는지 여부는 중요하지 않으며 여전히 잘못된 코드이며 여전히 품질 문제가 있습니다.
따라서이를 다른 개발자가 모퉁이를 자르고 잘못된 코드를 작성하는 것으로 취급해야합니다. 가게에서 어떻게 처리하는지 모르겠습니다.
다른 답변에 대한 의견에서 코드 생성기 자체보다는 팀 표준에 대해 묻는 것처럼 보입니다.
코드 생성 도구는 프로젝트에 포함되어야하며 (해당되는 경우) 빌드 프로세스의 일부 여야합니다. 예를 들어 우리 팀은 빌드시 데이터베이스 객체에서 클래스를 생성하는 Subsonic 2.2를 사용합니다.
이 작업을 수행하는 exe는 프로젝트의 일부로 SVN에 체크인되어 팀의 새 구성원이 svn에서 새 프로젝트를 가져 와서 모든 데이터베이스 클래스의 출처를 알 필요없이 즉시 빌드 할 수 있습니다 (이 예에서는 svn에 생성 된 코드를 포함시키지 마십시오).