Bir geliştiriciye daha yavaş bir geliştirme makinesi vermek, daha hızlı / daha verimli kod sağlar mı? [kapalı]

Sanırım geliştiricilerime çığlık atan hızlı bir makine verdim. WPF tabanlı VS2010 çok hızlı yüklenir. Geliştirici daha sonra, kutusunda iyi çalışan, ancak gerçek dünyada çok daha yavaş çalışan bir WPF veya WPF / e uygulaması oluşturur.

Bu sorunun iki bölümü var ...

1) Bir geliştiriciye daha yavaş bir makine verirsem, bu sonuçta ortaya çıkan kodun daha hızlı veya daha verimli olabileceği anlamına mı geliyor?

2) 'Tipik' çalışma zamanı deneyimleri verirken geliştiricilerime hızlı bir IDE deneyimi sunmak için ne yapabilirim?

Güncelleme:

Kayıt için yönetime verdiğim yanıtı bile hazırlıyorum. Bu benim fikrim değil ve siz müşterilerimin yanlış yönlendirilen isteklerini düzeltmeme yardımcı oluyorsunuz. Bana daha fazla cephane verdiğin için teşekkür ederim ve buna ne zaman ve nerede yaklaşacağına dair referanslar verdim. Geçerli kullanım durumlarını + 1'ledim:
- belirli sunucu tarafı programlama optimizasyonları
- test laboratuarları
- büyük olasılıkla hat grafik kartlarının yerine daha iyi bir sunucu satın alıyor

Kesinlikle

Ayrıca yöneticilerin tüm toplantıları Pig-Latin dilinde yapması gerektiği de doğru. Genel olarak basit beceriler söylerken dezavantajlı olmalarını sağlamak için iletişim becerilerini geliştirir. Dikkatlerini çekmek için yüz ifadelerine ve beden diline daha fazla güvenmek zorunda kalacaklar ve hepimiz bunun tüm iletişimin en az% 70'i olduğunu biliyoruz.

CFO'lar sadece bir abaküs ve tebeşir kullanmalıdır. Aksi halde 'ham verilere' çok fazla güveniyorlar ve 'içgüdülerini' yetmiyor.

Ve Başkan Yardımcıları ve daha yükseklerinin, tüm sarhoş iş toplantılarını golf sahaları gibi rahatsız edici ortamlarda yarı sarhoş halde tutmaları gerekmektedir. Ah çıtır ...

Cevap (Ben cesur olmak ve söylerim) 'dir , her zaman

NO .

Bütçenizle elde edebileceğiniz en iyi şekilde geliştirin ve kullanacağınız minimum - maksimum spesifik cihaz yelpazesini test edin.

Öykünücüler, sanal makineler, test edicinin gerçek olup olmadığını ve bunun bir faktör olup olmadığını görmek için test edebilecek gerçek makineleri var.

1) Çok, çok düşük bir ihtimal. Hayır, ve geliştiricileriniz kahvenize önerdiğiniz için pis bir şey koyabilirler. Zaman senin geliştiriciler derlemeye kodu için veya IDE onlar konum zamanı ne olursa olsun yapıyor veya ne gerekiyorsa yapmaya bekleyen harcadıkları değil kod daha iyi hale harcama. Onların zihinsel akışını da bozar. Akıllarını sorundan uzak tut, bu sorunu çözmede çok daha verimli olacaklar.

2) Her birine, asıl desteklemelerini istediğiniz en düşük özellikleri temsil eden ikinci bir PC verin, bununla gerçek iş istasyonu arasında bir KVM düğmesi kullanın.

Derleme zamanlarını çok severim. Özgeçmişim üzerinde çalışmak için bana daha fazla zaman veriyor.

Bu korkunç bir fikir. Geliştiricilerinizin mümkün olduğu kadar üretken olmalarını istiyorsunuz, bu onlara mümkün olduğunca hızlı bir makine vermek anlamına gelir, bu nedenle bütün gün etrafta oturup derlenmeden önce bir şeyler derlemek için oturmazlar. (Biraz OT, ancak WebSense ve benzeri ile potansiyel olarak yararlı sitelere erişimlerinin engellenmemesine de yardımcı olur.) Hala Stone-Age teknolojisini kullanan kullanıcılara sahip olmaktan kısıtlıysanız, bir test makineniz olması gerekir. Benzer özelliklere sahipseniz ve teknoloji seçimlerinde yanlış yolda gitmediğinizden emin olmak için erken ve sıklıkla test ettiğinizden emin olun.

Geliştirme mümkün olan en iyi ortamda yapılmalıdır. Test mümkün olan en kötü ortamda yapılmalıdır.

Yavaş bir makine verildi, günümü geliştirme sürecini optimize etmek ve teslim edilen kodumu optimize etmek için harcamazdım. Yani: HAYIR!

Gömülü sistemler programcıları her zaman bu işe karışıyor! Ve iki parçalı bir çözüm var:

1. Gereksinimleriniz, Y donanımında X performansını belirtmeniz gerekir.
2. Y donanımını test edin ve X performansı alamadığınızda, dosya hataları.

O zaman geliştiricilerinizin hangi donanımda çalıştığı önemli değildir.

Bunu yaptıktan sonra, daha hızlı ekipmanların programcılarınızı günde yarım saat veya yılda 125 saat kurtarabileceğini varsayalım. Ve diyelim ki, faydaları ve ek yükü (Silikon Vadisi için gülünç derecede düşük) ile yılda 100.000 dolar, saatte 50 dolar. Bu 125 saat * 50 dolar / saat 6250 dolar. Yani, programcı başına geliştirme donanımını geliştirmek için yılda 6250 dolardan daha az bir şey harcıyorsanız, paradan tasarruf edersiniz.

Yönetimine bunu söylemelisin.

Tim Williscroft, hemen hemen bir yorumda bunun yarısını söyledi ve adil bir dünyada, bu cevabın aldığı puanların yarısını alacağını söyledi.

24 Ekim Eklendi:

Eski işverenim bu teoriye sahipti ve 100 milyon dolar kazanmalarına yardımcı oldu.

Japonya, Kore ve Çin'deki programcıları işe almak için kullanılan, Japon merkezli bir şirkettir. Millet orada, berbat geliştirme donanımlarını kullanmak, 13 saatlik çalışma günleri, masalarında uyumak ve yaşamı olmamak harika. Böylece, Linux tabanlı bir cep telefonu işletim sistemi yapmak için bir Silikon Vadisi şirketi edindiklerinde, modern teçhizat isteyen aptal Kaliforniyalılar sadece sızlanmış ve aslında bunun için iyi bir nedene sahip olmadıklarını anladılar.

Dört yıl sonra, işletim sistemi bok gibi çalıştı, tüm programlar şişirildi ve müşteriler sinirlendi ve sözleşmeleri sağa ve sola sonlandırdı. Son olarak, İS projesi iptal edildi ve son bir yıl içinde, dünyadaki işgücünün büyük bir kısmı işten çıkarıldı. Açıkçası, tüm bu para ve çabanın nereye gittiğini hissedarlara açıklamak zorunda olan yöneticilerden biri olmak istemem.

Bu fiyaskoya neden olan yavaş gelişen makineler değildi. Bir çok stratejik ve taktiksel hata daha vardı - ama onlar siperlerde çalışan insanların tren kazasının geldiğini görebildiği ve karar vericilerin neden yapamayacağını merak ettikleri aynı şeydi.

Ve yavaş vites kesinlikle bir faktördü. Sonuçta, zamanında teslim etmek için silahın altındaysanız, işi kasten yavaşlatmak gerçekten akıllıca mı?

Programlamada, “ erken optimizasyonun tüm kötülüklerin kökü olduğunu” söyleyen eski bir söz vardır . Bence tüm kötülüklerden başka bir "kök" (veya en azından ilk dal) yaratmayı başardın. Şu andan itibaren, "erken geliştirici deoptimizasyon tüm kötülüklerin kökenidir" diyebiliriz.

Kısacası, bunun cevabı, bunun yalnızca geliştirme zamanınızı yavaşlatacağı ve daha fazla bakım yapmasını sağlayacağıdır. Derleme süreleri daha uzun sürecek, diskte kod aramak daha yavaş olacak, çevrimiçi yanıtları bulmak daha uzun sürecek ve en önemlisi, geliştiriciler gerekli işlevleri sınamak için kodlarını erken optimize etmek için kullanmaya başlayacak.

Bu son nokta en kritik konudur ve diğer cevapların çoğunda ortaya çıkmamıştır. İlk sürümünüzü tamamlayabilirsiniz, ancak daha sonra kodu ileride güncellemek istediğinizde, geliştiricilerin erken optimizasyonunun kodunuzun odağını iyi tasarımdan uzaklaştırdığını ve "bunu daha iyi hale getirmesi" için daha fazla ittiğini görürsünüz. en azından işimi korumak için çalışıyorum "kod tarzı. Ek özellikler eklemek daha zor hale gelecektir, çünkü o sırada seçilen optimizasyonlar gereksiz olabilir ve kodunuzu diğer yarı optimize edilmiş kesmelerin üstündeki yarı optimize edilmiş kesmeler yoluna kilitleyebilir.

Buna bir örnek olarak, mevcut sürümünüzün minimum sistem gereksiniminin biraz yavaş hızlı tek işlemcili bir makine olduğunu hayal edin. Geliştiricileri bu kutuya yerleştirirsiniz ve çok sayıda kanala dayanan karmaşık bir tek dişli çözüm ürettiler, çünkü ürünü hızlı bir şekilde geliştirmek istediler. Şimdi 5 yıl sonra, minimum çift işlemcili bir makine gereksinimi olan ürünün yeni bir sürümüne sahipsiniz. Paralel olarak çalıştırabileceğiniz programın bölümlerini temiz bir şekilde ayırabilmek istersiniz, ancak 5 yıl önce vermiş olduğunuz kararı, geliştiricilerinizi zorlu bir yazılım yapmaya zorlayan karar şimdi yeni minimum gereksiniminizin tam gücünden yararlanmanızı önlüyor .

Yapmanız gereken şey, geliştirme sürecinizin sonuna, alt sınır kutuları üzerinde kabul testi yaptığınız bir aşama eklemek. Şüphesiz, kodun bir kısmı geliştiricinin daha hızlı makinesi nedeniyle çok yavaş olacaktır, ancak o bölümü izole edip orada optimize edebilirsiniz. Kodunuzun geri kalanı temiz ve bakımlı kalır.

Sorunuzu "Geliştiricilerimi zayıf geliştirici makineleri vererek henüz daha iyi kodlar almaya başlayarak erken optimizasyona zorlayabilir miyim?" Olarak görüyorum. Ve cevap hayır.

İlginç okuma, tüm bu cevaplar.

Ama bence buraya cevap veren çoğu insan bu noktayı kaçırıyor. Benim okuduğum soru, (en azından sadece) gerçekten geliştiricilere daha hızlı kod yapmak için P1 verme ile ilgili değil.

Mesele şu ki, birçok yazılım bugün çok daha güçlü bilgisayarlara rağmen son bin yılda kullandığımız yazılımdan daha yavaş ya da daha yavaş. Buradaki cevaplara bakıldığında çoğu geliştirici bu ipucunu alamıyor. Bu web uygulamalarında çok açık. Bu site çok iyi bir istisnadır, ancak birçok site 1 mb'de bir ön sayfaya sahiptir. Bunun indirilmesini beklerken ne alacağım? Bilmiyorum. Sanırım, geliştirici tarafından kullanıcının harcaması gereken zamana saygı göstermeme konusundaki bir cehalet, ya da mb başına ödeme yaparsanız bunun için daha da kötü bir ödeme olduğunu düşünüyorum. Mesele şu ki, tüm bu web sayfaları yüksek çözünürlüklü resimler bile içermiyor. Genellikle, sadece bazı geliştirme ortamlarından gelen bazı kod kodlarıdır. Tabii ki, lanet kod değil sanırım, ama kullanıcı olarak bana kazanç sağlamaz.

Genel olarak sadece kodu optimize etmekle ilgili değil, aynı zamanda verdiğinden daha yavaşlayan şeyleri içermemeyi seçmekten de ibarettir.

Birkaç hafta önce 1995’ten bir dizüstü bilgisayara başladım. Windows 3.x hemen çalışıyordu. Veritabanının, enter tuşu tamamen serbest bırakılmadan önce başlatılmasından bir veri almam gerekiyor (en azından neredeyse).

Bugün yazılımımızdan çok daha fazlasını aldığımızı biliyorum, ama aynı zamanda bilgisayarlarımız da çok daha hızlı. Neden geliştirme endüstrisi, 1995’teki yazılımların hızını korumaya ve yeni işlevsellik istedikleri için yeni donanımlar satın almaya karar vermiyor. Bugün, günlük programlar ve web siteleri, insanları daha önce olduğu gibi aynı şeyleri yapmak için yeni donanım almaya zorlamaktadır. Ama elbette meraklı bir şekilde.

Linux gelişiminin bunu daha iyi halledebileceğini düşünüyorum. Linux dağıtımları, uzun yıllar boyunca, animasyonlu pencereler gibi pek çok göz şekerleme şeyleri olan düşkünlükteki pencerelerde oldukça ileride olmuştur. Mesele şu ki, bugün ve hatta dünkü bilgisayarlarında çalışmış olmasına rağmen. Sadece en yeni donanımlarda değil.

Şimdiye kadar birçok geliştiricinin sağlıksız bir adrenalin seviyesi olduğunu tahmin ediyorum. Evet,
önümdeki tüm beklemelerden biraz hayal kırıklığı bırakmanın bir yolunu buldum: office sql server (başlangıç ​​yönetim konsolu) arcgis (başlangıç ​​ve kullanma) acrobat reader (başlangıç) agresso (en azından web uygulaması olarak kullanıyor) windows (bakıp kullanıyorum, henüz 7 denemedim) .net web sayfaları (indirme)

ve bunun gibi

İyi hissediyorum :-)

Şerefe
Nicklas

1) Bir geliştiriciye daha yavaş bir makine verirsem, bu sonuçta ortaya çıkan kodun daha hızlı veya daha verimli olabileceği anlamına mı geliyor?

Son 6 yıldır yazılım geliştiriyoruz ve hala böyle sorular mı alıyoruz? Köşeleri kesmek için başka bir girişim daha görünüyor. Alınma ama, hadi, sorunun mantıklı olduğunu düşünüyor musunuz? Bunu bu terimlerle düşünün (eğer yapabilirseniz): zor şartlar altında, yağmurda, çamurda, her neyse çalışabilen 4x4 bir araç inşa etmek istiyorsunuz. Sadece ortaya çıkan aracın üzerinde çalışabilmesi için mühendislerinizi ve montaj hattınızı elemanların altına koyacak mısınız?

Demek istediğim, İsa Mesih! Gelişme var ve test var. Test, farklı ve daha sert bir ortamda yapılır veya geliştirici, stres testine uygun bir şekilde kendi test ortamında nasıl bir test yatağı monte edileceğini bilir. Yapamazsa, daha iyi bir geliştiriciyle değiştirin.

2) 'Tipik' çalışma zamanı deneyimleri verirken geliştiricilerime hızlı bir IDE deneyimi sunmak için ne yapabilirim?

Bunu geliştiricilerinize sormalısınız. Ve size nesnel ve geçerli bir cevap veremezlerse, onları gerçek geliştiricilerle değiştirmeniz gerekir.

Ancak soruyu eğlendirmek için, geliştiricilerinize (iyi geliştiricileriniz olduğunu varsayarak), iyi araçlara ve iyi donanıma, karşılayabileceğiniz en iyisini verin. Ardından, yazılımınızın çalışması gereken en düşük ortak bir başlangıç ​​ortamı oluşturun. Budur test meydana gelebileceği bu. Geliştirme ortamından farklı bir test ortamına sahip olmak daha iyi bir mühendislik uygulamasıdır (tercihen, testi strese sokmanıza izin veren).

Eğer geliştiricileriniz herhangi bir iyiyse, bunu size iletmiş olmalılar (onlara sorduğunuzu varsayarak).

Bir avuç kaltak geliştiricisiyle sonuçlanıyor. Bu şey yeterince zor, hadi deneyimi daha da kötüleştirmeyelim.

Ancak herhangi bir performans sorununu gidermek için bir Test veya KG ortamındaki kullanıcılarınızla benzer donanıma sahip olmanızı rica ediyorum. Bu iyi bir fikir.

Ben norm alayım ve eğer evet eğer onlar sunucu yazılımı yazıyorlarsa SADECE Söyleyeceğim. İstediğin kadar gül, ama gördüğüm en verimli ekip Wyse terminalleri olan bir grup Perl'di. Bu 1990'ların sonlarıydı, bir Üniversite'nin atölye dışı olduğu bir dükkandı ve mekansal gridleme yazılımı yazıyorlardı (temelde sadece hesaplardı). Bununla birlikte, bazı nispeten güçlü geç model RS / 6000'lerle konuşuyorlardı.

Sadece etkinliğe ilgi çekmek için orada kör bir programcı vardı. İyice etkilendim.

Bu kötü bir fikir değil - ancak geliştiricilerinizin hızlı bir programlama ortamına sahip olmasını istiyorsunuz.

Bunu, programlayıcılarınıza iki makine - hızlı bir kutu ve test için daha yavaş bir eşya kutusu (muhtemelen sanal) vererek, muhtemelen uygulayabilirsiniz.

VS derleme işleminde yapılan bazı değişiklikler, uzaktan hata ayıklama ile test kutusuna norm gönderebilir.

Kodlayıcılarınızı daha verimli kod geliştirmeye zorlamayı düşünmenin başka yolları da var; örneğin, birim testlerinize performans ve bellek kullanım hedeflerini dahil edebilirsiniz. Bellek kullanımı için bütçe belirlemek de mükemmel bir amaçtır. Ayrıca html kodu için sayfa ağırlığı bütçelerini ayarlama.

Sorun, geliştiricinin hızlı bir makineye verimsiz kod oluşturması değil, sorun, ölçülmesi gereken performans ölçümlerini tanımlamamış olmanızdır.

Ürün gereksinimlerinin bir parçası olarak, gerekli müşteri deneyimine dayanarak tüm bilgisayarlarda ölçülebilen belirli bir hedef tanımlanmalıdır. Bilgisayarınızı diğer bilgisayar türleriyle ilişkilendirmenize izin veren birçok web sitesi (SpecInt Kontrolü) vardır.

Bu, birçok nedenden dolayı iyidir. Minimum desteklenen donanımı daha kolay tanımlamanıza olanak tanır; böylece müşteri şikayetlerinin sayısını sınırlayabilirsiniz - çoğu yazılımın çoğu bilgisayarda çalıştığını biliyoruz, bu sadece bir performans meselesidir - şartnamemizi insanlar minimum gereksinim aralığına göre ayarlarsak makul derecede kabul edilebilir bir performansa sahipseniz, müşteri şikayetlerini sınırlandırırsınız - ve bir müşteri aradığında, gerçekten bir sorun olup olmadığını veya müşterinin ürünün nasıl çalışması gerektiğinden memnun olmadığını belirlemek için kriterleri kullanabilirsiniz.

Geliştirme için daha yavaş bir bilgisayara sahip olmanın daha hızlı kodla sonuçlandığına inanıyorum, ancak bu bir bedeli var. Bunun nedeni, ilk elden tecrübe ettiğim: uzun zaman geçtikten sonra, trende çalışmak için bir netbook, son 5 yılda aldığım herhangi bir bilgisayardan daha yavaş olan netbook aldım. Her şey çok yavaş olduğu için, bu netbook'ta bir şey dayanılmaz derecede yavaş olduğunda çok hızlı bir şekilde görüyorum ve yavaş noktalar hakkında çok daha hızlı bir şekilde farkındayım (her zaman kıyaslama yapmam gerekmiyor). Netbook üzerinde çalışmak gerçekten geliştirdiğim şekli değiştirdi.

Söyleniyor, özellikle profesyonel bir ortamda, bunu yapmayı savunmuyorum. İlk olarak, moral bozuyor. Neredeyse herkesin fikri söylediği gerçeği, programcıların bu fikre kötü tepki verdiğini bile göstermedi.

İkincisi, daha yavaş olan her şeye sahip olmak, hızlı bir makinede yapmak isteyebileceğiniz şeylerin (1 dakika sürdüğü anlamına gelir) artık yavaş bir makinede, tembellik vb. Nedeniyle artık yapılamayacağı anlamına gelir. Bu bir teşvik meselesidir.

Son olarak: üretilen kod daha hızlı olabilir, ancak üretilmesi neredeyse kesinlikle daha uzun sürer.

Nokta 1, HAYIR! Studio'nun iyi makinelerde çalıştırılması amaçlanmıştır ve bu gereksinim yalnızca her sürümde daha güçlü hale gelmiştir. İstihbarat açıp tek bir çekirdek olmayan HT kutusu kullanıyorsanız, aslında bazı stüdyo sürümlerini kilitleyebilirsiniz.

2. noktaya gelmek için, test projelerinde bazı kaynakları azaltmanıza izin veren bazı özellikler vardır. Mükemmel değiller ama oradalar. VPC veya düşük teknik özellikli VM görüntüleri de kısıtlanmakta oldukça iyidir. Kullanıcıların ara sıra test yapmak için kötü makinelere oturduğunu ve böylece talep ettikleri özelliklerin sonuçlarını görebiliyorum.

Hayır - aslında daha fazla hataya neden olur çünkü çok fazla test yapmazlar ve profilciler gibi ekstra araçlar kullanmazlar. Onlara ödeyebileceğiniz en iyi makineleri verin (oyun geliştirme veya grafik dükkanıysanız grafik hızlandırma donanımı dahil) ve VM'lerde test etmelerini sağlayın. VM özellikleri gerektiği gibi yukarı veya aşağı ölçeklenebilir.

Bunun ilginç bir soru olduğunu düşünüyorum ve hızlıca "hayır" demem. Benim fikrim: bu ne tür bir gelişim ekibinden bahsettiğimize bağlı. Örnek: yıllık ICFP programlama yarışması için çalışan bir gruba liderlik yapıyorsanız, belki de bir HPC kümesinde az miktarda geliştirildikten sonra iyi sonuçlar almak, mutlaka bulduğunuz çözümün iyi olduğu anlamına gelmez. Aynı şey, bazı bilimsel veya sayısal algoritmalar yazıyorsanız söylenebilir: Eski AMD Duron 600 MHz'de 64 MB bellek ile, işlerin nasıl yapıldığına dikkat etmek zorunda kalırsınız ve bu, bazı tasarımları bile etkileyebilir. seçimler.

Öte yandan, akıllı bir programcı / bilim adamı / her neyse dikkatli olması gerekiyordu. Ama kendimi en iyi kodlarımdan bazılarını yazıyordum, hiç de bilgisayarım yoktu ve kağıda not almam gerekti. Bir IDE'nin kesinlikle gerekli olduğu durumlarda, büyük çerçeveler içeren büyük projeler için bu geçerli olmayabilir.

Kesin olan bir şey var: hızlı makineler ve iyi anında sonuçlar (kötü) programcıları şımartır ve bilgisayarlarda bulduğumuz saçmalıkların sebeplerinden biri olabilir.

8 çekirdekli 8G makinemin (tam temiz yapı) kurulması yaklaşık bir saat süren bir paket üzerinde çalışıyorum. Ayrıca test ettiğim nispeten düşük son bir dizüstü bilgisayar var. Düşük uçtaki dizüstü bilgisayar, tek bir iş günü boyunca iki tam yapı yönetemiyor.

Dizüstü bilgisayarda yapılan bazı kasıtlı testlerle hızlı makinede daha üretken miyim, yoksa bütün yapımları dizüstü bilgisayarda mı yapmalıyım?

Bunların sayı sayılmadığını unutmayın.

Normalde her gün temiz bir yapı yapmam gerekmediği (sadece tekli modüller üzerinde çok sayıda test yapabilirim), ancak kısmi yapılar bile derleme / bağlantı zamanlarında kabaca bir büyüklük farkı gösterdiği için bir hileli bir demo. .

Bu yüzden asıl mesele yavaş makinemde tipik bir yapı benim için bir fincan kahve almaya yetecek kadar uzun, hızlı makinemde ise sadece biraz kahve yudumlayabiliyorum.

İş yapma açısından hızlı bir makinede geliştirme yapmayı tercih ederim. Son teslim tarihlerine daha güvenilir bir şekilde vurabilirim. Öte yandan, yönetimin yavaş makinemde geliştirme yapmamı sağladığını hayal ediyorum, çok daha fazla web taraması ya da en azından kitap okumamı.

İlginç bir şekilde, bunu yaptığımız bir başlangıçta çalıştım. Aslında oldukça iyi çalıştığını düşünüyorum, ancak içinde bulunduğumuz belirli durum yüzünden. Sınıf otomatik yeniden yükleme işleminin gerçekten doğru çalıştığı mod_perl dükkanıydı. Tüm geliştiriciler vim'i tercih edilen IDE'si olarak kullandılar (veya bazı uzaktan düzenleme yazılımlarını kullandılar). Sonuç, kodun derlenmesini / yeniden yüklenmesini / vb. Beklenmesini (varsa) çok az zaman kaybetmesiydi.

Temel olarak, bu fikri beğenirim IFF, tüm geliştiriciler için geliştirme döngüsü üzerinde göz ardı edilebilir bir etkiye sahiptir ve bu yalnızca kodunuzun çalışma zamanının çalışmasını etkiler. Kodunuz zaten derlenmiş, önceden işlenmiş vb. İse, geliştiricilerin çalıştığı "bug; bug; test; next" döngüsüne zaman ekliyorsunuzdur.

Kişilerarası açıdan insanlar yavaş sunucuları kullanmak zorunda kalmadı, ancak yavaş sunucuları kullandıysanız, kendi bakımınızı veya kurulumunuzu yapmak zorunda kalmadınız . Ayrıca, bu kurulum en başından beri vardı, bunu kurulu bir geliştirme ekibine satmayı deneyemeyi düşünemiyorum.

Asıl sorunuzu tekrar okuduktan sonra, beni sürekli korkutan bir şeyin üretim ortamlarından farklı geliştirme ortamları olduğu ortaya çıkıyor. Dev iş istasyonunu etkilemeden çalışma zamanı için saklayabileceğiniz kod yürütme için neden bir VM kullanmıyorsunuz? Son zamanlarda VirtualBox'ı kullanıyorum / seviyorum.

Ben de buradaki trendi yakalayacağım.

Fıkra: 286 bilgisayarı 486 es'e yükselten bir Hollandalı yazılım geliştirme firması için çalıştım (evet, o kadar yaşlıyım). Birkaç hafta içinde kurum içi kütüphanelerimizin performansı% 50 düştü ve hatalar arttı ... Küçük bir araştırma, insanların artık hata ayıklama işlemi sırasında kodun üzerinde düşündüklerini değil, “hızlı” ardışık kodlara başvurduklarını gösterdi -> derleme -> test -> düzeltme (kod) vb döngüleri.

İlgili: ABD'deki aynı şirkete bağlı bir iştiraki başlattığımda, daha az özellik / daha az güce sahip PC'lere alıştıkları ve çok daha verimli kodlayıcılar oldukları için Rus programcılarını işe aldım.

Bunların farklı zamanlar olduğunun farkındayım ve kaynaklar bugün olduklarından çok daha azdı, ancak donanım cephesinde kaydedilen tüm ilerlemelerle, net sonuç her adımda olduğu gibi görünüyor. yüksek minimum özellik gerektiren sloppier programlaması tarafından engellenmiştir ...

Bu nedenle ... Programcıların, uygulamalarını 'Ortalama Joe' hesaplama gücü ve donanım özelliklerini aşmayan makinelerde test etmeleri gerektiğini düşünüyorum.

Donanım, geliştirme zamanından daha az maliyetlidir.

Darboğazların çoğu, veritabanında istemci PC'de değil, ancak geliştiriciden daha yavaş makinelerde yapılan test için geçerli değildir. Optimizasyonu test etmek için test araçlarını kullanın.

Kesinlikle hayır. Programlayıcılarınıza satın alabileceğiniz en iyi dizüstü bilgisayar parasını, seçtikleri bir klavyeyi, çoklu büyük ekranları, özel bir ofisi, telefonsuz, ücretsiz alkolsüz içecekler, istedikleri tüm kitapları (alaka düzeyi olan), önemli teknik konferanslara yıllık geziler ve Harika sonuçlar alacaksınız. Ardından, üst ve alt sınır donanım / yazılım / tarayıcı / bant genişliği kombinasyonlarını test edin.

Bu ilginç bir düşüncedir (devs'e yavaş bir makine vermek onları daha fazla optimize etmeye yönlendirebilir).

Bununla birlikte, çözüm daha iyi bir şekilde çerçevelenmiştir - cevap verme süresini program gereksinimlerine koyun ve test için düşük kaliteli bir makineye sahip olun.

Ayrıca, gerçekten bir whiz-bang derleyiciniz / diliniz varsa, kod oluşturmak ve en iyisini seçmek için farklı yollar tasarlayabilirsiniz. Bu sadece daha hızlı bir bilgisayar tarafından yardımcı olurdu.

Diğerleri, genellikle geliştiricilerin hızlı makinelere sahip olmasını istediğinizi belirtti. Katılıyorum. RAM'i atlamayın - olabildiğince fazla bellekte istersiniz - bazı derleme işlemleri disk kullanımında çok ağırdır.

Kurtulmayı düşünmek isteyebileceğiniz şeyler, dahili sürücülerdeki antivirüs! Bu sadece yavaşlar ve çok güçlü bir yavaşlama faktörü olabilir.

Mümkünse, geliştiricilerin Linux'ta geliştirilmesine izin vermek isteyebilirsiniz. Buradaki araçlar, her türlü ekstra görev için çok daha iyidir (sadece dosyadaki bir şeyi bulmak, vb.). Bu aynı zamanda antivirüsten de kurtulur.

Macbook Pro iş yerimde birkaç yaşında. Linux ve Windows arasında (IE tuhaflıklarını test etmek için) vms, birkaç web tarayıcısı ve terminal açıktır, OSX çıkrık çok şey gösterir. Tahmin et, döndüğümde ne yaparım, otururum ve beklerim. Bu durumda, yavaş bir makine verimliliği yavaşlatır.

Pek çok uygulama için sorun, geliştiricilerin "tamamlanmadan" gerçek dünyadaki veri kümeleriyle test etmelerini sağlamaktır. Etkileşimli uygulamalar için bir temel test makinesi / VM gerekli olacaktır.

Yavaş bir Windows95 makinesinde çalışıyorum ve MindForth yapay zekasını Forth ve JavaScript'te yazmamı sağlıyor.

Programcılara, programcıların iyi bir donanıma sahip olup olmayacağını sormak, şişman bir erkeğe yemek yemeyi sevip sevmediğini sormak gibidir. Bunun öznel bir değişim olduğunu biliyorum ama yine de ... bize sormaya değer soru? : P

Tabii ki çoğunluğa katılıyorum dedi: HAYIR .