VBA'dan C # 'a taşınma sorgulayan ekip üyesi

Arka fon

Geçen yıl, yaklaşık 10 kullanıcı için iş planlaması için kullanılacak bir araç oluşturmam istendi. Bu, işi bana "alt-sözleşme yapan" başka bir BT ekibi adına yapıldı ve proje sürelerinin biraz planlanmamış olması nedeniyle biraz acele etmek zorunda kaldım.

O zaman, en hızlı yolun VBA ile bir Excel çalışma kitabı oluşturmak ve daha sonra kullanıcıların bu VBA-gelişmiş çalışma kitabını bilgisayarlarında kullanmak için bir İntranet'ten indirmelerini sağlamak olduğuna karar verdik. Excel bu durumda bir kısıtlamadır, çünkü kullandığımız planlama sistemi (yani veritabanı) yalnızca planlama çalışma kitabının açık olduğu sırada yüklenmesi gereken bir Excel eklentisi aracılığıyla etkileşime girebilir. Ancak, VBA o sırada bir kısıtlama değildi.

Yaklaşık 4.000 satır VBA kodu oluşturduğum çalışma kitabı ve veri ve sunum katmanlarını ayırmaya çalışırken, proje son tarihleri ​​nedeniyle her durumda yapamadım. Dürüst olmak gerekirse, bu çalışma kitabını oluşturmaktan gurur duyuyorum, aynı zamanda hem kodlama hem de kullanıcılara dağıtım açısından daha iyi yapılabileceği için biraz hayal kırıklığına uğradım.

Bugün

Bugüne kadar ve BT ekibi yine benzer bir çalışma kitabı talep etmek için bana geldi (böylece yukarıdaki diğer çalışma kitabının parçalarını tekrar kullanabilirim), ancak bu sefer çok daha karmaşık ve daha fazla sayıda kullanıcı tarafından kullanılacak ( 200 civarında).

Ancak bu sefer biraz daha iyi planlanmış ve işleri planlamak için biraz daha zamanımız olduğunu görebiliyorum. Buna dayanarak, 100 kullanıcı için programlama 10 kullanıcıya göre daha fazla etkiye sahip olduğundan çözüm ve altyapıyı düşündüm. Bu nedenle, ekibe, kodu daha rafine bir şekilde yönetebilmemiz için mevcut kodu bir C # çözümüne geçirmeyi düşünmemiz gerektiğini önerdim. Ben hala kullanıcılara dağıtılabilir VSTO / Excel-DNA kullanarak yazılı bir eklenti olarak düşünüyorum.

Bunu iki hafta önce BT ekibiyle tartıştım ve dünden önce, ekipten birinden (VBA veya C # bilmeyen) bir e-postayı neden C # 'da kullanmaya başlamamız gerektiğini sorgulayan bir posta alana kadar her şey iyi görünüyordu. öncekiyle aynı yaklaşım. Onların endişelerinden bazıları:

• Oldukça önemli bir projedir, bu yüzden çalışması gerekir - bir C # çözümü, mevcut VBA tabanlı bir çözüm kadar kararlı olmayacak veya çalışmayacaktır.
• VBA çözümünde yaptığım şeyi atmam ve C # 'da sıfırdan yaratmamız gerekirdi.
• Birisi biri VBA diğeri C # olmak üzere iki ayrı çözümü desteklemelidir. [aslında, şu anda destek için kimseleri yok, genellikle içeri giriyorum].

Şimdi, bazı endişelerini bir dereceye kadar anlayabiliyorum, ancak sonraki adımlar ve onlarla ne geri dönecekleri konusunda bir karara varmam gerekiyor. Şahsen, ben C # uygulamak istiyorum çünkü böyle bir "Kurumsal" çözüm oluşturmak için daha iyi ödünç hissediyorum. Ayrıca, şu anda C # yetenekleri VBA kadar yetkin değilim ve bu tür bir projenin beni "bir sonraki seviyeye" götürmesini istiyorum C # becerilerimi fırça fırlatmak istiyorum.

Bir C # çözümünün bu proje için daha iyi olacağına ikna etmek için kullanabileceğim noktaların bir listesini hazırladım, şu ana kadar olan şey:

• Birim testi.
• Kaynak kontrolü.
• Kod belgeleri - diğer destek kişilerine bilgi aktarımı için.
• Daha iyi kodlama kuralları - daha iyi adlandırma ve yapı oluşturmak için ReSharper gibi şeyleri kullanabilir.
• Daha iyi IDE - hata vurgulama nedeniyle daha az hata.
• Montajlar yoluyla daha fazla modülerlik - gelecekteki araçlarda yeniden kullanımı teşvik edebilir.
• Yönetilen dağıtım - bu aracın kimler tarafından kullanıldığını kontrol edebilir.

Soru: Onları ikna etmek için başka hangi noktaları ekleyebilirim? Yoksa bu projeyi çiğneyebileceğimden daha fazla ısırmaya mı çalışıyorum? Yine de sessiz kalmalı mıyım ve VBA'da da yapmalı mıyım?

Sadece yeni bir dile geçmenin farkındayım çünkü onun "daha yeni" ya da "daha havalı" olduğu düşünülen bir kararın temeli olmamalı ve bu yüzden onu bir karar noktası olarak eklemeye direndim - bu gerçeklerle ilgili.

Ayrıca, SO üzerinde çok sayıda karşılaştırma olduğundan, dil olarak C # ve VBA arasında gerçek bir karşılaştırma istemiyorum.

Listelediğiniz üç nokta adil görünüyor:

Oldukça önemli bir projedir, bu yüzden çalışması gerekir - bir C # çözümü, mevcut VBA tabanlı bir çözüm kadar kararlı olmayacak veya çalışmayacaktır.

Gerçekten de, daha sonra şunu söylüyorsunuz: " Şu anda C # becerilerimi VBA kadar yetkin olmadığım için C # becerilerimi bu fırçayla ele almak istiyorum " (vurgu mayın).

Başka bir deyişle, çalışan ve yoğun kullanıcı testlerinden geçen bir çözümünüz var. Tüm bunları atmak ve her şeyi iyi bilmediğiniz bir dilde yeniden yazmak istiyorsunuz. Sorunu görüyor musunuz?

VBA çözümünde yaptığım şeyi atmam ve C # 'da sıfırdan yaratmamız gerekirdi.

Asla Yapmamanız Gereken Şeyler akla geliyor. Kullanıcı testinin yanı sıra kodu da atıyorsunuz. İyi bir şey değil.

Birisi biri VBA diğeri C # olmak üzere iki ayrı çözümü desteklemelidir. [aslında, şu anda destek için kimseleri yok, genellikle içeri giriyorum].

VBA sürümü hala kullanılacaksa, yeniden yazma gerçekten daha sorunludur. Niçin dikkatinizi gerektiren iki farklı sisteminiz olsun ki, zaten çalışan bir sisteme sahip olduğunuzda ve bunları yeniden düzenleyip özellikleri ekleyebileceğiniz zaman?

Öte yandan, bazı noktalarınız eleştirilebilir:

• Birim testi.

  Mevcut projenizi de birim test edebilirsiniz. Bunun için uygun bir çerçeve yoksa bir tane oluşturun.

• Kaynak kontrolü.

  Kaynak kontrolü metinle ilgilenir. Mevcut kodunuz metindir, bu nedenle bunun için kaynak kontrolünü kullanabilirsiniz.

  Dil, işletim sistemi, çerçeve veya ekosistem tamamen önemsizdir. Yazdığınız herhangi bir kod için kaynak denetimini kullanabilirsiniz (ve kullanmalısınız): Visual Studio'da kod veya LINQPad'de birkaç dakika içinde taslak oluşturduğunuz bir kod parçası veya bir görevi veya veritabanı şemasını veya Excel makrolarını otomatikleştiren PowerShell komut dosyalarını .

• Kod belgeleri - diğer destek kişilerine bilgi aktarımı için.

  Kabul.

• Daha iyi kodlama kuralları - daha iyi adlandırma ve yapı oluşturmak için ReSharper gibi şeyleri kullanabilir.

  "Daha iyi" tanımlayın. Excel makroları için kodlama kuralları var mı? Evet ise, bunları kullanın: diğerlerinden daha iyi veya daha kötü değildirler. Değilse, başkalarını da kullanabilmeleri için bunları oluşturun ve yayınlayın. 2010'da yayınlanan bir sorunun cevabı oldukça hayal kırıklığı yaratıyor, ancak o zamandan beri yeni araçlar olabilir.

  Kodlama kurallarının önemli bir kısmının, taahhütte uygulanmaları gerektiğidir.

• Daha iyi IDE - hata vurgulama nedeniyle daha az hata.

  Kabul. Aslında biz, Visual Studio makro yazamazsınız çok talihsiz bir durumdur.

• Montajlar yoluyla daha fazla modülerlik - gelecekteki araçlarda yeniden kullanımı teşvik edebilir.

  Mevcut ürününüzün bir dereceye kadar modülerlik kullanabileceğinden eminim.

• Yönetilen dağıtım - bu aracın kimler tarafından kullanıldığını kontrol edebilir.

  Kabul.

Tam bir yeniden yazma yerine, kodu makrodan VB.NET'te yazılmış sıradan bir derlemeye aşamalı olarak taşımanın bir yolunu arayabilirsiniz . Neden VB.NET'te? Üç neden:

• VBA ve CB arasında olduğu için VBA ve VB.NET arasında daha az fark vardır.

• Sen daha iyi VBA biliyoruz ve bu tek başına C # yerine VB.NET kullanmak için iyi bir nedendir. "C # becerilerinizi geliştirmek" istiyorsanız, işinizle ilgili önemli şeylerle değil, kişisel projelerinizle yapın.

• Bir dilden diğerine yeniden yazmak olası hatalara yol açar. Bu proje için buna ihtiyacınız yok.

Bir .NET derlemesine geçmek, kullanışlı birim testi, TFS ve şu anda diğer projelerde kullandığınız hata vurgulamasıyla Visual Studio'nun kullanışlı ortamını sağlayabilir.

Aynı zamanda, kodunuzu adım adım taşırsanız, tam bir yeniden yazma riski almazsınız (yani, yüksek sayıda yeni hata nedeniyle kimsenin kullanmak istemediği bir şey oluşturmak için dört ay harcamak). Örneğin, belirli bir özellik üzerinde mi çalışmanız gerekiyor? Önce bu özelliği .NET'e nasıl taşıyabileceğinizi düşünün.

Bu, yeniden düzenlemeye oldukça benzer. Yeni tasarım desenleri ve dil özellikleri öğrendiğiniz için her şeyi yeniden yazmak yerine, şu anda üzerinde çalıştığınız kod üzerinde küçük değişiklikler yapmanız yeterlidir.

C # gidiş destek. Diğerleri puanlarınızı çok iyi kapattı, bu yüzden söylediklerini yeniden şekillendirmeyeceğim. VBA'ya sadık kalmak için kesinlikle çok iyi nedenler var.

Ancak , işverenlerimden biri anlamlı belgeler oluşturmada kusursuz bir iş çıkardı. Öyle ki, tasarım kararları haklı gerekçeyle yazılmıştır - sadece tüm yazılım projeleri buna sahip olsaydı! Demek istediğim? Tasarım kararlarından biri, "Bu programı Java'ya yazmayı seçiyoruz, çünkü Bay So-and-so, özgeçmişine x yıllık Java deneyimi koymak istiyor". C # 'a geçmeniz için güçlü bir nedense, önemsiz olarak göz ardı edilemez. BT ekibine haklı göstermek için kullandığınız nedenlerden biri olamaz, çünkü özgeçmişinizde ne istediğinizi gerçekten umursamıyorlar, çalışan ürünü önemsiyorlar.

Üzerinde düşünülmesi gereken VBA algısı da var. Bunun doğru olmadığını biliyorum, ama bir özgeçmişte 'VBA'yı gören ve "Ne, bu adam stajyerlik işi yapmakta sıkışıp kalmış? Neden gerçek bir dilde tecrübesi yok ?" 'VBA' görüyorlar ve 'excel makro geliştiricisi' düşünüyorlar. Bir hücreyi diğerine kopyalamak / yapıştırmak, basit hesaplamalar yapmak vb. Gibi. Genellikle VBA'daki gerçek gelişimi takdir edebilecek insanlar bunu yapan kişilerdir ve bu en azından benim deneyimime göre giderek daha küçük bir havuz gibi görünüyor. Bölgenizdeki VBA algısını daha iyi anlayabilirsiniz, ancak buna karşı birçok haksız olumsuzluk gördüm.

Ben sıfırlamak istiyorum başka bir şey: MainMa VBA ve C # benzerliklerinden bahsetti. Bu kesinlikle doğrudur ve JMK'nın cevabı okunacak birkaç teknoloji sunmaktadır. VBA kodunuzu bir C # projesine kopyalamayı / yapıştırmayı deneyin ve sözdizimi hatalarının ne kadar kolay düzeltildiğini görün.

4.000 kod satırınız olduğunu söylediniz, bu da iyi bir kod yığınıdır ve muhtemelen birçok işlevselliği kapsamaktadır ... sadece 4.000 kod satırı. Kopyala ve yapıştır özelliğini deneyin. Bu sözdizimi hatalarını temizleyebilir ve çalışan bir projeniz varsa gerçekten şaşırmam. Kodunuzun ayrıntılarını veya kullanabileceğiniz boş zaman miktarını bilmeden, bunu bir hafta sonu nakavt edebileceğinizi düşünürüm.

C # en iyi uygulamalarını takip etmeyebilir, verimsiz olabilir, ancak C # 'da işlevsel olarak eşdeğer bir proje ile sonuçlanırsınız. Ayrıca, yeni C # kodunuzun eski VBA kodunuzdan daha fazla kusurlu olmayacağından da emin olabilirsiniz.

VBA kodunuzu kendi zamanında C # 'a dönüştürmek sizin için birkaç şey yapar:

• Sözdizimi hatalarını araştırdıkça C # uygulamalarına daha aşina olacaksınız - aslında C #'da çalışmak için bir tür astar
• Eklentinin excel'e yüklenmesi ile ilgili bariz sorunlara ışık tutacaktır (excel muhtemelen hala bir gereksinim olduğu için). Belki de henüz engellemediğiniz bir sorun var.
• Müşterinize (BT ekibi) bir kavram kanıtı gösterir. Geçerli işlevlere sahip çalışan bir C # eklentisine sahip olduğunuzu görebilirlerse, C # ile algılanan risk düzeylerini düşürürsünüz.

Ve BT'nin üç noktasına geri dönüyoruz:

• Oldukça önemli bir projedir, bu yüzden çalışması gerekir - bir C # çözümü, mevcut VBA tabanlı bir çözüm kadar kararlı olmayacak veya çalışmayacaktır.

Belirtildiği gibi, C # kodunuz aynı işlevselliği kapsayacak ve VBA'nız kadar kararlı olacaktır. Açıkçası, orada olup böceklerin / kusurları veya yetersizliklere tanıtmak bir şans, ama bu zor görünüyor. İOS / Objective C'den Android / Java'ya bir bağlantı noktasından bahsetmiyoruz, sözdiziminde birçok benzerlik paylaşan ve tam olarak aynı teknolojiyi kullanabilen iki dil arasındaki bir bağlantı noktasından bahsediyoruz - excel çalışma kitapları.

• VBA çözümünde [I] yaptığımızı atmak ve C # 'da sıfırdan yeniden yaratmak zorunda kalacağız.

Bununla, herhangi bir çaba veya kodu atmazsınız.

• Birisi biri VBA diğeri C # olmak üzere iki ayrı çözümü desteklemelidir. [aslında, şu anda destek için kimseleri yok, genellikle içeri giriyorum].

Sadece 1 çözümü olacak, hepsi C #.

Sonuçta, müşteriniz çok fazla risk görüyor. Bu riski azaltmak için gerekli adımları atabilirseniz, C # değerindeki değişikliği kabul edebilirler.

Bunu söylemekten nefret ediyorum, ama argümanlarınız sadece su tutmuyor.

Birim testi.

Bu çok uzun zamandır çözülmüş bir problem. Orada birçok Birim Testi çerçevesi var. Birini seçin. Bunu zaten yapmalıydın. Bizimkini tavsiye ederim , çünkü IDE ile bütünleşir ve diğer harika özellikler sağlar.

Kaynak kontrolü

Bu biraz daha zor, az sayıda hazır çözüm var, ama gerçekten sadece kodunuzu bir depoya girip çıkma meselesi. İşte bunu yapmanın düşük bir kaş yolu , ancak başka daha iyi seçenekler de var.

Kod belgeleri

Ayrıca çözülmüş bir problem. MZ-Tools, .Net'in XML yorum belgelerine çok benzer şekilde çalışan bir XML dokümantasyon özelliğine sahiptir.

Daha iyi kodlama kuralları

Visual Studio ReSharper eklentisi vardır gibi, hem MZ-Araçlar ve Rubberduck gibi özelliklere sahip.

Daha iyi IDE

Yine, VBA IDE için eklentiler var.

Montajlar yoluyla daha fazla modülerlik - gelecekteki araçlarda yeniden kullanımı teşvik edebilir.

Ayrıca çözülmüş bir problem. Hayır, derleme oluşturamazsınız, ancak diğer VBA Projelerine başvurabilirsiniz.

Yönetilen dağıtım - bu aracın kimler tarafından kullanıldığını kontrol edebilir.

Biraz etiket, programa kimin erişebileceğini ve kimin erişemediğini kontrol etmek için kod yazmanız gerekir, ancak muhtemelen (yine) zaten güvenlik kodunun yazılı olması gerekir.

Dağıtım gelince, bu da çözülmüş bir sorundur. Evet, kod gerektirir, ancak kullanabileceğiniz / değiştirebileceğiniz örnekler vardır .

Hepsinden önemlisi, sıfırdan başlayacağınız gerçeğidir. Ben de Joel Spolsky'nin makalesini tavsiye edeceğim .

Herhangi bir yazılım şirketinin yapabileceği en kötü stratejik hatayı yaparak bunu yaptılar:

Kodu sıfırdan yeniden yazmaya karar verdiler.

BT adamlarınız haklı. Bunu sıfırdan yeniden yazmamalısınız. Mevcut çözümünüzle ilgili problemleri çözüyor olmalısınız.

Şimdi, tüm bu söyledikten sonra, bunu neden C # veya VB.Net'te yapmak istediğinizi kesinlikle anlayabiliyorum. Gerçekten daha iyi bir çözümdür, eğer yeni bir projeye başlıyorsanız , ancak seslerinden yeni bir proje değildir. Baştan sonra kırmak için sahip olduklarınızı geliştirmek çok daha iyidir.

Microsoft'un bile bu makalede belirttiğine dikkat çekebilirsiniz :

Özellikleri iyileştirmek veya hataları düzeltmek için kodu güncellemek, Office yapısının her bir kullanıcı tarafından ve özelleştirmeyi kullanan her bir dosyada yeniden e-postayla gönderilmesini, yeniden yapılandırılmasını ve yeniden çalışılmasını gerektirir.

Makale, Office'e dayalı şeyler geliştirmenin farklı yaklaşımları hakkındadır, belki de tartışmanızda başka artıları ve eksileri de alabilirsiniz.

Gerçekten C # 'a nasıl hareket edeceğinize bağlıdır (yani hangi teknolojiyi kullanacaksınız).

OpenXML kullanacaksanız, işe yarayan bir çözümünüz varsa, önerilmez bir toplam yeniden yazma konuşuyorsunuz.

Interop'u kullanmaktan bahsediyorsanız, sürecin şaşırtıcı derecede pürüzsüz olduğunu görebilirsiniz. Geçmişte VBA'dan C # 'a (Interop ile) birçok kod taşıdım ve çalışma kitabına bağlandıktan sonra şöyle:

var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");

Birlikte işlev çağrıları önek / makarna VBA kodu kopyalayıp durumlarda bir sürü olarak workbook.değiştirilmesi Dim ile var vs uygun olduğunda ve ucunda noktalı virgül ekleyerek.

Aslında (Excel) altında aynı Çerçeve, sadece sözdizimini VBA'dan C # olarak değiştiriyorsunuz.

İşiniz bittiğinde, uygulamayı kaydettiğinizden ve kapattığınızdan emin olun:

workbook.Save();
excelApplication.Quit();

Sonra Mareşal ile uygulamayı bırakın:

Marshal.ReleaseComObject(excelApplication);

Muhtemelen Excel Application nesnesi etrafında IDisposable uygulayan bir sarıcı sınıf yazmak, sonra usingbu nesne kullanılırken kullandığınızdan emin olun .

Davanızı yapmanın iyi bir yolu, bunu yapmak için bir saat harcamaktır, bu da kısa bir süre içinde kodu ne kadar hızlı bir şekilde bağlayabileceğinizi gösterecek ve meslektaşlarınızı bunun iyi bir fikir olduğuna ikna edecektir.

Kod bir şekilde büyük ölçüde değişmeden kalacak, ancak Visual Studio'da bir C # projesine sahip olmanın bahsettiğiniz tüm avantajlara sahipsiniz.

Bir EXCEL çalışma kitabında yerleşik çok büyük (20k + satır VBA kodu) uygulaması ile aynı pozisyondayım. Office 2013 ile test edildikten sonra, yeni ofis modelindeki başlatma olayı dizisindeki değişiklikler ve muhtemelen EMET'in daha sıkı bir şekilde uygulanması nedeniyle inanılmıyor. Bu nedenle, bu yıl Office 2013'ün piyasaya sunulmasından önce C # ve VB.NET'e bir çökme dönüştürme işlemi yapıyorum. Kuruluşta kullanılan diğer, daha basit (VBA gelişmiş) çalışma kitapları bağışıklık kazanmamış, bazıları çalışmış, bazıları çalışmamış.

Hatalar Workbook_Open içinde oluşur sayfalarının artık kullanılamadığı olayında ve başvurulan herhangi bir VBA kodundan önce dahili EXCEL kodunda oluşur.

Tüm VBA, C # ve VB.NET'te rahat olmak için, her ikisinde de dönüşüm yazıyorum. Dil deyimleri VB.NET'ten 3-4 kat daha hızlı o dilde belirli fonksiyonel yapıları yazmama izin verdiğinden, C # dilinde çerçeve kodu yazılıyor. Kodun büyük kısmı VB.NET'te çünkü yeniden yazım daha az kapsamlı ve C # 'da mevcut olmayan bazı deyimler var.

Herhangi bir karar vermeden önce, mevcut başvuruyu OFFICE 2013 ve kuruluşun önümüzdeki 2-3 yıl içinde piyasaya sürmeyi öngördüğü EMET zorlamasıyla test etmenizi şiddetle tavsiye ederim. Benim gibi, varolan uygulamanın yine de yeniden yazma olmadan o ortamda çalışmadığını keşfedebilirsiniz - bu durumda yeniden yazma da DOT NET ve VSTO'da olabilir.

Zeyilname:

Çalışma kitabının VBA'nın tüm içeriğini dolaşan ve tüm modülleri, sınıfları ve formları dosyalara aktaran küçük bir otomatik ayıklama yardımcı programı yazmak, ne kadar süslü olmasını istediğinize bağlı olarak 1-2 gün çalışır. Aynı şekilde, bir dizinden boş bir çalışma kitabına dosyaları içe aktarmak için bunun tersi de geçerlidir. Bu ikisi sayesinde düzgün kaynak denetiminde tüm VBA kodunu sahip ve sahip olmak oldukça mümkündür Oluştur çalışma kitabınız için kaynak kodundan işlemi .

VEYA - Excel VBA Kod Temizleyici gibi ücretsiz bir yardımcı program kullanın

Şu anda C # becerilerim VBA kadar yetkin olmadığım için C # becerilerimi bu fırçayla güçlendirmek istiyorum ve bunun gibi bir projenin beni "bir sonraki seviyeye" götürmesini istiyorum.

Dürüst ol. Bu bilgiyi, bu kararı vermekle ilgilenen diğer insanlarla paylaşmayı planlıyor musunuz? Değilse, proje başarısız olursa tüm suçu üzerinize yerleştiririm. Benzer bir proje zaten yaratıldığı ve sahaya çıkarıldığı için, herkes kendi zihninde olmasını beklediklerini oluşturdu. Sonuncuyu oluşturmanın ne kadar sürdüğünü biliyorlar ve bunu daha kısa sürede oluşturabileceğinize inanacaklar (ek gereksinimlere dayanarak doğru olabilir veya olmayabilir). Yeni bir dil öğrenmekle birlikte bu sorumluluğu üstlenmeye hazır mısınız?

Eski uygulamayı C # ASAP'a taşımanızı öneririz. Belki bir karar verilmeden önce bu süreçte yeterince öğrenebilirsiniz. En azından yeni dil ile becerilerinizi geliştirme hedefinize ulaşacaksınız ve projeyi zamanında tamamlayacaksınız.

Sonra tekrar, bu konuda güçlü hissediyorsanız ve projeyi inşa etmek tamamen omuzlarınızda duruyorsa, istediğiniz gibi yapın. Affetmek her zaman izin almaktan daha kolaydır.