코드 생성으로 코드 품질이 향상됩니까?

코드 생성을 주장하면서 코드 품질을 향상시키는 방법에 대한 몇 가지 예를 찾고 있습니다. 코드 생성의 의미를 명확히하기 위해 내 프로젝트에 대해서만 이야기 할 수 있습니다.

XML 파일을 사용하여 데이터베이스 스키마에서 엔티티 관계를 설명하므로 엔티티를 추가, 삭제 및 수정하는 데 사용할 수있는 ORM 프레임 워크 및 HTML 양식을 생성하는 데 도움이됩니다.

인간의 실수가 줄어들 기 때문에 코드 품질이 향상됩니다. 잘못 구현 된 경우 모델에서 오류가 발생합니다. 더 생성 된 코드가 손상되어 오류가 더 빨리 나타날 수 있기 때문에 좋습니다.

코드 품질 의 정의를 요청 받았으므로 소프트웨어 품질 이라는 것을 명확히하겠습니다 .

소프트웨어 품질 : 그것은 하나의 속성이 아니라 서로 영향을 미치는 효율성, 수정 성, 가독성, 정확성, 견고성, 이해력, 유용성, 이식성 등과 같은 많은 속성입니다.

코드 생성기는 생성기를 작성한 사람보다 더 나은 코드를 생성 할 수 없습니다.

코드 생성기에 대한 나의 경험 은 생성 된 코드를 편집 할 필요가없는 한, 이것은 훌륭하다는 것 입니다. 당신이 그 규칙을 유지할 수 있다면, 당신은 갈 수 있습니다. 즉, 자신감과 속도로 시스템의 해당 부분을 안정적으로 재생성 할 수 있으며 필요한 경우 자동으로 더 많은 기능을 추가 할 수 있습니다. 품질이 중요하다고 생각합니다.

한 번은 단일 프로그래머가 매일 너무 많은 코드 줄을 생성 할 수 있고 코드 생성기를 사용하면 수천 줄을 생성 할 수 있다는 코드 생성기에 대한 주장을 들었습니다! 분명히 우리가 발전기를 사용하는 이유는 아닙니다.

흥미로운 주장을한다고 가정하면 코드 생성이 코드 품질을 떨어 뜨린다. 코드 생성의 특성은 코드 생성 도구에 지속적으로 의존하지 않고 처리하기가 매우 어려워 져 쿠키 생성기, 과장, 과도하게 지정된 프레임 워크에 큰 보상을줍니다. 좋은 도구가 될 수 있지만 실제로는 기본 도구가되어서는 안됩니다.

자동화 된 코드 생성과 코드 품질은 다소 직교하며 반드시 서로 관련이있는 것은 아니라고 생각합니다.

코드 생성은 특정 기술 작업을 해결하는 방법 일뿐입니다. 코드 품질이 크게 향상되는지 여부는 수행중인 작업에 따라 다릅니다.

귀하의 상황은 코드 생성의 좋은 예이며 잠재적 오류를 조기에 포착하여 코드 품질을 향상시킵니다.

자동화 된 코드 생성이 코드 품질을 떨어 뜨릴 경우 다른 예를들 수 있습니다. 전능 한 ASP.NET WebForms입니다. UI 컨트롤 계층을 HTML 마크 업으로 변환하여 코드 생성을 자동화합니다. HTML 마크 업은 안정적이고 예측 가능하며 관리가 가능합니다.

결론을 도출하기 위해 자동화 된 코드 생성 기능을 올바르게 사용하면 코드 품질을 향상시킬 수 있습니다.

코드 생성 자체는 코드 일관성 만큼 코드 품질에 영향을 미치지 않습니다 .

생성 된 코드는 생성 인스턴스간에 일관됩니다. 생성기가 양질의 코드를 방출하도록 설계된 경우 생성 된 코드의 품질은 일정하게 유지됩니다. 그러나 코드 생성기가 나쁜 품질의 코드를 생성하면 지속적으로 나쁜 코드가 표시됩니다.

코드 생성을 사용하여 코드를 더 빠르게 작성할 수도 있습니다 . 그러나 더 빠르다고해서 더 나은 의미는 아닙니다 ... 나쁜 품질의 코드를 훨씬 빨리 얻는다는 의미 일 수도 있습니다.

다음과 같은 경우 코드 생성이 좋습니다.

• 생성 된 코드는 편집되지 않아야합니다
• 코드 생성기는 필요한 작업을 수행 할 수있는 충분한 유연성을 제공합니다.
• 코드 생성기에 대한 입력 언어는 달리 작성해야하는 것보다 낫습니다 (예 : DRY).
• 코드 생성기는 문제가 없어도 걱정할 필요가없는 안정적인 코드를 생성합니다.

이러한 경우 품질을 고려해야 할 코드는 생성기에 입력되는 코드입니다.

품질의 간단한 척도는 요구 사항의 일반적인 변경에 대한 수동 편집의 양입니다. 적을수록 좋습니다.

DRY 로 인한 코드 품질 향상 (반복하지 마십시오).

코드 생성 규칙은 한 번 작성됩니다. 생성 된 모든 코드 인스턴스에 대해 하드 코딩 된 것은 아니므로 내용을 약간 수정하여 복사 / 붙여 넣기 할 때 사람이 실수 할 가능성을 줄입니다.

기계 코드가 부족한 것이 코드 생성기이기 때문에 특정 사내 사용을 위해 독점적 인 코드 생성기를 수동으로 굴린다 고 가정합니다. 그러나 여기 있습니다.

Blueprints의 노드 그래프가 생성하는 GLSL / HLSL 코드보다 유지 관리가 쉽고 오류가 덜 발생한다는 것은 매우 논쟁의 여지가 있다고 생각합니다.

그래프를 변경할 때 최종 결과가 어떻게 보이는지 실시간 시각적 피드백을 얻을 수 있으므로 새로운 셰이더를 만드는 것이 훨씬 생산적입니다. GLSL / HLSL 코드 대신 노드 그래프로 표현 된 수천 개의 셰이더를 유지하는 것을 확실히 원합니다. 실제로 블루 프린트를 사용하는 것보다 GLSL / HLSL을 작성하는 것이 더 익숙합니다. "시각 언어"는 종종 순수한 기능적 스타일로 현명한 제약 조건을 강요하기 때문에 아마도 바로 잡을 수있는 약간의 시각적 결함 외에도 주요 버그와 같은 원인을 일으키는 것은 실제로 불가능하다고 생각합니다. 적어도 AFAIK (셰이더 충돌) (블루 프린트 전문가는 아닙니다).

더 이상 유지하기위한 "코드"도 없습니다. 그래프 안에 노드를 배치하고 노드 사이에 링크를 그리면 Voila는 쉐이더 코드를 생성합니다. " 이것은 블루 프린트를 사용하는 대신 GLSL 코드로 작성하면 인생이 훨씬 쉬워지고 자유 시간이 훨씬 더 많아 질 것입니다. "

즉, 나는 삶을 더욱 어렵게 만든 독점적 코드 생성기를 공유하여 생성 된 코드의 언어로 코드를 작성하는 것보다 이점이 매우 적은이 바보 같은 메타 언어를 배울 수있었습니다. 나에게 똥 소리가 나는 코드 생성의 흔적은 소량의 상용구를 줄이는 것 이상으로 실제로 버그의 가능성을 줄이는 것이 아닙니다. 원래 언어에 없었던 버그를 일으키는 새로운 방법을 실제로 소개한다면 특히 시끄러운 것입니다. 그러나 위와 같이 생산성 향상이 너무 커서 코드를 작성하는 경우가 있습니다. 엄청난 시간이 걸리는 세심한 것들이 이제는 돈이 많이 들기 때문에 아무도 그것을 사용하지 않고 되돌아 보지 않을 것입니다.

나에게 Epic 팀의 독점적 인 청사진 개발에 대한 합법적 인 주장이 있습니다.이 테이블에 새로운 것을 거의 가져 오지 않는 일반 대중을 위해 만든 많은 불필요한 프로그래밍 언어가 있습니다.

귀하의 경우 품질이 약간 향상 될 수 있지만 개발 시간이 크게 줄어 듭니다. 때로는 생성 된 코드가 벗겨 지거나 어색하거나 평범하지 않습니다. 이 경우 생성 된 코드는 품질을 저하시키고 테스트 / 고정 / 회귀 테스트 시간을 프로젝트에 추가 할 수 있습니다. 또한 일부 작업은 너무 복잡하여 쉽게 생성 할 수 없습니다. 생성기는 자체적으로 전체 시스템 (주 프로젝트보다 더 크고 복잡 할 수 있음)이됩니다.

코드 생성기는 훌륭하지만 조심하십시오!

코드 생성에 크게 의존하는 상점에서 일했었습니다. 내 생각에 그것은 프로젝트 코드를 매우 균일하게 만들었다. 그런 점에서 품질은 좋았습니다.

그러나 모든 것이 생성기를 통과해야하기 때문에 더 이상 사용자 정의 코드를 작성할 수 없으면 프로그래머가 될 수있는 이점을 잃어 버린 것 같습니다.

저는 이것이 양날 칼 주제라고 생각합니다. 그렇습니다. 제너레이터는 오류를 줄이고 코드 표준을 높이기 때문에 훌륭하지만, 프로그래머의 손을 더럽 히지 않고 제너레이터에 의존하기 때문에 프로그래머 중 일부를 바보로 만듭니다.

그냥 내 2 센트.

Martin의 답변 외에도 레코드별로 작업 할 때 SQL 코드 생성이 매우 우수하다고 덧붙입니다 (tab1.pkcolumn = : parameter, update tab1 set [모든 열 수] tab1.pkcolumn = : parameter 등). 그리고 생성해야하는 SQL이 실제로 반복되기 때문에 ORM은이 시나리오에서 빛날 것입니다.

내 주요 걱정은 메타 쿼리입니다. ORM이 알고리즘을 사용하여 SQL로 변환하는 객체 속성에 대한 쿼리입니다. 매우 유사한 메타 쿼리는 완전히 다른 SQL을 생성 할 수 있으며이 생성 된 SQL의 성능이 보장되지는 않습니다.

효과적으로 데이터 수집을 실행하기 위해 쿼리 계획으로 변환하는 다른 언어 (SQL)로 변환되는 메타 쿼리 언어입니다. 생성 된 결과는 객체 여야하므로 ORM은 영향을받는 객체를 인스턴스화해야합니다. 따라서 메타 쿼리 자체가 가져 오지 않은 객체의 속성을 채우기 위해 다른 쿼리를 실행할 수 있습니다.

나는 생성 된 코드를 편집 할 필요가없는 한 (바람직하게 볼 필요가없는 한) 코드 생성이 좋다고 말하는 사람들에게 전적으로 동의한다.

우리는 생성 된 코드 작성 손으로 라인 같은 수의 약, 받아 들일 수 있다면 그리고 우리가 버그가 무료라고 말할 수 있다면, 잠재적 인 버그를 포함 할 수 있습니다 라인의 다음 수는 감소했다. Ergo, 코드 품질이 향상되어야합니다.

부록 : 물론, 실행 시간과 같은 다른 요소들이 중요한 역할을 할 수 있습니다.

개인적으로 필자는 몇 가지 코드 생성기를 작성했지만 초기 접근 방식으로는 결코 사용하지 않았습니다.

기존 코드에서 반복적 인 패턴을 발견했을 때 항상 그렇기 때문에 생성기는 새 코드를 추가 할 때 기존 코드를 가져 와서 유사하지만 코드의 일부를 매개 변수화했습니다.

그 정도로, 생성 된 코드는 기존의 손으로 쓴 코드와 거의 동일합니다.

Btw, 나는 도구 및 유지 보수의 세부 사항을 포함하여 코드가 생성되었음을 나타내는 열기 / 닫기 주석 삽입을 옹호합니다.