Kod üretimi kod kalitesini artırır mı?


12

Kod üretimi için tartışırken, kod kalitesini artırdığı yolların bazı örneklerini arıyorum. Kod üretimi ile ne demek istediğimi açıklığa kavuşturmak için, sadece bir projem hakkında konuşabilirim:

Veritabanı şemamızdaki varlık ilişkilerini tanımlamak için XML dosyaları kullanırız, böylece varlıkları eklemek, silmek ve değiştirmek için kullanılabilecek ORM çerçevemizi ve HTML formlarımızı oluşturmamıza yardımcı olurlar.

Bence insan kalitesi azaldığı için kod kalitesini arttırıyor. Bir şey yanlış uygulanırsa, modelde bozulur, bu da iyidir, çünkü daha fazla oluşturulan kod da bozulduğundan hata daha erken görünebilir.

Kod kalitesinin tanımlanması istendiğinden , bunu açıklığa kavuşturayım, demek istediğim yazılım kalitesidir .

Yazılım Kalitesi : Bir özellik değil, birbirini etkileyen verimlilik, değiştirilebilirlik, okunabilirlik, doğruluk, sağlamlık, anlaşılabilirlik, kullanılabilirlik, taşınabilirlik gibi pek çok özelliktir.


3
Kod kalitesi tanımınız nedir?
NoChance

@EmmadKareem Orijinal soruya kısa bir tanım ekledim.
platzhirsch

1
Otomatik kod oluşturmanın kodunuzdaki tutarlılığı ve bütünlüğü artırmaya yardımcı olacağını düşünüyorum. Bazı durumlarda bu kaliteyi artırır ancak bunun bir yakalama olduğunu düşünmüyorum.
joshin4colours

Yanıtlar:


38

Kod üreticileri, jeneratörü yazan kişiden daha iyi kod üretemez.

Kod üreteçleriyle ilgili deneyimim , oluşturulan kodu düzenlemek zorunda kalmadıkça sadece iyi olmalarıdır . Eğer bu kurala dayanabilirsen, o zaman gitmek iyidir. Bu, gerektiğinde otomatik olarak daha fazla özellik ekleyerek, sistemin bu bölümünü güvenle ve hızla güvenle yeniden oluşturabileceğiniz anlamına gelir. Sanırım bu kalite için geçerli olabilir.

Bir keresinde tek bir programcının günde çok fazla kod satırı üretebileceği ve kod üreteçleri ile binlerce satır üretebileceği konusunda kod üreticileri için bir argüman duydum! Açıkçası jeneratörleri kullanmamızın nedeni bu değil.


6
+ italik bölüm bin defa. Kod üreteçleri derleyiciniz veya C ++ şablon mekanizması gibi çalışmalıdır: çıkışlarını asla manuel olarak düzenlemeniz gerekmez. Çıktıyı okumanız gereken tek zaman, bir hatadan şüpheleniyorsanız.
anon

1
Daha fazla oy kullanamayacağım bir utanç ...
Fabricio Araujo

@anon: Homans, genellikle kod üreteçlerinin veya derleyicilerin çıktılarını düzenlememelidir, ancak bazen bazı değişiklikler uygulayan bir program aracılığıyla makine tarafından üretilen bir parçanın çalıştırılmasını gerektiren bir oluşturma işlemine sahip olmak bazen makul olabilir. Ayrıca, minimum sayıda bayt değiştirilirken alanlı kodu yamalamak gerekirse, bir oluşturma işleminin çıktısını insan eliyle düzenlemenin gerekli olabileceği durumlar da vardır, ancak kod bu şekilde elle ayarlandığında, Ayrıca derleme işleminden tüm dosyaları arşivleyin (sadece kaynak değil!) ve ...
supercat

... ayrıca kaynak kodunu elle düzenlenen nesne kodunun anlamıyla eşleşecek şekilde güncelleyin.
supercat

20

Ben tam tersini iddia ediyorum - ilginç uygulamalar yazdığınızı varsayarsak, kod üretimi kod kalitesini düşürür. Kod oluşturmanın doğası, sürekli olarak daha büyük, daha karmaşık, daha çirkin kod grupları oluşturmak için kod oluşturma aracına sürekli olarak güvenmeksizin uğraşması çok zorlaşan çok çerez kesici, aşırı şişirilmiş, aşırı belirlenmiş çerçeveleri ödüllendirir. İyi bir araç olsa da, gerçekten kutudaki birincil araç olmamalıdır.


3
Bazı ORM'lerden çıkan çöp (iyi performans gösteren veritabanı kodunun nasıl yazılacağını bilen birinin bakış açısıyla çöp) iyi bir örnektir. Genellikle işe yaradığını düşünmek için ne yaptığını bilmeyen biri için yeterince çalışır. Ve yeni programcılar jeneratör dışında yapılması gereken daha zor şeyleri yapma becerisine sahip değiller, çünkü temel kavramları anlamıyorlar.
HLGEM

1
Ooh, +1 veya -1 .... bir yandan kod üretimi, sadece kod içine genişletilmiş bir tanımınız olan sıkıcı tekrarlayan kodu kaldırmak için çok yararlıdır, ancak daha sonra her şekilde aşırı kullanıldığını haklıyorsunuz Kendi içinde bir anti-desen oluşturan 'zaman kazandıran' karmaşıklık.
gbjbaanb

13

Otomatik kod üretimi ve kod kalitesinin biraz dik olduğunu ve birbiriyle ilintili olmadığını düşünüyorum.

Kod üretimi yalnızca belirli bir teknik görevi çözmenin bir yoludur. Kod kalitesinin artmasıyla sonuçlanıp kaynaklanmadığı, ne yaptığınıza bağlıdır.

Durumunuz, olası hataların erken yakalanmasıyla kod kalitesinin artmasına neden olan iyi bir kod oluşturma örneğidir.

Otomatik kod üretimi kod kalitesini düşürdüğünde size başka bir örnek verebilirim. Yüce ASP.NET WebForms çıktı. UI kontrolleri hiyerarşisini, sabit, öngörülebilir ve yönetilebilir olan her şey olan HTML işaretlemesine çevirerek otomatik kod üretimi yapar.

Sonuç olarak, otomatik kod üretimi doğru kullanıldığında kod kalitesinin artırılmasına yardımcı olabilir.


11

Kod nesil kodu etkilemez kalitesini başına, o kadar çok gibi kod tutarlılık .

Oluşturulan kod, üretim örnekleri arasında tutarlı olacaktır. Jeneratör kaliteli kod verecek şekilde tasarlanmışsa, üretilen kod sürekli olarak iyi kalitede olacaktır. Bununla birlikte, kod üreticisi kötü kalite kodu verirse, sürekli olarak kötü kod alırsınız.

Kod oluşturma, kodu daha hızlı oluşturmak için de kullanılabilir . Bununla birlikte, daha hızlı, daha iyi anlamına gelmez ... Bu, kötü kalite kodunuzu daha hızlı aldığınız anlamına gelebilir.


6

Kod oluşturma aşağıdaki durumlarda iyidir:

  • oluşturulan kodun düzenlenmemesi gerekiyor
  • kod üreteci, yapmanız gerekenleri yapmanız için yeterli esneklik sağlar
  • kod üretecinin giriş dili, aksi takdirde yazmak zorunda olduğunuzdan daha iyidir (örn. KURU)
  • kod oluşturucu, endişeli olsa bile, endişelenmenize gerek olmayan iyi güvenilir bir kod oluşturur

Bu durumda, kalitesini dikkate almanız gereken kod, jeneratöre girilen koddur.

Kalitenin basit bir ölçüsü, gereksinimlerdeki tipik değişiklikler için ne kadar manuel düzenleme yapmanız gerektiğidir. Ne kadar az, o kadar iyi.


ve oluşturulan kodun orijinaliyle şeffaf bir şekilde eşleştiğinden, oluşturulan kodda hata ayıklamanız gerekmez.

@ Thorbjørn: Katılıyorum. Ben korumak zorunda bir app orada Fortran oluşturulur. Hata ayıklama ihtiyacı yıl boyunca kayboldu ve hala hizmet aramalarını alan etrafında olacak kadar aptal tek :) :)
Mike Dunlavey

Kod üretecinin esnek olması gerektiği konusunda hemfikir değilim. Hedeflenmesi gerekiyor - bir şeyi iyi yapın, pek çok şeyi değil. Küçük, iyi tanımlanmış bir girdi almalı ve sizin için bir kod parçası yazmalıdır. Program olmaya başladığında , başarısızlığa yönelir.
gbjbaanb

@gbjbaanb: Katılıyorum. Bu yüzden yeterince esneklik söyledim . Benim için sorun kod üreticisinin kendisi değil, girdisi olarak hizmet veren etki alanına özgü dildir. Bu DSL çok esnekse, kullanıcı seçeneklerde yüzmek zorundadır. Yeterince spesifik değilse, kullanıcı sınırlamaları aşmak zorundadır. Bunlara örnekler verebilirim.
Mike Dunlavey

4

KURU nedeniyle artan kod kalitesi (Kendinizi tekrarlamayın).

Kod oluşturma kuralları bir kez yazılır; üretilen her kod örneği için sabit olarak kodlanmazlar ve böylece içeriği küçük değişiklikler yaparak kopyalama / yapıştırmada insan hatası olasılığını azaltırlar.


Tabii ki hiç DRY olmayan oluşturulan kodu düzenlemek zorunda .... Bunu son zamanlarda yapmak zorunda - hiç hoş değil . Eğer yeniden otomatik olarak oluşturulan bir kod tabanı düzenlemek zorunda olsaydım, üç kez ücret!
Fabricio Araujo

1
Bu kodu hiç düzenlemeniz gerekmez; neslin kendisini yapan kodu düzenleyin ve gerekirse ek kurallarla artırın. Oluşturulan kodun düzenlenmesi en son çözüm olmalıdır.
earlNameless

1
O seçeneğe sahip olmak istiyorum .. Ben yapmadım.
Fabricio Araujo

2

Ben aksi takdirde makine kodu kısa bir şey bir kod üreteci olduğundan belirli şirket içi kullanım için handrolled tescilli kod jeneratörleri demek varsayıyorum. Ama işte gidiyorsunuz:

resim açıklamasını buraya girin

Blueprints'teki düğüm grafiğinin daha kolay ve ürettiği GLSL / HLSL kodundan daha az hataya meyilli olduğunu ve aksi takdirde el yazısının gerekli olacağını düşünüyorum.

Ayrıca, yeni gölgelendiriciler bulmak çok daha verimlidir, çünkü grafiği değiştirirken nihai sonucun nasıl göründüğüne dair gerçek zamanlı bir görsel geri bildirim alırsınız. Kesinlikle GLSL / HLSL kodu yerine bu şekilde düğüm grafiklerle temsil edilen binlerce gölgelendiriciyi korumayı tercih ederim ve aslında GLSL / HLSL yazmayı Blueprints kullanmaktan daha çok tanıyorum. Sanırım muhtemelen hemen yakalayabileceğiniz bazı küçük görsel aksaklıkların yanı sıra büyük bir hataya neden olmanın neredeyse imkansız olduğunu düşünüyorum çünkü "görsel dil", genellikle size izin vermeyen saf bir işlevsel stille mantıklı kısıtlamalar getiriyor. bir gölgelendiriciyi çökert, en azından AFAIK (Kuşkusuz Blueprints konusunda uzman değilim).

Artık sürdürmek için "kod" bile yok. Sadece bir grafiğin içine düğümler yerleştirirsiniz ve aralarında bağlantılar çizersiniz ve işte, sizin için gölgelendirici kodu oluşturur. Bunu kim sürdürüyor ve şöyle diyor, " Biliyorsunuz, hayatım çok daha kolay olurdu ve eğer bu Blueprints kullanmak yerine GLSL koduyla yazılmış olsaydı çok daha fazla boş zamanım olurdu. " Muhtemelen asla.

Yani, hayatı zorlaştıran tescilli kod üreteçleri payına düştüm, bu da bana üretilen kodun dilinde kod yazarken çok sınırlı faydaları olan bu aptal meta dili öğrenmemi sağladı. Bana göre, boktan bir kod oluşturma işareti, küçük bir kazan plakasını azaltmaktan biraz daha fazlasını yapan ve aslında hata olasılığını azaltmayan bir işarettir. Orijinal dilin sahip olmadığı hatalara neden olmanın yeni yollarını sunması özellikle boktan bir şey. Ancak, yukarıda belirtildiği gibi, verimlilik artışının bu kadar büyük olduğu kod üretimi için vakalar var, bu da şimdi çok büyük zamana mal olan titiz şeyler üretiyor, hiç kimsenin kullanamayacağı ve sonra geriye bakmayacağı.

Bana göre, Epic ekibi arasında Blueprints'in tescilli gelişimi için, masaya yeni bir şey getirmeyen genel halk için yapılan birçok gereksiz programlama dilinden daha yasal bir argüman var.


1

Durumunuzda kaliteyi biraz artırabileceğini söyleyebilirim, ancak geliştirme süresini çok azaltır. Bazen üretilen kod kesintili, garip veya sadece kötüdür. Bu durumlarda, oluşturulan kod kaliteyi düşürebilir ve projeye daha fazla test / düzeltme / regresyon test süresi ekleyebilir. Ve bazı görevler kolayca oluşturulamayacak kadar karmaşıktır - jeneratör kendi başına tamamen ayrı bir sistem (muhtemelen ana projeden daha büyük ve daha karmaşık) haline gelir.

Kod üreticileri iyidir, ancak bunlara dikkat edin!


1

Eskiden kod üretimine yoğunlaşan bir dükkanda çalışıyordum. Bana göre projenin kodunu çok düzgün hale getirdi. Ve bu bakımdan kalite iyiydi.

Ancak, artık özel kod yazma izniniz olmadığında, çünkü her şey jeneratörden geçmelidir, o zaman bir programcı olmanın bazı kenarlarını kaybettiğinizi düşünüyorum.

Bu yüzden bence bu iki uçlu bir kılıç konusu. Evet jeneratörler harikadır, çünkü hataları azaltırlar ve kod standartlarını arttırırlar, fakat aynı zamanda programcıların “bir kısmını” aptal yaparlar, çünkü ellerini kirletmek yerine jeneratörlere güvenirler.

Sadece 2 sentim.


3
Derleme dili programcıları derleyiciler hakkında bunu söylerdi. Bu yüzden bunun büyük bir tartışma olduğundan emin değilim. Ellerinizi kirletmek zorunda kalmak iyi bir öğrenme deneyimi olabilir, ancak öğrendikten sonra mevcut en üretken aracı kullanmalısınız.
MarkJ

@MarkJ: Bazen montaj tekdüzelik için derlenmiş bir dilden daha iyi olabilir. Örneğin, bazı gömülü sistemlerde, eşdeğerini kodlamak ve x=someValue ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;dört XOR-literal komutla kodlanmasını sağlamak yararlıdır . Kod depolama ortamı yalnızca boş (0xFF) bayt yazabiliyorsa, yukarıdaki yapı değerde dört rasgele değişikliğe izin verir. Bir kişi ifadeyi şu şekilde yeniden x=someValue; x = x ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;yazmış olsa ve derleyici çalışma zamanında tüm xors değerlerini değerlendirmiş olsa da, yine de bir "tüm bitleri tamamlayıcı" kullanabilir ...
Supercat

... xor-ani değil, talimat.
supercat

1

Martin'in cevabına ek olarak, rekor bir kayıt esasına göre çalıştığınızda SQL kod oluşturma işleminin çok iyi olduğunu da ekleyeceğim (tab1'den tab1.pkcolumn =: parametresini seçin, tab1 setini güncelleyin [herhangi bir sütun sayısı] tab1.pkcolumn =: parametre, vb.). Ve ORM'niz bu senaryoda parlayacak, çünkü üretilmesi gereken SQL gerçekten tekrarlayıcı.

Ana endişelerim metaqueries - nesnenin özellikleri üzerinde ORM'in hangi algoritmayı kullanarak SQL'e çevirdiği sorgular. Çok benzer meta sorgular, tamamen farklı SQL üretebilir ve bu üretilen SQL'in gerçekte olduğunu garanti etmez.

Veri toplamayı etkin bir şekilde yürütmek için bir sorgu planına çeviren başka bir dile (SQL) çevrilen bir metaquery dili. Ve üretilen sonuç nesneler olmalıdır, bu yüzden ORM etkilenen nesneleri başlatmalıdır - böylece metaquery tarafından getirilmeyen nesnelerin niteliklerini doldurmak için başka bir sorgu yağmuru tetikleyebilir ...


0

Tamamen oluşturulan kodu düzenlemek (tercihen, asla bakmak zorunda) sürece kod oluşturma iyi olduğunu söyleyenler tamamen katılıyorum.

Oluşturulan kodun elle yazılmış satırların yaklaşık olarak aynı sayıda olduğunu kabul edebilirsek ve bunun hatasız olduğunu söyleyebilirsek, potansiyel olarak hata içerebilecek satır sayısı azalmıştır. Ergo, kod kalitesi artmış olmalı.


Zeyilname: tabii ki, yürütme süresi gibi diğer faktörler de rol oynayabilir.

Şahsen, birkaç kod üreticisi yazdım, ama asla ilk yaklaşım olarak değil.

Her zaman mevcut kodda tekrar eden bir desen fark ettiğimde, bu yüzden jeneratörüm yeni, ancak benzer kod eklerken bazı mevcut kodları alır ve bazı değişken parçalarını parametrelendirir.

Bu kapsamda, oluşturulan kodum mevcut el yazısıyla kodla neredeyse aynıdır (ancak daha iyi görsel olarak ortaya konma ve daha tekdüze olma eğilimi dışında, bakıldığında, okunabilirliği yardımcı olurum).

Btw, kodun oluşturulduğunu belirten açılış ve kapanış açıklamaları eklemeyi savunuyorum, aracın detayları ve bakıcısı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.