it-swarm-id.com

Apakah memberi pengembang mesin pengembangan yang lebih lambat menghasilkan kode yang lebih cepat / lebih efisien?

Misalkan saya memberi pengembang saya mesin yang menjerit cepat. VS2010 berbasis WPF memuat sangat cepat. Pengembang kemudian membuat aplikasi WPF atau WPF/e yang berjalan dengan baik di kotaknya, tetapi jauh lebih lambat di dunia nyata.

Pertanyaan ini memiliki dua bagian ...

1) Jika saya memberi pengembang mesin yang lebih lambat, apakah itu berarti kode yang dihasilkan mungkin lebih cepat atau lebih efisien?

2) Apa yang bisa saya lakukan untuk memberi pengembang saya pengalaman IDE, sementara memberikan pengalaman runtime 'tipikal'?

Perbarui:

Sebagai catatan, saya sedang mempersiapkan tanggapan tangan saya terhadap manajemen. Ini bukan ide saya, dan kalian membantu saya memperbaiki permintaan klien saya yang salah arah. Terima kasih telah memberi saya lebih banyak amunisi, dan referensi ke mana dan kapan untuk mendekati ini. Saya telah memberi +1 kasus penggunaan yang valid seperti:
- optimalisasi pemrograman sisi server tertentu
- lab uji
- mungkin membeli server yang lebih baik daripada kartu grafis garis atas

130

Tent

Benar juga bahwa para manajer harus melakukan semua pertemuan dalam bahasa Pig-Latin. Ini meningkatkan keterampilan komunikasi mereka secara keseluruhan untuk membuat mereka kurang beruntung ketika berbicara kalimat sederhana. Mereka harus lebih mengandalkan ekspresi wajah dan bahasa tubuh untuk menyampaikan maksud mereka dan kita semua tahu bahwa setidaknya 70% dari semua komunikasi bagaimanapun juga.

CFO harus menggunakan hanya sempoa dan kapur. Kalau tidak, mereka akhirnya terlalu mengandalkan 'data mentah' dan tidak cukup pada 'nyali perasaan' mereka.

Dan Wakil Presiden dan lebih tinggi harus diminta untuk mengadakan semua pertemuan bisnis penting dalam pengaturan yang mengganggu seperti lapangan golf sementara setengah mabuk. Oh jepret ...

234
Jay Beavers

Jawabannya adalah (saya akan berani dan katakan) selalu

NO .

Kembangkan yang terbaik yang bisa Anda dapatkan dengan anggaran Anda, dan uji berbagai peralatan minimum yang akan Anda gunakan.

Ada emulator, mesin virtual, mesin aktual dengan penguji yang semuanya dapat menguji kinerja untuk melihat apakah itu faktor.

376
Steven Evers

1) Sangat, sangat tidak mungkin.Tidak, dan pengembang Anda mungkin menaruh sesuatu yang tidak enak di kopi Anda untuk menyarankannya. Waktu yang dihabiskan pengembang Anda menunggu kode untuk dikompilasi atau untuk IDE untuk melakukan apa pun yang dilakukannya atau apa pun waktu mereka tidak pengeluaran membuat kode lebih baik. Mengganggu aliran mental mereka juga. Jaga pikiran mereka pada masalah, dan mereka akan jauh lebih efisien menyelesaikan masalah itu.

2) Beri mereka masing-masing PC kedua yang mewakili spesifikasi terendah yang Anda ingin mereka benar-benar dukung, dengan sakelar KVM untuk memilih antara itu dan workstation nyata mereka.

70
BlairHippo

Saya suka waktu kompilasi yang lama. Ini memberi saya lebih banyak waktu untuk mengerjakan resume saya.

43
Wonko the Sane

Ini ide yang buruk. Anda ingin pengembang Anda menjadi seproduktif mungkin, yang berarti memberi mereka mesin secepat mungkin, sehingga mereka tidak duduk sepanjang hari menunggu barang dikompilasi. (Sedikit OT, tetapi juga membantu untuk tidak memblokir akses mereka ke situs yang berpotensi membantu dengan WebSense dan sejenisnya.) Jika Anda dibatasi oleh memiliki pengguna yang masih menjalankan teknologi Zaman Batu, maka Anda harus memiliki mesin uji dengan spesifikasi yang serupa, dan pastikan untuk menguji lebih awal dan sering untuk memastikan bahwa Anda tidak salah jalan dalam hal pilihan teknologi.

33
o. nate

Pembangunan harus dilakukan di lingkungan terbaik yang layak. Pengujian harus dilakukan di lingkungan terburuk yang layak.

32
Yevgeniy Brikman

Jika saya diberi mesin yang lambat saya akan menghabiskan hari saya mengoptimalkan proses pengembangan dan tidak mengoptimalkan kode yang saya kirim. Jadi: TIDAK!

27
user6015

Pemrogram sistem tertanam mengalami hal ini sepanjang waktu! Dan ada solusi dua bagian:

  1. Persyaratan Anda perlu menentukan kinerja X pada perangkat keras Y.
  2. Tes pada perangkat keras Y, dan ketika Anda tidak mendapatkan kinerja X, kutu bug.

Maka tidak masalah apa perangkat keras Anda bekerja pada pengembang.

Setelah Anda selesai melakukannya, katakanlah peralatan yang lebih cepat dapat menghemat programmer Anda setengah jam sehari, atau 125 jam dalam setahun. Dan katakanlah biayanya $ 100.000 setahun dengan manfaat dan biaya overhead (sangat rendah untuk Silicon Valley), atau $ 50 per jam. 125 jam itu * $ 50/jam adalah $ 6250. Jadi, jika Anda menghabiskan kurang dari $ 6250 per tahun untuk pengembangan perangkat keras rockin per programmer, Anda menghemat uang.

Itulah yang harus Anda sampaikan kepada manajemen Anda.

Tim Williscroft cukup banyak mengatakan bagian pertama dari ini dalam komentar, dan di dunia yang adil, ia akan mendapatkan setengah dari setiap poin jawaban ini didapat.


Ditambahkan 24 Oktober:

Mantan atasan saya memiliki teori itu, dan itu membantu mereka membuat marah sekitar $ 100 juta.

Mereka adalah konglomerat yang berbasis di Jepang yang digunakan untuk merekrut programmer di Jepang, Korea dan Cina. Orang-orang di sana keren dengan menggunakan perangkat keras pengembangan yang jelek, 13 jam hari kerja, tidur di meja mereka, dan tidak memiliki kehidupan. Jadi mereka membayangkan ketika mereka mengakuisisi perusahaan terkenal Silicon Valley untuk melakukan OS ponsel berbasis Linux, orang-orang California konyol yang menginginkan peralatan modern hanyalah primadona dan tidak benar-benar memiliki alasan yang baik untuk itu (seperti produktivitas).

Empat tahun kemudian, OS bekerja seperti omong kosong, semua jadwal macet, dan pelanggan kesal dan mengakhiri kontrak kanan dan kiri. Akhirnya, proyek OS dibatalkan, dan sebagian besar tenaga kerja konglomerat di seluruh dunia di-PHK selama setahun terakhir. Dan terus terang, saya tidak ingin menjadi salah satu eksekutif yang harus menjelaskan kepada para pemegang saham di mana semua uang dan usaha itu pergi.

Bukan hanya mesin pengembangan lambat yang menyebabkan kegagalan ini. Ada banyak kesalahan strategis dan taktis lainnya - tetapi itu adalah hal yang sama di mana orang-orang yang bekerja di parit bisa melihat keruntuhan kereta datang, dan bertanya-tanya mengapa para pembuat keputusan tidak bisa.

Dan persneling yang lambat tentu merupakan faktor. Lagi pula, jika Anda berada di bawah senjata untuk tepat waktu, apakah benar-benar hal yang cerdas untuk sengaja memperlambat pekerjaan?

26
Bob Murphy

Dalam pemrograman, ada pepatah lama bahwa " optimasi prematur adalah akar dari semua kejahatan ". Saya pikir Anda telah berhasil membuat "root" lain (atau setidaknya cabang pertama) dari semua kejahatan. Mulai sekarang, kita dapat mengatakan "deoptimisasi pengembang prematur adalah akar dari semua kejahatan."

Singkatnya, jawabannya adalah ini hanya akan memperlambat waktu pengembangan Anda dan membuat perawatan lebih lanjut lebih sulit. Waktu kompilasi akan lebih lama, mencari kode pada disk akan lebih lambat, menemukan jawaban online akan lebih lama, dan PALING penting, pengembang akan mulai menggunakan kode mereka secara prematur untuk bahkan dapat menguji fungsionalitas yang diperlukan.

Poin terakhir itu adalah masalah paling kritis dan tidak diangkat dalam banyak jawaban lain. Anda mungkin mendapatkan versi pertama Anda ok, tetapi kemudian ketika Anda ingin memperbarui kode di masa depan, Anda akan menemukan bahwa optimasi pengembang prematur mengambil fokus kode Anda dari desain yang baik dan mendorongnya lebih dekat ke "harus membuat ini di paling tidak bekerja untuk mempertahankan "kode gaya pekerjaan saya. Menambahkan fitur tambahan akan menjadi lebih sulit karena optimisasi yang dipilih pada saat itu mungkin tidak diperlukan dan mengunci kode Anda ke jalur peretasan semi-optimal di atas peretasan semi-optimal lainnya.

Sebagai contohnya, bayangkan bahwa persyaratan sistem minimum versi Anda saat ini adalah mesin prosesor tunggal dengan kecepatan agak lambat. Anda menempatkan pengembang di kotak ini dan mereka datang dengan solusi berulir tunggal rumit yang bergantung pada banyak peretasan karena mereka ingin mengembangkan produk dengan cepat. Sekarang 5 tahun kemudian, Anda memiliki versi baru produk yang memiliki persyaratan minimum mesin prosesor ganda. Anda ingin dapat memisahkan bagian-bagian dari program yang dapat Anda jalankan secara paralel, tetapi keputusan yang Anda buat 5 tahun lalu yang memaksa pengembang Anda untuk membuat perangkat lunak yang rusak sekarang mencegah Anda menggunakan kekuatan penuh dari persyaratan minimum baru Anda. .

Apa yang harus Anda lakukan adalah menambahkan fase di akhir siklus pengembangan Anda di mana Anda melakukan pengujian penerimaan pada kotak batas bawah. Tentu saja beberapa kode akan terlalu lambat karena mesin yang lebih cepat dari pengembang tetapi Anda dapat mengisolasi bagian itu dan mengoptimalkannya di sana. Sisa kode Anda tetap bersih dan dapat dipelihara.

Saya melihat pertanyaan Anda mengatakan, "Dapatkah saya memaksa pengembang saya untuk mengoptimalkan awal dengan memberi mereka mesin pengembang yang buruk namun masih mendapatkan kode yang baik?" Dan jawabannya adalah tidak.

20
EntropyFails

Bacaan yang menarik, semua jawaban itu.

Tapi saya pikir kebanyakan orang yang menjawab di sini tidak mengerti. Pertanyaannya, ketika saya membacanya bukan (hanya setidaknya) tentang benar-benar memberikan pengembang P1 untuk membuat kode lebih cepat.

Intinya adalah bahwa banyak perangkat lunak saat ini sama lambatnya atau bahkan lebih lambat dari seftware yang kita gunakan pada milenium terakhir meskipun komputer jauh lebih kuat. Menilai dari jawaban di sini kebanyakan pengembang tidak mendapatkan petunjuk itu. Ini sangat jelas dalam aplikasi web. Situs ini merupakan pengecualian yang sangat baik, tetapi banyak situs memiliki halaman depan dalam 1 mb. Apa yang saya dapatkan untuk menunggu untuk mengunduh? Saya tidak tahu Saya pikir itu tampaknya tentang ketidaktahuan dari pengembang tidak menghormati waktu yang harus dihabiskan pengguna untuk itu, atau bahkan lebih buruk membayar jika Anda membayar per mb. Masalahnya adalah bahwa semua halaman web itu bahkan tidak mengandung gambar resolusi tinggi. Seringkali itu hanya beberapa kode omong kosong yang dikirimkan dari beberapa lingkungan pengembangan. Yah, tentu saja itu bukan kode omong kosong saya kira, tetapi tidak memberikan keuntungan bagi saya sebagai pengguna.

Secara umum ini bukan hanya tentang mengoptimalkan kode, tetapi juga tentang memilih untuk tidak memasukkan hal-hal yang melambat lebih banyak daripada yang diberikannya.

Beberapa minggu yang lalu saya memulai laptop dari 1995. Windows 3.x sudah berjalan dan berjalan dalam waktu singkat. Basis data saya harus mendapatkan beberapa data dari mulai sebelum tombol enter sepenuhnya dirilis (hampir setidaknya).

Saya tahu bahwa kami mendapatkan lebih banyak dari perangkat lunak kami hari ini, tetapi kami juga memiliki komputer berkali-kali lebih cepat. Mengapa industri pengembangan tidak memutuskan untuk menjaga kecepatan perangkat lunak sejak 1995 dan membuat orang membeli perangkat keras baru karena mereka menginginkan fungsionalitas baru. Hari ini lebih seperti program sehari-hari dan situs web memaksa orang untuk membeli perangkat keras baru untuk melakukan hal yang persis sama seperti yang mereka lakukan sebelumnya. Tapi tentu saja dengan cara yang lebih mewah.

Saya harus mengatakan saya pikir pengembangan Linux tampaknya menangani ini dengan lebih baik. Distribusi Linux telah selama bertahun-tahun berada cukup jauh di depan jendela bahkan dalam fantasi dengan banyak hal menarik seperti windows animasi. Masalahnya adalah bahwa mereka telah bekerja di komputer hari ini dan bahkan kemarin. Tidak hanya pada pemotongan perangkat keras Edge.

Sekarang saya kira banyak pengembang memiliki tingkat adrenalin yang tidak sehat. Ya, saya menemukan cara untuk mengembalikan frustrasi dari semua yang menunggu di depan:
server sql server (memulai konsol manajemen) arcgis (memulai dan menggunakan) acrobat reader (memulai) agresso (menggunakan, setidaknya sebagai aplikasi web) jendela (menatap dan menggunakan, saya belum mencoba 7 yet) halaman web bersih (mengunduh)

dan seterusnya

Saya baik-baik saja :-)

Bersulang
Nicklas

15
Nicklas Avén

1) Jika saya memberi pengembang mesin yang lebih lambat, apakah itu berarti kode yang dihasilkan mungkin lebih cepat atau lebih efisien?

Kami telah membangun perangkat lunak selama 6 dekade terakhir, dan kami masih mendapatkan pertanyaan seperti ini? Tampaknya lebih seperti upaya lain untuk memotong sudut. Jangan tersinggung, tapi ayolah, apakah menurut Anda pertanyaannya masuk akal? Pikirkan dalam istilah ini (jika Anda bisa): Anda ingin membangun kendaraan 4x4 yang dapat beroperasi di bawah kondisi yang keras, hujan, lumpur, apa pun. Apakah Anda akan menempatkan insinyur dan jalur perakitan di bawah elemen hanya untuk memastikan kendaraan yang dihasilkan dapat beroperasi pada mereka?

Maksudku, Yesus Kristus! Ada pengembangan dan ada pengujian. Pengujian dilakukan di lingkungan yang berbeda, lebih keras, atau pengembang tahu cara merakit tempat uji di lingkungan pengembangnya sendiri dengan cara yang sesuai untuk pengujian stres. Jika tidak bisa, ganti dia dengan pengembang yang lebih baik.

2) Apa yang bisa saya lakukan untuk memberi pengembang saya pengalaman IDE, sementara memberikan pengalaman runtime 'tipikal'?

Anda harus menanyakan hal itu kepada pengembang Anda. Dan jika mereka tidak dapat memberikan jawaban yang objektif dan valid, Anda perlu menggantinya dengan pengembang yang sebenarnya.

Tetapi untuk menghibur pertanyaan, berikan pengembang Anda (dengan asumsi Anda memiliki pengembang yang baik), alat yang baik dan perangkat keras yang baik, yang terbaik yang Anda mampu. Kemudian atur lingkungan baseline umum terendah di mana perangkat lunak Anda harus beroperasi. It tempat pengujian harus dilakukan. Adalah praktik rekayasa yang jauh lebih baik untuk memiliki lingkungan pengujian yang berbeda dari lingkungan pengembangan (lebih disukai yang memungkinkan Anda melakukan untuk stress testing.)

Jika pengembang Anda bagus, mereka harus mengomunikasikan hal ini kepada Anda (dengan asumsi Anda telah meminta mereka.)

10
luis.espinal

Ini menghasilkan banyak pengembang bitchin. Hal ini cukup sulit seperti itu, jangan membuat pengalaman lebih buruk.

Saya akan mendorong Anda untuk memiliki perangkat keras yang serupa dengan pengguna Anda dalam lingkungan Uji atau QA untuk mengeluarkan masalah kinerja apa pun. Itu ide yang bagus.

6
bigtang

Saya akan melawan norma dan mengatakan ya JIKA DAN HANYA jika mereka menulis perangkat lunak server. Tertawalah semua yang Anda inginkan, tetapi tim paling efisien yang pernah saya lihat adalah sekelompok Perl dengan terminal Wyse. Ini adalah akhir 1990-an, adalah toko off-shoot Universitas, dan mereka menulis perangkat spasial gridding (yang pada dasarnya hanya menghitung). Namun mereka berbicara dengan beberapa RS/6000 model akhir yang relatif kuat.

Hanya untuk menambah minat pada acara tersebut, ada seorang programmer yang buta di sana. Saya benar-benar terkesan.

alt text

6
Jé Queue

Ini bukan ide yang buruk - tetapi Anda ingin pengembang Anda memiliki lingkungan pemrograman yang cepat.

Anda mungkin bisa menerapkan ini dengan memberi programmer Anda dua mesin - kotak dev cepat, dan kotak komoditas lebih lambat (mungkin virtual) untuk pengujian.

Beberapa penyesuaian dari proses pembuatan VS dapat membuat penyebaran ke kotak tes norma, dengan debugging jarak jauh.

Ada beberapa cara lain untuk mempertimbangkan memaksa coder Anda untuk mengembangkan kode yang lebih efisien - Anda dapat memasukkan tujuan kinerja dan penggunaan memori dalam pengujian unit Anda, misalnya. Menetapkan anggaran untuk penggunaan memori juga merupakan tujuan yang sangat baik. Juga mengatur anggaran berat halaman untuk kode html.

5
damien

Masalahnya bukan pengembang membuat kode tidak efisien pada mesin cepat, masalahnya adalah Anda belum mendefinisikan metrik kinerja yang harus diukur.

Harus ada, sebagai bagian dari persyaratan produk, target spesifik yang dapat diukur pada semua komputer berdasarkan pengalaman pelanggan yang diperlukan. Ada banyak situs web (Periksa SpecInt) yang memungkinkan Anda menghubungkan komputer Anda ke komputer jenis lain.

Ini bagus karena banyak alasan. Hal ini memungkinkan Anda untuk mendefinisikan perangkat keras minimum yang didukung lebih mudah sehingga Anda dapat membatasi jumlah keluhan pelanggan - kita semua tahu sebagian besar perangkat lunak berjalan pada kebanyakan komputer, itu hanya masalah kinerja - jika kita menetapkan spesifikasi kami sehingga orang-orang dalam rentang persyaratan minimum memiliki kinerja yang cukup dapat diterima, Anda membatasi keluhan pelanggan - dan kemudian ketika pelanggan menelepon, Anda dapat menggunakan tolok ukur untuk menentukan apakah memang ada masalah, atau jika pelanggan tidak senang dengan bagaimana produk seharusnya bekerja.

5
Mike Glasspool

Saya yakin bahwa memiliki komputer yang lebih lambat untuk pengembangan menghasilkan kode yang lebih cepat, tetapi ini harus dibayar mahal. Alasannya adalah bahwa saya telah mengalami tangan pertama ini: memiliki waktu perjalanan yang panjang, saya membeli netbook untuk bekerja di kereta, netbook yang lebih lambat dari komputer mana pun yang saya beli dalam 5 tahun terakhir. Karena semuanya sangat lambat, saya melihat dengan sangat cepat ketika ada sesuatu yang sangat lambat di netbook ini, dan saya menyadari titik lambat jauh lebih cepat (tidak perlu benchmark sepanjang waktu). Bekerja di netbook benar-benar mengubah cara saya berkembang.

Karena itu, saya tidak menganjurkan melakukan ini, terutama di lingkungan profesional. Pertama, itu melemahkan semangat. Fakta bahwa hampir semua orang mengatakan ide itu bahkan tidak masuk akal menunjukkan bahwa programmer bereaksi buruk terhadap ide tersebut.

Kedua, memiliki segalanya lebih lambat berarti bahwa hal-hal yang Anda mungkin ingin lakukan pada mesin cepat (katakanlah 1 menit) tidak benar-benar dapat dilakukan lagi pada mesin lambat, karena malas, dll ... Ini adalah masalah insentif.

Akhirnya: kode yang dihasilkan mungkin lebih cepat, tetapi hampir pasti membutuhkan waktu lebih lama untuk diproduksi.

5
David Cournapeau

Butir 1, TIDAK! Studio dimaksudkan untuk dijalankan pada mesin yang layak dan persyaratan itu hanya menjadi lebih kuat pada setiap versi. Anda benar-benar dapat mengunci beberapa versi studio jika Anda mengaktifkan intellisense dan menggunakan kotak single core non HT.

Untuk poin # 2 ada beberapa fitur dalam proyek pengujian yang memungkinkan Anda untuk membatasi beberapa sumber daya. Mereka tidak sempurna, tetapi mereka ada di sana. VPC atau spec rendah VM gambar untuk pekerjaan yang cukup baik dibatasi juga. Saya memiliki pengguna duduk di mesin yang buruk untuk melakukan pengujian sesekali sehingga mereka dapat melihat implikasi dari fitur yang mereka miliki. telah meminta.

4
Bill

Tidak - sebenarnya itu akan menghasilkan lebih banyak bug karena mereka tidak akan melakukan banyak pengujian, dan mereka tidak akan menggunakan alat tambahan seperti profiler. Beri mereka mesin terbaik yang Anda mampu (termasuk perangkat keras akselerasi grafis jika Anda seorang pengembang game atau toko grafis), dan minta mereka mengujinya di dalam VM. Spesifikasi VM dapat ditingkatkan atau diturunkan sesuai kebutuhan.

4
JohnL

Saya pikir ini adalah pertanyaan yang menarik, dan saya tidak akan menjawab "tidak" secepat itu. Pendapat saya adalah: itu tergantung pada tim pengembangan seperti apa yang sedang kita bicarakan. Contoh: jika Anda memimpin grup yang berjalan untuk kontes pemrograman ICFP tahunan, mungkin memiliki hasil yang baik setelah sedikit waktu pengembangan pada cluster HPC tidak akan berarti bahwa solusi yang Anda temukan baik. Hal yang sama dapat dikatakan jika Anda menulis beberapa algoritma ilmiah atau numerik: pada AMD Duron 600 MHz lama Anda dengan 64 MB memori Anda terpaksa harus berhati-hati tentang cara Anda menyelesaikan sesuatu, dan ini dapat mempengaruhi bahkan beberapa desain pilihan.

Di sisi lain, seorang programmer/ilmuwan/pintar apa pun yang seharusnya berhati-hati. Tetapi saya menemukan diri saya menuliskan beberapa kode terbaik saya ketika saya TIDAK punya komputer AT SEMUA dan harus membuat catatan di atas kertas. Ini mungkin tidak berlaku untuk proyek besar yang melibatkan kerangka kerja besar, ketika IDE sangat diperlukan.

Satu hal yang pasti: mesin cepat dan hasil langsung yang baik membuat programmer (buruk) manja dan mungkin menjadi salah satu alasan untuk beberapa omong kosong yang kita temukan di komputer.

4
Lorenzo Stella

Saya mengerjakan paket yang membutuhkan waktu sekitar satu jam untuk membangun mesin 8 core 8G saya (full clean build). Saya juga punya laptop yang relatif rendah saya uji. Laptop low end tidak mengelola dua build penuh selama satu hari kerja.

Apakah saya lebih produktif di mesin cepat dengan beberapa pengujian yang disengaja dilakukan pada laptop, atau haruskah saya melakukan semua build saya di laptop?

Perlu diingat ini bukan angka yang dibuat-buat.

Ini adalah demo kecurangan dimana saya biasanya tidak perlu melakukan build bersih setiap hari (saya bisa melakukan banyak pengujian pada modul tunggal), tetapi bahkan build parsial menunjukkan secara kasar urutan perbedaan besarnya dalam waktu kompilasi/tautan .

Jadi masalah sebenarnya adalah pada mesin saya yang lebih lambat, bentuk yang khas cukup lama bagi saya untuk mendapatkan secangkir kopi, sedangkan pada mesin yang lebih cepat saya hanya bisa menyesap kopi.

Dari sudut pandang menyelesaikan pekerjaan saya lebih suka melakukan pengembangan pada mesin cepat. Saya jauh lebih andal bisa mencapai tenggat waktu. Di sisi lain saya membayangkan jika manajemen membuat saya melakukan pengembangan pada mesin lambat saya, saya akan mendapatkan lebih banyak browsing web dilakukan, atau setidaknya membaca buku.

4
Stripes

Menariknya, saya bekerja di sebuah startup di mana kami akhirnya melakukan ini. Saya pikir itu benar-benar bekerja dengan cukup baik, tetapi hanya karena situasi khusus kami berada. Itu adalah toko mod_Perl di mana kelas auto-reload sebenarnya bekerja dengan benar. Semua pengembang menggunakan vim sebagai IDE pilihan mereka (atau menggunakan beberapa perangkat lunak pengeditan jarak jauh). Hasil akhirnya adalah sangat sedikit (jika ada) waktu yang hilang menunggu kode untuk dikompilasi/reload/dll.

Pada dasarnya, saya suka ide ini IFF ada dampak yang dapat diabaikan pada siklus pengembangan untuk semua pengembang, dan itu hanya berdampak pada operasi runtime dari kode Anda. Jika kode Anda tetap dikompilasi, preprocessed, dll, maka Anda menambahkan waktu untuk "memperbaiki bug; tes; selanjutnya" loop yang sedang dikerjakan pengembang.

Dari sisi interpersonal, orang tidak pernah dipaksa untuk menggunakan server lambat, tetapi jika Anda menggunakan server lambat, Anda tidak perlu melakukan pemeliharaan atau pengaturan Anda sendiri. Juga, pengaturan ini ada sejak awal, saya tidak bisa membayangkan mencoba menjual ini ke tim pengembangan yang sudah mapan.

Setelah membaca ulang pertanyaan awal Anda, terpikir oleh saya bahwa satu hal yang terus-menerus menakutkan saya adalah lingkungan pengembangan yang berbeda dari lingkungan produksi. Mengapa tidak menggunakan VM untuk eksekusi kode yang Anda dapat melumpuhkan untuk runtime tanpa mempengaruhi workstation dev? Belakangan ini, saya telah menggunakan/mencintai VirtualBox.

3
user6041

Saya akan melawan tren di sini juga.

Anekdot: Saya bekerja di sebuah perusahaan pengembangan perangkat lunak Belanda yang memutakhirkan 286 komputer menjadi 486-es (ya, saya setua itu). Dalam beberapa minggu, kinerja semua perpustakaan internal kami turun 50% dan bug meningkat ... Sebuah penelitian kecil menunjukkan bahwa orang tidak lagi memikirkan kode itu sendiri selama proses debugging, tetapi menggunakan kode berturut-turut 'cepat' -> kompilasi -> tes -> perbaiki (kode) dll siklus.

Terkait: ketika saya memulai anak perusahaan untuk perusahaan yang sama di AS, saya akhirnya mempekerjakan programmer Rusia karena mereka terbiasa dengan PC dengan fitur yang lebih sedikit/daya yang lebih sedikit dan coders yang jauh lebih efisien.

Saya menyadari ini adalah waktu yang berbeda, dan sumber daya jauh lebih langka daripada saat ini, tetapi tidak pernah berhenti membuat saya takjub bagaimana, dengan semua kemajuan yang telah dibuat di bagian depan perangkat keras, hasil akhirnya tampaknya bahwa setiap langkah ke depan adalah dinegasi oleh pemrograman sloppier yang membutuhkan spesifikasi minimum lebih tinggi ...

Oleh karena itu ... Saya merasa programmer harus dipaksa untuk menguji aplikasi mereka pada mesin yang tidak melebihi daya komputasi 'Rata-Rata Joe' dan spesifikasi perangkat keras.

3
John SMythe

Perangkat keras lebih murah daripada waktu pengembangan.

Sebagian besar kemacetan ada di database bukan di PC klien, tapi itu tidak memaafkan pengujian pada mesin yang lebih lambat daripada pengembang. Gunakan alat pengujian untuk menguji optimasi.

3
Brian

Benar-benar tidak. Berikan Programmer Anda uang laptop terbaik yang bisa dibeli, keyboard pilihan mereka, beberapa layar besar, kantor pribadi, tanpa telepon, minuman ringan gratis, semua buku yang mereka inginkan (yang relevan), perjalanan tahunan ke konferensi teknologi utama dan Anda akan mendapatkan hasil yang bagus. Kemudian uji pada kombinasi perangkat keras/lunak/browser/bandwidth batas atas dan bawah.

3
addictedtoswdev

Untuk banyak aplikasi, masalahnya adalah membuat para pengembang untuk menguji dengan set data dunia nyata sebelum mereka "selesai." Untuk aplikasi interaktif, mesin uji baseline/VM akan diperlukan.

2
user6043

Saya bekerja pada mesin Windows95 yang lambat, dan memungkinkan saya secara efisien untuk menulis kecerdasan buatan MindForth di Forth dan di JavaScript.

2
Mentifex

Ini adalah pemikiran yang menarik (memberikan mesin lambat mungkin akan membuat mereka lebih mengoptimalkan).

Namun, solusinya dibingkai dengan cara yang lebih baik - berikan waktu respons dalam persyaratan untuk program, dan miliki mesin low-end yang tersedia untuk pengujian.

Juga, jika Anda memiliki kompiler/bahasa yang benar-benar jagoan, ia mungkin dapat menemukan berbagai cara untuk menghasilkan kode dan memilih yang terbaik. Itu hanya akan terbantu oleh komputer yang lebih cepat.

2
Paul Nathan

Yang lain merespons bahwa umumnya Anda ingin pengembang memiliki mesin cepat. Saya setuju. Jangan melewatkan RAM - Anda ingin sebanyak mungkin dalam memori - beberapa proses pembuatan sangat berat pada penggunaan disk.

Hal yang Anda mungkin ingin pertimbangkan untuk menyingkirkannya adalah antivirus pada drive yang dibuat! Itu hanya melambat dan bisa menjadi faktor pelambatan yang sangat kuat.

Anda mungkin ingin membiarkan pengembangan berkembang di Linux jika memungkinkan. Alat yang ada jauh lebih baik untuk semua jenis tugas tambahan (hanya ambil sesuatu dalam file, dll). Ini juga menghilangkan anti-virus.

2
user1249

Menanyakan kepada pemrogram apakah pemrogram harus mendapatkan perangkat keras yang baik seperti bertanya pada seorang pria gemuk apakah ia menyukai makanan. Saya tahu ini adalah pertukaran subjektif, tapi tetap saja ... apakah pertanyaan ini layak ditanyakan kepada kami? : P

Yang mengatakan saya tentu saja setuju dengan mayoritas: NO .

2
Matthew Read

Saya tergoda untuk mengatakan "Tidak" dengan tegas, tetapi izinkan saya berbagi pengalaman baru-baru ini: Seseorang di proyek kami sedang mengerjakan beberapa kode untuk mengimpor data ke dalam basis data. Pada saat itu ia memiliki PC tertua di grup kami, bahkan mungkin seluruh organisasi. Ini bekerja dengan baik dengan VS 2008, tetapi tentu saja mesin yang lebih cepat akan membuat pengalaman lebih baik. Ngomong-ngomong, pada satu titik proses yang dia tulis dibom saat diuji (dan itu sebelum fitur lengkap). Dia kehabisan ingatan. Proses ini juga memakan waktu beberapa jam sebelum dieksekusi. Perlu diingat, sejauh yang kami tahu, inilah yang harus digunakan oleh pengguna.

Dia meminta lebih banyak RAM. Mereka menolak, karena dia mendapatkan mesin yang lebih baru dalam 3-4 minggu dan yang lama akan dibuang.

Perlu diingat bahwa filosofi orang ini tentang pengoptimalan adalah: "Kami memiliki mesin cepat dengan banyak RAM" (dan beberapa mesinnya dikecualikan), jadi mengapa buang waktu berharga untuk mengoptimalkan programer? Tetapi situasinya memaksanya untuk mengubah algoritma menjadi lebih hemat memori sehingga akan berjalan pada mesin 2Gb-nya (menjalankan XP.) Efek samping dari penulisan ulang adalah bahwa prosesnya juga berjalan jauh, lebih cepat daripada sebelumnya. . Juga versi aslinya akhirnya akan dibom bahkan dengan 4Gb ketika lebih banyak data yang diimpor - itu adalah babi memori, sederhana dan sederhana.

Soooo ... Walaupun secara umum saya akan mengatakan "Tidak", ini adalah kasus di mana pengembang memiliki mesin yang kurang kuat menghasilkan modul yang lebih optimal, dan pengguna akan mendapat manfaat sebagai hasilnya (karena itu bukan proses yang perlu dijalankan sangat sering, ia awalnya tidak punya niat untuk mengoptimalkannya, sehingga mereka akan terjebak dengan versi asli jika mesin sudah cukup RAM untuk menjalankan beberapa tes besar .. .) Saya bisa melihat maksudnya, tetapi secara pribadi saya tidak suka gagasan pengguna harus menunggu 8 jam untuk menyelesaikan proses, ketika itu dapat berjalan di sebagian kecil dari waktu itu.

Dengan mengatakan itu, secara umum programmer harus memiliki mesin yang kuat karena kebanyakan pengembangannya cukup intensif. Namun, harus sangat hati-hati untuk memastikan bahwa pengujian dilakukan pada mesin "common denominator terendah" untuk memastikan bahwa prosesnya tidak meledak dan bahwa pengguna tidak akan menonton Paint kering sepanjang hari. Tapi ini sudah dikatakan. :)

2
MetalMikester

Dalam membaca pertanyaan, dan jawabannya, saya agak kaget dengan kerasnya kasus TIDAK.

Saya telah bekerja dalam pengembangan perangkat lunak selama 25 tahun sekarang, dan saya dapat mengatakan tanpa ragu bahwa programmer membutuhkan banyak hal untuk mengembangkan kode yang baik:

  • Lingkungan pengembangan yang WAJAR. Bukan dinosaurus. Tidak perlu Edge yang berdarah. Cukup bagus untuk tidak membuat frustrasi.

  • Spesifikasi yang baik (berapa banyak yang dilakukan tanpa spesifikasi tertulis?)

  • Manajemen yang baik dan mendukung.

  • Jadwal pengembangan yang masuk akal.

  • Pemahaman yang baik tentang pengguna DAN LINGKUNGAN yang akan dimiliki pengguna.

Lebih jauh, pada poin terakhir ini, pengembang harus berada dalam pola pikir apa yang akan digunakan pengguna. Jika pengguna memiliki superkomputer dan sedang melakukan simulasi pemisahan atom atau sesuatu di mana kinerja menghabiskan banyak uang, dan kalkulasi berjalan selama berjam-jam, maka pikirkan hitungan kinerjanya.

Jika pengguna memiliki 286 laptop bertenaga uap maka pengembang dan pengembang harus melakukan tes pengembangan mereka pada Core i9000 47 GHz terbaru akan menyebabkan beberapa masalah.

Mereka yang mengatakan "berikan pengembang yang terbaik dan UJI itu" sebagian benar tetapi ini memiliki masalah MENTAL besar bagi pengembang. Mereka tidak menghargai pengalaman pengguna sampai terlambat - saat pengujian gagal.

Ketika pengujian gagal - arsitektur telah berkomitmen, manajemen telah membuat janji, banyak uang telah dihabiskan, dan kemudian berubah menjadi bencana.

Pengembang harus berpikir seperti, memahami, dan berada di zona pengalaman pengguna sejak hari pertama.

Mereka yang menangis "oh tidak, itu tidak bekerja seperti itu" sedang membicarakan apa yang mereka katakan. Saya telah melihat ini terjadi, berkali-kali. Tanggapan pengembang yang biasa adalah salah satu dari "beri tahu PELANGGAN untuk membeli komputer yang lebih baik", yang secara efektif menyalahkan pelanggan. Tidak cukup baik.

Jadi ini berarti Anda memiliki beberapa masalah:

  • Buat para pengembang senang dan kencing di manajemen, tingkatkan kemungkinan proyek gagal.

  • Gunakan mesin yang lebih lambat untuk pengembangan, dengan risiko mengecewakan para devs, tetapi pertahankan agar mereka tetap fokus pada apa yang sebenarnya penting.

  • Letakkan 2 mesin di meja devs DAN FORCE MEREKA UNTUK MENGUJI CLUNKER (yang tidak akan mereka lakukan karena itu di bawah penghinaan .... tapi setidaknya sangat jelas maka jika ada masalah kinerja yang diuji).

Ingat sistem batch dan kartu punch? Orang-orang menunggu satu jam atau satu hari untuk perubahan haluan. Banyak hal dilakukan.

Ingat sistem unix lama dengan prosesor 5 MHz? Hal-hal dilakukan.

Techo-geeks suka mengejar Edge yang berdarah. Ini mendorong bermain-main, bukan berpikir. Sesuatu yang saya miliki tentang argumen dengan lebih banyak pengembang junior selama bertahun-tahun .... ketika saya mendesak mereka untuk menjauh dari keyboard dan menghabiskan lebih banyak waktu membaca kode dan berpikir.

Dalam pengembangan kode, tidak ada pengganti untuk berpikir.

Dalam hal ini, perasaan saya adalah - mencari tahu APA YANG BENAR-BENAR MASALAH. Keberhasilan proyek? Apakah ini latihan membuat/membunuh perusahaan? Jika ya, Anda tidak bisa gagal. Anda tidak mampu mengeluarkan uang untuk hal-hal yang gagal dalam ujian. Karena tes terlambat dalam siklus pengembangan, dampak kegagalan ditemukan terlambat.

[Sebuah bug yang ditemukan dalam biaya pengujian sekitar 10x lebih banyak untuk memperbaiki daripada bug yang ditemukan oleh seorang pengembang selama pengembangan.

Dan bug yang ditemukan dalam biaya pengujian sekitar 100x lebih banyak untuk memperbaiki seperti bug yang dirancang selama fase desain arsitektur.]

Jika ini bukan deal breaker, dan Anda punya waktu dan uang untuk dibakar, maka gunakan lingkungan pengembangan Edge yang berdarah, dan menderita kegagalan tes. Kalau tidak, temukan cara lain. Ujung bawah h/w, atau 2 mesin di setiap meja.

2
quickly_now

Macbook Pro saya di tempat kerja sudah berumur beberapa tahun. Antara Linux dan Windows (untuk menguji IE quirks) vms serta beberapa browser dan terminal terbuka, roda pemintalan OSX banyak muncul. Tebak apa yang saya lakukan ketika berputar, saya duduk dan tunggu, dalam hal ini, mesin lambat memang memperlambat produktivitas.

2
Thierry Lam

Saya mengatakan pengembang membutuhkan sistem pengembangan terbaik yang tersedia - tetapi itu tidak berarti yang tercepat. Ini mungkin berarti sistem modern namun relatif lambat dengan pendingin pasif, untuk menjaga kebisingan seminimal mungkin, misalnya.

Satu hal - sistem pengembangan harus cukup baru, dan harus mutlak memiliki banyak inti.

PC lama mungkin terdengar menarik dengan cara pertunjukan-kinerja-masalah-cara awal, tetapi Pentium 4, misalnya, sebenarnya mungkin lebih cepat (per inti) daripada beberapa chip saat ini. Apa itu artinya dengan membatasi pengembang untuk menggunakan sistem P4 (sebenarnya apa yang saya gunakan sekarang - meskipun itu masalah penganggaran pribadi saya) ...

  1. Anda mendorong pengembangan perangkat lunak non-konkuren yang tidak akan mendapat manfaat dari sistem multi-core mainstream saat ini.
  2. Bahkan jika perangkat lunak multi-thread dikembangkan, bug mungkin tidak diperhatikan (atau setidaknya tidak diketahui lebih awal) karena masalah yang terkait dengan konkurensi mungkin tidak muncul dalam pengujian pada sistem inti tunggal.
  3. Perangkat lunak multi-utas dapat menyebabkan masalah kinerja serius yang mungkin menjadi lebih buruk dengan prosesor multi-inti. Seseorang akan menyebabkan disk head disk (yang dapat mengakibatkan ribuan kali lebih lambat akses ke data) di mana masing-masing thread melakukan akses sekuensial, tetapi masing-masing ke bagian disk yang berbeda. Ini bahkan dapat hilang pada PC lama yang lebih lambat, misalnya dengan memiliki dua drive 160GB yang lama alih-alih satu drive 1TB, utas tersebut mungkin tidak lagi saling bertikai untuk akses ke disk yang sama.

Ada juga masalah dengan PC yang terlalu terbatas untuk mendukung mesin virtual dengan baik - mis. untuk pengujian di berbagai platform.

1
Steve314

Jawabannya ada di tengah.

Memiliki satu kotak cepat untuk menjalankan lingkungan dev (mis Eclipse)

Dan kotak lambat lain untuk menguji output. Ini sangat penting untuk aplikasi web.

Layar berdampingan, satu untuk setiap kotak.

Jika kode dapat diterima di kotak output, itu akan lebih dari dapat diterima oleh sebagian besar pengguna.

Kotak dev cepat membuat programmer malas. Misalnya, mencari elemen di DOM setiap kali dibutuhkan. Temukan sekali dan simpan hasilnya.

Anda akan benar-benar melihat perbedaan pada kotak lambat yang menjalankan IE 6 ....

1
David Semeria

Teori ini berpikiran sederhana dan kedaluwarsa. Memang benar kembali pada hari-hari.

Saya ingat menghabiskan lebih banyak waktu mengoptimalkan mikro Pascal Turbo saya di komputer pra-Pentium saya. Masuk akal sebelum Y2K, apalagi sejak itu. Saat ini Anda tidak mengoptimalkan perangkat keras berusia 10 tahun. Cukup untuk menguji perangkat lunak untuk menemukan kemacetan. Tetapi karena semua orang di sini maju, ini tidak berarti pengembang (dan dengan demikian optimasi) berkorelasi dengan memberi mereka perangkat keras yang ketinggalan zaman untuk pengembangan.

1
mario

1) Jika saya memberi pengembang mesin yang lebih lambat, apakah itu berarti kode yang dihasilkan mungkin lebih cepat atau lebih efisien?

Tidak. Pengembang yang Baik dimanjakan. Jika mereka melihat mereka mendapatkan alat yang buruk di perusahaan Anda, mereka akan bekerja di tempat lain. (Pengembang yang baik biasanya memiliki pilihan untuk pergi ke tempat lain)

1

Bukankah jawaban untuk pertanyaan ini adalah "TIDAK" yang independen dari siapa pun yang Anda tanyakan?

Tanyakan seniman grafis Anda apakah mereka harus diberikan mesin yang lebih lambat.

Tanyakan penulis Anda apakah mereka akan memilih mesin yang lebih lambat daripada yang lebih cepat.

Tanyakan kepada asisten administrasi Anda apakah mereka lebih suka mesin yang lebih lambat atau lebih cepat.

Mereka semua akan mengatakan mereka akan lebih produktif dengan mesin yang lebih cepat.

1
Barry Brown

Saya hanya bisa membayangkan pengalaman profil saat menggunakan mesin lambat. Astaga.

Pendeknya. Tidak.

Juga memiliki setidaknya 4gb ram sehingga Anda dapat memiliki 2gb pada mesin utama Anda, 1 untuk VM dan 1 lainnya untuk memori tambahan kebutuhan VM kebutuhan dan bagi Anda untuk memiliki kelonggaran memori.

Juga dua prosesor adalah suatu keharusan jadi jika aplikasi mengunci/memakan CPU, pengembang tidak perlu dengan susah payah cara ctrl-alt-del sesuatu.

0
user2528

Mari kita melawan arus di sini: YA. Atau setidaknya itu sudah menjadi kebijaksanaan umum dalam industri selama beberapa dekade (kecuali tentu saja di antara pengembang, yang selalu marah ketika mereka tidak diperlakukan seperti bangsawan dan mendapatkan gadget dan komputer terbaru).

Tentu saja ada titik di mana mengurangi mesin pengembang akan menjadi merugikan bagi kinerja karyanya, karena menjadi terlalu lambat untuk menjalankan aplikasi yang harus dijalankan untuk menyelesaikan pekerjaannya. Tetapi poin itu jauh dari komputer $ 10.000 + dengan 6GB RAM, 2 kartu video 4GB, kartu suara kelas atas, 4 layar, dll.

Saya di pekerjaan tidak pernah memiliki mesin kelas atas, dan itu tidak pernah memperlambat saya selama itu layak (dan beberapa mesin sub-standar nyata dengan cepat diganti ketika saya menunjukkan bagaimana mereka memperlambat saya).

0
jwenting

Kecepatan run-time pada mesin pengembang sangat tidak relevan, kecuali jika Anda ingin membalas dendam atau menghukum pengembang Anda karena menulis kode lambat dan karena ketidaktahuan lingkungan penyebaran target.

Sebagai manajer, Anda harus memastikan pengembang tahu tujuan proyek dan selalu memastikan mereka berada di jalurnya. Tentang masalah mesin target yang sedang kita diskusikan, itu bisa dicegah dengan pengujian awal dan sering pada mesin lambat, bukan dengan memberi mereka mesin lambat untuk digunakan dan menderita.

Kecepatan run-time yang lambat juga memperlambat pengembangan, karena kebanyakan programmer menggunakan metode kode-dan-uji. Jika run-time lambat, tugas mereka juga akan lambat.

0
tia