Derleme aracı nedir?

Son 4 yıldır Eclipse (Java için) ve Visual Studio Express (C # için) ile programlama yapıyorum. Bahsedilen IDE'ler her zaman bir programcının isteyebileceği her olanağı sağlıyor gibiydi (tabii ki programlama ile ilgili).

Son zamanlarda "araç oluşturma" denen bir şey duyuyorum. Neredeyse her tür gerçek dünya gelişiminde kullanıldıklarını duydum. Tam olarak nedir? Hangi sorunları çözmek için tasarlandılar? Son dört yılda neden onlara hiç ihtiyacım olmadı? IDE'leri azaltılmış bir tür komut satırı mı?

Derleme araçları nelerdir?

Derleme araçları, kaynak koddan çalıştırılabilir uygulamaların oluşturulmasını otomatikleştiren programlardır (örn. Android uygulaması için .apk). Oluşturma, kodu derlemeyi, bağlamayı ve kullanılabilir veya yürütülebilir bir formda paketlemeyi içerir.

Temel olarak inşa otomasyonu, yazılım geliştiricilerin günlük etkinliklerinde aşağıdaki gibi çok çeşitli görevleri komut dosyası oluşturma veya otomatikleştirme eylemidir:

1. Bağımlılıklar indiriliyor.
2. Kaynak kodunu ikili koda derlemek.
3. Bu ikili kodu paketleme.
4. Testler çalıştırılıyor.
5. Üretim sistemlerine dağıtım.

Neden derleme araçları kullanıyoruz veya otomasyon oluşturuyoruz?

Küçük projelerde, geliştiriciler genellikle oluşturma sürecini manuel olarak başlatır. Bu, neyin inşa edilmesi gerektiğini, hangi sırada ve inşa sürecinde hangi bağımlılıkların olduğunu takip etmenin çok zor olduğu daha büyük projeler için pratik değildir. Bir otomasyon aracı kullanmak, inşa sürecinin daha tutarlı olmasını sağlar.

Çeşitli oluşturma araçları mevcuttur (yalnızca birkaçını adlandırır):

1. Java için - Ant, Maven, Gradle.
2. .NET çerçevesi için - NAnt
3. c # - MsBuild.

Daha fazla okumak için aşağıdaki bağlantılara başvurabilirsiniz:

1. Derleme otomasyonu

2. Derleme otomasyon yazılımının listesi

Teşekkürler.

Yapı araçları, yapılarınızı yönetmek ve düzenlemek için kullanılan araçlardır ve birçok projenin olduğu ortamlarda, özellikle de birbirleriyle bağlantılılarsa çok önemlidir. Çeşitli insanların çeşitli projeler üzerinde çalıştığı yerlerde hiçbir şeyi kırmamalarını sağlamaya hizmet ederler. Ve değişikliklerinizi yaptığınızda, hiçbir şeyi bozmamalarını sağlamak için.

Bunları daha önce duymamış olmanızın nedeni, daha önce ticari bir ortamda çalışmamış olmanızdır. Ticari ortamlarda karşılaşacağınız, özellikle yazılım evlerinde çalışıyorsanız muhtemelen karşılaşmadığınız pek çok şey var.

Başkalarının da söylediği gibi, onları kullanıyorsunuz, ancak bunları dikkate almak zorunda kalmadınız, çünkü muhtemelen olağan ticari çalışma yönteminden farklı bir şekilde çalışıyorsunuz.

Derleme araçları genellikle bir IDE'nin içinde veya ondan tamamen ayrı olarak komut satırında çalıştırılır.

Buradaki fikir, kodunuzu derleme ve paketleme işini oluşturma, hata ayıklama vb. İşlemlerden ayırmaktır.

Bir oluşturma aracı, her ikisi de sizin tarafınızdan tetiklenen komutta veya bir IDE içinde çalıştırılabilir. Kodunuzu bir havuzdan ve temiz bir derleme makinesinde kontrol ettikten sonra sürekli entegrasyon araçları tarafından da kullanılabilirler.

make, C / C ++ oluşturmak için * nix ortamlarında kullanılan erken bir komut aracıydı.

Bir Java geliştiricisi olarak, en popüler derleme araçları Ant ve Maven'dir. Her ikisi de IntelliJ veya Eclipse veya NetBeans gibi IDE'lerde çalıştırılabilir. Cruise Control veya Hudson gibi sürekli entegrasyon araçlarıyla da kullanılabilirler.

Derleme araçları genellikle kaynak kodunu ikililere dönüştürmek içindir - kaynak kodunu düzenler, derleme bayrakları ayarlar, bağımlılıkları yönetir ... bazıları ayrıca çalışan birim testi ile entegre olur, statik analiz yapar, bir dokümantasyon üretir.

Eclipse veya Visual Studio aynı zamanda derleme sistemleridir (ancak daha çok bir IDE'dir) ve görsel stüdyo için, görsel stüdyo proje dosyalarını başlık altında ayrıştırmak için temel msbuild'dir.

Tüm yapı sistemlerinin kökeni ünlü 'marka' gibi görünüyor.

Farklı diller için inşa sistemleri vardır:

1. C ++: make, cmake, premake
2. Java: karınca + sarmaşık, maven, gradle
3. C #: msbuild

Genellikle, bir yapı belirtmek için özel bir etki alanına özel dil (make, cmake) veya xml (ant, maven, msbuild) kullanarak sistemler oluşturun. Mevcut eğilim, premake için lua ve gradle için harika gibi derleme komut dosyası yazmak için gerçek bir komut dosyası dili kullanmaktır, komut dosyası kullanmanın avantajı çok daha esnektir ve ayrıca bir dizi standart oluşturmanıza olanak tanır API'ler (DSL olarak).

Derleme Süreci, bazı derleme araçlarını kullanarak herhangi bir hata için kaynak kodunuzu derleme ve derlemeler (projenin çalıştırılabilir sürümleridir) oluşturma İşlemidir. Biz (esas olarak geliştiriciler) kaynak kodda bazı değişiklikler yapıyoruz ve bu kodu oluşturma işleminin gerçekleşmesi için kontrol ediyoruz. Oluşturma işleminden sonra iki sonuç verir: 1. GEÇERLER oluşturun ve projenizin çalıştırılabilir bir sürümünü elde edin (Derleme hazır). 2. Başarısız olur ve belirli hatalar alırsınız ve yapı oluşturulmaz.

Aşağıdakiler gibi farklı yapım süreci türleri vardır: 1. Gecelik Yapı 2. Kapılı Yapı 3. Sürekli entegrasyon oluşturma vb.

Derleme araçları, derleme oluşturma sürecine yardımcı olur ve bunları otomatikleştirir.

* Yani Kısa Yapıda, Geliştirici veya Geliştirme ekibi tarafından Ürünlerini sürekli olarak izleyerek ve herhangi bir sorunu geliştirme sürecinin erken aşamalarında çözerek Ürünlerinin nihai sonucu için güven kazanmak için kullanılan ön sürüm formatındaki bir Yazılım Sürümüdür. *

Bunlar, yapılarınızı tamamlayabileceğiniz farklı süreç türleridir.

1. Sürekli Entegrasyon derlemesi:Bu temelde geliştiriciler kodlarını kontrol eder ve check-in yaptıktan hemen sonra bir yapı, son değişikliklerin oluşturulması için başlar, bu nedenle geliştirici tarafından yapılan değişikliklerin işe yarayıp yaramadığını, check-in yapıldıktan hemen sonra bilmeliyiz. Daha küçük projeler veya proje bileşenleri için tercih edilir. Projeyle birden fazla ekibin ilişkilendirilmesi veya büyük bir hayır olması durumunda. Aynı proje üzerinde çalışan geliştiriciler arasında bu senaryonun "n" hayır varmış gibi ele alınması zor hale geliyor. Check-in'ler ve yapı belirli noktalarda başarısız olursa, tüm arızaların bir sorundan mı yoksa birden çok sorundan mı kaynaklandığını izlemek oldukça zorlaşır, bu nedenle eski sorunlar düzgün bir şekilde ele alınmazsa, daha sonra izini sürmek çok zor olur. bu değişiklikten sonra meydana gelen kusurlar.

2. Geçitli check-in yapıları: Bu tür bir yapıda bir yapıda, değişiklikler bir raf setinde tutularak, check-in yapıldıktan hemen sonra başlatılır. Bu durumda, derleme, raf seti kontrolünün gerçekleştirilmesinden daha başarılı olursa, aksi takdirde Team Foundation Server'a taahhüt edilmeyecektir. Bu, yalnızca başarılı check-in'lerin taahhüt edilmesine izin verildiğinden, sürekli entegrasyon yapısından biraz daha iyi bir resim verir.

3. Gecelik derlemeler: Bu aynı zamanda Zamanlanmış derlemeler olarak da adlandırılır. Bu durumda, değişiklikleri oluşturmak için derlemeleri belirli bir süre çalışacak şekilde planlıyoruz. Son derlemeden önceki tüm taahhüt edilmemiş değişiklikler bu derleme işlemi sırasında oluşturulur. Bu, birden çok kez kontrol etmek istediğimizde ancak kodumuzu her kontrol ettiğimizde bir yapı istemediğimizde uygulanır, böylece teslim edilen kodun oluşturulması için oluşturmayı başlatabileceğimiz sabit bir süre veya süreye sahip olabiliriz.

Bu yapılar hakkında daha fazla ayrıntı aşağıdaki konumda bulunabilir.

Yapılarda geçitli kontrol

Sürekli Entegrasyon Yapıları

gece kondular

Bunları kullanıyorsunuz - IDE bir inşa aracıdır. Komut satırı için aşağıdaki gibi şeyler kullanabilirsiniz make.

İnsanlar, bir gecelik bina gibi şeyler için komut satırı araçlarını kullanırlar - bu nedenle, sabah akşamdan kalmayken, programcı, kütüphanelerin en son sürümleriyle uğraştığı kodun çalışmadığını fark etti!

"... neyin oluşturulması gerektiğini takip etmek çok zordur" - Derleme araçları bu konuda yardımcı olmuyor. Ne inşa etmek istediğini bilmen gerekiyor. (Ritesh Gun'un cevabından alıntılanmıştır)

"Neredeyse her tür gerçek dünya geliştirmede kullanıldığını duydum" - Bazı nedenlerden dolayı, yazılım geliştiriciler büyük şirketlerde çalışmayı severler. Orada çalışan her birey için daha belirsiz çalışma direktifleri var gibi görünüyor.

"Neden son dört yılda onlara hiç ihtiyacım olmadı". Muhtemelen yetenekli bir programcı olduğunuz içindir.

Sözde, meta. Bence yapım araçları gerçekten gerçek bir fayda sağlamaz. Kötü şirket uygulamalarından, yön eksikliğinden kaynaklanan bir güvenlik duygusu eklemek için oradadır - kötü yazılım mimari liderliği proje hakkında kötü fiili bilgi birikimine yol açar. Projenizde asla derleme araçlarını (test etmek için) kullanmak zorunda kalmamalısınız. Yazılım projesi hakkında bilgi eksikliği ile rastgele test yapmak hiçbir şekilde yardımcı olmaz.

Asla bir projeye amacını ve diğer bileşenlerle nasıl çalışacağını bilmeden bir şey eklememelisiniz. Bileşenler ayrı işlevsel olabilir, ancak birlikte çalışamaz. (Bu, üstlendiğim yazılım mimarının sorumluluğudur).

Projeye 4-5 bileşen eklenirse ne olur? 6. bileşeni eklersiniz. Eklenen ilk bileşenle birlikte her şeyi mahvedebilir. Hiçbir otomatik bunu tespit etmeye yardımcı olmaz.

Düşünmekten başka kısayol yoktur.

Ardından depolardan otomatik indirme var. Neden bunu yapmak istedin? Ne indirdiğinizi, projeye ne eklediğinizi bilmeniz gerekiyor. Depoların sürümlerindeki değişiklikleri nasıl tespit edersiniz? Bilmen gerekiyor. Hiçbir şeyi "otomatik" yapamazsınız.

Ya bisikletleri test etsek ve bir sopayla gözleri bağlı bebek taşıma araçlarıyla rastgele vurursak. Bu, araç testi yapma fikri gibi görünüyor.

Üzgünüm kısayol https://en.wikipedia.org/wiki/Scientific_method ve https://en.wikipedia.org/wiki/Analysis yok