Birisi size yazılım geliştirme uygulamaları hakkında doğrulanmamış bir beyanda bulunursa, “atıf gerekli” ile yanıt verir misiniz? [kapalı]

Geçenlerde Greg Wilson (Yazılım Marangozluğu Baş Bilimcisi) tarafından verilen bir konferansa katıldım . Özetden:

Yazılım geliştirme uygulamalarıyla ilgili iddiaların kanıtlara dayandırılması gerektiği fikri, yazılım geliştiricileri için hala yabancıdır, ancak bu nihayet değişmeye başlamaktadır: belirli bir aracın veya uygulamanın yazılım geliştirmeyi daha hızlı, daha ucuz veya daha güvenilir hale getirdiğini iddia eden herhangi bir akademisyen şimdi bu iddiayı bir çeşit ampirik çalışma ile desteklemesi bekleniyor.

Genel olarak, ders çok bilgilendiriciydi ve beni kalkınma yaklaşımım hakkında çok derin düşünmeye bıraktı. Özellikle, şimdi kendimi birçok ifadeyi yedeklemek için atıflar ararken buluyorum. Daha önce, sunulan gerçekleri tekrarlama alışkanlığına girmiştim, belki daha sonra kontrol etmek için zihinsel bir notla.

Açıkça söylemek gerekirse, saf oluyordum .

İşte derste alınan bir örnek:

"Kodun% 25'inden fazlasının yeniden düzenlenmesi gerekiyorsa, yeniden yazmak daha hızlıdır".

Kulağa mantıklı geliyor, ama doğru mu? Bunu destekleyen çalışma nerede? Tüm diller için geçerli mi? Ve bunun gibi.

Tamam, bunu aşırı derecede almak ve kendiniz ilk prensiplerden türetmedikçe kimsenin bir şeye inanmaması oldukça mümkündür. Bu şekilde delilik ya da matematik ;-) yatıyor. Ancak, eğer birisi size "Hey, [anın dilini seç] şeklinde yaparak, [% 10'un katını seçin]% 'a kadar üretkenliği artırabileceğiz. kabul et, yoksa kanıtlanmış kanıt isteyecek misin?

İkincisi ise (ve umarım öyle ise)

1. bu kanıtı nerede bulabilirsin?
2. ne kadar katı olursun?

Kısacası, birisi size doğrulanmamış bir beyanda bulunursa, "atıf gerekli" ile yanıt verir misiniz?

Bu tür ifadelerle ilgili sorun, iddiayı destekleyen ampirik kanıtlara sahip olsanız bile, mevcut durumunuza uygulanan kanıtlara yol açan çalışmanın belirlenip belirlenmemesinin çok zor olacağıdır.

Meslekteki hemen hemen her şeyin bir uyarısı var ya da bir yerde her iyileştirme başka bir yerde bir kötülük olma olasılığına sahip.

Siperlerde yaşayan insanlar farkı tecrübe yoluyla biliyorlar ve genellikle bilimsel bir çalışma ile kanıtlamaya çalışacak finansmana / zamana / kaynağa sahip değiller.

Bilimsel bir çalışma ile kanıtlamaya çalışan insanlar açıkça bu tür çalışmalara adanmış kaynaklara sahiptir ve bu nedenle size bir şey satma olasılığı yüksektir, bu yüzden iddia ettiğiniz herhangi bir şeye kendi kişisel deneyiminizi daha sıkı bir şekilde uygulamanız gerektiğini söyleyebilirim. ampirik araştırmalarla desteklenmelidir.

Birisi size "Kodun% 2'sinden fazlasının yeniden düzenlenmesi gerekiyorsa, yeniden yazmak daha hızlıdır" demişse, birisi size söylediği kadar yanlış olduğunu bilirsiniz "Yalnızca kodun% 98'inden fazlası yeniden düzenleme gerektiriyorsa, yeniden yazmak için daha hızlı ". Gerçek sayı nerede yaptığınıza ve geçerli kodun idealinden ne kadar uzak olduğuna bağlıdır.

Belli bir noktadan sonra nükleer bir refactor yapmanın daha kolay olduğu fikri birçok durumda açık bir şekilde doğrudur, ancak gerçek yüzde, (ekibinizin) kendi deneyiminizin ve mevcut durumunuzun merceğiyle dikkate almanız gereken bir örnektir.

Birisi size yazılım geliştirme uygulamaları hakkında doğrulanmamış bir beyanda bulunursa, “atıf gerekli” ile yanıt verir misiniz?

Hayır, buraya gönderiyorum ve herhangi bir upvotes alıp almadığını görüyorum. Toplumsal kanıt, kanıt olmamasından iyidir!

Birçok geliştirici, anı kararlarını kodla çalışan siperlerde ve bu kodun hizmet verdiği müşterilerdeki deneyimlere dayandırmaktadır.

Bir sınıf veya yöntem hata düzeltmeleri ve müşteri değişikliği talepleri tarafından sürdürülemez hale geldiğinde çok parçalandığında, bir geliştirici bazen uzun süre boyunca zamandan ve çabadan tasarruf edeceği teorisine göre yeniden düzenleyici yerine yeniden yazma kararı alır. , çünkü ortaya çıkan kod daha yüksek kalitede olacaktır.

Bu tür bir deneyim zekası İK departmanlarının “insan sermayesi” dediği şeydir. Deneyimli geliştiricileri değerli kılan şeylerden biri ve iyi şirketlerin çalışanlarının uzun ömürlülüğünü korumak için bir şeyler yapmasının nedenlerinden biridir.

Deneyimli geliştiricilerin tekniklerinin geçerli olduğunun kanıtı olarak bir çalışma ve ampirik veriler bulmalarını istemek adil ve hatta pratik görünmüyor. Deneyim bu şekilde çalışmaz. Aksine, deneyim "hissedilen" bir şeydir. Yeniden düzenleme dünyasında, buna genellikle "koku" diyoruz.

Nihayetinde, "Kodun% 25'inden fazlası yeniden düzenleme gerektiriyorsa, yeniden yazmak daha hızlıdır" gibi bir ifadenin her koşulda çalıştığı kanıtlanamaz, bu nedenle [alıntı gerekli] ifadesinin, dogmatik programcıya başkaları hakkındaki görüşlerini her zaman "Yolu veya Yolu" olmadığı konusunda zorlamaya çalışır.

Denemeden asla bilmediğin bir şeyle düşünüyorum. Bir ifadeyi destekleyecek kanıtla bile, gerçekleri sizin açınızdan yararınıza tutmak her zaman mümkündür. İnterweb'lere çarpan her yeni şeyi denememeniz gerektiği söyleniyor. En iyi kararınızı verin. Unutmayın, eğer bir şey gerçek olamayacak kadar iyi ise, muhtemelen doğrudur. Her zaman kendinize neden bir şey benimsemeniz gerektiğini sorun. Ne kazanmalısın? Bir iş potansiyelinden mantıklı mı? İnanç üzerine bir şey dışında asla kör olmadım.

Derste örnek bir sezgisel tarama, genel bir kural ve daha fazlası değil. Bu açık bir şekilde açık olmalıdır.

Sezgisel tarama başka bir şey gibidir: belirli bir bağlama tabidir ve herhangi bir sayıda ifade edilmemiş varsayımlara bağımlıdır ve yararlılıkları çok belirleyici olmayabilir. Ne kadar keyfi bir karar, onları en başta onları formüle ederken de faydalı bulmaya gidiyor.

Bu onların değersiz oldukları anlamına mı geliyor? Ben öyle demezdim.

Sezgisel tarama, NP-tam problemlerini ele almak için alabileceğimiz yaklaşımlardan biridir ve birçok bakımdan yazılım mühendisliğinin kendisi de NP-tam bir problemdir.

Değişir. :) Birinin ifadesi tekrarlanan, yansıtılan ve kişisel olarak doğrulanmış deneyimlerle çeliştiğinde, evet, bir çalışmanın bir tür referansını görmek istiyorum. Öte yandan, eğer birisi defalarca gördüğünüz ve yaşadığınız bir fikri yansıtırsa, kışkırtılan çok fazla tepki yoktur (bu fikrin yanılmaz olduğu anlamına gelmez).

Örnek olarak, "Kod Tamamlandı" kitabı, bazen görünüşte küçük konulardan (girinti ve boşluk veya değişken ad uzunluğu gibi) ilgili noktaları belirtmek için her bölümde yapılan çalışmalardan bahseder. Bu ayrıntı ve kanıt düzeyinin saçma olduğunu düşünmek için kitabı tanıttığım bazı (genç) geliştiricileri hatırlıyorum. Ancak birkaç ay sonra daha fazla üretim kodlama deneyimi ve birkaç kod incelemesinden sonra, aynı geliştiricilerin bazıları, evet, girinti alanlarının bile önemli olduğunu kabul etme dürüstlüğüne sahipti. İyi yorumlar önemlidir. Kapsülleme önemlidir. vs vs.

Öte yandan, bir satıcı yeni IDE'nin% 50 daha verimli olduğunu iddia ettiğinde, ilk tepkim boğa $% ^ &!

Bu çok fazla maddi olmayan değişkene (bilimsel olarak ölçülmenin bir yolu olmayan değişkenler) bağlı bir şey değil mi?

Bence, duyguları ölçmek için ampirik bir yöntemden bahsediyorlar. Spock'ın bile başaramadığı bir şey. =)