Yazılımın yeniden kullanımı işlemin tekrarlanabilirliğini engelliyor mu?

Bir sorun olarak kod yeniden kullanma

Ben düşünüyordum bu soruya yazılım teslimat ve ben konusuna geri gelmeye devam etti tekrarlanabilirlik ve / veya tekrarlanabilirlik . Önemli, çünkü bir projeyi tekrarlamazsanız, o zaman projeyi oluşturmak için kullandığınız süreci iyileştirmek zorlaşır. Mühendislik, daha yüksek kalitede projeler üretmek için tasarım ve inşaat ile ilgili süreçlerin sürekli iyileştirilmesini içerir.

Yazılım, dijital biçimi nedeniyle yeniden kullanıma büyük ölçüde güvenebilir. Bir modülü yeniden yazmak yerine, onu tekrar ararız veya diğer sisteme kopyalarız. Bazı örnekler kimlik doğrulama / giriş veya belki de bir kayıt işlevidir. Bu kategoriler için bilinen birçok örnek vardır ve geleneksel bilgelik , kendinizinkini almak yerine var olanı yeniden kullanmaktır.

Diğer Disiplinlerle Bazı Karşılaştırmalar

İnşaat

Buna karşılık, fiziksel sistemlerin (binalar, köprüler) inşası yeniden kullanılabilecek kadar yakın değildir. Bir evin planının aynı evin kopyasını oluşturmak için birçok kez tekrar kullanılabileceği doğrudur, ancak inşaat her zaman yapılmalıdır. Kes ve yapıştır analog dünyada böyle çalışmaz. Köprü planları, ev koşulları daha az olacağı için evler için daha az tekrar kullanılabilir.

Usta inşaatçılar, bölgelerinde onlarca, yüzlerce veya binlerce şey tasarladıkları ve / veya inşa ettikleri için tanınan uzmanlardır. Örneğin, dünyaca ünlü bir mimar ve tasarımcı olan Frank Lloyd Wrightdesigned more than 1,000 structures and completed 532 works . Kontrast bununla Anders Hejlsberg tasarlamıştır “sadece” beş dil (Turbo Pascal; Delphi; J ++, C #, daktilo yazısı). Alanlar farklı olduğu için birçok yönden haksız bir karşılaştırma. Ancak geniş bir düzeyde, iki çok zeki insandan ölçülebilir üretim oldukça farklıdır.

Dövüş sanatları

Dövüş sanatçıları, hareketin ustalığının sadece binlerce tekrardan geldiğini söyleyecekler. Bu tekrarların iyi bir kısmı konulduktan sonra, birçok dövüş sanatçısı daha önce karmaşık bir kata veya form olarak algılanmasının nasıl basitleştiğine şaşırıyor. Bu öğrencilerin eğitmenleri ayrıca hareketin nasıl daha akıcı ve maksatlı olduğunu ve hareket ekonomisine sahip olduğunu fark edeceklerdir. Aynı şekilde, deneyimli dövüş sanatçıları, daha az deneyimli öğrencilere göre daha karmaşık kataları daha hızlı toplayabiliyor. Tekrarlamadan elde edilen deneyimler, onlara daha hızlı öğrenmelerini sağlayan bir çerçeve veya süreç vermiştir.

Ağaç

Ağaç işleri benzer bir dönüşüm yaşarlar. Hobi ustaları her zaman çok sayıda çekmece gerektiren ilk projelerine geri dönerler. Projeyi tamamlarlarsa, montaj hatlarının ürettiği verimlilik için yeni bir takdir kazanırlar. Ahşabın kullanımını en üst düzeye çıkarmak için çekmece parçalarının sac stoğuna nasıl yerleştirileceğinin daha iyi anlaşılması gibi başka faydalar da vardır. Hobileri ile karşılaştırıldığında, profesyonel ahşap işçileri daha önce birçok kez yaptıkları eşyaları daha hızlı tasarlayabilir, başlatabilir ve inşa edebilirler. Ayrıca, çalışmalarında bu hatayı yapan bir başkasının tasarımındaki doğal sorunları görme yeteneği kazanırlar.

Öyleyse, yazılımı yeniden kullanmak yazılım geliştiricilerin daha ustalaşmasını önlüyor mu?

Birçok yönden, yazılım tasarımı ve yapımı her zaman yenidir. Geçmiş işleri tekrar etmeyiz, çünkü bir modülü, kütüphaneyi veya sistemi tekrar kullanabilirsek yaparız. Her şeyi sıfırdan yeniden yazmadan önce mevcut bir sistemi tercihli olarak genişletiriz . Ancak tekrarlama, tasarımda ve yapımda verimliliği bulmamızı sağlayan şeydir. Bir spor ya da fiziksel aktivite yapanlar, tekrarlamanın iyi bir uygulayıcı olmanın anahtarı olduğunu söyleyecektir.

Sorum şu: Yazılımın yeniden kullanılabilmesi, bir projenin tekrarlanmasından gelen süreç iyileştirme ve verimliliği gerekli kılıyor mu?

Yazılımı tekrar kullanabilmek, işlem geliştirmeyi engellemez.

Gereksinim geliştirme, sistemi tasarlama, sistemi uygulama, sistemi dağıtma, gereksinimleri yönetme, yapılandırmaları yönetme, iş ürününü doğrulama ve doğrulama, değişiklikleri izleme ve diğerleri gibi (yazılım geliştirme sürecine giren süreçleri düşünüyorsanız) (bkz. CMMI , yazılım geliştirmedeki kilit faaliyetlerin muhtemel bir dökümü için alanları işler) - bunlar ne kadar tekrar kullandığınıza bakmaksızın her projede tekrarlanır. Ek olarak, her birinin belirli bir sürecin veya faaliyetin ne kadar iyi olduğunu belirlemek için kullanılabilecek bir miktar nicel ve nitel önlemleri ve bunun sonucunda da geliştirme sürecinin bir bütün olarak ne kadar iyi olduğunu belirleyebilir.

Extreme'nin bir ucunda, sağlam bir yazılım ürün gamını varsayabiliriz.. Diğer yandan, yeşil alan gelişimini üstlenebilirsiniz. Her ne kadar farklı hızlarda veya belki de farklı sekanslarda gerçekleşebilse de, bu işlemlerin hepsini farklı derecelerde gerçekleştirme ihtiyacı hala var. Örneğin, yüksek miktarda tekrar kullanımda, tahsis edilen zamanın daha büyük bir yüzdesi, sistem seviyesinde entegrasyon ve doğrulama / doğrulama faaliyetlerine harcanabilir (şartlar V&V, entegrasyon testleri, sistem testleri, kabul testleri). Yeni geliştirme çabalarıyla, tasarım ve uygulamada zamanın daha büyük bir yüzdesi gerekli olabilir. Bir proje boyunca en az bir kez bir işlem gerçekleştirdiğiniz sürece, bunu ölçebilirsiniz (kantitatif ve kalitatif). Ayarlamaları yaptığınızda ve ayarların işlem alanı ya da yazılım sağlama kabiliyetinin bir ölçüsünü nasıl etkilediğini görünce,

Süreç iyileştirmenin anahtarı faaliyetlerinizde ve süreçlerinizde bir miktar mantıksal bozulma sağlamak, bunların nasıl ölçüleceğini (tercihen tutarlı şekilde) ve süreç değişikliklerini bir tarafa doğru yapmak için bu ölçümlerin nasıl anlaşılacağını belirlemektir. Bu, projeyi tekrarlamakla ilgili değil, süreci nasıl tekrarladığınızdaki tutarlılıkla ilgilidir.

Diğer mühendislik disiplinlerinin yeniden kullanımı kullanmadığı fikrinin yanlış olduğunu düşünüyorum. Binaları / makineleri tasarlarken bile, birçok başka proje tarafından kullanılan bileşenlere sahipsiniz. Mesela kendi vidalarını kendin mi tasarlıyorsun? Motorlar? Kapı veya pencereler? Tabii ki değil. Bunlar daha sonra bunları farklı ürünlerde kullanan farklı insanlar tarafından tasarlanır. Ve oldukça sık standardize edilmiş durumdalar ve bu da daha fazla yeniden kullanımı teşvik ediyor.

Bence problem karmaşıklığı sever. En karmaşık binaların bile karmaşıklığını karmaşık yazılımlarla karşılaştıramazsınız. Yazılım karmaşıklığının mühendislik tarafından yaklaşılmasını zorlaştıran şey, genel kabul görmüş bir düşüncedir. Kabul edilebilir kalitede bir yazılım oluşturmanıza olanak tanıyan bir sürece sahip olduğunuz an, büyüklük sırasına göre zıplamak için gereken yazılım karmaşıklığının farkına varırsınız. Bu yüzden işlem kullanılamaz. Dolayısıyla, sonuçtan memnun kalana kadar yazılımın bir bölümünü bir kaç kez tekrarlamak zorunda kalırsak, bu yazılımı asla bitiremeyiz.

Bu nedenle temiz kod tanıtılır. Yeni deneyimlere dayanarak geçmiş kodu değiştirebilme yeteneğinin tasarımın yeniden kullanımı şeklinde olduğu söylenebilir. Bu nedenle, birçok kez farklı yazılımlar oluşturmak yerine, eski deneyimler ve tasarımları eski problemlerle yeniden kullanarak tek bir yazılım parçasını yeniden inceler ve geliştiririz. Tüm yazılım yapmaya çalışırken aynı şeyi yapın.

Yazılım olduğu biz en iyi bizim zaman harcamak nerede ekonomi genellikle farklıdır, bu yüzden çoğu diğer disiplinler farklı.

Yapım, bir plan üzerinde zaman ve para belirli bir miktar harcama (ve yazılım çok daha bir bina inşa etmek gibi daha bir plan üretme gibi), o zaman, kabaca söylemek gerekirse, bir sürü daha doğrusu bir veya daha fazla kez oluşturmaya. Bu yüzden, planı doğru bir şekilde yapmak için epey çaba harcamak buna değer. Daha spesifik olarak sorunuza - son ürünü biraz daha iyi hale getirmek için sıfırdan başlayarak yapma çabasını tekrarlamaya değer.

Yazılımda, plana sahip olduğunuzda, ürünü oluşturmak, planı yapmaktan daha ucuzdur. En azından çoğu zaman - yazılım bir kalp pilinin içine gömülecekse, bazı şekillerde bir köprü üreticisi durumuna daha yakınsınız demektir. Ancak, genel olarak, yazılımı tekrar kullanmak en büyük bütçe kaleminizin maliyetinin% 90'ını koruyabilir; köprü oluşturmak için çok daha küçük bir bütçe kaleminin% 90'ını koruyabilir. Bu nedenle, yeniden kullanım daha sık kazanır.

Verimlilik kadar - bir köprü oluştururken, gerçekten önemli gerçek dünya kısıtlamaları ile karşı karşıya kalırsınız. Mimarlara, inşaat maliyetlerinin 0'a yakın olduğu ve sınırlamanın gerçek dünyadan daha az önemli olduğu devasa çok oyunculu çevrimiçi oyunlar için köprü tasarlamak için büyük miktarda para ödenip ödenmediğini düşünün. Gerçek dünyadaki köprü standartlarına göre son derece karmaşık olan köprüler tasarlarlardı. Plan aşaması biraz daha uzun sürebilir.

Ayrıca, inşa edilecek sınırlı sayıda köprü vardır ve tasarım maliyetin ufacık bir parçası olduğundan, en iyisini ödeyebilirsiniz ve tasarımın çoğunu en iyisini yapabilirsiniz. Yüz binlerce yazılım geliştiricisi var ve temel olarak hepsinde vakti olsaydı yapacakları dev bir iş listesi var. Bunların büyük bir kısmını yapan bir adam bulamayacaksınız - bu, gerçekten yakınlaşan insanlar olması şaşırtıcı.

Gerçek mesele, bir şeyi tekrarlamaya ve geliştirmeye çalışmak yerine tekrar kullanarak bir şeyleri kaybediyor olacağımıza benziyor. Sanırım bir noktan var. Sorun şu ki, bazı temel şeyleri yeniden yazmak ve onu geliştirmek için denemek daha büyük olasılıkla, küresel olarak daha etkili olacak olsa da, bunu üst üste kim üstlense tüm risk alır ve muhtemelen o kadar da ödül kazanmaz. (Muhtemelen bazı şeyleri yeniden yazmaktan kurtulabilen, ama en azından küresel resme bakarken, bunun faydalı olmayacağı kadar büyük bir pratik bağımlılık cehennemi sorunu var.) önerilen bir yeniden-mühendislik çabasını, varolan kodun daha küçük parçalarını yeniden yapmak için bir miktar yeniden yazma çalışması yapması için zorlamak).

Tekrarı öğrenme açısından - orada çünkü bütün disiplinlerde bu, inşaat tasarım olarak daha az olur ise daha az tekrarlama, öğrenmenin çok az şans ve belki daha az fayda. Ayrıca, tasarım süreci muhtemelen sadece tekrarlanabilir değil. Roman yazmak için bir sürecin olması gibi bir şey. İyi bir süreç neredeyse kesinlikle yardımcı olabilir ve yazılım genellikle bir romandan çok daha işbirlikçidir, ancak amaç yeni bir şey icat etmek olduğunda bir işlemi tekrarlamak sorunludur. Romancılar bile geçmişten öğreniyorlar, ama tekrarlanabilir bir süreç yaratıcı çabalar için ikincil bir faktör. Yazılım geliştirmenin herhangi bir kısmı gerçekten gerçekten tekrarlanabilirse, neden bir bilgisayar bunu yapmıyor?

Yazılımın yeniden kullanılabilmesi, bir projenin tekrarlanmasından kaynaklanan süreç iyileştirme ve verimliliği gerekli kılıyor mu?

Son 17 yıldır aynı büyük projede, tesadüfen askeri uçak sektöründe sorumluluğum olsa da, uçak endüstrisinde tesadüfen (ilk bağlantınızdaki Airbus A380 referansını düşünerek) bir sistem ve yazılım mühendisi olarak çalıştım. Bunun gibi hikayeler temelde saf bir kurgu ve içeriden bir bakış açısı varken izlemek gerçekten çok komik.

Ancak kısa ve özlü sorunuz için: Tecrübelerime göre hem evet hem hayır diyebilirim.

Öncelikle hepimin her şekilde yazılım geri dönüşümü için olduğumu söylememe izin verin (tamam, belki hepsi değil ...). Kes ve yapıştır kod parçacıklarından ve algoritmalardan kod kod modüllerine ve işlev kitaplıklarına kadar hemen hemen her şeyi yeniden kullanmanın avantajları, her zaman baştan başlamaktan (biraz zorlamaktan) çok daha iyidir.

Dezavantajı, işaret ettiğiniz gibi (ya da en azından çıkarımda), sadece belirli bir bileşen kümesini bir araya getirerek işlevsellik eklediğinizde (ve evet, bunu aşırı derecede basitleştiriyorum), gerçekten bir programcı, mühendis veya her neyse.

Sadece iş yerimdeki yazılım mühendislerine bakıyorum, uzun deneyimlerden çoğunun bilmediğini ve daha kötüsünü - öğrenmeye ilgi duymadıklarını, üretmeleri gereken asgari üretim dışında inşa ettiğimiz ürünler hakkında hiçbir şey bilmediklerini biliyorum. Belge veya yapmaları için atandıkları kod parçası.

Burada konu dışı biraz çile ediyorum, ama benim açımdan programcılar olmadığı zamanlarda yani gerek Yapılanların kod gerçekten kullanılacaktır ve vermediğimizi öğrenmek için ihtiyaç sistemin iç işleyişini öğrenmek beri onlar sadece can önceden yazılmış ve test edilmiş bileşenleri yeniden kullanın, o zaman çoğu sadece bunu yapmak için uğraşmayacak.

Kabul ediyorum, bu aynı zamanda, inşa ettiğimiz ürünün inanılmaz derecede karmaşık olması ve bir kişinin hepsini öğrenmesi imkansız olacak gibi diğer koşullardan da kaynaklanmaktadır (ve sadece uçaktaki bilgisayarlardan biri hakkında konuşuyorum. Bunlardan en karmaşık olanı, ama yine de).

Yazılım mühendislerimiz bu kadar kodu tekrar kullanma seçeneğine sahip değilse, genel olarak mesleklerinde daha iyi olacaklarına ve projeye özel olarak daha büyük varlıkları olduğuna ikna oldum.

Oh, ve burada onlar hakkında çok fazla konuştuğumu fark etmiş olabilirsiniz . Elbette bu yazılım mühendislerine de dahilim. Bunun istisnası, diğerlerinden sonra yeni şeyler öğrenmek için çok daha meraklı ve istekli görünmek gibi görünüyor :-) Yeni bir görevle karşılaştığımda, her ikisinde de, öğrenebileceğim kadar çok şey öğrenmeyi hep kendime alıyorum. gerçeklerin şekli ve kaynak kodu çalışarak (evet, ben de bundan zevk alıyorum).

Ah - dang, tekrar izlenen ... Bahanem 32 saattir uyumamış olmam, bu yüzden odaklanma yeteneğim biraz ... ne diyordum?

Eğer biri hala okuyorsa, benim sonucum şudur:

Evet , yazılımın çok fazla tekrar kullanılması daha az bilgili yazılım mühendisleri için çalışır, bu da aslında işlerin nasıl yürüdüğünü bilmeleri gerektiğinde daha az verimli olmalarını sağlar. Problem analizi iyi bir örnektir, hatta önerilen bir tasarım çözümünün uygulanabilir olup olmadığını söyleyebilmek bile. Ve elbette, ne yaptığınızı gerçekten bilmiyorsanız, süreç iyileştirme de daha zordur. :-)

ve Hayır , yazılımı dikkatle yeniden kullanmak , süreç iyileştirmelerini göz önünde bulundurmanız ve planlamanız için size bolca boş zaman sağlar.

İşaret edildiği gibi kabul cevap başka Programcılar söz konusu, inşaat ile benzetmeler özenle alınacak gibidir:

Bunun için önerilen bir okuma: Yazılım Yapı Analojisi Bozuldu

yazılım genellikle yapıya benzetilir. Ne yazık ki bu analoji hatalı ve inşaat sektöründen alınan dersler şüpheli ...

Gözlemlediğim şey, iyi yazılım projeleri birçok tekrarlanabilirliği kalite güvencesine “kaydırıyor”.

1,5 yıl süren bir projede test ediciyken, haftalık "kontrol noktası" sürümlerinde, proje boyunca toplamda yaklaşık 70 kez test döngüleri yürütüyoruz. Bu ... oldukça tekrarlanabilir, yumuşak konuşabiliyordu (bir haftada pek bir şey değişmiyor). Her gece yapılan binaların test edilmesi doğal olarak daha da tekrarlanabilirdi - proje boyunca yaklaşık 500 kez (birkaç eğlenceli gösterici böcek, bir fark yaratmak için çok nadirdi).

Şimdi, bu "şüpheli" analojiyi izleyerek, 500 köprüyü inşa eden bir inşaat şirketine - hepsi aynı ekipte.

• Daha sonra, yeni köprülerinin her birinde çoğunlukla aynı tuğlaları ve demiri kullanan bir şirket anlat bana (burada, test ettiğimiz bültenlerin çoğunlukla her gün aynı kod bitlerine sahip olduğunu belirtiyorum. hafta - "çok şey değişmez").
  

Usta inşaatçılar, bölgelerinde onlarca, yüzlerce veya binlerce şey tasarladıkları ve / veya inşa ettikleri için tanınan uzmanlardır.

Güzel, yukarıda belirtilen tekrarlanabilirliğin açıklamasının ardından, ne diyebilirim ki? O zamanlar, küçük, çok özel olmayan test gruplarımız doğruladı, bölgemizdeki yüzlerce şeyi yukarıdan ("yaklaşık 500") görün.

Proje geliştiricilerine gelince, kelimenin tam anlamıyla inşa ettiler ("gece inşa ediyor") - bakın, kelime aynıdır ve anlamı bu bağlamda doğrudur - kendi alanlarında yüzlerce şey.

Eğer biri "şüpheli" analojiyi "binlerce şeye" kadar devam ettirmek isterse, bu miktarlar, yine de, doğru şeylere bakıldığında yazılım geliştirmede muhteşem bir şey değildir.

• Örnek olarak, geçmiş projelerimden bir başkası (yine, hiçbir şey muhteşem değil, normal olanı), bu kez dev rolünde, 5 yıldan fazla bir süredir devam ediyor (8 büyük sürüm, birkaç düzine küçük proje). Benzer haftalık kontrol noktaları ( 5x52~=250onlardan), benzer gece yayınları ( 5x365~=1800onlardan) ve benzer şekilde, bunlar üzerinde çalışan aynı dev / QA ekipleri vardı. Günden güne, haftadan haftaya, aydan aya, çoğunlukla tekrarlayan şeyler (iki gecelik yapı arasında çok fazla değişiklik yok) - söz verildiği gibi, binlerce kez (1800).

Windows veya Java gibi daha uzun ömürlü projeler veya AutoCAD 10, 20, 30 yıl sürebilir, bu da birçok "bin" gecelik yapıyı ve gece testlerini olduğu gibi tekrarlamayı kolayca gerçekleştirir.

QA'ya tekrar edilebilirlik kavramı sürekli entegrasyonla daha da öne çıkıyor ...

Tüm geliştirici çalışma kopyalarını paylaşılan bir ana hat ile günde birkaç kez birleştirme uygulaması ... CI, periyodik entegrasyon uygulamalarının yoğunlaştırılması olarak görülebilir.

Otomatikleştirilmiş birim testlerine ek olarak, CI kullanan kuruluşlar genellikle genel olarak kalite kontrolünü uygulamak için sürekli süreçler - sık sık uygulanan küçük çaba parçaları için bir yapı sunucusu kullanırlar . Ünite çalıştırma ve entegrasyon testlerine ek olarak, bu tür işlemler ek statik ve dinamik testler gerçekleştirir, performansı ölçer ve profillendirir, kaynak koddan dokümanları ayıklar ve biçimlendirir ve manuel KG işlemlerini kolaylaştırır. Bu sürekli kalite kontrol uygulaması, daha sonra geleneksel kalite kontrol uygulamalarını değiştirerek, yazılımın kalitesini iyileştirmeyi ve teslim etme süresini azaltmayı amaçlamaktadır.tüm gelişimin tamamlanması. Bu, entegrasyonu kolaylaştırmak için daha sık entegrasyona yönelik orijinal fikrine çok benzer, yalnızca KG işlemlerine uygulanır ...

Tekrarlanabilirlik? Tam orada, sanıldığı kadarıyla.

Sık / sürekli KG ile, yanlış giden şeyler, başarısız testler başarılı bir şekilde başarılı oluncaya kadar doğru yapma girişimlerini tekrarlamaya zorlanan geliştiricilere geri döner. Bir anlamda, o geçinceye kadar tekrarlama döngüsünün kata koduna benzemesi ,

Bir programcının uygulama ve tekrarlama yoluyla becerilerini geliştirmesine yardımcı olan programlama alıştırması ...

Söylediklerinizin bazıları doğru: örn. Kütüphaneler, makine kodu ile çözülmeyen sorunları çözen, montaj ile çözülmeyen problemleri çözen üst düzey dillerle çözülmeyen fonksiyonları çözer. Java'da System.out.println () işlevini çağırdığınızda, bir CPU'nun bir cihaza nasıl çıktığı konusunda görüş kaybedersiniz.

Yani evet, bir şey kaybediyorsun. Kazandığınız şey çözülemeyen problemlere odaklanma yeteneğidir. Şimdi bir problemi çözmek için kendinizi teknolojinin başka yönlerine (örneğin ağların nasıl işlediğine) sokmanız gerekebilir. Ancak, yapmak istediğiniz tek şey bir web sayfası oluşturmak olduğunda, makine dilini okuma konusunda uzman olmanıza gerek yok.

Aynı şekilde, köprü üreticileri her seferinde biraz farklı bir problemi çözüyorlar (farklı bir nehir). Belli bir gerilme kuvvetinde çelik kirişlerin nasıl oluşturulacağı ya da cıvataların belirli bir toleransla nasıl işleneceği konusunda endişelenmezler. Bunu, bu sorunu çözen uzmanlara bırakıyorlar.

Yakından bakın, tüm toplumumuzun ve altyapımızın% 99 yeniden kullanım ve sadece% 1 gerçek ilerleme üzerine kurulu olduğunu göreceksiniz. Çoğu yeni şey, eklenmiş veya kaldırılmış, biraz fazladan bir şey olan eski şeylerdir. İnsan bilgisinin birikimi. Kodları, iyi bir kütüphaneye sahip yüksek seviyede bir dilde yazabilirsiniz çünkü birileri bu noktaya ulaşmak için gereken zihin-karmaşıklığı karmaşık olan her şeyi çözdü. Yeni ve ilginç problemleri çözmenizi sağlar.

Bunları bir araya getirmek ve yorumlara cevap vermek için: Yeterliliği geliştirmek için zaten çözülmüş olan problemleri çözmek zorunda değilsiniz. Ayrıca, yaptığınız işlerin çoğu tekerleği yeniden icat edecek. Kısacası, cevap hayır - yeterli olmak için kütüphanelerin işlevlerini yeniden uygulamanıza gerek yok. Birçoğu fırsat, bir kısmı ezilmiş, bir kısmı da zanaatınızı geliştirmek için yaratıcı.

Hepsi kaynaklarla ilgili. Yıllar önce, büyük anabilgisayar bilgisayarları için yazılım projeleri geliştirdiyseniz, büyük ölçüde statik bir geliştirme ortamıyla 15 yıl kadar sürebilirler. Bordro hesaplamak için yazılan FORTRAN programı veya COBOL programı, on yıllardan beri mükemmelleştirildi çünkü sürekli kullanılıyordu. Bunun nasıl geliştirilebileceğini görmek için kaynaklar vardı. Belirli bir projenin becerilerini ayarlamak ve parlatmak için artık bu kadar yavaş bir ortama sahip değiliz. Ancak yetenekleri kullanıyoruz ve bunları bir sonraki proje kaynaklarına izin veriyoruz. Ancak sonuçta, yeni projeye iş yapmak için harcanan para seçimi veya yeni işi büyük miktarda altın kaplama ile yapmak. Altın kaplama, bir projeyi ilk dereceye kadar geliştirmek ve kullanıcı yapmamış olsa bile tonlarca zil ve ıslık eklemek anlamına gelir.

Yapabileceğimizin en iyisi, yeni bir projenin genel tasarımına bakmak ve ekibin geçmiş deneyimlerine dayanarak nasıl geliştirilebileceğini görmek. Ancak, Acile, OOP, vb. Gibi geliştirilmekte olan en son terimleri kullanmak için becerileri geliştirmek için tasarımın geliştirilmesinde gerçekte neyin düşünüldüğü konusunda bir vizyon sahibi olmak gerçek bir deneyim yazılım mimarını gerektirir.