Bagaimana tim pengembang dapat mencegah kinerja lambat dalam aplikasi konsumen?


32

Ketika saya sebelumnya bertanya apa yang bertanggung jawab untuk perangkat lunak lambat, beberapa jawaban yang saya terima menyarankan itu adalah masalah sosial dan manajemen:

Ini bukan masalah teknis, ini masalah pemasaran dan manajemen .... Tepatnya, manajer produk bertanggung jawab untuk menulis spesifikasi untuk apa yang seharusnya didapatkan pengguna. Banyak hal yang bisa salah: Manajer produk gagal untuk menempatkan tombol respons di spec ... Orang-orang QA melakukan pekerjaan pengujian yang biasa-biasa saja terhadap spec ... jika manajemen produk dan staf QA semua tertidur di belakang kemudi, kami programmer tidak bisa menebusnya. - Bob Murphy

Orang-orang bekerja di aplikasi berukuran besar. Saat mereka bekerja, masalah kinerja merayap masuk, seperti halnya bug. Perbedaannya adalah - bug "buruk" - mereka berteriak "temukan aku, dan perbaiki aku". Masalah kinerja hanya duduk di sana dan semakin buruk. Pemrogram sering berpikir "Yah, kode saya tidak akan memiliki masalah kinerja. Sebaliknya, manajemen perlu membelikan saya mesin yang lebih baru / lebih besar / lebih cepat." Faktanya adalah, jika pengembang secara berkala hanya mencari masalah kinerja ( yang sebenarnya sangat mudah ) mereka bisa membersihkannya. - Mike Dunlavey

Jadi, jika ini merupakan masalah sosial, mekanisme sosial apa yang dapat dilakukan organisasi untuk menghindari pengiriman perangkat lunak yang lambat kepada pelanggannya?


2
Ini mengingatkan saya pada posting blog baru-baru ini oleh Jeff Atwood .
rahmu

2
Komentator: jika Anda suka pertanyaannya, pilih suara itu. Jika Anda punya jawaban, silakan tinggalkan itu sebagai jawaban , bukan komentar. Jika tidak, silakan hanya memberikan komentar jika Anda merasa pertanyaannya diklarifikasi atau ditingkatkan, atau jika Anda memiliki tautan ke sumber terkait.

Jawaban:


34

Dengan persyaratan tertulis dan lengkap yang benar, tidak ada perbedaan antara bug dan kinerja buruk . Karena Anda menentukan kinerja sebagai persyaratan non-fungsional, kinerja yang buruk menjadi bug seperti bug lainnya, dan akan ditangkap oleh QA dan diselesaikan oleh pengembang sebelum dirilis.

Apakah ada masalah sosial? Saya kira tidak. Masalah utama adalah bahwa persyaratan tidak lengkap. Bekerja selama bertahun-tahun sebagai freelancer, saya tidak pernah melihat persyaratan non-fungsional yang mengatakan bahwa tugas tertentu harus dilakukan dalam rata-rata N detik maksimum . Jika manajer / pelanggan / pemangku kepentingan atau apa pun tidak peduli tentang aset kinerja, mengapa saya, sebagai pengembang, akan peduli tentang hal itu, karena orang yang harus peduli akan hal itu tidak peduli sama sekali?

Ada faktor lain yang mempengaruhi kinerja yang buruk: fakta bahwa pengembang bekerja pada PC mahal yang berkinerja baik . Ketika Anda bekerja selama bertahun-tahun pada PC quad-core dengan 8 GB RAM, SSD kelas atas, OS terbaru, dll., Sangat sulit untuk membayangkan bagaimana aplikasi Anda akan berjalan pada Windows XP pada PC dual-core dengan RAM 512 Mo dan hard disk lama terisi 90% dan tidak didefragmentasi selama bertahun-tahun. Sayangnya, di beberapa negara, kasus terakhir adalah kasus yang kami lihat untuk sebagian besar konsumen aplikasi. Semakin besar kesenjangan antara PC pengembang dan PC konsumen, semakin rumit bagi pengembang untuk menjaga kinerja aplikasinya.


2
Menyokong komentar ini, saya pikir cara terbaik untuk memastikan bahwa setidaknya devs (dan penguji) sangat menyadari masalah ini adalah dengan membuat mereka SELALU menguji pada perangkat yang lebih tua, ujung bawah persyaratan perangkat keras atau Mesin Virtual. . Sebagai seorang dev, sulit bagi saya untuk mengatakan kata-kata ini, tetapi beberapa kali kita tidak bekerja untuk memperbaiki masalah sampai kita mengalaminya sendiri. Oleh karena itu, setidaknya memaksa pengembang Anda untuk menguji aplikasi mereka pada sistem sub-par akan memaksa mereka untuk menemukan solusi yang efisien karena kinerja buruk yang mereka alami secara langsung.
RLH

3
Saya tidak akan menyarankan itu setiap hari, karena itu akan mengurangi kinerja keseluruhan departemen QA dan menekan karyawan yang bekerja pada mesin lambat. IMHO, menempatkan metrik kinerja sebagai persyaratan sudah cukup, jika ditentukan dengan benar (yaitu pada mesin apa tes kinerja otomatis harus dilakukan, dengan beban apa, berapa kali untuk mengambil rata-rata, dll.).
Arseni Mourzenko

1
Saya bekerja dengan persyaratan yang memiliki persyaratan kinerja formal (tidak fungsional). Ini adalah perangkat lunak penting dalam kehidupan nyata. Spesifikasi adalah "respons dalam x rata-rata, dan y 95% dari waktu". Perangkat lunak ini masih lambat dibandingkan dengan apa yang bisa terjadi, tetapi kita tahu kapan harus meningkatkan kinerja karena itu menjadi cacat, sama seperti hal lain yang dilakukan sistem secara tidak benar. Meninggalkan pengembang untuk memutuskan adalah ide yang sangat sangat buruk. Sebagian besar pengembang, dibiarkan perangkat di sana sendiri, lebih dari insinyur dalam segala hal, dan triply dengan masalah kinerja.
mattnz

3
Masalah lain dengan kinerja adalah Anda tidak dapat menguji kinerja pada apa pun kecuali sistem yang sepele sampai integrasi akhir selesai, seringkali lama setelah pengembang perangkat lunak menyelesaikan pekerjaan mereka. Ambil aplikasi telepon - berfungsi dengan baik pada telepon baru pabrik tanpa tulang yang mengkilap, karena beberapa aplikasi yang diunduh dan memori penuh, dan pengembang perangkat lunak disalahkan karena menulis perangkat lunak jelek ......
mattnz

2
Masalahnya di sini adalah, Anda TIDAK PERNAH mendapatkan "persyaratan yang ditulis dengan benar dan lengkap". Tidak pada aplikasi dengan ukuran atau kompleksitas apa pun.
CaffGeek

12

Masalah(?):

  • Pelanggan (atau pengguna akhir) tidak mengeluh tentang hal itu (cukup)
  • Dengan demikian manajer proyek (/ produk) tidak menganggapnya sebagai persyaratan
  • Dengan demikian pengembang tidak mendapatkan waktu untuk memperbaikinya.

Anda harus mulai dari awal, mendidik pelanggan. Tetapi jika mereka membeli iPhone alih-alih ponsel yang lebih cepat, lebih sedikit mengkilap, para pengembang berhak untuk menghabiskan waktu mereka pada penampilan alih-alih kinerja. Organisasi bukanlah masalahnya.

Tentu saja, beberapa hal dapat membantu. Menunggu tes otomatis menjengkelkan, jadi jika Anda memiliki tes otomatis, pengembang memiliki umpan balik yang konstan tentang masalah kinerja, dan mereka akan lebih cenderung menyelesaikannya (sebagai masalah teknis, bukan sebagai fitur).

Tapi kamu tidak bisa melakukan semuanya. Ini mengoptimalkan atau menambah fitur, dan mereka yang menghabiskan uang memutuskan.

Tetapi beberapa kabar baik: Saya perhatikan bahwa aplikasi SaaS / Cloud / Buzzword banyak membantu di sini. Ketika orang memilih di antara beberapa aplikasi web yang serupa dan dapat menguji secara langsung alih-alih membuat daftar buatan fitur 'yang diperlukan', mereka lebih cepat dipengaruhi oleh daya tanggap, dan dengan demikian kinerja akan mendapat lebih banyak perhatian.


Saya tahu betul, hanya memberi waktu +1
mKorbel

8

Sayangnya, saya menemukan masalah terbesar adalah Anda tidak bisa melakukan semuanya. Anda memiliki tanggal pengiriman, dan Anda tahu itu lambat, tetapi Anda PERLU untuk mendapatkan fitur X, Y, Z keluar ke pasar.

Dalam pikiran Anda, lambat Anda dapat memperbaikinya nanti, tetapi aplikasi setidaknya berfungsi.

Jadi, Anda khawatir tentang fungsi dan estetika (karena pengguna sering fokus pada estetika). Rilis berikutnya Anda akan memperbaiki kinerja.

Tetapi PM hanya memberi Anda daftar Fitur, dan tidak ada waktu untuk memperbaiki kinerja.

Dan lingkaran setan berlanjut.


3
Ini hanya diperbaiki ketika PM memberi Anda "fitur" bernama "peningkatan kinerja"!
FrustratedWithFormsDesigner

4
Pada saat PM ingin meningkatkan kinerja, satu-satunya cara nyata untuk melakukannya adalah menulis ulang :)
Ayub

Poin kunci di sini adalah bahwa untuk sebagian besar aplikasi konsumen, kinerja bukanlah fitur yang menjual perangkat lunak. Ini bukan sesuatu yang terlihat mengkilap di daftar periksa "Hal-hal yang dilakukan perangkat lunak ini." Game komputer adalah contoh cemerlang dari pemikiran ini. Persyaratan sistem untuk game terus meningkat dari waktu ke waktu, artinya game baru lebih lambat dengan perangkat keras yang sama dengan yang Anda miliki sebelumnya, karena framerate yang lebih tinggi tidak akan memindahkan kotak itu dari rak, tetapi lingkungan yang realistis ditampilkan secara real time dengan detail fraktal. akan ...
Maleakhi

1
+1 Di sinilah sangat membantu memiliki pesaing dengan kinerja yang baik. Ketika PM melihat itu, mereka menjadi takut, dan meminta Anda untuk melakukan sesuatu tentang hal itu.
Mike Dunlavey

1
@ Chad, probabilitas bersyarat tinggi, tetapi absolutnya rendah. Saya bekerja pada aplikasi yang dimulai sebagai program C 16-bit untuk versi Windows "hampir setelah saya dilahirkan". Fast-forward untuk hari ini dan bertahun-tahun dan banyak programmer kemudian Anda telah mendapat campuran C, C ++, C #, VB.Net dan banyak vendor SQL. Menulis ulang beberapa bagian penting dari aplikasi di F # tidak terdengar seperti ide yang buruk sekarang ...
Ayub

4

Saya setuju dengan yang lain, bahwa kita harus menemukan cara untuk membuat pengembang lebih peduli tentang masalah, seperti membuat mereka menguji pada perangkat keras yang lebih lambat, dan memiliki tujuan kinerja. Itu semua baik-baik saja, tapi sungguh, ketika datang ke penyetelan kinerja -

Orang Harus Tahu Bagaimana - Dan Mereka Tidak Tahu

Mereka mungkin berpikir begitu, tetapi lihat saja semua pertanyaan dan jawaban terkait kinerja di StackOverFlow dan di forum ini. Sungguh menyakitkan berapa banyak yang menunjukkan sedikit akal sehat tentang kinerja.

Ini bukan sesuatu untuk dibicarakan, orang perlu belajar dengan melakukannya . Satu-satunya waktu mereka dalam mode itu adalah ketika mereka mengambil kelas, atau belajar hal-hal baru dari buku atau blog.

Jadi satu-satunya cara saya dapat memikirkan untuk menyelesaikan masalah ini adalah dengan menghubungi orang-orang yang mengajar pemrograman, dan mengajari mereka cara melakukannya.

Tuhan tahu, saya sudah mencoba di forum ini, seperti di -

Siapa pun bisa melakukannya. Mereka hanya perlu melakukannya .


4

Jadikan kinerja sebagai persyaratan.


+1: Sesederhana itu. "Fungsi X harus selesai dalam Y milidetik".

jangan lupa untuk menentukan lingkungan di mana ia akan dijalankan - misalnya, kami memiliki NFR yang akan dilakukan untuk standar ketika dijalankan pada jaringan dengan latensi 40ms (yaitu WAN). Jika Anda tidak, para devs akan menyajikan sesuatu yang hanya berfungsi baik pada superkomputer.
gbjbaanb

2

Menulis kode performan sulit. Ini membutuhkan pemahaman yang kuat tentang konsep-konsep seperti threading, penanganan peristiwa yang tidak sinkron, caching, dan kompleksitas asimptotik. Dilihat oleh kelompok pemrogram yang telah bekerja dengan saya, sekitar 20-40% dari kelompok mana pun tidak cukup memahami konsep-konsep itu untuk memasukkan pertimbangan kinerja sebagai hal yang biasa dalam pekerjaan sehari-hari mereka.

Namun, para programmer itu jelas masih berguna bagi perusahaan, tetapi mereka ditugaskan untuk tugas-tugas yang tidak dianggap sebagai kinerja kritis, sehingga Anda berakhir dengan pemutar blu ray yang dapat memutar stream Netflix dengan sempurna tanpa menjatuhkan frame apa pun, tetapi dibutuhkan 30-60 detik untuk membuka item menu yang menampilkan antrian Anda.

Kecuali jika Anda adalah perusahaan perangkat lunak terkemuka yang mampu memecat 20% staf Anda dan menggantinya dengan pengembang yang lebih berpengalaman (dan lebih mahal), satu-satunya cara nyata untuk memperbaikinya adalah pelatihan pengembang dan melaporkan laporan bug. Saya tidak tahu bagaimana keadaannya di perusahaan lain, tetapi di sini jika kami pengembang melihat masalah kinerja yang kami tidak punya waktu atau prioritas bisnis untuk diperbaiki, kami sepenuhnya berhak untuk mengajukan laporan bug kami sendiri tentang hal itu. Mungkin diperlukan beberapa rilis untuk mencapai puncaknya, tetapi biasanya mereka akhirnya ditanggapi.


Selain itu, bahkan programmer yang hebat membutuhkan instrumentasi dan alat profil yang bagus untuk mendapatkan wawasan tentang masalah kinerja. (Ada banyak paradigma pemrograman dengan karakteristik kinerja yang menentang analisis tumpukan jejak.) Alat-alat ini umumnya tersedia untuk platform Linux dalam gaya open-source, tetapi dalam platform eksklusif dan kustom, alat-alat ini sering ditolak untuk karyawan.
rwong

Saya tidak setuju dengan sentimen yang diungkapkan. Mendapatkan perf maksimal bisa sangat sulit, tetapi sering kali ada banyak buah gantung rendah yang bisa didapat. Jadi lakukan saja profil sederhana (mungkin teknik yang disarankan Mike Dunlavey di atas), dan cobalah untuk memperbaiki masalah yang sudah jelas. Seringkali itu akan berpengaruh besar.
sleske

2

Jika kinerja merupakan persyaratan, uji untuk itu.

Kalau tidak, Wally dapat menulis infinite loop dan pergi lebih awal, "Butuh beberapa saat." Dia bisa mengklaim.

Tes penerimaan perangkat lunak Anda harus memiliki uji penerimaan terperinci untuk berbagai karakteristik kinerja operasi.

Jika Anda tidak melakukan ini, Anda tidak merekayasa kinerja apa pun ke dalam produk.

Kinerja (seperti konsumsi sumber daya) harus dianggarkan untuk sub-sistem. Kemudian tes penerimaan sub-sistem dapat memeriksanya.

Kemudian Anda dapat menguji lebih awal dan sering untuk kinerja. Bahkan unit test kemudian dapat memeriksanya.

Jadi sekarang pengembang memilikinya sebagai kriteria penerimaan, dan dapat mengatur pendekatan mereka sesuai dengan itu.

Di tempat saya bekerja sekarang, tes stres kinerja 2x lebih besar dari kumpulan data pelanggan yang kami ketahui. Ini secara teratur merusak versi produk yang baru. Pengujian yang bagus.


2

Saya ingat suatu kali di pertengahan tahun 90-an dan saya meluangkan waktu untuk mencoba mengoptimalkan sesuatu dan seorang rekan kerja mengatakan kepada saya, "Ini dijalankan pada pentium, siapa yang peduli?" .... itu adalah pembuka mata. Sayangnya, itu hanya puncak gunung es, saya telah mendengar bahwa sikap sepanjang karir saya - meskipun bagian "pentium" telah berubah dari waktu ke waktu.

Satu-satunya cara untuk mendapatkan pengembang rata-rata untuk peduli adalah untuk mendapatkan kurangnya kinerja untuk dilihat sebagai bug pada bagian dari pelanggan. Tergantung pada aplikasi dan audiensnya, ini bisa menjadi tugas yang mudah atau sulit (saya telah melihat keduanya). Jika audiens tidak peduli dengan kinerja yang buruk, pengembang tidak akan pernah (cepat, bagus, cepat - pilih dua).


2

Tetapi tidak seharusnya mengambil surat dari QA untuk seorang programmer untuk menyadari bahwa jeda 3 detik antara penekanan tombol dan respons tidak dapat diterima

Setuju tidak seharusnya. Perlu lebih dari itu: bukti bahwa jeda yang diperoleh relevan untuk pengguna akhir .

Karena Anda tidak menyediakan konteks, sangat mungkin bahwa kelambatan dalam lingkungan dev / QA disebabkan oleh masalah lokal mereka dari akses disk / memori / jaringan lambat. Jika itu masalahnya, QA dan dev Anda hanya akan menyia-nyiakan upaya mereka memperbaiki hal-hal yang tidak penting bagi pengguna akhir.

Mengandalkan pengembang dalam pengujian kinerja adalah sama produktifnya dengan menggulirkan dadu untuk memilih bagian dari fungsionalitas untuk mempercepat. Oh dan ini bisa diandalkan - "pengembang umumnya memiliki intuisi yang mengerikan tentang di mana masalah kinerja dalam aplikasi sebenarnya" ( Brian Goetz ).

  • Saya pernah berada di sebuah proyek di mana manajemen lumpuh pernah memutuskan orang-orang pemasaran yang cerdas dan programmer pintar cukup baik untuk menangani masalah kinerja pelanggan. Pelajaran yang luar biasa. Ditolak keluar, upaya setengah tahun berlalu ke tempat sampah, dan perusahaan hampir kehilangan mitra strategis. Pada akhirnya, mereka mengundang para profesional (ahli dalam benchmarking, statistik, UX, optimasi tingkat rendah, hal-hal seperti itu) dan para profesional memperbaiki kekacauan itu.

haruskah semua programmer melakukan QA mereka sendiri sehingga mereka segera melihat masalah seperti itu?

Fakta bahwa itu bisa dilakukan bukan berarti itu cara untuk pergi. Sebaliknya - dalam pengalaman saya ini adalah salah satu cara yang paling dapat diandalkan untuk kehilangan produktivitas programmer . Hampir sama baiknya dengan pertemuan tanpa akhir dan bahkan lebih baik daripada mewawancarai kandidat.

  • Sebagai seorang mantan tester, saya pernah berpikir seharusnya tidak menjadi masalah untuk menggabungkan pengembangan dan aktivitas QA. Sepertinya perbedaan antara pengujian dev rutin dan QA sistematis tidak akan terlalu menjadi masalah. Saya pikir pemisahan dev / QA hanyalah sebuah tradisi dalam industri perangkat lunak. Belajar agak sulit bahwa ini tidak benar. Pemisahan ternyata menjadi masalah fokus dan produktivitas, dan cukup serius.

Jika ada masalah kinerja, beri saya patokan dan tetapkan target kinerja dan saya akan melakukan yang terbaik untuk mendapatkannya. Saya tidak begitu bagus dalam pengujian kinerja tetapi tahu sedikit atau dua tentang optimasi.


downvoter - apakah itu terjadi pada Anda untuk bekerja dengan penguji profesional yang mencakup kebutuhan tim pengembang di QA dan dalam pengujian kinerja? Jika tidak, pertimbangkan memberikan mencobanya
nyamuk

1

Saya pikir Anda akan menemukan bahwa 99% dari waktu masalahnya adalah ruang lingkup creep. Dengan dvr misalnya. Anda akan berpikir ini mudah tetapi TIVO atau pesaing memperkenalkan fitur baru yang diterima dengan baik. Hal berikutnya yang Anda tahu fitur baru ada di piring. Ini mungkin atau mungkin tidak kompatibel dengan produk yang ada dan kami tidak mengulangi produk yang sudah ada yang akan membutuhkan waktu lama. Jadi fitur macet dan itu menyebalkan kinerja. Tentu data ada di sana untuk mendapatkan informasi tetapi jika tidak ada pemikiran untuk mendapatkan informasi itu maka ada peluang bagus itu tidak akan mudah didapat. Jadi sekarang memiliki proses yang kompleks untuk membangun informasi itu setiap kali Anda pergi dekat daftar program.


1

Mengabaikan pengembang yang tampaknya tidak peduli ...

Saya berpikir bahwa sering kali pengembang yang bekerja pada kode tidak memiliki alat untuk mengukur kinerja secara terus menerus.

mis. Jika mungkin untuk mengukur waktu respons untuk aplikasi Anda (mis. ini adalah aplikasi berbasis web, atau query database, dll.) - Apakah Anda saat ini mendapatkan notifikasi (email, SMS, apa pun) yang mengindikasikan "top 10" terburuk melakukan (atau melebihi ambang batas yang ditentukan) tanggapan?

Dalam banyak, banyak kasus - pengembang tidak mendapatkan info ini dari penyebaran "dunia nyata" dan akibatnya sangat mudah untuk mengabaikan informasi yang tidak Anda lihat.

Namun, jika setiap hari / beberapa jam Anda mendapatkan email yang menunjukkan bahwa layar "x" memerlukan 13 detik untuk memuat dan menjalankan kueri SQL berikut, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...Anda sebaiknya percaya bahwa pengembang dapat (dan semoga akan) menyelesaikan semua perbaikan saya t.

Jadi, meskipun saya ingin percaya bahwa semua programmer benar- benar memperhatikan kinerja, saya pikir kurangnya visibilitas terhadap masalah seringkali menjadi penyebabnya.

Catatan: Saya pikir ini adalah sesuatu yang kedua pengembang harus meminta akses ke (atau bahkan mengembangkan fitur seperti itu) dan manajemen harus menyediakan / mendanai alat tersebut.


1

Bisakah Anda memberikan contoh yang lebih baik di mana kita bisa menyalahkan programmer? Terlepas dari Eclipse, dan satu komentator telah menunjukkan bahwa itu adalah plugin yang melakukannya (instalasi pertama saya untuk setiap versi Eclipse baru berjalan seperti kilat, tetapi ketika saya menambahkan alat lain itu mulai melambat), contoh Anda mungkin bukan programmer dan kode terkait tetapi terkait lingkungan.

Hari-hari menjalankan program pada komputer secara terpisah dan menentukan apakah itu 'cepat' atau 'lambat' hilang. Contoh lain yang Anda berikan bergantung pada lingkungannya - kemacetan jaringan saat ini, apakah server back end kelebihan beban, kartu jaringan yang dikonfigurasi dengan buruk, kabel yang salah, jumlah orang lain yang menggunakannya di sekitar Anda, atau ratusan variabel lainnya. misalnya. penyedia hosting kami membebankan biaya tambahan untuk koneksi server gigabit tetapi akhirnya kami menentukan semuanya melalui perangkat firewall kuno dengan port 10MB. Masalah-masalah ini bergeser dan sulit ditemukan.

Setuju, ada banyak hal yang bisa dilakukan oleh pemrogram (meminimalkan bandwidth, trik UI yang meningkatkan daya tanggap dan menunjukkan kemajuan untuk memberi kesan itu cepat). Tetapi ketika Anda memasuki dunia nyata, ada segala macam keadaan yang hanya Anda pelajari berdasarkan pengalaman (dan Anda melihat asumsi Anda berantakan di depan Anda).


Contoh yang saya berikan adalah semua kasus di mana kinerjanya buruk di lingkungan yang murni lokal - DVR hanya menavigasi menu program yang direkam secara lokal. iTunes lambat hanya menelusuri data lokal, tidak melihat toko. Bahkan dalam "mode pesawat" - tidak ada jaringan apa pun - iPhone 3G membutuhkan waktu lama untuk menampilkan foto sehingga terkadang pengawas OS akan mematikan aplikasi sebelum dapat diluncurkan. Semua ini adalah contoh kasus di mana programmer tahu persis perangkat keras apa yang mereka targetkan ketika mereka menulis kode, dan iPhone terutama karena semakin buruk dengan setiap pembaruan.
Crashworks

@ Crashworks - seseorang telah menghapus contoh-contoh itu dari pertanyaan Anda. Bisakah Anda menambahkannya lagi dengan detail? Contoh foto terdengar seperti sesuatu yang sedang terjadi, seperti ketergantungan yang hilang atau sedang mencoba mencari sesuatu di internet dan waktu habis. Sudahkah Anda menjalankan debug untuk melihat apa yang terjadi? Sebuah cerita yang bagus adalah ketika MS merilis HyperV, reviewer VMWare dengan gembira menunjukkan bahwa meskipun ia menginstalnya sehari setelah dirilis, ia harus mengunduh banyak pembaruan Windows. Mengapa? proses aktivasi HyperV menggunakan kembali IE8 dll. Ada banyak gotcha di lingkungan modern.
jqa

1

Berapa yang Anda bayarkan untuk perangkat lunak yang lebih baik? Berapa pasar akan menunggu perangkat lunak yang lebih baik? Berapa sedikit cruft yang ingin ditambahkan ke rilis berikutnya?

Ini adalah pasar yang sulit di mana ada banyak kompromi dibuat. Jika benar-benar omong kosong maka pasar akan (atau harus) gagal produk. Mungkin ada cukup banyak pelanggan yang bisa hidup dengan status-quo?


0

Saya pikir jawaban paling umum untuk masalah ini juga yang paling sulit untuk dikelola, yaitu bahwa setiap programmer harus memperhatikan kinerja dengan apa pun yang mereka lakukan. Saya menyadari juga bahwa itu sedikit keluar polisi.

Tergantung pada ukuran proyek, dan tim yang sesuai, saya percaya akan ada banyak nilai dalam memiliki pemrogram kinerja yang berdedikasi.

Sebagai contoh, saya telah bekerja pada sebuah tim di mana tim proyek (termasuk sekitar 30 devs) memiliki setidaknya 2 orang yang didedikasikan untuk optimasi kinerja. Aplikasi khusus ini juga cukup rentan terhadap masalah kinerja karena ada banyak komponen interoperabilitas, tidak hanya melalui layanan web tetapi juga dalam hal lapisan warisan dengan berbagai pemetaan data dan komponen adaptor.


0

Pengalaman langsung itu penting. Berikan pengembang komputer yang cepat untuk dikompilasi dan dibangun, tetapi komputer yang kelebihan beban sangat lambat (seperti yang mungkin dimiliki sebagian pengguna) untuk menjalankan aplikasi mereka. (Ini dapat dilakukan di lingkungan pengembangan berbasis cloud / server dengan mempartisi VM atau server berdasarkan fungsi.) Beri mereka ponsel dengan baterai setengah mati, dan minta mereka menggunakannya hanya untuk hari-hari awal pengujian aplikasi seluler.

Jika pengembang berempati dengan pelanggan sehubungan dengan kinerja dan masa pakai baterai, maka mereka tidak akan menganggap kinerja sebagai beberapa spesifikasi manajemen semi-palsu untuk ditempatkan di bagian bawah daftar prioritas. (Seperti pada: "hei, saya pikir itu optimasi prematur" sampai terlambat.)


0

Berhentilah membeli barang-barang itu, dan berkomentar tentang kinerja buruk pada ulasan online yang Anda temui.

Jika perangkat masih menjual maka perangkat lunak "cukup baik" untuk tidak menginvestasikan lebih banyak waktu dan uang. Jika ulasan buruk tentang kinerja mengurangi penjualan secara signifikan maka perangkat lunak "tidak cukup baik" dan perlu diperbaiki.

Satu-satunya metrik yang menarik minat produsen barang konsumen adalah penjualan dan laba per unit.


0

Saya setuju bahwa programmer harus diajarkan lebih baik tentang memaksimalkan kinerja, dll

Tapi saya pikir solusinya adalah tidak memberikan programmer perangkat keras yang hampir mati untuk penggunaan sehari-hari. Betapa stresnya jika studio visual Anda crash dua kali sehari, butuh x detik untuk membangunnya, y detik untuk membuka solusinya, z detik untuk mengubah windows. Saya tidak berpikir itu sangat hemat biaya bagi perusahaan baik karena perangkat keras murah dan waktu programmer mahal.

Karena pihak berikutnya yang akan menangani kode adalah tim QA (pengujian), bukankah akan lebih baik untuk mengajarkan mereka tentang pentingnya kinerja, memiliki standar standar kinerja apa yang dapat diterima, dll sebagai standar perusahaan (baik, di dunia yang sempurna , standar kinerja harus spesifik tetapi itu tidak sering terjadi)? (mis. halaman / tab ee-ubah perusahaan reguler harus terjadi secara instan, "simpan pembaruan harus terjadi dalam x detik", jika itu adalah aplikasi penting maka ...). Komputer yang dijalankan oleh tim QA haruslah komputer pengguna biasa. (Kami tidak ingin membuat mereka kesal dengan memberi mereka 386, tapi jangan beri mereka quad core dengan ram 8GB misalnya). Tidakkah mereka akan curhat ke programmer jika mereka cukup kesal dengan kinerja?

Saya pikir klien / manajer proyek harus memaksa programmer / tim qa / pengembang / perwakilan tim perusahaan untuk melakukan presentasi mereka pada perangkat keras khas terendah yang mereka miliki. (komputer terlemah di perusahaan misalnya). Jika ditulis ulang, mereka perlu mengumpulkan data tentang seberapa cepat melakukan x proses pada perangkat lunak lama dan membandingkannya dengan seberapa cepat pada perangkat lunak baru (bisa lebih lambat, karena perangkat lunak baru mungkin melibatkan proses bisnis tambahan tetapi harus ada jendela yang dapat diterima).


-1

Saya sudah mengatakannya sebelumnya, tetapi saya akan mengatakannya lagi: Saya pikir salah satu cara terbaik untuk menangani ini adalah dengan hanya membuat pengembang Anda bekerja pada (relatif) trailing edge hardware.

Untuk programmer tipikal Anda, sebagian besar pertimbangan kinerja resmi hanya di urutan kedua: "Apakah itu mengganggu ketika saya mencoba menjalankannya?" Jika mereka merasa menjengkelkan, mereka (setidaknya akan mencoba) memperbaikinya. Jika mereka senang dengan cara kerjanya, yang terbaik yang akan Anda dapatkan adalah upaya setengah hati untuk memperbaikinya. Ini juga membantu dalam menemukan masalah sejak dini, sebelum menjadi lebih mahal untuk diperbaiki.

Jika sampai pada titik bahwa QA harus menegakkan aturan, pengembang benar-benar tidak percaya karena mereka berpikir kinerja memadai, kemungkinan cukup bagus bahwa sebagian besar "perbaikan" yang Anda dapatkan akan mendapatkan cara kreatif untuk menyelesaikan aturan, bukan perbaikan nyata yang meningkatkan kehidupan pengguna akhir.

Pada saat yang sama, saya harus menambahkan bahwa saya jarang melihat ini sebagai masalah. Jika ada, saya telah melihat pengembang menghabiskan terlalu banyak waktu mencoba untuk meningkatkan kinerja di mana saya benar-benar tidak cukup peduli untuk mengganggu (dosa yang saya sering bersalah juga).


1
Sangat mudah untuk jatuh ke dalam jebakan terobsesi pada hal-hal yang tidak penting, tetapi jika ponsel dikirimkan dengan UI yang sangat lambat sehingga panggilan masuk masuk ke voicemail sebelum tombol "Jawab" merespons, jelas seseorang gagal meningkatkan kinerja ketika hal itu terjadi. masalah.
Crashworks

4
Dalam hal ini perusahaan harus membelikanku pedang yang layak, karena aku akan menghabiskan sebagian besar waktuku untuk menyusun.
David Thornley

Setengah masalahnya adalah sulit untuk menguji pada mesin dev. Mesin-mesin pengembang cenderung besar dan cepat sehingga seorang pengembang mungkin tidak pernah melihat masalah. Sulit untuk memperbaiki sesuatu jika Anda tidak dapat melihat ukuran (dipengaruhi oleh) masalah apalagi bagaimana perbaikan Anda akan mengubah perilaku.
Martin York

7
Ini disarankan dalam komentar Slashdot (tentang sesuatu) tahun yang lalu. Tanggapannya adalah: "pengembang harus mengembangkan pada mesin cepat dan menguji pada yang lambat."
user16764

1
@ user16764: Seringkali terlalu sedikit perhatian diberikan untuk memberikan lingkungan uji pengembang yang berbeda dari lingkungan pengembangan mereka. Istri saya memiliki waktu yang sangat sulit untuk mendapatkan akun admin (untuk dikembangkan) dan akun yang lebih terbatas (untuk pengujian), dan sebelum itu memiliki masalah terus-menerus dengan tidak sengaja memasukkan sesuatu ke dalam perbaikan pemeliharaan yang tidak akan berjalan pada pengguna biasa rekening.
David Thornley
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.