Dev ekipleri tüketici uygulamalarında performansı nasıl yavaşlatabilir?

Daha önce yavaş yazılımdan neyin sorumlu olduğunu sorduğumda , aldığım birkaç cevap sosyal ve yönetim sorunuydu:

Bu teknik bir problem değil, bir pazarlama ve yönetim problemidir. Bir çok şey ters gidebilir: Ürün yöneticisi teknik özelliklere düğme tepkisi koyamıyor ... Kalite kontrol uzmanları, tekerleğin tamamında uyuyorsa, QA çalışanları teknik özelliklere karşı test yapmak için vasat bir iş yapıyor. programcıların bunu telafi edemeyiz. - Bob Murphy

İnsanlar iyi uygulamalar üzerinde çalışıyor. Çalışırken, performans sorunları tıpkı böcekler gibi içeri giriyor. Aradaki fark - böcekler "kötü" - "beni bulup düzelt" diye haykırdılar. Performans sorunları sadece orada oturup daha da kötüye gidiyor. Programcılar sık ​​sık "Eh, kodumun performans sorunu olmaz. Bunun yerine, yönetimin bana daha yeni / daha büyük / daha hızlı bir makine alması gerekiyor." Gerçek şu ki, eğer geliştiriciler periyodik olarak sadece performans problemlerini araştırıyorsa ( ki bu gerçekten çok kolay ) basitçe temizleyebiliyorlardı. - Mike Dunlavey

Öyleyse, eğer bu bir sosyal sorunsa, bir kuruluş yavaş yazılımını müşterilerine göndermekten kaçınmak için hangi sosyal mekanizmaları devreye sokabilir?

Doğru yazılı ve eksiksiz gerekliliklerle, hatalar ve düşük performans arasında bir ayrım diye bir şey yoktur . Performansı işlevsel olmayan bir gereksinim olarak belirttiğiniz için, düşük performans diğer tüm hatalarda olduğu gibi bir hata haline gelir ve QA tarafından yakalanır ve yayınlanmadan önce geliştiriciler tarafından çözülür.

Sosyal bir sorun mu var? Sanmıyorum En önemli sorun, gereksinimlerin eksik olmasıdır. Freelance olarak yıllardır çalışarak, ben asla daha önce belirli bir görevi maksimum performans gereken bir işlevsel olmayan gereklilik söylüyorum gördü N ortalama saniyede. Eğer yönetici / müşteri / paydaş ya da herhangi bir kişi performans varlığına zahmet etmiyorsa, ben neden bir geliştirici olarak onunla ilgilenirim ki, onunla ilgilenmesi gereken insanlar hiç umursamıyor?

Düşük performansı etkileyen başka bir faktör daha var: geliştiricilerin iyi performans gösteren pahalı bilgisayarlarda çalışması . 8 GB RAM, son teknoloji ürünü SSD, en son işletim sistemi vb. İçeren dört çekirdekli bir bilgisayarda yıllarca çalışırken, uygulamanızın çift çekirdekli bir bilgisayarda Windows XP'de nasıl çalışacağını hayal etmek çok zor 512 Mo RAM ve eski bir sabit disk% 90 dolgulu ve yıllarca birleştirilmemiş. Ne yazık ki, bazı ülkelerde, son durum bir uygulamanın çoğu tüketicisi için gördüğümüz durumdur. Geliştirici PC'ler ve tüketici PC'ler arasındaki boşluk arttıkça, geliştiricinin uygulamasının performansına bakması o kadar karmaşık olur.

Sorun(?):

• Müşteri (veya son kullanıcı) bundan şikayet etmiyor (yeterince)
• Dolayısıyla proje (/ ürün) yöneticisi bir şart olarak görmüyor
• Böylece geliştirici düzeltmek için zaman almaz.

Baştan başlamak, müşterileri eğitmek zorundasınız. Ancak iPhone'u daha hızlı, daha az parlak bir telefon yerine satın alırlarsa, geliştiriciler zamanlarını performans yerine görünüşe harcamayı hak ediyorlar. Organizasyon sorun değil.

Tabii ki, bazı şeyler yine de yardımcı olabilir. Otomatikleştirilmiş testlerin beklenmesi can sıkıcıdır, bu nedenle otomatikleştirilmiş testleriniz varsa, geliştiricilerin performans sorunları hakkında sürekli geri bildirimleri vardır ve bunu çözme olasılıkları daha fazla olacaktır (teknik bir özellik olarak, özellik olarak değil).

Ama sen her şeyi yapamazsın. En iyi duruma getirme veya özellikler ekleme ve parayı harcayanların karar vermesi.

Ancak bazı iyi haberler: SaaS / Cloud / Buzzword uygulamalarının burada çok yardımcı olduğunu fark ettim. İnsanlar bir kaç benzer web uygulaması arasında seçim yaptıklarında ve 'gerekli' özelliklerin suni listelerini oluşturmak yerine canlı olarak test edebiliyorlarsa, duyarlılıktan daha hızlı etkileniyorlar ve bu nedenle performans daha fazla dikkat çekecek.

Ne yazık ki, en büyük sorunun her şeyi yapamayacağınız olduğunu biliyorum. Bir gemi randevunuz var ve bunun çok yavaş olduğunu biliyorsunuz, ancak piyasaya X, Y, Z özelliklerini eklemeniz gerekiyor.

Aklında, yavaş sonra düzeltebilirsiniz, ancak uygulama en azından çalışır.

Bu nedenle, işlevsellik ve estetikten endişe ediyorsunuz (çünkü kullanıcılar genellikle estetiğe odaklanır). Bir sonraki sürümde performansı düzelteceksiniz.

Ancak PM sadece size bir Özellikler listesi sunar ve performansı düzeltmek için zaman yoktur.

Ve kısır döngü devam ediyor.

Diğerleriyle aynı fikirdeyim, geliştiricilerin sorunla daha fazla ilgilenmelerini sağlamanın yollarını bulmamız gerektiği, onları daha yavaş donanımlar üzerinde test etme ve performans hedeflerine sahip olmaları gibi kabul ediyorum. Her şey yolunda, ama gerçekten, performans ayarlaması söz konusu olduğunda -

İnsanlar Nasıl Bilmeli - Ve Bilmiyorlar

Yaptıklarını düşünebilirler , ancak sadece StackOverFlow ve bu forumdaki performansla ilgili tüm soru ve cevapları gözden geçirin. Performanstan kaçının çok az sağduyu göstermesi acı verici.

Bu sadece konuşacak bir şey değil, insanların bunu yaparak öğrenmesi gerekiyor. Bu modda oldukları tek zaman, bir sınıfa girdikleri veya bir kitaptan veya blogdan yeni şeyler öğrendikleri zamandır.

Bu problemi çözmeyi düşünebilmemin tek yolu , programlamayı öğreten insanları yakalamak ve onlara nasıl yapılacağını öğretmektir .

Cennet biliyor, bu forumlarda denedim.

• Temel süper basit yöntem
• A 43x hızlanma - do o senin profilcisine ile
• Nedenleri, mide bulandırıcı ayrıntılı olarak

Herkes yapabilir. Sadece gerçekten yapmaları gerekiyor.

Performansı bir gereklilik haline getirin.

Performans kodunu yazmak zor. Diş açma, asenkron olay işleme, önbellekleme ve asimptotik karmaşıklık gibi kavramların sağlam bir şekilde anlaşılmasını gerektirir. Çalıştığım programcı grupları tarafından değerlendirildiğinde, verilen herhangi bir grubun yaklaşık% 20 - 40'ı, günlük çalışmalarına tabii ki performansla ilgili konuları dahil edecek kadar iyi anlamıyor.

Bununla birlikte, bu programcılar hala şirket için hala faydalıdır, ancak performans açısından kritik sayılmayan görevlere atanırlar, bu nedenle Netflix akışlarını herhangi bir kare düşürmeden kusursuzca oynatabilecek bir blu-ray oynatıcı ile sonlanır, ancak 30-60 saniye sürer Kuyruğunuzu gösteren menü öğesini açmak için

Çalışanlarınızın% 20'sini kovabilecek ve onları daha deneyimli (ve daha pahalı) geliştiricilerle değiştirebilecek bir sıcak yazılım şirketi değilseniz, düzeltmenin tek gerçek yolu geliştirici eğitimi ve dosyalama hata raporlarıdır. Nasıl diğer firmalarda olduğunu bilmiyorum, ancak burada geliştiriciler düzeltmek için zamanımıza veya iş önceliğimize sahip olmadığımız bir performans sorunu görüyorsak, bu konuda kendi hata raporumuzu verme hakkına sahibiz. Biriktirmenin, birikintinin tepesine kadar çalışması birkaç dakika sürebilir, ancak genellikle sonuçta ele alınmaktadır.

Performans bir gereklilik ise, test edin.

Aksi takdirde, Wally sonsuz bir döngü yazabilir ve erken bırakabilir "Biraz zaman alır." Hak iddia edebilir.

Yazılım kabul testiniz, çeşitli işlem performansı özellikleri için ayrıntılı bir kabul testine sahip olmalıdır.

Bunu yapmazsanız , ürün üzerinde hiçbir performans mühendisliği yapmazsınız.

Performans (kaynak tüketimi gibi) alt sistemlere bütçelenmelidir. Daha sonra alt sistem kabul testleri bunları kontrol edebilir.

Sonra erken ve sık sık performans için test edebilirsiniz. Hatta ünite testleri bile kontrol edebilir.

Dolayısıyla şimdi geliştiriciler bir kabul kriteri olarak kabul ediyorlar ve yaklaşımlarını buna uyacak şekilde organize edebiliyorlar.

Şu an çalıştığım yerde, performans stresi testi bildiğimiz herhangi bir müşteri veri setinden 2 kat daha büyük. Düzenli olarak ürünün yeni bir versiyonunu kırar. İyi test.

90'lı yılların ortalarında bir kez hatırlıyorum ve bir şeyi optimize etmek için biraz zaman harcadım ve bir iş arkadaşım bana "Bu pentiumlarda çalışıyor, kimin umurunda?" .... o bir göz açıcıydı. Ne yazık ki, buzdağının sadece görünen yüzüydü, kariyerim boyunca tutumu duydum - "pentium" kısmı zaman içinde değişmiş olsa da.

Ortalama bir geliştiricinin bakımını almanın tek yolu, müşteri tarafında bir hata olarak görülmesi için performans eksikliği elde etmektir. Uygulamaya ve izleyiciye bağlı olarak bu kolay veya zor bir iş olabilir (ikisini de gördüm). Seyirci düşük performansı önemsemiyorsa, geliştiriciler asla (hızlı, iyi, hızlı - iki tane seç).

Ancak, bir programcının, tuşa basma ile yanıt arasındaki 3 saniyelik bir gecikmenin kabul edilemez olduğunu fark etmesi, KG'den bir mektup almamalıdır.

Kabul etmemelisin. Bundan daha fazlası gerekir: Elde edilen gecikme, son kullanıcılar için önemlidir .

Bağlam sağlayamadığınız göz önüne alındığında, dev / QA ortamındaki gecikmenin yerel yavaş disk / bellek / ağ erişimi sorunlarından kaynaklandığı tamamen olası görünüyor. Eğer durum buysa, QA'nız ve cihazınız yalnızca son kullanıcılar için önemli olmayan şeyleri düzeltmek için harcadıkları çabayı harcayacak.

Performans testindeki geliştiricilere güvenmek, hızlandırmak için bir işlevsellik parçası seçmek için zar atmak kadar verimlidir. Bu kadar güvenilir ve "geliştiriciler genellikle bir uygulamadaki performans sorunlarının gerçekte nerede olacağı konusunda korkunç bir sezgiye sahipler " ( Brian Goetz ).

• Bir zamanlar topal yönetimin bir zamanlar parlak pazarlama uzmanlarının ve akıllı programcıların müşterilerin performans kaygılarını giderecek kadar iyi olduğuna karar verdikleri bir projeydim. Ne harika bir dersti. Reddedilen serbest bırakma, çabaların yarım yıl çöp kutusuna gitti ve şirket neredeyse stratejik bir ortak kaybetti. Sonunda, onlar davet uzmanları (benchmarking uzmanlar, istatistik, UX, düşük seviye optimizasyonu, böyle şeyler) ve profesyoneller karmaşa sabit.

Bütün programcılar kendi QA'larını yapmalı ve bu tür sorunları hemen görebilsinler mi?

Yapılabilir olduğu gerçeği, gitmenin yolu olduğu anlamına gelmez. Aksine - benim tecrübeme göre bu programcıların verimliliğini kaybetmenin en güvenilir yollarından biriydi . Neredeyse sonsuz toplantılar kadar iyi ve hatta adaylarla röportaj yapmaktan daha iyi.

• Eski bir test uzmanı olarak, bir zamanlar gelişim ve kalite güvencesi faaliyetlerini birleştirmenin bir sorun olmaması gerektiğini düşündüm. Rutin dev testi ile sistematik KG arasındaki fark çok da önemli değildi. Dev / QA ayrımının yalnızca yazılım endüstrisinde bir gelenek olduğunu düşündüm. Bunun böyle olmadığını zor yoldan öğrendim. Ayrılma, odaklanma ve üretkenlik ve oldukça ciddi bir sorun olarak ortaya çıktı.

Bir performans sorunu varsa, bana bir ölçüt verin ve hedef performansı ayarlayın, ben de onu vurmak için elimden geleni yapacağım. Performans testinde o kadar iyi değilim ama optimizasyon hakkında bir iki şey biliyorum .

Bence sorunun zamanın% 99'unda kapsamın sürünmesi olduğunu göreceksiniz. Örneğin dvr ile. Bunun kolay olduğunu düşünürsünüz, ancak daha sonra TIVO veya bir rakip iyi karşılanan yeni bir özellik sunar. Bildiğiniz bir sonraki şey, yeni bir özellik plaka üzerinde. Mevcut ürünle uyumlu olabilir veya olmayabilir ve uzun sürecek mevcut ürünü yeniden yapmıyoruz. Böylece özellik sıkışır ve performansı emer. Verilerin bilgi almak için orada olduğundan emin olun, ancak bu bilgiyi edinmeyi düşünmüyorsanız, o zaman elde etmek kolay olmayacaktır. Şimdi, program listesine her gittiğinizde bu bilgiyi oluşturmak için karmaşık bir süreç var.

Umurunda görünmeyen geliştiricileri görmezden gelmek ...

Kod üzerinde çalışan geliştiricilerin çoğu zaman performansı sürekli ölçecek araçlara sahip olmadığını düşünüyorum.

Örneğin, uygulamanızın yanıt süresini ölçmek mümkünse (örneğin, web tabanlı bir uygulama veya bir veritabanını sorgular, vb.) - Şu anda en kötü "en iyi 10" u gösteren bildirimler alıyorsunuz (e-posta, SMS, ne olursa olsun). (veya belirli bir eşiğin üstünde) cevapları mı veriyorsunuz?

Pek çok durumda, geliştiriciler bu bilgiyi "gerçek dünya" dağıtımlarından almazlar ve sonuç olarak görmediğiniz bilgileri göz ardı etmek çok kolaydır.

Ancak, her gün / birkaç saatte , "x" ekranının yüklenmesinin 13 saniye sürdüğünü belirten bir e-posta alırsanız ve aşağıdaki SQL sorgusunu çalıştırıyorsa, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...bir geliştiricinin baştan başa kalmaya devam edebileceğine (ve umarım ki) o.

Bütün programcılar inanmak istiyorum Böylece her ne kadar do almak performansını ciddi Ben sorun (s) için görünürlük eksikliğinin genellikle suçlu olduğunu düşünüyorum.

Not: Bunun, hem geliştiricilerin erişim talep etmesi (hatta böyle bir özelliği geliştirmesi) hem de yönetimin bu araçları sağlaması / finanse etmesi gerektiğini düşünüyorum.

Suçluları programcılara asabileceğimiz daha iyi örnekler bulabilir misin? Eclipse dışında ve bir yorumcu zaten bunu yapan eklentileri olduğuna dikkat çekti (her yeni Eclipse sürümünün ilk kurulumunda aydınlatma gibi çalışıyor, ancak diğer araçları eklediğimde yavaşlamaya başlıyor), örnekleriniz programcı olmayabilir ve kodla ilgili, ancak çevre ile ilgili.

Bilgisayarda bir programı ayrı ayrı çalıştırma ve 'hızlı' mı yoksa 'yavaş' mı olduğunu belirleme günleri geçti. Verdiğiniz diğer örnekler ortamlarına bağlıdır - mevcut ağ tıkanıklığı, arka uç sunucuların aşırı yüklenip yüklenmediği, kötü yapılandırılmış ağ kartları, hatalı bir kablo, bulunduğunuz yerde kullanan diğer kişilerin sayısı veya yüzlerce değişken. Örneğin. bizim barındırma sağlayıcımız sunucu gigabit bağlantıları için ekstra ücret aldı ancak sonunda hepsinin 10Mb portlu eski bir güvenlik duvarı cihazından geçtiğini belirledik. Bu problemler etrafında kayıyor ve bulunması zor.

Kabul edildi, programcıların yapabileceği pek çok şey var (bant genişliğini en aza indirgemek, yanıt vermeyi artıran ve hızlı olduğu izlenimini vermek için ilerleme gösteren UI hileleri). Ancak, gerçek dünyaya girdiğinizde, yalnızca deneyimle öğrendiğiniz her türlü koşul vardır (ve varsayımlarınızın önünüzde dağıldığını izlersiniz).

Daha iyi bir yazılım için ne kadar para ödemeye hazırsınız? Piyasa daha iyi bir yazılım için ne kadar bekleyecek? Bir sonraki sürümde ne kadar küçük bir hamle yapmak isteyeceksiniz?

Burada pek çok uzlaşmanın yapıldığı bir boğaz pazarı var. Eğer gerçekten berbatsa, pazar ürünü bozar (veya gerekir). Belki de statükoyla yaşayabilecek kadar müşteri var?

Bence bu soruna en genel cevap aynı zamanda yönetilmesi de en zor olanı; bu nedenle her programcının yaptığı her şeyde performans konusunda dikkatli olması gerekiyor. Bunun bir polis olduğunu da anlıyorum.

Projenin büyüklüğüne ve ilgili ekibe bağlı olarak, özel performans programcılarına sahip olmanın çok değerli olabileceğine inanıyorum.

Örnek olarak, proje ekibinin (yaklaşık 30 dev dahil) performans optimizasyonuna atanmış en az 2 kişisinin olduğu bir ekip üzerinde çalıştım. Bu özel uygulama, sadece web servisleri üzerinden değil, aynı zamanda çeşitli veri haritalama ve adaptör bileşenlerine sahip eski katmanlar açısından da birlikte çalışabilirlik bileşenlerinin çokluğu olduğu için performans sorunlarına da oldukça yatkındı.

İlk elden deneyim önemlidir. Geliştiricilere derleme ve geliştirme için hızlı bir bilgisayar verin, ancak uygulamalarını çalıştırmak için gerçekten yavaş aşırı yüklenmiş bir bilgisayar (bazı kullanıcıların yüzdesi olabilir). (Bu, VM'leri veya sunucuları işlevine göre bölümlere ayırarak bulut / sunucu tabanlı geliştirme ortamlarında yapılabilir.) Onlara, yarısı bitmiş bir bataryaya sahip bir cep telefonu verin ve yalnızca ilk mobil uygulama testi için kullanmalarını isteyin.

Geliştiriciler, performans ve batarya ömrü ile ilgili olarak müşteriyle empati kurarlarsa, performansı öncelikli listenin en altına konacak yarı-sahte bir yönetim özelliği olarak görmezler. (Olduğu gibi: "hey, erken optimizasyon olduğunu düşündüm" çok geç saatlere kadar.

Eşyaları satın almayı bırakın ve karşılaştığınız çevrimiçi incelemelerde düşük performans hakkında yorum yapın.

Aygıtlar hala satılıyorsa, yazılım daha fazla zaman ve para harcamamak için "yeterince iyi" demektir. Performansla ilgili kötü yorumlar satışları önemli ölçüde azaltırsa, yazılım "yeterince iyi değil" ve düzeltilmesi gerekiyor.

Bir tüketim malı üreticisini ilgilendiren tek ölçüt, satışlar ve birim başına kazançtır.

Programcılara performansı en üst düzeye çıkarma, vb. Konusunda daha iyi öğretilmesi gerektiğine katılıyorum.

Ancak çözümün programcılara günlük kullanım için neredeyse ölmekte olan bir donanım sağlamadığını düşünüyorum. Görsel stüdyonuz günde iki kez çöktüğünde ne kadar stresli olacağı, malzeme oluşturmak için x saniye, çözümü açmak için y saniye, pencereleri değiştirmek için z saniye sürdü. Donanımın ucuz olması ve programcıların zamanının pahalı olması nedeniyle şirket için maliyet açısından verimli olduğunu sanmıyorum.

Kodu ele alacak bir sonraki el QA (test) ekibi olduğundan, onlara performansın önemi hakkında bilgi vermek, kurumsal standart olarak kabul edilebilir performans standardı, vb. Standartlarına sahip olmaktan daha iyi olmaz mıydı? , performans standardı spec olmalıdır ama bu çok sık olmaz)? (örn. düzenli ee değiştiren sayfa / sekme anında gerçekleşmeli, o zaman kritik bir uygulama ise "güncellemeyi x saniye içinde yapmalı" ...). KG ekiplerinin çalıştığı bilgisayar, tipik kullanıcı bilgisayarı olmalıdır. (386 vererek onları kızdırmak istemeyiz, ama örneğin 8GB koç ile dört çekirdekli vermeyin). Performansa yeterince sinirlenirlerse programcılara havalandırma yapmazlar mı?

Bence müşteri / proje müdürü, programcı / qa ekibi / geliştiricisi / şirket ekibinin temsilcisi olarak, sahip oldukları en düşük seviye donanım hakkında sunum yapmaya zorlamalıdır. (örneğin şirketteki en zayıf bilgisayar). Yeniden yazıyorlarsa, eski yazılımda x işlem yapmanın ne kadar hızlı olduğu hakkında veri toplamaları ve yeni yazılımda ne kadar hızlı olduğu ile karşılaştırmaları gerekir (yeni yazılım ek iş süreci gerektirebileceğinden daha yavaş olabilir, ancak kabul edilebilir bir pencere olmalıdır).

Daha önce de söyledim ama tekrar söyleyeceğim: Bunun üstesinden gelmenin en iyi yollarından birinin, geliştiricilerinizin (göreceli olarak) son teknoloji donanım üzerinde çalışmasını sağlamak olduğunu düşünüyorum.

Tipik programcınız için, çoğu resmi performans düşüncesi basitçe şöyledir: "Çalıştırmaya çalıştığımda sinir bozucu mu?" Can sıkıcı buluyorlarsa, düzelteceklerdir (en azından denemeye çalışacaklar). Çalışma şeklinden memnunlarsa, elde edeceğiniz en iyi şey sabitleme için yarı yürekli bir girişimdir. Bu aynı zamanda, sorunları gidermeleri çok daha pahalı hale gelmeden önce sorunları erken bulmada yardımcı olur.

QA'nın kuralları uygulamak zorunda kaldığı noktaya gelirse, geliştiricilerin gerçekten performansın yeterli olduğunu düşündükleri için inanmadıkları için, aldığınız "düzeltmelerin" çoğunun kuralları aşmanın yaratıcı yollarını alacağı ihtimalleri oldukça iyidir. son kullanıcı için hayatı iyileştiren gerçek düzeltmeler değildir.

Aynı zamanda, bunu nadiren bir sorun olarak gördüğümü de eklemeliyim. Eğer bir şey varsa, geliştiricilerin çok fazla zaman harcadıklarını ve onları gerçekten suçlu olduğum bir günahla uğraşacak kadar zorlamadığım performansları iyileştirmeye çalıştıklarını gördüm.