Hayatım boyunca araştırmada çalıştım, bu yüzden araştırmacıların çirkin kod yazdığına dair bir stereotip biliyorum (örneğin   ,   veya   bakın). Ama düşündüm: Bunu düzeltebiliriz, değil mi? Bu yüzden birçok kez güzel araştırma çerçeveleri tasarlamaya çalıştım. Okumayı sevdiğim yazılım mühendisliği kitaplarını ve bloglarını kullanarak arayüzler oluşturmaya ve güzel soyutlamalar oluşturmaya çalıştım. buraya buraya buraya  Ancak tekrar tekrar tüm bu çabalar boşa çıktı. Üzerinde çalıştığım araştırma yazılımlarının çoğunluğu hiçbir zaman üretime geçmedi (bazıları üretime geçmiş olsa da). Birisi bana basit bir gerçeği söyleseydi akıl sağlığım için harika olurdu:   . Araştırmacılar ilk etapta bunun mühendisliğine fazla zaman harcamamalıdır. aslında olması gereken şey araştırma kodunun ölmesidir  Profesyonel yazılım mühendisleri, en iyi yazılım uygulamalarını kullanmayan araştırmacıları her zaman küçümserler. Araştırma kodu çıtasını yükseltmeye çalışan birkaç gönderi var (örneğin bu   ve bir   ). Ancak bu yazı bunun tam tersini söylüyor: En iyi yazılım uygulamalarını abartmamayı ve bunun yerine yalnızca hızlı keşfetmeye nasıl yatırım yapılacağını tartışıyor. Amacının birçok fikri hızlı bir şekilde denemek olduğu araştırma odaklı şirketlere yöneliktir. harika gönderi araştırma kodu el kitabı  1. Stratejik teknoloji borcunu üstlenin  Bir şirketteki başarılı bir araştırma projesinin iki aşaması vardır: keşif ve kullanım. "Keşifte" mümkün olduğunca çok sayıda farklı çözümü denemek istersiniz. “Kullanım” sırasında en iyi çözümü sağlamlaştırmanız ve onu kullanışlı bir ürüne dönüştürmeniz gerekir.    Optimal yazılım uygulamaları ikisi arasında oldukça farklıdır. Bu nedenle şirketlerin sıklıkla ayrı araştırma ve ürün bölümleri vardır. Yazılım tasarımıyla ilgili olarak okuyabileceğiniz kitapların tümü esas olarak ikinci "kullanım" aşamasıyla ilgilidir. Bu aşamada ölçeklenebilir bir ürünün temellerini oluşturuyorsunuz. Tüm tasarım modellerinin devreye girdiği yer burasıdır: güzel API'ler, günlük kaydı, hata yönetimi vb.  Ancak ilk "keşif" aşamasında sonsuza kadar yaşayacak temeller   . Aslında, çabalarınızın çoğunluğu hayatta kalıyorsa, o zaman (tanım gereği) yeterince araştırmamışsınız demektir. atmıyorsunuz  Bu yazıdaki birçok uygulama, normalde "teknoloji borcu" haline gelecek olanın örnekleridir. Temiz, yeniden kullanılabilir, iyi özetlenmiş kod yazmayarak elde ettiğiniz şey budur. Borç her zaman kötü müdür? Asla kredi veya ipotek almamayı tercih ederiz, ancak borç para almak genellikle hayatta iyi bir stratejidir. Hızlı hareket etmek ve daha sonra kâr etmek için borca girmekte sorun yoktur.    Benzer şekilde, teknik borç almayarak araştırmanızı yavaşlatıyor olabilirsiniz. İyi haber şu ki çoğu zaman geri ödemek zorunda kalmıyorsunuz. Araştırma kodunuzun çoğunun zaten ölmesi muhtemeldir. Yani ortalama olarak aldığınız tüm teknik borcun acısını çekmeyeceksiniz.  Kodun yeniden kullanımına karşı dava  Birçok yazılım mimarisi ve yeniden düzenleme tekniği, özellikle kodun yeniden kullanılabilirliğini iyileştirmeye yöneliktir. Kodun yeniden kullanımının genel   vardır. Ancak üretimde, iyi bilinen faydalar nedeniyle bunlar daha ağır basmaktadır (örneğin,   bakın). Araştırma projelerinde kodun çoğunluğunun unutulmaya mahkum olması kaçınılmazdır. Kodu yeniden kullanmak için çabalamak aslında sizi yavaşlatabilir. dezavantajları bu tipik gönderiye  Kodun yeniden kullanımını sınırlamak, araştırmada alınması uygun olan teknik borç türüdür. Tartışmak istediğim birkaç kod yeniden kullanım modeli var: gereksiz bir bağımlılık eklemek, kodu kopyalayıp yapıştırmak, çok sayıda paylaşılan araştırma kodunu sürdürmek, erken tasarım yatırımları.  Yeni bir şey ithal etmeden önce iki kez düşünün  Sizi hızlandıracak, bakımlı ve sürümlü bir kitaplık biliyorsanız - devam edin! Ancak yeni bir bağımlılığa başlamadan önce buna değip değmeyeceğine karar vermeye çalışın. Her ilave, sizi bağımlılık cehennemine daha da yaklaştırır. Öğrenmeye ve sorun gidermeye zaman ayırmanızı sağlar. Bu   bağımlılığın diğer tuzaklarını görün. kısa gönderide  Aşağıdaki durumlarda bir şeye bağlı olmak muhtemelen iyidir:  zaten kullandınız, öğrenecek pek bir şey yok, geniş bir topluluğu var, iyi dokümanlar ve testler var  versiyonlanmıştır, kurulumu kolaydır  ve son olarak, bunu kendi başınıza uygulayabilmenizin hiçbir yolu yok.  Ancak aşağıdaki durumlarda bağımlılığa karşı dikkatli olun:  onu nasıl hızlı bir şekilde kullanacağınızı çözemiyorsunuz, çok yeni (ya da çok eski) ya da hiç kimse onu bilmiyor gibi görünüyor; belge veya test yok  monorepo'nuzdan geliyor ve diğer ekipler tarafından sürekli değiştiriliyor  diğer birçok bağımlılığı ve aracı da kendine çeker; veya kurulumu zor  ve son olarak, kendinizin (veya bazı LLM'lerin) bu kodu birkaç saat içinde yazabileceğini hissediyorsunuz.  Açık bir bağımlılık yerine güzel bir Go atasözünü takip edebilirsiniz: Bir sonraki konumuz olan “   ”. biraz kopyalamak, biraz bağımlılıktan iyidir  Copypaste size deneme özgürlüğü verir    Bazıları “   ” söylüyor. Ama şaşırtıcı bir şekilde kendimi sık sık bunun lehine tartışırken buldum. Kopya macunu, keşif aşamasında en uygun seçim olabilir. kopyala-yapıştırın yasa dışı olması gerektiğini  Kod tabanının başka bir bölümünden yoğun olarak kullanılan bir işleve bağlıysanız, onu kolayca değiştirmeyi unutabilirsiniz. Muhtemelen birisi için bir şeyleri bozarsınız ve kod incelemeleri ve düzeltmeleri için değerli zaman harcamak zorunda kalırsınız. Ancak gerekli kodu kopyalayıp klasörünüze yapıştırırsanız, onunla istediğiniz her şeyi yapmakta özgürsünüz. Bu, deney yapmanın bir istisna olmaktan çok bir norm olduğu araştırma projelerinde büyük bir sorundur. Özellikle değişikliklerin herkes için yararlı olup olmayacağından emin değilseniz.  Derin öğrenme kod tabanlarının kopyalayıp yapıştırmaya en uygun olduğunu düşünüyorum. Genellikle bir modeli ve onun eğitimini tanımlamak için gereken kod miktarı o kadar da büyük değildir. Ancak aynı zamanda çok incelikli olabilir ve genelleştirilmesi zor olabilir. Paylaşılabilir eğitim komut dosyaları yönetilemez bir boyuta ulaşma eğilimindedir: örneğin Hugging Face     +4k satırı vardır. İlginçtir ki, transformatörler model düzeyinde kopyala yapıştırmayı tercih etti. Lütfen "tek dosya modeli" politikalarının ardındaki gerekçeleri içeren   göz atın. Sonunda kopyala macunun güzelliği hakkında daha fazla kaynak görün. transformers Trainer'ın gönderilerine  Kopyala yapıştırmanın bir alternatifi dalda kalmaktır. Ancak bunun ekip çalışmasına çok fazla yük getirdiğini düşünüyorum. Ayrıca, kopya macunun güzelliği hakkında birkaç gönderi daha buldum - daha fazla gönderiyi sonuç bölümünde görebilirsiniz.  Paylaşılan araştırma kodunu sürdürmek zordur  Yoğun olarak kullanılan paylaşılan kodun bakımı çok fazla çalışma gerektirir.   sürümüne göre çizilen   dosya satırı sayısına bir göz atın. En gelişmiş araştırma ekiplerinin bile karmaşıklığı kontrol altında tutmakta zorlandığını görebilirsiniz. Pytorch torch.nn.Module    Büyük bir paylaşılan araştırma kodunu sürdürmek için gereken zamanı ve kaynakları küçümsemeyin. Bir araştırma kütüphanesi ne kadar çok kullanılırsa o kadar karmaşık hale gelir. Bu, tipik bir kütüphaneye göre daha hızlı gerçekleşir çünkü her araştırma yönünün biraz farklı bir kullanım durumu vardır. Neyin geri bağışlanabileceği konusunda çok katı kurallar belirleyin. Aksi takdirde, paylaşılan kod çok sayıda seçenek, hatalı optimizasyonlar ve uç durumlarla kırılgan hale gelir ve büyümüş olur. Araştırma kodlarının çoğunluğu ortadan kalktığı için, bu ekstra karmaşıklığın tümü bir daha asla kullanılamayacak. Paylaşılan kodunuzun bir kısmını bırakmak, gerçek araştırma yapmak için biraz zaman kazandıracaktır.  Kodun yeniden kullanımı için değil, keşif için tasarım  Üretim aşamasında bile   istemeyeceğiniz bir bakıma doğrudur. Gereksinimleri karşılayan mümkün olan en basit çözümü uygulamaya çalışın. Ancak üretim kodunda her zaman sürdürülebilirliğin dikkate alınması gereken yönleri vardır. Örneğin, hata işleme, hız, kayıt tutma, modülerleştirme genellikle düşünmeniz gereken şeylerdir. kodunuzu gelecekte de kullanıma hazır hale getirmek  Araştırma kodunda bunların hiçbiri önemli değil. Bir fikrin iyi ya da kötü olduğunu mümkün olan en hızlı şekilde kanıtlamak ve devam etmek istiyorsunuz. Yani herhangi bir modül veya API olmadan bunu başaran kirli basitlik kesinlikle sorun değil!  Değerli zamanınızı aşağıdaki gibi erken yazılım yatırımlarıyla boşa harcamayın:  bileşen arayüzlerinin projenin çok erken aşamasında oluşturulması. Kendi yarattığınız yapay kısıtlamalara uyum sağlamak için çok fazla zaman harcayacaksınız  derin öğrenme çözümüne geçmeden önce derin öğrenme eğitim altyapısını optimize etme  üretim yapılandırması/fabrikalar/serileştirme sistemleri veya temel sınıfları kullanma. Çoğu zaman prototipleme sırasında bunların işlevlerine ihtiyacınız olmaz.  aşırı katı astarlama ve tip kontrol sistemleri. Hızla değişen, atılan araştırma kodunu yavaşlatmanın bir anlamı yok.  2. Hızlı keşfe yatırım yapın  Bir araştırma projesinin amacı yeni bir çözüm bulmaktır. Hiç kimse (tanım gereği) neye benzediğini bilmiyor. Bu, sınırlı bilgiye sahip karmaşık bir araştırma ortamındaki optimizasyon sürecine benzer. İyi bir minimum bulmak için birçok yolu denemeniz, iyi ve kötü yolları tanımanız ve yerel minimumlara takılıp kalmamanız gerekir. Tüm bunları hızlı bir şekilde yapabilmek için bazen teknoloji borcu almak yerine yazılım yatırımları yapmanız gerekebilir.  Ortak yolları hızlandırın    Denemek istediğiniz birkaç farklı araştırma yolu vardır. Yolların çoğundan zaman kazandıracak bir tasarım, kitaplık veya optimizasyon var mı? Hiçbir şeye aşırı mühendislik yapmamaya dikkat etmelisiniz çünkü denemek üzere olduğunuz fikirlerin tamamını her zaman bilemezsiniz. Bu her proje için çok özeldir, ancak işte bazı örnekler:  Derin ağları eğitiyorsanız eğitim altyapısına yatırım yapın. Egzersiz sırasında hızlı ve güvenilir bir şekilde birleşmenizi sağlayan hiperparametreleri belirleyin  her deney farklı bir model kullanmanızı gerektiriyorsa, bunları hızlı bir şekilde nasıl değiştirebileceğinizi öğrenin (örneğin, basit bir fabrika sistemi kullanarak veya yalnızca kopyala yapıştır yaparak)  Her deneyde çok fazla parametre varsa ve yönetilmesi zorsa güzel bir yapılandırma kitaplığına yatırım yapın.  Hızla şubeleşin    Araştırmacılar yeni ve çeşitli fikirleri hızlı bir şekilde başlatabilmelidir. Projenin başlangıcında kolay görünüyor. Ancak daha sonra insanlar en sevdikleri araştırma yollarına yerleştikçe bu durum giderek daha da zorlaşıyor. Bunu ele almak için kültürel ve organizasyonel değişiklikler şarttır. Gelecek vaat etmeyen araştırmaları, çok fazla para ve duygu harcamadan önce durduran bir süreç olmalıdır. Düzenli demo günleri ve teknik emsal incelemeleri bu amaç için etkili stratejiler olarak hizmet edebilir. İnsanların yeni ve parlak bir fikre atlaması ile mevcut projeleri düzgün bir şekilde kapatması arasında bir denge bulmak da önemlidir.  Ancak bu bir yazılım gönderisi olduğundan, yeni projeleri dallara ayırmayı kolaylaştıracak bazı uygulamaları burada bulabilirsiniz:  değerlendirme kodunu algoritmalardan uzak tutun. Değerlendirmeler genellikle araştırma yönergelerinden daha istikrarlıdır  Boş bir sayfadan yeni bir projeye başlamayı benimseyin, ancak ardından hangi bileşenlerin yeniden kullanıldığına dikkat edin. Bunları modüler hale getirmek ve temizlemek iyi bir yatırımdır  Yeni bir araştırma projesinde önce en yenilikçi ve riskli bileşeni uygulayın. Bunu yapmak, gelecekteki yazılım tasarımına yön veren darboğazların çoğunu tanımlar.  Sinyal-gürültü oranını artırın    Gürültülü ve hatalı kod, sonuçları o kadar belirsiz ve sonuçsuz hale getirir ki tüm proje zaman kaybı olur. İşleri gereğinden fazla tasarlamamanız gerekirken, karmaşık kodlardan kaçınmak için bu basit temel kuralları kolayca takip edebilirsiniz:    olan kodlardan kaçının yan etkileri  varsayılan olarak sınıflar yerine işlevler; ve sınıflarda, kalıtıma karşı kapsüllemeyi tercih edin  fonksiyonların/sınıfların/modüllerin uzunluğunu en aza indirin; if ifadelerinin sayısını en aza indirin  Python'u iyi biliyorum ama basit teknikler kullanıyorum. Metasınıfların, dekoratörlerin ve işlevsel programlamanın entelektüel yabani otlarına girmenin cazibesine karşı koyun.  Farklı çalıştırmalar sırasında farklı sonuçlar üreten yazılımlarla çalışmak zordur. Şanssız bir tohuma dayanarak önemli ama yanlış bir karar verdiyseniz, iyileşmek için çok zaman kaybedersiniz. Deterministik olmayan yazılımlarla çalışırken bazı ipuçları:  Gürültünün algoritmadan mı yoksa değerlendirmeden mi geldiğini anlayın. Gürültü kaynakları birleşir ve tamamen deterministik bir değerlendirme için çabalamalısınız.  Gerçekten tekrarlanabilir bir senaryo elde edene kadar rastgelelik kaynakları bulmayı bırakmayın. Tüm rastgele tohumları bulduktan sonra gürültünün verilerden veya yan etkileri olan genel işlevlerden gelebileceğini unutmayın.  tohumları çeşitlendirin ve sonuçlarınızın temel değişkenliğini belirleyin. İstatistiksel olarak anlamlı olmayan sonuçlar hakkında karar almayın.  Çözüm  Can alıcı nokta, araştırma koduyla ilgili   geliyor: bu yazıdan    . “[İyi yazılım tasarımı] ile uğraşmıyorsunuz çünkü amaç kod değil. Kod, size ihtiyacınız olan cevabı sağlayan bir araçtır”  Harika kodlama temellerine sahip olmak son derece önemlidir. Ancak günün sonunda önemli olan keşfedilmiş ve gerçekten faydalı üründür. Araştırmada çok fazla üretim yazılımı kullanırsanız, yeni bir şey keşfetmek için gereken zamanı boşa harcarsınız. Bunun yerine keşif sürecinizi neyin yavaşlattığını bulun. Hızlı dallanmaya, sonuçlara ulaşma süresine ve temiz, gürültüsüz koda yatırım yaparak araştırma yollarını hızlandırın.  Kodun yeniden kullanımına tamamen karşı çıkmak çılgınlık olurdu. Sadece kodun yeniden kullanımının dengeli bir etkinlik olması gerektiğini belirtmek istiyorum. Araştırmada, atılan kodların oranı üretimdekinden daha fazladır. Denge yeniden kullanıma karşı daha da eğilir. Kodun yeniden kullanılmasıyla ilgili tuzakları içeren birkaç harika gönderi daha:   Yeniden Kullanılabilir Kod: İyi, Kötü ve Çirkin   Kendinizi Tekrarlamak Mantıklı Olduğunda   Yeniden kullanımın artıları ve eksileri ile Dengeli StackExchange  Ve işte kopya yapıştırma uygulamalarını savunan birkaç gönderi daha:   Kopyala yapıştır gerçekten bir sorun mu?   Kodu Ne Zaman Kopyala-Yapıştır Yapmalısınız?   Kopyala-Yapıştır Programlamanın İyisi ve Kötüsü   "5 YOE'li bir son sınıf öğrencisi olarak, maaşımın bir kısmının hangi kodu kopyalayacağımı bilmek olduğunu hissediyorum, hahaha"  Okuduğunuz için teşekkürler! Bazı kısımların biraz tartışmalı olduğunu düşünüyorum, lütfen yorumlarda bana bildirin!  Ayrıca   görünür. burada

Not sure if I mentioned already? Twitter time!

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Make resilience your competitive advantage

Keşif Yazılımı: Keşifte Dengeyi Sağlamak

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

AI/ML Datalake için Referans Mimarisi Oluşturmaya Yönelik Mimar Kılavuzu

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps