Ujung depan dulu atau Ujung belakang dulu. Dari dua yang merupakan praktik desain sistem yang baik?


30

Saya memiliki klien sekarang mengharuskan saya untuk mengembangkan sistem pendaftaran sekolah. Sekarang ini adalah pertama kalinya saya mengalami tantangan semacam ini. Sebagian besar perangkat lunak masa lalu yang saya buat tidak terlalu rumit.

Saya tahu sebagian besar dari Anda semua telah membuat perangkat lunak yang kompleks, saya hanya ingin saran Anda tentang ini. Haruskah saya mendesain ujung depan atau belakang?

Terima kasih!

Inilah kesimpulan dari artikel yang saya temukan di internet beberapa waktu lalu. Hanya ingin berbagi

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Pengembang front-end vs back-end (my take)

Pilihan pribadi saya

Sekali lagi ini masalah pelatihan, beberapa generalisasi stroke luas:

Pengembang ujung depan

  • Biasanya tidak memiliki gelar CS, atau memiliki gelar CS dari sekolah tingkat 3.
  • Bekerja dalam bahasa yang mirip dengan dasar (lihat PHP Dasar)
  • Memiliki keterampilan visual dalam mengonversi dokumen photoshop ke CSS / HTML / dll.
  • Memiliki toleransi yang tinggi untuk pemrograman berulang, karena mengetik bahasa gratis

Pengembang ujung belakang

  • Memiliki gelar CS atau banyak pengalaman
  • Cenderung saya lebih sistematis dalam pendekatan pemecahan masalah mereka
  • Jangan pedulikan menghabiskan waktu berhari-hari untuk menemukan satu objek yang bocor
  • Coba dan bangun alat untuk memecahkan masalah


2
smh, inilah alasan mengapa saya memberi tahu orang-orang bahwa saya adalah Pengembang Perangkat Lunak vs Pengembang Web.
plve

10
Apa generalisasi ini tentang para pengembang bagian depan dan belakang terkait dengan pertanyaan?
Erik Reppen

Front End Dev! = Back End Devs, meskipun sebagian besar waktu, transisi dengan mereka terus berjalan.
Abhinav Gauniyal

Saya pikir satu-satunya jawaban yang valid di sini adalah 'Itu tergantung ...'
Oliver Weiler

Jawaban:


43

Jika Anda mulai dari belakang, dan melangkah maju, Anda berisiko salah paham terhadap klien. Karena Anda akan menciptakan hal-hal yang tidak mudah dilihat dan dipahami, mereka tidak dapat berpartisipasi dengan sangat mudah dalam memverifikasi apakah Anda memenuhi persyaratan. Ini berarti Anda mungkin menghabiskan banyak pekerjaan.

Jika Anda mulai dari depan, dan mundur, Anda menghadapi risiko bahwa klien akan berpikir itu hampir selesai, ketika semua yang telah Anda lakukan adalah menggambar formulir sederhana di layar. Mereka kemudian mungkin mempertanyakan mengapa ini memakan waktu begitu lama, karena Anda telah menyelesaikan sebagian besar dalam beberapa hari. Anda juga menghadapi risiko melukis diri sendiri, ketika Anda menyadari bahwa Anda harus melakukan pekerjaan yang rumit untuk mengawinkan bagian depan ke belakang, ketika bagian depan yang lebih cocok akan lebih sederhana.

IMO, Anda harus mengerjakan fitur-nya terlebih dahulu. Tulis bagian depan dan belakang secara bersamaan, untuk setiap fitur dalam sistem. Ini memberikan visibilitas kemajuan yang lebih besar kepada klien, dan memberi mereka kesempatan untuk mengatakan "tidak, bukan itu yang saya maksudkan", tanpa menyebabkan Anda terlalu tertekan.

Yang mengatakan, jika ini adalah proyek yang sangat besar di mana Anda perlu mempertimbangkan perangkat keras server atau kemampuan perangkat lunak apa pun yang Anda andalkan (mis. Database mana yang Anda gunakan), maka Anda mungkin harus memikirkan bagian itu terlebih dahulu.


Saya pikir itu penjelasan yang lebih ringkas. Tetapi apakah akan lebih baik untuk membuat back end pertama karena saya pikir lebih mudah untuk membuat front end jika Anda memiliki back end terstruktur dengan baik.
drexsien

3
Jika mereka berpikir ujung depan adalah segalanya, Anda bisa menyebut Google ...
l0b0

1
Itu sebabnya Anda harus membangun GUI mock-up yang Anda perlihatkan kepada klien dan berkata "Apakah ini yang Anda inginkan untuk dilakukan program?", Dan begitu selesai Anda membuangnya dan mulai membangun backend.
gablin

1
+1. @andsien: Jika Anda sudah mendapatkan pendapat Anda, mengapa Anda bertanya? Menurut pengalaman saya, Paul benar, pengembangan berbasis fitur hampir selalu merupakan strategi yang lebih baik.
Doc Brown

3
@andsien: "lebih mudah untuk membuat ujung depan jika Anda memiliki ujung belakang yang terstruktur dengan baik". IMHO itu kesalahpahaman yang berbahaya. Masalahnya adalah: Anda tidak tahu apakah ujung belakang Anda terstruktur dengan baik sampai Anda menggunakannya untuk membangun fitur untuk frontend.
sleske

9

Ada banyak dimensi untuk perangkat lunak, oleh karena itu, front-vs-back yang terlalu sederhana adalah pertanyaan yang buruk dan sangat, sangat sulit untuk memberikan jawaban yang masuk akal dan berguna.

Satu tampilan adalah struktur statis data. Setidaknya ada tiga dimensi pada pandangan ini: lapisan arsitektur ("depan-ke-belakang"), kasus penggunaan dan aktor, serta biaya atau risiko implementasi.

Satu tampilan adalah struktur dinamis dari pemrosesan. Setidaknya ada tiga dimensi untuk pandangan ini.

Pandangan ketiga adalah komponen arsitektur, yang secara alami jatuh ke dalam lapisan, mendukung kasus penggunaan, dan memiliki biaya dan risiko.

Saya bisa melanjutkan, tetapi intinya adalah ini.

Pengembang front-end vs back-end (my take)

Adalah kira-kira cara paling tidak berguna untuk melihat masalah. Pengembang aktual - dan pendapat Anda tentang mereka - sangat penting di sini. Yang penting adalah

  • Gunakan Kasus dan Aktor

  • Model data logis untuk mendukung kasus penggunaan tersebut

  • Proses itu dilakukan sebagai bagian dari use case

  • Komponen yang akan Anda gunakan untuk membangun elemen logis dan pemrosesan dari use case tersebut.

Inilah sebabnya mengapa kebanyakan orang mengatakan bahwa Anda perlu menguraikan sistem Anda berdasarkan cerita pengguna atau kasus penggunaan.

Tidak melakukan generalisasi stroke luas tentang orang-orang yang akan melakukan pengembangan.


7

Tidak juga. Apa yang perlu dilakukan aplikasi Anda? Pastikan katup panas memberikan air panas, katup dingin memberikan air dingin, bahwa air mengalir di tempat pertama, bahwa Anda dapat memperpanjang pipa di mana pun dibutuhkan dan kemudian khawatir tentang menerapkan pipa yang sebenarnya ke semua kamar rumah atau apa yang akan dilakukan rumah sebenarnya terlihat persis.

Ujung depan hanyalah topeng dengan beberapa sakelar dan tuas di atasnya. Bagian belakang hanyalah hal yang menerima permintaan untuk mengambil dan memproses data. Dapatkan titik di mana Anda dapat mengimplementasikan keduanya dengan cepat dalam kombinasi yang diinginkan terlebih dahulu.

Tapi apa pun yang Anda lakukan, jangan biarkan desain yang satu mendikte desain yang lain. Dengan begitu kegilaan terletak.

Dapatkan alat di tempat untuk membiarkan devs Anda membangun apa pun yang mereka butuhkan untuk klien Anda, terlepas dari berapa kali mereka berubah pikiran. Kemudian buat sesuai spesifikasi dan gabungkan kembali sampai sedikit cusses akhirnya bahagia.

Juga, membandingkan dev ujung depan dengan dev ujung belakang pada tahun 2008 adalah waktu yang lalu di tahun web. Demi bersenang-senang, saya ingin memperbaiki / menambahkan beberapa hal ke berangan tua itu karena kami telah menautkannya dalam pertanyaan, tetapi juga (semoga) menanamkan beberapa tips di dalam:

Pengembang ujung depan

Biasanya tidak memiliki gelar CS, atau memiliki gelar CS dari sekolah tingkat 3.

Tunjukkan tangan. Berapa banyak orang dengan gelar CS telah diajarkan praktik terbaik di ujung depan? Atau bagaimana agar tidak membuat kekacauan dengan JavaScript? Atau bagaimana menangani masalah CSS dari IE6-IE9? Industri buku teks, yang menjalankan akademisi, terlalu gemuk malas dan kembung untuk menangani teknologi yang terus berubah sehingga sangat sedikit mendapat perhatian 'serius' di perguruan tinggi. Ini sangat baik untuk orang yang terlambat berkembang seperti saya.

Bekerja dalam bahasa yang mirip dengan dasar (lihat PHP Dasar)

Karena PHP adalah teknologi sisi klien? Atau karena JavaScript, yang diilhami terutama oleh Skema memiliki lebih banyak kesamaan dengan Basic daripada Visual Basic yang sekarang tidak lagi menjadi perhatian di ujung depan dan tidak pernah benar-benar tetapi masih tersedia untuk back end. Aplikasi web NET? Blog ini membandingkan pengembang web open source otodidak dengan pengembang web lulusan CS menggunakan teknologi populer perusahaan pada titik ini saya pikir. Saya telah bertemu dengan insufferable dan kompeten dalam bagian yang sama di kedua sisi dari pertarungan tertentu tapi dia masih cara OT di sana.

Memiliki keterampilan visual dalam mengonversi dokumen photoshop ke CSS / HTML / dll.

Lebih memperhatikan detail daripada "keterampilan visual" yang agak luas. Tidak semua dari kita memiliki keterampilan desain estetika apa pun. Tapi ya, kebanyakan dari kita harus mempelajari hal-hal ini di tingkat Jr. dan itu sebenarnya cukup kritis untuk menulis UI yang baik yang tidak menggunakan palu JS ketika pisau bedah CSS akan melakukannya.

Memiliki toleransi yang tinggi untuk pemrograman berulang, karena mengetik bahasa gratis

Inilah sebabnya mengapa Anda ingin potongan yang saya sebutkan di tempat pertama. Kami meneruskan tombol yang ditekan, Anda menghasilkan / mengambil barang. Kami mengemas dan mengirimkannya. Tidak ada alasan untuk hal-hal ini terikat erat satu sama lain. Selain itu, pengetikan yang ketat tidak boleh mengganggu proses berulang jika Anda tidak menyedot OOP yang kebanyakan orang suka membenci bahasa yang tidak memiliki kelas secara teknis, pada kenyataannya, biasanya. Tetapi bahkan jika mereka memang bau, ujung depan hanya membutuhkan titik akses yang dapat diprediksi dan Anda dapat melakukan apa pun yang Anda inginkan di ujung belakang selama Anda tidak melakukan sesuatu yang konyol seperti secara dinamis menulis JavaScript yang bukan JSON atau secara ketat mengikat perilaku back-end yang sukses ke struktur HTML menjadi "just so." * batuk * devs java * / batuk *


Satu-satunya penyesalan saya adalah saya tidak dapat memberi +1 pertanyaan Anda lebih dari sekali. Sayang sekali saya harus menggulir ke bawah 2 jawaban untuk pertanyaan ini untuk akhirnya menemukan satu di mana dinyatakan bahwa bertanya tentang urutan di mana depan dan belakang dan harus dikembangkan adalah pertanyaan yang salah untuk ditanyakan. Saya juga setuju dengan pendapat Anda tentang Gelar CS. Dan komentar terakhir "late bloomers".
Shivan Dragon

5

Tidak ada jawaban yang benar untuk ini. Baik pendekatan itu bisa baik (dan buruk) dalam situasi tertentu.

Saya sarankan Anda mempertimbangkan pendekatan TDD, di mana seseorang dipimpin oleh (penerimaan dan unit) tes.

Mulailah dengan menyusun kerangka sistem: infrastruktur dasar, dengan fungsi minimum absolut. Ini hanya untuk menunjukkan bahwa konsep Anda berfungsi dan komponen yang berbeda dapat bekerja bersama. Ini juga termasuk UI tulang kosong (jika berlaku), cukup untuk benar-benar melakukan dan / atau menunjukkan sesuatu yang minimal.

Kemudian Anda menyempurnakan detail, fitur demi fitur : tulis tes penerimaan untuk fitur / skenario tertentu, buat gagal, lalu tulis kode untuk memuaskannya. Ini membuatmu bekerja ke dalam dari luar : sistem menerima beberapa pesan input, jadi Anda perlu menangani / mengonversi pesan itu, melakukan sesuatu dengannya, lalu menyebarkan hasilnya kembali ke UI. Di jalan Anda akan menemukan konsep domain dan mewakilinya dengan kelas-kelas baru, dari UI menuju lapisan domain dan kembali.

Untuk pendekatan ini, bacaan yang disarankan adalah Growing Object-Oriented Software, Dipandu oleh Tes .


1

API dulu

Insinyur dari kedua tim harus bekerja bersama pada API antara front-end dan back-end. Kemudian kedua tim dapat mulai bekerja berdasarkan API yang dirancang. Ini memiliki keuntungan bahwa tim front-end lain juga dapat memulai pekerjaan (mungkin seluler, setelah klien web) selain keuntungan nyata bahwa tim dapat mulai bekerja secara paralel.

Gabungkan dengan pendekatan berulang dan akan terlihat seperti ini:

  1. Desain API sederhana
  2. Kedua tim mengembangkan dan menguji berdasarkan API
  3. Tes integrasi
  4. Tunjukkan kepada klien dan terima umpan balik.
  5. Tingkatkan API dan ulangi.

0

Mulai dengan frontend, tetapi pertama-tama, mengapa mereka tidak dapat menemukan aplikasi yang sudah ada? Ini akan memberi lebih banyak wawasan tentang proyek ini. Apakah mereka memiliki beberapa persyaratan unik atau mereka pikir Anda dapat membangun lebih murah?

Dapatkan pemahaman penuh tentang harapan keamanan mereka dan apa yang dituntut oleh hukum. Tidak yakin apa jenis sekolah ini, tetapi informasi siswa biasanya memerlukan kerahasiaan.

Jika siswa potensial memasukkan data di situs web, desain grafis akan lebih menjadi masalah.

Berdasarkan permintaan mereka, gambar tiruan dari ujung depan. Jika Anda berpikir gui tidak lurus ke depan, Anda mungkin harus membuat sesuatu berfungsi, sehingga mereka dapat melihatnya beraksi. Mereka mungkin melihat pendaftaran sebagai semacam 'penyihir' yang bercabang ke berbagai arah berdasarkan entri data.

Kemudian Anda dapat mulai mendapatkan informasi yang tersimpan di basis data.


1
masalah dalam memulai dengan ujung depan (berdasarkan pada pengalaman) adalah bahwa ketika Anda melupakan beberapa fungsi, itu dapat mengacaukan ujung belakang Anda dan dapat membuat Anda berputar-putar berusaha memperbaikinya
drexsien

1
@andsien - apakah Anda berbicara tentang mendesain atau membangun? Saya tidak akan mulai membangun ujung depan tanpa merancang backend terlebih dahulu.
JeffO

ops salahku im berpikir untuk membangun ... terima kasih untuk jeff itu.
drexsien

0

Ya saya menyadari OP bertanya beberapa waktu lalu. Mulai dari belakang tetapi MOCK UP ujung depan untuk memungkinkan pengguna untuk melihat apa yang Anda bayangkan. Ujung depan, apa pun nilainya, hanyalah lonceng dan peluit. Bagian belakang adalah di mana uang itu berada, dan begitu Anda memiliki yang lurus, FE hanya saus daging.


Sayangnya itu yang diinginkan klien, biasanya, tetapi saya pikir perilaku seperti itu harus dihilangkan. Jangan biarkan mereka terpaku pada tampilan visual dan tetap dengan prototipe Anda sampai mereka dapat memverifikasi mereka mendapatkan perilaku dasar yang mereka inginkan. Klien sering kali tidak dapat memisahkan eye candy dari fitur yang berguna dan mereka akan membuat Anda membuang banyak waktu untuk hal-hal yang kurang penting hanya untuk menyalahkan Anda ketika aplikasi gagal pada niat utamanya dalam jangka panjang.
Erik Reppen

@ErikReppen Saya telah memiliki pengalaman itu berkali-kali - saya ingin menunjukkan kepada klien "pengguna akan memasukkan data dalam bidang teks" dan klien melihat "bidang formulir akan persis 400 piksel lebar dan halaman akan berwarna biru pucat latar belakang dengan teks Arial 11pt ... "Tapi saya masih berpikir itu lebih baik daripada tidak pernah menunjukkan ujung depan. Kalau tidak, mungkin untuk membangun seluruh sistem yang bertentangan dengan beberapa asumsi yang tidak disebutkan dalam use case utama mereka.
octern

Anda dapat melakukan demo front end tetapi tetap sederhana dan sederhana. Jauhkan mereka dari photoshop, kebodohan yang sebenarnya, kecuali kalau memang itulah yang mereka minta dijual kepada mereka. Dan di situlah letak masalahnya. Itu yang mereka harapkan, tetapi mereka lebih sering tidak terlalu bodoh untuk memprioritaskan piksel dari "sebenarnya membuat pelanggan kami melakukan apa yang kami ingin mereka lakukan."
Erik Reppen

errr, bukankah itu sebabnya kami memiliki CSS? (meskipun saya tidak merasa sakit Anda). Saya selalu & dengan sengaja memiliki FE yang jelek, tetapi fungsional, & menjelaskan bahwa kami sedang mendiskusikan Use Cases, workflow ... & dapat mempersonifikasikannya nanti. (tapi jawaban sebenarnya adalah persyaratan-> database-> FE)
Mawg

0

Memperluas komentar saya:

Pertama, kumpulkan persyaratan, lalu ubah menjadi Kasus Penggunaan & desain.

Pertama datang definisi database yang terperinci. Saya tidak peduli jika klien tidak sepenuhnya mengguncangnya, saya memaksa mereka untuk duduk & melihatnya - dan menandatanganinya (mungkin kemudian memaksa kemudian menyadari bahwa sekali dari orang yang lebih mengerti teknologi mereka harus melakukannya ), sebelum melanjutkan.

Bagaimana Anda bisa mulai dengan FE, tanpa BE? FE untuk apa ??? Tentukan basis data Anda !! Itulah yang dimanipulasi FE.

Ok, akan ada masalah & kemudian tweak, dan saya lakukan setuju bahwa itu baik untuk mendapatkan sederhana, sampel, GUI di depan klien secepat mungkin, karena itu ujung tertentu gunung es yang paling paling mengerti.

Namun, saya 1) menekankan bahwa ini hanya mock-up yang kasar, untuk porpoise diskusi, dan 2) sengaja membuatnya jelek, tetapi fungsional , sehingga mereka yang tidak mengerti dapat mengacaukan & menyuruh saya untuk membuat kotak input itu dengan tepat 400px lebar & latar belakang biru terang.

Saya merasa bahwa sebagian besar jawaban di sini (dan saya telah mengikuti mereka) cenderung terlalu fokus pada pelanggan, tetapi, dari sudut pandang murni, saya berpendapat bahwa Anda tidak dapat merancang FE untuk memanipulasi BE tanpa terlebih dahulu merancang BE itu.


"Anda tidak dapat merancang FE untuk memanipulasi BE tanpa terlebih dahulu merancang BE". Oh ya, Anda bisa - itu disebut "prototipe". Ini bisa menjadi langkah awal yang berharga ketika memulai sistem baru.
sleske

apa itu prototyping? Tidak ada perang api, itu hanya muncul di kepalaku. Saya mengerti apa prototipe itu, tapi mungkin karena saya berasal dari bidang yang berbeda, saya selalu melihatnya sebagai: dapatkan persyaratan, ubah menjadi case use & design. Jika Anda tidak memiliki d / b dipaku maka Anda akan melakukan banyak pengerjaan ulang yang tidak perlu, jadi selesaikan dulu, lalu cari tahu bagaimana cara memanipulasinya (sesuai persyaratan). YMMV ... melanjutkan ...
Mawg

Ini bisa dibilang bukan hitam & putih, kalau tidak pertanyaan itu tidak akan ditanyakan, tapi JADILAH yang pertama, selalu, IMO. Sebenarnya, saya sedang melakukan yang seperti itu sekarang untuk clietn yang hanya memiliki perasaan kabur kabur di tempat persyaratan (saya seharusnya tidak pernah menyentuh mereka, tapi itu cerita keseluruhan nother :-)
Mawg

1
Pengalaman saya adalah bahwa persyaratan pengguna harus didahulukan, dan arsitektur harus mengikuti. Namun tentu saja ini tergantung pada detail teknisnya, beberapa hal memang sulit diubah nantinya. Setidaknya penting untuk menyadari pengorbanannya.
sleske

Saya menduga bahwa kita mungkin mengatakan hal yang sama dengan cara yang berbeda (+1)
Mawg
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.