Evet, yapmalısınız.

İlk olarak, çoğu bilimsel yazılım berbattır. Sizinki ortalamanın altındaysa çok şaşırırım: Tasarım modellerini bildiğiniz gerçeği ve özyineleme ile döngüler arasındaki fark bunun daha iyi olduğunu gösterir.

İkincisi, teşvik veya motivasyona sahip olma olasılığınız düşüktür. başka biri (veya 6 ay içinde) ihtiyaç duymadıkça veya ihtiyaç duyulana kadar daha iyi hale getirmek için. Açmak size bu teşviki sağlar.

Olası avantajlar: olası yeni ortak çalışanlar, hata düzeltmeleri, uzantılar, yayınlar.

Olası olumsuz yönler: zaman çizelgesi (diğer insanlar için kodu koruma veya sorunları düzeltme), kepçe almak. Açık olacağım: Bu olumsuz yönlerin ikisini de çok ciddiye almıyorum.

Biraz temizler ve paylaşırdım. Yıllar boyunca pek çok kod yayınladım ve ayrıca verdiğiniz nedenlerden dolayı kod yayınlamadım.

Yapabildiğiniz her düzeyde gözden geçirin ve yorum yapın. "Başarısız girişimleri" bırakın ve bu şekilde yorumlayın. Neden başarısız olduklarını ve ne denediğini söyle. Bu, sizden sonra gelen kişiler için ÇOK yararlı bilgidir.

Birine yardımcı olması umuduyla, istek üzerine yayınladığınızı söyleyen bir BENİOKU dosyası oluşturun. Kodun çirkin olduğunu bildiğinizi, ancak yine de yararlı olmasını umduğunuzu söyleyin.

Mükemmel olmadığı için çok fazla insan her şeyi saklıyor!

Evet! Özellikle makaleniz ör. uyguladığınız yeni / geliştirilmiş bir algoritma hakkında veya önemli standart dışı veri analizi yaptığınız veya temelde sonuçlarınızı yeniden oluşturmanın yazılımınızı yeniden uygulamak anlamına geldiği herhangi bir şey hakkında.

Makalelerde nadiren daha fazlasını vermek için yer vardır bir taslaktan daha. Kritik ayrıntıları dışarıda bırakan (ancak kağıtla tamamen alakalı olmayan) makalelerden algoritmaları uygulamaya çalışmak için çok fazla zaman harcadığımı (= boşa harcadığımı) biliyorum.

¿Kodunuzun dağınık olduğunu mu düşünüyorsunuz? Bana kabuslar veren bir kod gördüm (ve üzerinde çalışmaya çalıştım):

• Beş düzey eğer Doğruysa kod aracılığıyla rastgele yerlere dağılmış.
• Bir sıfır dizisi oluşturun, onu dereceye çevirin, kosinüsü alın ve radyanlara geri dönün. Sonra, sonucu atın.
• Yoğun geliştirme altındaki bir yazılımda, "desteklenen mimariler" listesi o kadar eskidir (ve kendileri de söylerler) bu bilgisayarlardan birini elinize almak zor olurdu günümüzde.
• Birkaç sürümden önce kırılmış veya değiştirilmiş özellikler olup, yine de dokümanlarda önerilmektedir.
• Standart bir biçim girdisi kullanmaktan kendi biçimlerine kadar giden kod. Nasıl üretilir? Hiç kimse gerçekten bilmiyor ve geliştiriciler bir yanıt veriyor.
• Derlenmeyen sürümler. (Test ettin mi?)
• Belirli bir sırada erişmeniz gereken GUI menüleri. Aksi takdirde, bir segmentasyon hatası alırsınız ve baştan başlamanız gerekir.
• Kod içinde dağılmış sabit kodlu yollar. Bu nedenle, / home / someguy / absurd_project / working / 'in tüm oluşumlarını bulup değiştirerek sizinkine geçmeniz gerekiyor.

Ve benim kişisel favorim , binlerce satırlık kod içeren belirli bir program, yalnızca rasgele kod bitlerini ortadan kaldırmak için yorumları kullandı, biri hariç:

Burada kartları yumrukluyoruz.

Yine de ne yaptığı hakkında hiçbir fikriniz yok.

Ve bu sadece kodun her yerinde tek harfli değişkenler, hiçbir yerde belirtilmemiş algoritmalar gibi klasik iyi uygulama öğelerinin dışında kalıyor ...

Kodunuzun kalitesiyle ilgili endişeleriniz varsa, bu muhtemelen onu ortalamadan daha iyi hale getirecek kadar önemsediğiniz anlamına gelir. Kod temizlenene kadar beklerseniz, asla dışarı çıkmayabilir ve bilimsel katkılarınız kısmen kaybolur.

Bence, önem vermeniz gereken önemli şeyler sırayla:

1. Giriş ve çıkış formatları. Mümkün olduğunda standartları kullanın, olmadığında basitleştirin. Programınızı kara kutu olarak kullanmayı kolaylaştırın.
2. Yorum yaptı. Fonksiyonların kısa açıklamaları, algoritmaya hızlı bir bakış.
3. Okunaklılık. Deyimsel kod kullanmak, iyi değişken isimleri ...
4. Yapı. Ne yapmak istediğinizi bildiğinizde bu daha kolay olur, bu genellikle araştırma kodunda geçerli değildir. Yalnızca toplulukla ilgileniyorsanız, onu yeniden düzenlemeyi düşünebilirsiniz.

Bu nedenle, yazılımınızı 1'e sahip olduğunuzda yayınlayın (yazarken 2 ve 3'ün bir kısmı gelmelidir) .

Düşük kaliteli yazılımı paylaşmanın sizin hakkınızda kötü bir izlenim bırakıp bırakmayacağını soruyorsunuz. Yazılım paylaşmanın kesinlikle iyi bir izlenim bıraktığını düşünüyorum.

1. Bir bilgisayar bilimcisi olarak, meslektaşların kaynak kodlarını kullanıma sunmasını seviyorum. Çalışmalarına daha derinlemesine bakma, belki onlarla iletişime geçme, belki onlardan alıntı yapma olasılığımı artırıyor, çünkü etkileşimde bulunabileceğim bir eser daha var (sadece kağıt değil, aynı zamanda kod).

2. Bir makale kaynak kodu tarafından "kanıtlanmış" bir sonucu bildirdiğinde, ancak kaynak kodu kamuya açık değilse, genellikle sonucun gerçek olup olmadığını merak ediyorum. Kaynak koduna (ya da hiç bakmadan sadece kaynak kodunun kullanılabilirliğine) bakmak beni ikna edebilir.

Yani kaynak kodunuzu paylaşmak korkunç olsun ya da olmasın, her zaman bana sizin hakkınızda iyi bir izlenim verirdi.

Şimdi, daha da fazla etkilemek istiyorsanız, yardımcı olur ...

... sorunlara tepki verirseniz veya github gibi bir sitedeki talepler, yani başkalarının sizinle iletişim kurmaya çalıştığını gördüğümde ve sizin tepki verdiğinizde.

... kodunuz, makalenizdeki iddiaları kaynakla ilişkilendiren bir benioku dosyası içeriyorsa kodu. Bu şekilde, makaleyi okuduğumda ve daha fazlasını öğrenmek istediğimde, kodda uygun yere atlamak için benioku'yu kullanabilirim. Bu tür bir benioku dosyasından tipik ifadeler şunlar olabilir: "Makalenin Sec. 3.2 algoritması dosya algoritması / newversion / related / secondtry / foo.c içindedir" veya "Çalışmayı Bölüm 2'de açıklanan küçük veri kümesiyle tekrarlamak için kağıt, "make; second_step yapmak; foo_bar_2 veri kümeleri / christmas.dataset. Bu çalışma dizüstü bilgisayarımda yaklaşık 2 gün sürüyor ".

Ayrıca, http://matt.might.net/articles/crapl/ adresinde bulunan Matthew Might's CRAPL (Topluluk Araştırması ve Akademik Programlama Lisansı) ile de ilgilenebilirsiniz. Şu terimi içerir: "Yazarı, Program dahilinde bulunan her türlü saldırı, küfür veya inanç sıçramasından dolayı utançtan, utançtan veya alay etmekten kurtarmayı kabul edersiniz." Bu "lisansın" herhangi bir yasal etkisinin olup olmadığı benim için net değil, ancak amaç açık: Çirkin kodunuzu serbest bırakın ve başkalarının çirkin kodu hakkında kötü düşünmeyin.

Teğetsel olarak ilgili, endişelerinize göre yazılımı nasıl paylaşacağınıza değineceğim (zaten yanıt verdiğiniz yazılımı paylaşmamalısınız ).

Başarısız girişimleri etkin bir şekilde sürüm kontrolüne koymak, onları hiç kimsenin görmeyeceği anlamına gelir. Bunu halletme şeklim, her bir girişimi bir yönteme ve her başarısız girişimi ayrı bir yönteme koymaktır:

  def main (): get_foobar (x, y) def get_foobar (): return x ** ydef get_foobar_legacy_1 (): "" "Bu deneme > 100" "" değerleri için işe yaramadı return x + ydef get_foobar_legacy_2 (): "" "Bu girişim Eylül'de Çarşamba günleri işe yaramadı" "" return x - y  

Aşağıdaki yorumlara göre, bu yöntemleri ayrı bir FailedAttempts veya BadIdeas sınıfına koymak iyi bir fikirdir. Bu, gerçek ihtiyaca göre sürecin çeşitli aşamalarını bölümlere ayırmanın güzel bir etkisine sahiptir. Bilgisayar programcılarının çoğu zaman mantığı bir yönteme ne zaman ayırıp ne zaman kesmeyecekleri konusunda ustalıkları olduğunu görüyorum, ancak bilgisayar bilim adamları çoğu zaman bunu yapmıyor. Bu yaklaşım, bilgisayar bilimcilerinin gerektiğinde bir yöntem oluşturmasına yardımcı oluyor.

Elbette kaynak kodunu paylaşmalısınız.

Akademik olarak konuşursak, kolayca bulunmayan bir yazılım tabanlı sonuç çok değerli değildir, çünkü gerekirse başkaları iddialarınızı nasıl doğrulayabilir? Bu amaç için kendi başlarına programlama yapmalarını mı bekliyorsunuz? İkili dosyaları paylaşmak çok daha az değerlidir ve çoğu zaman onları çalıştırmaya çalışan insanlar için kabuslara yol açar.

Bence paylaşmalısın. Her şeyden önce bazı temel temizlik yapmalısınız. (örneğin: artık kullanılmayan daha önceki bir kod yok; yorumda kod yok; geçerli yorumlama yöntemi vb.) Ayrıca, koda bazı "yapılacaklar" koyarsanız, diğerleri zamanınızın dolduğunu görebilir ve görebilirler niyetleriniz. (örneğin: yapılacaklar listesi: bu enum olarak değiştirilmelidir) Ayrıca algoritmalarınızın en önemli bölümünü paylaşmanız gerektiğini düşünüyorum. Bir kodu paylaştığımda hiçbir zaman önemsiz kısımları paylaşmam. Herkes dosyaların okunmasını / yazılmasını, iş parçacıkları arasındaki iletişimi, gui vb. Ancak okunamayan kodu paylaşmayın. Hiç mantıklı değil. Bu yüzden orta yolun çoğu kez en iyisi olduğunu düşünüyorum. :-)

Bilgisayar bilimleri bölümünüzdeki bazı profesörlerle konuşun. Öğrencilerin dağınık kodu temizleyerek daha kolay anlaşılır hale getirebilecekleri bir proje arayanlardan herhangi birinin olup olmadığına bakın.

Kodu revize eden öğrenciler için bu iyi bir öğrenme deneyimi olabilir. Kodlayıcılar önce sonuç odaklı program yaptığında veya yalnızca sonuç odaklı olduğunda ne olur? Bunu ilk elden görecekler. Ayrıca öğrendikleri bu en iyi uygulamalardan bazılarını da uyguluyorlar. Ve diğer profesyonellerin zaten kodu görmekle ilgilendiğini bilerek özellikle iyi bir iş çıkarmaya motive olabilirler.

Bir profesör bunu bir yarışmaya bile dönüştürebilir, öğrenci ekiplerinin hepsi yazılımı gözden geçirmeye çalışır ve en iyi sonuç dünyanın geri kalanıyla paylaşılır.

Yeniden düzenleme çabaları başarısız olursa, olduğunuzdan daha geride değilsiniz. Durum buysa, feragatnameler harika bir şeydir. Sadece kodu paylaşın, ancak bir uyarı ekleyin: "Güzel değil. Bunu yazdığımda, araştırmamı yapmaya çalışıyordum - bilgisayar laboratuvarımın dışına çıkacağını hiç düşünmemiştim. Ama rica ederim gerçekten istiyorsanız bir göz atmak için. "

Kodun yayınlanması lehine pek çok nokta diğer cevaplarda belirtildi ve bunlara tamamen katılıyorum. Bu nedenle, kodun yayımlanmasının temel istenirliği tartışıldığı için, bunu, dikkate alınması gereken diğer noktaların bir kontrol listesi ile tamamlamak istiyorum. Bu sorunların çoğu muhtemelen hemen hemen tüm akademik yazılımlarda ortaya çıkmaktadır, bu nedenle "Bu projem için geçerli değil" yanıtını veremeseniz bile. hepsine, kodunuzu yayınlamadan önce en azından "Bu bir endişe, ancak bu sorunu çözerek ..." şeklinde yanıt verebilmelisiniz:

• kodu yayınlama izniniz var mı?
  • Yalnızca yeniden dağıtmanıza izin verilen kod parçalarını kullandığınızı garanti edebilir misiniz? Yoksa açık olmayan kaynaklardan kod mu kullandınız? kendi dahili yazılımınız için kullanabileceğiniz, ancak yayınlamanıza izin verilmediğini? Kullandığınız tüm kodun tek bir pakette yayınlanmasına izin verildiğini garanti edebilir misiniz? Lisans uyumluluğu önemsiz olmayan bir sorundur.
  • Hatta güvenilir bir şekilde öğrenebiliyor musunuz? Kodlama çalışmanızın herhangi bir bölümünü dış kaynak olarak kullandınız mı veya başka bir yerden yayınlanmamış kodu entegre ettiniz mi? Örneğin, mezuniyet tezleri sırasında herhangi bir öğrenciye nezaret ettiniz mi veya çalışmaları araştırmanıza dayanan ve bu nedenle kodları kod tabanınıza eklenmiş olan herhangi bir öğrenci araştırma asistanı istihdam ettiniz mi? Herhangi bir iş arkadaşınız kod tabanınıza kod kattı mı? Kodlarının bir kısmını öğrencilerden mi aldılar? Dahil olan tüm bu kişiler lisans konularına gerektiği gibi dikkat ettiler mi (eğer bu lisanslama soruları hakkında eğitimli bir yargıya varacak bilgiye sahiplerse)? Kodun hangi bölümlerinin nereden kaynaklandığı hala belirlenebilir mi? Her bölüme katkıda bulunan insanlar hala biliyor mu? Hâlâ sizin için "iletişim menzilinde" mi?
  • Kod, çalışma süresinde üçüncü taraf fonlarına göre mi geliştirilmişti? Öyleyse, finansman sözleşmesi koşulları kodun yayınlanmasına izin veriyor mu yoksa finanse edilen proje dahilinde oluşturulan yazılımın yalnızca proje ortaklarıyla paylaşılması gereken herhangi bir gereksinimi içeriyor mu?
• Kodu ve yorumlarını temizlemek için çaba harcayacak kadar yeterli kaynağa (zaman veya başka türlü) sahip misiniz? yine de anlamlı olacak, ancak kamuya açık hale getirilmemeli mi?
  • Kod üzerinde çalışanı başkalarına veren yorumlarınız var mı? Kodu katkıda bulunan kişilerin, fonlarına göre ilgili araştırmada çalışmalarına resmi olarak izin verildi mi? ? (Yazılım geliştiricileri, takım çalışmasının ve bileşenlerin yeniden kullanımının yazılım geliştirmenin temel yönleri olduğunun farkındadırlar. Fon sağlayan kuruluşlar, maalesef, genellikle bundan habersizdirler ve eğer geliştirici A X projesinden ve geliştirici B'nin Y projesinden finanse edildiyse, A, yalnızca X ve B üzerine yapılan çalışmalar, yalnızca Y üzerinde çalışır ve wlog, A'nın Y projesinde sona eren bir şeyi yapmak için yalnızca yarım saat harcadığını, finansmanın bazı kısımlarını geri almak gibi ciddi sonuçlara yol açabileceğini ortaya koyar.)
  • Yayınlanan verilerdeki herhangi bir şey, işin nasıl yapıldığına dair kamuya açıklanmaması gereken özellikler hakkında herhangi bir bilgi veriyor mu? Bu, özellikle bir VCS'deki tüm taahhüt geçmişi, kamuya açık hale gelebilir (veya pratik olarak, taahhüt tarihinin asla yayınlanmaması gerektiği anlamına gelir), ancak başka durumlarda da rol oynayabilir. Örneğin: Resmi olarak atanan çalışma saatleri dışında (örneğin hafta sonları) kod üzerinde herhangi bir çalışma yapıldı mı? Çalışma süreleri, günlük çalışma saatleri için ülkenizin yasal sınırının üzerinde çalıştığınızı gösteriyor mu? Çalışma saatleri, yasal olarak gerekli molalara uymadığınızı gösteriyor mu? Çalışma süreleri, başka projelere atanan kişilerin katkı sağlamasına neden oluyor mu? Çalışma süreleri, çalışma sürelerinizle ilgili olarak aksi belirtmiş olduğunuz herhangi bir ifadeye güvenmemek için herhangi bir neden sağlıyor mu (örneğin, belirli maksimum tahsislerle önceden tanımlanmış çalışma paketlerine ayrıntılı bir çalışma süresi atanmasını gerektiren proje başarı raporlarında)? Çalışmamanız gereken durumlarda çalıştığınızı belli eden herhangi bir şey var mı (örneğin bir proje toplantısı sırasında)? Çalışmamanız gereken yerlerde çalıştığınızı gösteren herhangi bir şey var mı (örneğin, evden, sözleşmenizin ev ofisi yapmanıza izin vermediği durumlarda, örneğin sigortayla ilgili komplikasyonlar için)?
  • Kodda, şifreler, kullanıcı hesabı adları veya URL'ler gibi herkese açık olarak bilinmemesi gereken gizli bilgiler var mı? (Çünkü sunucular, az sayıdaki seçkin kişiden daha fazla sayıda kullanıcıyı işleyecek şekilde düzenlenmemiştir. Kime test kurulumu için URL şahsen verildi)?
• Kod başkaları tarafından kullanılabilir mi?
  • Kod çalışacak mı yoksa kapsamlı yapılandırma çalışmaları mı gerektiriyor? Hangi yapılandırmanın gerekli olduğunu açıklamak için gereken çabayı harcayabilir misiniz?
  • Kod derlenebilir mi? Herkese açık olmayan resmi olmayan değiştirilmiş veya özel olarak oluşturulmuş derleyiciler kullandınız mı? Öyleyse, kod, makalelerinizde sözde kod algoritması olarak sağlanabilecek olanın ötesinde bir şey ekliyor mu?
  • Kod herhangi bir harici kaynak gerektiriyor mu? Yalnızca kod şu veya bu nedenle kodla birlikte yayınlayamayacağınız sunuculara, kitaplıklara veya veri kümelerine erişebiliyorsa yararlı olabilir mi? Bu kaynakların en azından bir açıklaması sağlanabilir mi, yoksa arayüzleri bir tür NDA'ya tabi mı?
  • Kod, üzerinde çalıştığı sistemlerde geri döndürülemez değişiklikler yapıyor mu? Örneğin, herhangi bir sistem yapılandırmasını otomatik olarak değiştiriyor mu (sistem arama yolunun üzerine yazmak gibi)? Bazı takımyıldızlarda (test kurulumlarınızda dahili olarak kaçındığınız) herhangi bir bileşende kalıcı hasara neden olabilecek donanım bileşenlerine herhangi bir düşük seviyeli erişim gerçekleştiriyor mu? Kullanıcıları bu tür olası istenmeyen yan etkilere karşı güvenilir bir şekilde uyarabilir misiniz?

Elbette. İyi bir yazılım yazmada daha iyi olmanın tek yolu geri bildirim almaktır (her türden). Geri bildirimden korkuyorsanız, gerçekten çok uzağa gidemezsiniz. Harika bir yazılım yazmanın üç temeli alıştırma, uygulama ve alıştırmadır.

Şimdi, insanlar yazılım yazma becerilerinizin birinci sınıf olmadığını öğrenirse bunun kariyerinize zarar verip vermeyeceği sorusuna gelelim. Sanırım hayır, aksine akademik dürüstlüğünüz için size saygı duyacaklar. Ve sizinle işbirliği yapmayı dört gözle bekliyorum.

Projenizle ilgilenen diğer kişilerin kodunuza kolayca erişmesi ve belki de kodunuzu iyileştirmeye yardımcı olmaları ihtimaline karşı bunu GitHub 'a aktarabilir ve bir projeyi sürdürmeye çalışabilirsiniz.

Evet, yapmalısınız. Sonuçta, Linux çekirdeği kaynak kodu oldukça karışık ve bu, birçok profesyonel geliştiricinin onu incelemesini ve ona yamalar ve eklemeler eklemesini engellemedi. Unutmayın ki Linux çekirdeği, dünyadaki en hızlı ve en güçlü süper bilgisayarları ve çoğu cihazı çalıştıran işletim sisteminin temeli. Linux çekirdeği kaynak kodunun dağınık olmasından olumsuz etkilenmiş veya herhangi bir şekilde zarar görmüş.

Kimsenin neden kodunuzu paylaşmanız gerektiğinden bahsetmemesinin bir nedeni, sizinle işbirliği yapmakla ilgilenen, ancak kodu temizlemek ve farklı sistemlerde çalışmasını sağlamak için daha fazla zaman harcamaya hazır birini bulmanız olabilir. vb., yaptığınız yenilikçi geliştirmeyi yapmaktan çok.

Pek çok insan bu tür işleri çok tatmin edici buluyor ve eğer kodunuz gerçekten onlar için yararlıysa, bunu yapmaktan mutlu olabilirler. Her durumda, onu kullanmaya çalışan ancak bir tür yardıma ihtiyaç duyan insanlardan geri bildirim almanın, onu daha sürdürülebilir / kullanımı ve anlaşılması daha kolay hale getirmek için iyi bir motivasyon olduğunu fark edebilirsiniz.

Kodunuzu kesinlikle paylaşmalısınız.

Bir şeyleri sıralamak için, başarısız bir girişimin bir bölgesini yapmak gibi kodun aynı parçalarının bölgelerini yapın ve neden başarısız olduğunu açıklayın. Ayrıca, Visual Studio'da geliştirme yapıyorsanız, Extension Manager'dan "CodeMaid" uzantısını yükleyin ve eksiksiz çözümünüzü temizleyin. Boşlukları kaldıracak ve kullanılmayan referansları kaldırarak çoğu şeyin daha iyi görünmesini sağlayacaktır.

C # ile geliştirirseniz kodunuzu benimle paylaşın. Ayrıca işleri halletmenize yardımcı olabilirim :)

İsterseniz paylaşın, istemiyorsanız paylaşmayın. Bunun kulağa tuhaf geldiğini biliyorum ama bence bugünlerde "her şeyi paylaşmak" için çok fazla baskı var ve insanlar paylaşmadığınız için sizi suçlu yapmaya çalışacaklar, ancak gerçekten hiçbir şey paylaşma zorunluluğunuz yok.

Kodun "olduğu gibi", herhangi bir destek vaat etmeden sağlandığına dair bir sorumluluk reddi beyanı ekleyin. Ardından kodu paylaşın.

Örnek olay: İzole noktalar bulutunu su geçirmez bir yüzeye dönüştürme robotikten bilgisayarla görmeye ve Microsoft Kinect gibi 3D sensörlerden gelen verileri işlemeye kadar her yerde kullanılan son derece önemli bir pratik sorundur.

Poisson yüzey rekonstrüksiyonu 7 yaşında ve uzun zamandır en son teknoloji olmayı bıraktı. bu sorunu çözmek. Ama bugün hala herkes kullanıyor. Neden? Çünkü yazar kodu yayınladı ve o zamandan beri bir dizi popüler geometri işleme kitaplığına dahil edildi. Gazetede şu anda binin üzerinde alıntı var.

Evet. Kodunuzu, muhtemelen CRAPL lisansı altında yayınlamalısınız. Amaç daha iyi bir gelecek inşa etmektir - ve sizin berbat kodunuz insanların bunu yapmasına yardımcı olacaktır. Bir uyarı, kodun başarılı bir şekilde nasıl çalıştırılacağını, birinin yayınlanan herhangi bir sonucu yeniden üretme şansına sahip olacak kadar belgelemeniz gerektiğidir.

Ve endişelenmeyin - üzerinde çalıştığım bir parça araştırma kodu Yaklaşık 8 yıl boyunca bir dizi proje için 5 kayıtsız programlama yeteneği postdoc tarafından geliştirilmiştir.

Genel değişkenlerin listesi (sadece isimler) kabaca 4 sayfaydı.

Bunların kabaca üçte biri, belirli bir anda çalışan işlevselliği değiştirmek için varsayılan davranışı ayarlamak için kullanıldı. Diğer% 20'si paralel veri yapılarıydı - yani yaklaşık olarak aynı verileri depoladılar - ve bu nedenle veri yapılarından az çok rastgele çekilen koddaki işlevler. Evet. Bazen senkronize olmadılar. Ve bazen senkronize olmaması gerekiyordu.

Grubun sunucusunun rastgele bölümlerinde depolanan kabaca 50 belgelenmemiş sürüm vardı - her biri en az bir belirli amaca hizmet ediyordu - ve yalnızca bir yönetici bu belirli amaçlara sahipti kafasında. İnsanların belirli bir amaç için 'yanlış' sürümü kullanmamasından daha yaygındı.

İnanılmaz derecede karmaşık yinelemeli prosedürlerin, örneğin bir dosya yazmak için kullanılması standarttı. Cidden - görüntü sonuçlarını kaydetmek için birkaç bin satır.

Oh, ve hiçbir zaman yeni bir değişken oluşturarak bir bellek sızıntısını (aslında görünmez bir figür) çözmeye yönelik kasaplık bir girişimin kalıntıları.

Oh, ve veritabanı, o güzel veritabanı. Verilerin yaklaşık yarısı (a) veritabanı tasarım hataları (b) veri giriş hataları (otomatik programlarda) nedeniyle kullanılamaz durumdaydı. Veritabanından dosya alma kodu birkaç yüz satır mantık uzunluğundaydı ... Veritabanının kendisi de aynı verilerin birçok kopyasını içerecek kadar nazikti, çoğu tablolar arasında kopuk bağlantılar vardı. Kısıtlamalar? Hayır. Bir istatistikçinin, veri tabanına emanet edildikten sonraki bir ay içinde huzursuzluktan korkudan ağlamaya ve bırakmaya doğru ilerlemesini izledim ...

Yazılımı çalıştırmanın ve doğru sonuçları almanın 0 ile 1 arasında bir yolu vardı herhangi bir anda ...

Ve evet, gotos vardı.

Oh, ve opak ve belirleyici olmayan operasyon sağlamak için GUI aranarak bir dizi hesaplama yapıldı

Verilen herhangi bir işlevin yaklaşık% 90'ı, oldukça güvenilir bir şekilde sonuçla veya sonucun hata ayıklamasıyla alakalı değildi - kısa vadeli projelerden ziyade, eklenen ve sonra asla kaldırıldı. Cidden - gerçekten işe yarayan tam bir özellik sürümü yazdım, bu boyutun 1 / 10'u ... Önemli kesirler kopyalanarak yapıştırılan eklenen işlevlerdi ve çoğu birbirinden farklıydı.

Ve Virginia yok belge yok. Veya açıklayıcı değişken isimleri.

Oh, ve artık var olmayan kod kullanılarak oluşturulmuş belgelenmemiş, hatalı, dll'ler ve ilişkili kütüphaneler.

Hepsi Matlab'da yazılmıştır. Matlab kodlama uygulamaları açısından, bol miktarda eval kullanımının günün en önemli anı olacağını varsayalım.

Cidden, kodunuz o kadar da kötü değil.

Bununla birlikte, gerçekten yararlı bir şey yaptıysanız, başkalarının kitaplığınızı kullanması ve bunlardan alıntı yapması için temizlenmiş bir sürüm yayınlamak kariyerinizi geliştirebilir. Az önce bir şey yaptıysanız, çoğaltma muhtemelen gitmeniz gerektiği yere kadardır.