Utanmadan bir açık kaynaklı projenin yayınlanması [kapalı]


51

Uzun zamandır oldukça büyük bir açık kaynaklı projede tek başıma çalışıyordum ve yayınlamak istediğim noktaya yaklaşıyor. Ancak, kendi kendime öğrendim ve projemi yeterince gözden geçirebilecek birini tanımıyorum.

Birkaç yıl önce, yayımladığım forumda (kritik anlamda) hemen hemen parçalanan küçük bir kod kodu yayınlamıştım. Kurallar çalışsa bile, eleştiri doğru, ancak acımasızdı. Her şey için en iyi uygulamaları aramaya başlamamı istedi ve sonunda beni daha iyi bir geliştirici yaptığını hissediyorum. Projemdeki herşeyi çok fazla aştım, defalarca kaybettim mükemmel hale getirmeye çalışıyorum.

Projeme inanıyorum ve birçok insana yardım etme potansiyeline sahip olduğumu düşünüyorum ve bununla ilginç şeyler bazı harika şeyler yaptığımı hissediyorum. Yine de, kendi kendime öğrendim çünkü yardım edemem ama kendi eğitimimde ne gibi boşluklar olduğunu merak ediyorum. Kodumun geçen sefer parçalanması, tekrarlamak istediğim bir şey değil. Sanırım sayısız saatimi içine döktüğüm projemden kesinlikle utanç duyduğum için korku duyduğum en büyük korkum, çünkü kendi eğitimim yüzünden ya da daha da kötüsü, cırcır böceği sesiyle salıverdiğim için açıkça bariz şeyler kaçırdım.

Benzer bir durumda olan var mı? Yapıcı eleştiriden korkmuyorum, yapıcı olduğu ve sadece nasıl battığım hakkında bir öfke olmadığı sürece. StackExchange'te bir kod inceleme sitesi olduğunu biliyorum, ancak gerçekten büyük projeler için ayarlanmadı ve proje parçamın bir kısmını yayınlayacak olsam iyi geribildirim alabilmek için yeterince büyük bir topluluk var gibi hissetmedim (I bir dosya ile denedim). Sürecimde utanmadan veya tahrif edilmeden projeme en azından bir miktar başarı ölçüsü vermek için ne yapabilirim?


17
Bir foruma kod bırakma ve kaygıları olanlara uygun kaynak içeren bir proje yayınlama arasında bir fark var. Pek çok kullanıcı ve potansiyel geliştiricilerin koda baktıkları büyük açık kaynak projeleri için bile, "kodunuzun X ve Y'nin kusurlu olduğunu düşünüyorum" türü tepkiler nadir görünüyor.

17
Açıklamadan, birkaç yıl önce o zaman aldığınız eleştiri sizi daha iyi bir programcı yaptı. Öyleyse neden bu kez eleştirmekten bu kadar korkuyorsun? Artık daha iyi bir programcı olmak zorunda olmadığınızı düşünüyor musunuz? İyileşmek istiyorsan, egonu bir kenara bırakıp birkaç vuruş yapmalısın.
Paul Tomblin

3
Açık kaynak kullanımıyla ilgili en güzel şey, eğer insanlar şikayet ederse, onlardan her zaman sorunları sizin için çözmelerini isteyebilirsiniz.
blueberryfields

4
Belirli şüpheli alanlarınız varsa, onları codereview.stackexchange.com adresinde kaldırın .
pdr

12
BTW eğer utanma bir sorun olsaydı, asla Wordpress ya da Joomla gibi projelerimiz olmazdı ... Blogların yarısından fazlası WP'de, kimsenin kod temeli kalitesini önemsemediği görülüyor ...
yannis

Yanıtlar:


35

Proje geliştiricilere yönelik değilse (örneğin: bir geliştirme çerçevesi, bu durumda daha fazla öğrenmenizi sağlarsa eleştirmelerini istersiniz), endişelenmemelisiniz. Ancak o zaman bile, geliştiricileri hedef alan birçok açık kaynak projesi var, ancak insanlar onları seviyor çünkü o noktaya gidiyorlar (çok kötü bir şekilde yapılandırılmış olan Codeigniter'i düşünüyorum, ama yine de en popüler php çerçevesi)

Düzenli insanlar için bir uygulama ise, muhtemelen sadece sonuçları önemser.


3
+1 Ve kritik geliştiriciler size bir düzeltme eki gönderebilir! Bilginizi ve çabalarınızı dünyaya açmak her zaman saygıdeğer olur :)
yati sagade 13:11

4
Gerçekten herhangi bir eleştiri değerli geri bildirimdir. Sert olsa bile (sadece geri bildirim olarak bakabilme yeteneğine sahipsin) ve bu değer, korkutmak için bir sebep değil. :-) Çabalarınızla gurur duyun! Yapabileceğinin en iyisi, eğitiminle ya da BÜYÜK olanları anlayabiliyorsan! Takip eden Geribildirim, yalnızca daha iyi bir geliştirici olmanıza yardımcı olacaktır. Dürüst olmak gerekirse, dünün kodu her zaman iyileştirdiğiniz ve büyüdüğünüz sürece emilecektir.
Robert French

+1 - Teşekkürler. Proje geliştiriciler içindir, ancak sonuçlar hakkında iyi bir noktaya değinirsiniz.
Umutlu

1
Herkesin kodu berbat, değerli bir öğrenme deneyimi olarak herhangi bir eleştiriyi al. Birisi sizi yapıcı olmayan bir şekilde ayırırsa, onları kesinlikle aptallar olarak görmezden gelirsiniz
David Hayes

25

Kodunuzda sorun var. Benimki de öyle. Bu soruyu cevaplayan başka biri var mı? Kodlarında da sorunlar var.

Söylemediği sürece 10 ya da daha az satır kusurludur. Belki trajik bir şekilde.

Bir geliştirici olmak CONSTANTLY yeteneklerinizi ve anlayış sınırlarını karşı kendinizi ezmek için. TÜM geliştiriciler için böyle olmayabilir, ama benim için ve tanıdıklarım için, hemen hemen her zaman yetkinliğimizin sınırında çalışıyoruz. Ve bununla tekrar tekrar yüzleşiyorsunuz, sonra güzel bir hafta sonu geçiriyorsunuz, sonra Pazartesi'ye geri dönüp tekrar tekrar yapıyorsunuz.

Bu yaşamı 15 yıl boyunca çalıştım, üzerinde durduğum şey şu: Bu sizin kodunuz değilsiniz . Sen kod yaz. Kodun kararı sizin kararınız DEĞİLDİR . Kodunuzun, bazılarının bildiğiniz, bazılarının bilmediği sorunlar var. Bunu dikkatinize sunmak size yardım edebilir , bu konuda yapabileceğiniz tek şey kötü hissetmediğiniz sürece. Kötü hissetmek kodunuzu iyileştirmez, sadece kendinizi kötü hissetmenizi sağlar.

Kodunuzu yazıyorsunuz ve nasıl yaptığınızı bildiğiniz gibi yazıyorsunuz. Belki yarın bugün bildiğinden daha fazlasını bileceksin, ama bugün bildiğin kadar yaptın. Tavsiyem: bugünün kodunu bugün ve yarın kodunu yarın yazın. O zaman iyi bir hafta sonu geçirin ve pazartesi gününün kodunu yazmak için Pazartesi günü tekrar gelin.


24

Genel bir kural olarak açık kaynaklı programların kaynak koduna bakan üç grubu vardır.

  1. Programın kendileri için biraz farklı çalışmasını sağlamak, farklı bir platforma taşımak veya kendi programları için bir başlangıç ​​noktası olarak kodunu değiştirmeyi düşünenler. Kodu beğenmezlerse, genellikle kodu kullanmazlar ve asla onlardan haber alamazsınız.
  2. Öğrenciler, kullandığınız dilde kodlamayı öğrenmeye çalışıyor. Bunlar neredeyse hiç sizinle temasa geçmez, ancak ara sıra neden bir şeyi diğerine karşı yaptığınızı soran bir e-posta alabilirsiniz. (Adil olmak gerekirse, uzun yıllardır bu e-postalardan birini almadım. StackExchange gibi web sitelerinin bu etkileşimin yerini alabileceğini düşünüyorum)
  3. OpenBSD'deki çocuklar gibi güvenlik araştırmacıları, aracınızın dağıtımlarına dahil edilecek kadar güvenli olup olmadığına karar vermeye çalışıyor. Değilse, ancak yine de programınızı dahil etmek istiyorlarsa, onu güvenceye almanın bir yolunu bulmak için irtibatta olacaklar. (Programınız popüler hale gelirse, muhtemelen siyah şapka araştırmacılarını da çekeceğini, ne bulursanız olun sizinle temas etmeyeceğini hayal ediyorum.)

Gerçek dünyada, insanlar kaynak kodunuzu bunlardan başka bir nedenden ötürü okumazlar, çünkü buna gerek yoktur. Daha önce yalnızca böyle bir geri bildirim aldınız, çünkü kodu bir foruma gönderdiniz, bu da kod hakkında geri bildirim almak istediğinizi ima etti.

Gerçekten bir istismarı torrenti için endişelenmene gerek yok; Sizinle iletişim kurması muhtemel olan tek kişi, özellikler eklemek veya hataları gidermek isteyen, kod temeli üzerinde daha önce gezinen ve tepeler için çığlık atamayan kişilerdir. ;)


5

Bu sorunun arkasındaki psikolojiyi gerçekten anlamıyorum ... kendinize sormak için daha iyi bir soru "bu yazılımı piyasaya sürerek ne kaybedeceğim" olacaktır.

Projeniz kod kokusu dolu olsa bile, bir şey kaybetmek zorunda mısınız?

Kod çok kötü olsa ve birisi size bir alev-posta yazmak için zaman ayırsa bile, ne olduğunu tahmin edin, muhtemelen yazılımınızı üzerinde bazı değişiklikler yapmak ve daha iyi hale getirmek için yeterince kullandı.

Bundan mutlu olmalısın! Eleştiriyi kabul et ve kodunu daha iyi hale getir, sana yazmak için zaman ayıran öfkeli adama sor. Umursar!

Bir süre sonra alev postaları duracak, insanlar yazılımınızı kullanmaya devam edecek, hatalarınızdan öğrenmiş olacaksınız ve eğitiminizde var olduğunu bilmediğiniz boşluklar artık orada olmayacak.

Bir şey yapmaya istekli biriyle çalışmayı, hatalarını kabul etmeyi, düzeltmeyi ve hiçbir şey yapmaya istekli olmayan bir kişiden daha çok çalışmayı tercih ederim .

Yazılımı adınız altında bırakmak gerçekten rahat değilse, bir takma ad altında bırakın. Başarılı olursa, kendin olarak kabul et, takma adını değiştirmezse :)


Son cümle için +1, müzik endüstrisindeki insanlar bunu "deneysel" albümleri ile her zaman yaparlar :)
MattDavey

4

Ben sadece açık kaynak kodlu değil aynı zamanda insanların kodunuzun tam evrimini görebileceği açık gelişim konusunda da inancım var. Saçlı beyin prototipinden çalışma koduna kadar ... hiç utanmamalısın. Kendini oraya koyuyorsun, bu cesaret ister. Sahip olun ve bununla gurur duyun. Kimse mükemmel değildir.


3

Ne kadar uzun süredir bu oyunda olursam, kod kalitesinin tek ölçüsünün müşteri deneyimi olduğunu fark ettim. Bir işlev yazıyorsanız, bu işlevin arayanıdır. Bir kütüphane? Bu kütüphane için yazanlar. Bir çerçeve? Bunun benimseyenleri. Bağımsız mı? Programı başlatan kişi veya arka plan programı.

Güzel kod erdemine sahiptir, beni yanlış anlama - ama söylendiğinde ve yapıldığında tek önlem "İşe yarıyor mu?" Bir buggy karmaşası olan temiz kodun ve tamamen güvenilir olan şeytani bir kodun bol olduğunu gördüm (ayrıca iyi, temiz ve çirkin de :))

Öyleyse, eleştirmenler kodunuzun çirkin olduğunu söylüyorsa kimin umurunda. İşe yaramazsa, programınızı geliştirmeye çalıştığınız faydalı eleştiri (test verileri!). İçeride kalın, internetin trol popülasyonundan kaçının ve projenizde eğlenin!


2

Diğer afişlerin söylediklerine kesinlikle katılıyorum: Kodunuz berbat ve kaliteli olmasa bile - çoğu insan umursamıyor. Bir anda veya başka bir zamanda OpenSource koduna dalmış olan herkes "WTF burada oldu" diye düşünmüş olabilir.

Ama bir projenin kod tabanını sadece "ahbap, kodun berbat görünüyor!" Demek uğruna eleştirmek için motive eden kimseyi tanımıyorum . Hepimiz oradaydık ve hepimiz biliyoruz ki şu anda yazdığımız herhangi bir kod sadece birkaç adımda kendimiz için oldukça kötü görünecek (benimki kesinlikle olacak).

Bu yüzden o kadar endişelenmeyin - insanlar boş zamanlarında OpenSource projelerinin kodunu nitelemekten daha iyi yapacaklar.


2

Gerçek kod her zaman çürüyen ve kirli, birbirine tokatlanmış ve yaklaşık geçici bir şekilde korunur. Temizleme, özel durumları ve özel sabitleri belgelemekle sınırlıdır. Temiz kod ve gerçek dünya arasında bir empedans uyumsuzluğu var.

Ayrıca herhangi bir yetkili mühendisin başkasının kodunu paramparça edebileceğini de fark ettim.

(1) testleri geçerse ve başarısız olmadan amaca ulaşırsa VE (2) sadece küçük yeniden yazma ile küçük değişiklikler yapabilirsiniz, bu iyi bir koddur.


2

LinkedIn'in kurucusu Reid Hoffman'dan bazı bilge sözler:

“İlk ürün sürümünüzden utanmıyorsanız, çok geç bıraktınız.”

“Üyelerle etkileşimde bulunmak ve gerçekte neyin önemli olduğunu görmek çok önemli… Böylece mümkün olan en kısa sürede en düşük ürünü elde edersiniz.”

Bunun özellikle umut verici bir başlangıçla harika bir fikre sahip olmanın insanları katkıda bulunmaya ve katılmaya teşvik ettiği açık kaynaklı projeler için geçerli olduğunu düşünüyorum. Çok cilalanmış bir şey, güneş gözlüklerini takmana neden olur, bu duyguları uyandırmayabilir. Ancak erken bırakma konusunda en önemli şey, yapılması gerekenler hakkındaki tüm önyargılarınızı paramparça etmek ve doğru yönde hareket etmeye başlamaktır.


1

Kimsin? İnsanların Tanrı programcısı olarak tanıdığı ve itibarınızın düşeceğinden endişe duyan biri misiniz? İş başvurusunda bulunacak olan ve işverenin bu eleştiriyi okuyabileceği ve kötü bir programcı olduğunu düşünmesinden endişe duyan siz misiniz? Benim sorduğum, neden batırdığın konusundaki eleştiriden neden korktuğun. Hangisinin gerçek ve hangisinin öfkeli olduğuna karar ver. İyi olanları kusur olarak alın ve bir sonraki sürümde onları düzeltin. Sadece eleştiri hakkında gereksiz endişelendiğinizi hissediyorum. Açık kaynak topluluğuna yardım ediyorsun, bunun kendisi de çok iyi bir sebep. Lütfen iyi çalışmaya devam edin.


2
Tanrı programcısı nedir?
Umutlu

1
@Hopeful. HTE Bombay Üniversitesi'nde bir profesör var. Söylentiler, bu adamın program yazdığı, derlediği ve çalıştırdığı yönünde. Yeniden derleme veya hata ayıklama olarak bilinen bir aşama yoktur. Bu, Tanrı programcısı.
Manoj R

Tamam, ben olmadığımdan eminim ... Hata ayıklama konusunda takıntılıyım. Bir şey sadece ilk kez çalıştığında, serin bir duygu. O zaman bile, hala test ediyorum ve testler yapıyorum.
Umutlu

1

Gerçekten endişeleniyorsanız, yazılımı piyasaya sürerken çevrimiçi bir takma ad kullanın. O zaman gerçek hayattaki itibarınızı etkilemesinin imkânı yok.

Ne zaman / kamu eleştirisi alırsanız, bu kodda iyileştirmelere yol açar ve geliştirici olarak büyümenize yardımcı olur. Bu iyi bir şey.

Projelerim için çoğu yapıcı eleştirinin / önerinin kamuya açık bir şekilde yayınlanmak yerine özel olarak gönderildiğini ve o zaman bile bir yorum selinin gelme ihtimalinin olmadığını görüyorum. Bu nedenle, sadece bunun için gitmek öneririz!

İyi şanslar.


1

Kendi kendine çalışma konusunda yanlış olan bir şey yoktur. İzole edilemez ve eş kod incelemeleri bu konuda yardımcı olabilir.

Ayrıca ne yaptığınıza odaklanmanız gerekir. İşiniz hakkında olumsuz geribildirim alsanız neden umursuyorsunuz? Bunun nedeni, eleştirilirseniz, kodun kötü olduğu veya programlamada herhangi bir iyi olmadığınız varsayımı yapıyor olmanızdır, bu doğru olabilir veya olmayabilir.

Çabaların amacı, kodun çalıştığından emin olmak ve mümkün olan en iyi kodu elde etmektir, ancak pratik deneyimlerden, ticari kodların tümü de yıldız değildir. Bazen kötü şartlar alırsın, bazen doğru yapmak için zamanın olmaz. Bazen geliştiriciler başkalarının kötü görünmesini sağlayarak bir dahi olarak karşılaşmak isterler.

Bazı hatalar yapmadan öğrenebileceğinize inanmıyorum, özellikle de gerçek disiplin ve çaba gerektiren bir şeyse. Kolay olsaydı herkes yapardı. Sadece en iyi uygulamaları kullanarak hataları küçük hatalarla sınırlamaya çalışın. Bunun her zaman mümkün olmadığını anladım!

Başkalarının benim hakkımda bir programcı olarak ne düşündüğü hakkında endişelenirsem, ilk başta sahaya girmezdim. Olduğu söyleniyor, benim ilk kod eleştirisi almak, nesnel olarak almaya çalışın ve ondan öğrenmek.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.