Apakah programmer GUI memiliki keunggulan yang tidak semestinya dibandingkan yang lain?


23

Mudah bagi manajer dan pelanggan untuk menghargai apa yang dapat mereka lihat.

Saya telah melihat banyak pengembang GUI yang merupakan programmer rata-rata dengan pengetahuan minimal prinsip-prinsip desain atau idiom pemrograman lainnya. Namun, kekurangan ini sering tidak diperhatikan, khususnya oleh manajemen dan pelanggan, jika programmer dapat membuat antarmuka pengguna yang tampak mengesankan. Begitu banyak sehingga banyak pengembang GUI yang saya kenal menghabiskan waktu berjam-jam mempercantik GUI dengan mengorbankan penulisan kode yang buruk dan tidak dapat dipertahankan.

Di sisi lain, programmer tingkat menengah yang mengembangkan API atau fungsi bisnis atau kode basis data (SQL, dll.) Berada pada posisi yang kurang menguntungkan karena tidak ada yang nyata untuk ditampilkan. Mungkin peninjau kode atau arsitek mungkin menghargai keanggunan, desain yang bagus, skalabilitas dll dari kode tetapi tidak ada artinya bagi dunia luar. Kode Anda dapat berjalan selama bertahun-tahun tanpa melanggar, mungkin sangat mudah untuk mempertahankan dan memiliki kinerja yang baik, namun tidak pernah memunculkan 'wow' yang dilakukan oleh GUI yang apik.

Menurut pendapat saya, akibat dari ini adalah (dan saya akan sangat downvoted untuk ini, saya tahu) bahwa ada sedikit motivasi bagi seorang programmer GUI untuk menulis kode bersih yang baik.

EDIT : Saya harus menjelaskan di sini bahwa oleh programmer GUI, maksud saya bukan web / desainer GUI penuh tetapi programmer front-end misalnya, programmer java-swing.

Apakah anggota komunitas lainnya setuju?


6
Siapa yang harus menderita melalui permintaan pengguna 'konyol' untuk font, label, warna, dan memindahkan semuanya? Anda mengambil yang baik dengan yang buruk.
JeffO

@ Jeff O: Sangat benar. Tidak ada pengguna yang pernah mengkritik pilihan saya tentang berapa banyak memori yang dialokasikan untuk struktur data atau kolom mana dari tabel basis data yang akan diindeks.
dan04

2
Harus bekerja dengan tata letak (apakah Swing, GWT, HTML, CSS.) Adalah penyiksaan sehingga tidak harus berurusan dengan itu adalah keuntungan ...
Uri

@ dan04: Cobalah bekerja dengan pengguna ilmiah senior. Mereka senang menggunakan UI jelek dan akan menghabiskan waktu berabad-abad memperebutkan struktur basis data (biasanya dalam upaya untuk menjaga beberapa kesalahan lama yang tidak dapat dijelaskan karena skrip lama mereka memanfaatkannya). Grr…
Donal Fellows

Agak seperti perbedaan antara bassis dan sisa band. Mereka melakukan banyak pekerjaan impor di latar belakang tetapi tidak ada yang memperhatikan kecuali bassis lainnya.
Gordon

Jawaban:


21

Saya pikir saya mengerti maksud Anda, tetapi saya curiga ada masalah lain yang perlu dipertimbangkan.

Pada dasarnya, saya yakin Anda menyarankan itu, karena UI adalah elemen dari aplikasi 'in the face' dari pengguna akhir, pengembang UI menikmati visibilitas yang lebih tinggi daripada anggota tim yang bekerja di lapisan aplikasi yang lebih dalam.

Tentu saja saya setuju bahwa mungkin ada visibilitas yang lebih tinggi. Misalnya, pengembang yang bekerja pada elemen UI mungkin lebih sering berinteraksi dengan pengguna akhir (bisa dibilang, untuk alasan yang baik, karena mereka memang fokus pada aspek Interaksi Manusia / Komputer).

Namun, saya berpikir bahwa visibilitas yang lebih tinggi ikut berperan bahkan dalam kasus ketika ada masalah. Sebagai contoh, pengguna akhir sangat mungkin melaporkan masalah sebagai 'Masalah GUI' meskipun tidak.

Itu semua mungkin bermuara pada persepsi, dan organisasi yang matang harus dapat mengenali nilai-nilai, kebajikan dan kelemahan dari berbagai anggota tim secara terpisah dari lapisan aplikasi mana mereka bekerja. Organisasi yang matang mungkin juga telah bergerak melampaui perbedaan seperti 'pengembang UI' dan 'pengembang lapisan bisnis', mengakui bahwa mereka semua adalah anggota tim, mungkin dengan keahlian yang berbeda, tetapi selalu berusaha untuk saling mendidik tentang bidang keahlian tersebut.


1
Dan tidak seperti kebanyakan perusahaan mengambil survei pengguna untuk melihat siapa programmer terbaik.
JeffO

1
+1. Saya bekerja pada GUI, dan setiap kali ada 'masalah', itu mendarat di kotak masuk saya. Tanggung jawabnya adalah pada saya untuk 'membuktikan' bahwa sumber masalahnya berasal dari bawah. Pemrogram GUI juga harus menyulap 'kemurnian' API yang indah itu dengan kekacauan kebutuhan pengguna.
Benjol

10

Untuk seseorang yang tidak berurusan dengan programmer, saya dapat dengan yakin mengatakan bahwa mereka akan percaya hal-hal semacam ini. Mereka tidak tahu jumlah pekerjaan yang berjalan di latar belakang, yang mereka lihat hanyalah banyak tombol / kotak teks / menu / [masukkan elemen GUI] dan kecepatan yang diperlukan untuk mencapai apa yang dimulai tombol. Jadi pada awalnya, orang-orang GUI lebih disukai.

Jika orang tersebut memang berurusan dengan programmer, maka itu sedikit berbeda. Seperti yang Anda katakan, mereka akan perhatikan jika Anda membuatnya skalabel, lebih mudah dirawat, menulis ulang suatu algoritma sehingga lebih masuk akal, atau tugas jenis perawatan lainnya. Orang seperti ini akan memandang semua programmer dengan setara.

Di tengah tergantung pada apa yang Anda lakukan. Kecepatan kemudian menjadi faktor penting di sini. Jika Anda dapat menunjukkan sebelum dan sesudah rekaman berapa lama formulir diproses dan disimpan dan ada peningkatan, Anda sama. Jika Anda dapat menampilkan aplikasi yang sedang dimuat dari 100 klien dan menunjukkan kepada mereka peleburan server, dan kemudian menunjukkan kepada mereka versi Anda di mana semuanya baik-baik saja, sama dengan Anda. Dll


Singkatnya, itu tergantung pada orang tersebut dan apa yang Anda lakukan.


8
Sebagai seseorang yang baru saja menghabiskan 5 tahun terakhir atau lebih mengerjakan hal-hal infrastruktur (tumpukan SIP), +1 - kebanyakan orang tidak tahu apa yang Anda lakukan, dan tidak ada yang terlihat, selain sesuatu yang tidak berfungsi. Berapa banyak yang Anda pikirkan tentang pipa ledeng Anda ... sampai pecah?
Frank Shearar

6

Sebagai "pakar UI" di perusahaan saya (orang yang bertanggung jawab atas semua pengembangan UI, bukan hanya desain), saya pikir Anda mungkin kehilangan beberapa bagian dari cerita. Meskipun saya orang yang bertanggung jawab atas UI, saya juga mengerjakan back-end, pada database, dll. Saya melakukan semuanya (kami tim kecil). [Pengembangan C # dan ASP.Net WebForms]

Pertama-tama, ya itu jauh lebih mudah bagi orang-orang non-teknis untuk menghargai karya seorang pengembang GUI karena itulah yang ada di hadapan orang-orang. Untuk orang-orang non-teknis, GUI adalah aplikasi . Kekurangannya adalah bahwa GUI juga yang pertama disalahkan ketika terjadi kesalahan.

Yang kedua, mengembangkan front-end jauh lebih menantang bagi saya daripada back-end sebelumnya (selain algoritma yang tidak jelas / kompleks). Ada begitu banyak yang harus dijaga, ini stateless (aplikasi kami ada di Web), browser tidak berperilaku konsisten (perpustakaan JavaScript adalah anugerah), dll. Saya berharap sebagian besar kompleksitas ini disebabkan oleh kerangka yang saya miliki untuk bekerja dengan (ASP.Net WebForms) dan bahwa semua hal yang sulit tidak akan menjadi masalah di masa depan.

Secara keseluruhan, saya memiliki lebih banyak kesulitan untuk menyelesaikan masalah UI daripada masalah back-end.


5

Saya benci pengembangan GUI karena dua alasan,

  1. Saya lebih logis daripada artistik grafis dan sebagai hasilnya UI saya selalu menderita.
  2. Karena UI tidak didasarkan pada logika, unit test hampir tidak mungkin untuk menulis dengan makna apa pun

Namun, pada akhirnya, saya pikir kode saya akan lebih dihargai oleh pengguna akhir (sebagai lawan, mungkin untuk sponsor proyek), daripada pengembang biasa-biasa saja yang ahli di UI, karena umumnya berfungsi .


4

Untuk (mungkin) memperluas sedikit pada jawaban @ TheLQ, saya pikir itu juga tergantung pada "viewer".

Saya memiliki pengalaman dengan beberapa manajer / supervisor tingkat atas yang tidak memiliki latar belakang pemrograman. Beberapa menghargai bahwa mereka tidak memprogram, tetapi memahami bahwa chrome dan dop sama pentingnya dengan mesin dan sasis.

Dan saya sudah memiliki pengalaman dengan beberapa manajer / penyelia tingkat atas yang tidak peduli dengan metrik apa pun selain mendesis UI. Bahkan menyatakan bahwa lebih banyak pengembang berorientasi UI mana yang penting.

IMHO, kita semua tahu bahwa Anda tidak dapat memoles kotoran dan aplikasi yang cepat, andal namun jelek akan jauh lebih buruk daripada aplikasi yang keduanya terlihat bagus dan berfungsi dengan baik. Semuanya ada di mata yang melihatnya dan sampai batas tertentu, Anda memiliki kekuatan (terlepas dari apa yang Anda lakukan) untuk dilihat dalam cahaya yang Anda inginkan, dengan bekerja untuk mereka yang menghargai kualitas yang sama seperti Anda.

EDIT: Saya mungkin menambahkan, sebagai seseorang yang merasa lebih nyaman mengerjakan item tingkat rendah, saya telah letih ketika Anda bekerja sama kerasnya dengan tim UI dan itu adalah pemoles yang dipuji dalam demo dan bukan fakta bahwa sistem " baru saja bekerja ". Tapi seperti yang saya katakan, saya tahu bahwa atasan saya tahu pekerjaan diperlukan di semua bidang.


3

Saya pikir ada anggapan umum di luar sana bahwa pengembang UI adalah pengembang "junior". Saya hanya bisa memikirkan satu kasus dimana saya bertemu seorang pria UI yang dianggap senior.

Yang mengatakan, saya pikir UI jauh lebih sulit daripada bagian lain dari aplikasi kami. Dan saya tidak berbicara tentang desain UX, saya berbicara tentang pengkodean. Berapa banyak area lain yang kita kode di mana kita harus menghitung lusinan, jika tidak ratusan, atau skenario yang mungkin? Mengubah ukuran layar terkadang dapat menjadi masalah besar ketika Anda harus mencari tahu apa yang perlu terjadi dengan beberapa elemen. Ini terutama muncul ketika Anda memiliki pedoman yang mengatakan "kita perlu mendukung 800x600" dan kemudian desainer UX yang tidak pernah menggunakan apa pun selain resolusi HD.

Jadi, jika mereka mendapatkan lebih banyak kebaikan karena lebih banyak paparan, mereka mungkin layak mendapatkannya. Biasanya, mereka berada di ujung penerima yang salah lebih sering daripada penerima yang baik.


3

Tampaknya sering ada gagasan bahwa seorang programmer GUI ada di bagian bawah rantai programmer. Seberapa sulitkah untuk menarik & melepas tombol di VS ke formulir? Apa, Anda butuh seminggu untuk memprogram itu? Ini menggambar beberapa batang. Jadi saya tidak terkejut melihat ide bahwa programmer GUI, menjadi tombol seret seperti mereka, harus menulis kode yang mengerikan juga.

Pemrograman GUI memang memiliki beberapa tantangan unik. Multithreading untuk menjaga GUI aktif saat data dimuat. Ini mengarah ke utas kode aman dan tepat. Performa sangat penting. Tidak ada yang suka menunggu dua menit sampai mereka dapat mengendalikan aplikasi lagi. Penggunaan kembali juga menjadi masalah besar. Jika Anda harus menulis sepuluh layar yang sama, Anda sebaiknya menyusun kode dengan baik. Ini mengarah ke kode yang lebih baik. Dan tentu saja menciptakan GUI yang baik adalah tantangan tersendiri.

Tetapi bagi sebagian orang itu hanya akan menyeret tombol ke aplikasi Anda. Seperti halnya bagi sebagian orang, logika bisnis tidak lebih dari "parsing sebuah pesan dan masukkan ke dalam DB".


2

Saya pikir sudah jelas mereka melakukannya. Mungkin rumah-rumah dev terkemuka tidak dikecualikan, tetapi sebagian besar yang lain tidak.

Ketika manajer Anda bertanya kepada Anda apa yang telah Anda lakukan selama sebulan terakhir, mudah untuk menunjukkan GUI yang keren. Sulit untuk menampilkan API yang keren. Sangat keras. Kesejukan API hanya terlihat melalui penggunaan aktual - itu tidak bisa dihargai sekilas.


1

Anda bisa lolos dengan segala macam peretasan dan pintasan di sistem internal. Ketika berhadapan dengan GUI Anda tidak memiliki kebebasan itu. Api internal Anda mungkin memiliki inkonsistensi dan Anda hanya berharap coders untuk mengatasinya karena terlalu sulit untuk diperbaiki. Anda tidak dapat mencoba dan membuat pelanggan Anda melakukan hal yang sama. Jadi dalam beberapa hal, orang-orang yang harus berurusan dengan komponen yang terlihat oleh pengguna harus benar-benar mengikuti standar yang lebih tinggi.


1

Saya akan mengatakan ya, karena satu alasan sederhana: iPhone. Semua orang yang pernah saya ajak bicara berpikir itu fantastis karena antarmuka yang apik, tetapi saya hanya bisa membayangkan pekerjaan di bawahnya untuk membuat itu semua mungkin.


1

Itu tergantung pada audiens. Saya bekerja dengan banyak analis keuangan dan gagasan mereka tentang desain gui yang baik adalah bidang yang memiliki banyak bidang yang dapat Anda selipkan dalam satu bentuk. Serius, saya berbicara 75-100. Mereka pecandu data yang selalu menginginkan lebih. Saya baru-baru ini meningkatkan kinerja pada beberapa prosedur tersimpan yang bisa memakan waktu 45 detik untuk memuat (menghitung rata-rata tertimbang sejak awal waktu barang). Dapatkan hingga 30 detik; Saya berpikir wow, potong sepertiga waktu; itu harus menjadi item baris di resume saya. Tidak ada yang memperhatikan. Terus mengerjakannya dan mencapai 15-20. Perubahan yang nyata. Semua orang sangat senang. Saya masih berpikir GUI adalah kekejian dan jika kami mengeluarkan omong kosong yang tidak berguna ini, itu akan dimuat dalam 2 detik,

Jadi, jika Anda ingin pengguna benar-benar mencintai Anda, ingatlah bahwa antarmuka pengguna terbaik adalah tanpa antarmuka sama sekali (harap saya ingat siapa yang mengatakan itu). Setelah ingin melihat semua data ini, analis saya telah menyadari bahwa merekalah yang melakukan semua entri data - horor.


1

Menguji bagian UI aplikasi adalah mimpi buruk.

Setiap orang di sekitar merasa kompeten untuk memberikan saran atau untuk menetapkan permintaan bagaimana Anda harus melakukannya.

Setelah sistem bekerja dengan baik, nanti bahkan jika seseorang mungkin secara tidak sengaja mengingat siapa dia di dalamnya, tidak ada yang akan ingat siapa yang melakukan apa.

Tetapi jika ada kesalahan akan terlihat ( beberapa selalu terjadi), orang pertama yang dihukum akan menjadi programmer GUI, Pengguna tidak pernah melihat yang lain!

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.