Apakah banyak kerangka kerja yang mematikan programmer? [Tutup]


22

Dengan semua kerangka kerja yang tersedia saat ini, ORM , injeksi ketergantungan (DI), Inversion of control (IoC), dll., Saya menemukan bahwa banyak programmer kehilangan atau tidak memiliki keterampilan pemecahan masalah yang diperlukan untuk menyelesaikan masalah yang sulit. Sering kali, saya telah melihat perilaku tak terduga masuk ke aplikasi dan pengembang tidak dapat benar-benar menggali dan menemukan masalah. Tampak bagi saya bahwa pemahaman mendalam tentang apa yang terjadi di bawah tenda sedang hilang.

Jangan salah paham , saya tidak menyarankan kerangka kerja ini tidak baik dan belum memajukan industri, hanya menanyakan apakah, sebagai konsekuensi yang tidak diinginkan, pengembang tidak mendapatkan pengetahuan dan keterampilan yang dibutuhkan untuk pemahaman mendalam tentang sistem.


Inilah artikel bagus yang saya ingat beberapa tahun lalu yang berhubungan dengan pertanyaan Anda. Secara khusus, penulis mengutip kurangnya sesuatu yang mirip dengan BASIC sebagai platform pembelajaran sebagai masalah. salon.com/technology/feature/2006/09/14/basic
GrandmasterB

Kami melatih keterampilan pemecahan masalah yang diperlukan untuk memilih kerangka kerja yang tepat dari banyak kerangka kerja "yang lain".
systempuntoout


1
Apa artinya membodohi sekelompok orang?
Randall Schulz

Jawaban:


18

Sepakat. Saat ini saya bekerja pada paket perangkat lunak yang begitu terbebani oleh kerangka kerja sehingga hampir tidak mungkin untuk memahami bisnis. Setelah kerangka menghapus Anda dari benar-benar memecahkan masalah bisnis, bukan hanya memecahkan MVC , itu sudah terlalu jauh. Seperti yang Anda nyatakan, IMO banyak programmer mencoba dan arsitek / program untuk memecahkan ORM dan MVC, dan mereka jarang bertanya apakah itu benar-benar membantu dalam cara apa pun untuk memecahkan masalah perangkat lunak yang ada di sana sejak awal.


Ya, saya tahu melihat beberapa SQL mentah di halaman JSP adalah "tidak-tidak", tetapi jika Anda seorang konsultan lapangan, di mana ini cocok dengan solusi spesifik? Dan tidak, itu tidak berarti bahwa kerangka kerjanya tidak benar, tidak semua pelanggan memiliki $ 20k duduk di setiap belokan untuk memastikan bahwa titik data kecil diproyeksikan di halaman.


4
+1...just solving MVC, it has gone too far.
Talvi Watia

2
Saya merasa lucu bahwa Gratzy menerima jawaban ini daripada masyarakat memilih jawaban terbaik untuk pertanyaan subjektifnya (yang mengatakan sebaliknya). Sepertinya dia memancing jawaban, bukannya mengajukan pertanyaan.
Craige

1
@Craige - apakah Anda menyiratkan bahwa jawaban yang benar selalu merupakan jawaban yang paling populer?
Jé Queue

1
@ Xepoch - Tidak sama sekali. Sebagai pertanyaan subyektif, saya merasa pertanyaan ini tidak memiliki jawaban nyata untuk memulai. Saya hanya merasa menarik bahwa ia memilih jawaban yang mengatakan kebalikan dari sebagian besar jawaban lain di halaman ini. Saya pikir dia menemukan satu jawaban yang mencerminkan apa yang dia sarankan dalam pertanyaannya, dan memutuskan itu benar karena itu sejalan dengan kepercayaannya.
Craige

31

Ini adalah argumen yang muncul secara teratur, di banyak bidang dan dalam berbagai bentuk.

Bentuk umum dari argumen ini adalah:

Apakah memiliki [x: alat / teknologi] membuat orang lebih buruk di [y: fungsi terpengaruh oleh x]?

Sebagai contoh:

  • Apakah perangkat lunak CAD menghasilkan insinyur yang lebih buruk?
  • Apakah kalkulator di sekolah menengah membuat siswa lebih buruk dalam matematika?
  • Apakah perangkat lunak sosial menghambat ketrampilan sosial pribadi orang?
  • Apakah perangkat lunak akuntansi menghasilkan akuntan yang lebih buruk?

Dari ingatan, jawaban di mana-mana hampir selalu: tidak juga. Anda akan selalu memiliki orang yang baik dan buruk dalam melakukan [y] tetapi sekarang mereka hanya buruk pada aspek keterampilan yang berbeda.

Pemahaman yang lebih mendalam tentang fundamental dengan pekerjaan apa pun akan membantu, apa pun yang Anda lakukan - bahkan pekerjaan yang dianggap 'perbaikan'. Pengetahuan selalu membantu.


Apakah raket yang lebih besar membutuhkan lebih sedikit keterampilan dari pemain tenis yang lebih buruk?
systemovich

22

Abstraksi adalah konsep kunci pemrograman komputer dan kerangka kerja membantu programmer mencapai ini. Ini hal yang baik. Saya ragu banyak dari kita ingin mengembangkan sistem yang kompleks dalam bahasa assembly! Masalahnya datang, saya pikir, ketika programmer memiliki sedikit gagasan tentang apa yang lapisan abstraksi menutupi. Dengan kata lain, Anda perlu memiliki gagasan tentang apa yang terjadi di bawah tenda, bahkan jika Anda tidak berinteraksi atau berinteraksi secara langsung dengannya.

Saya ingat mengembangkan beberapa situs web dinamis pertama di pertengahan 90-an, menggunakan C dan CGI (pada saat sebagian besar situs web masih HTML statis). Sebenarnya tidak ada bahasa skrip sisi server yang matang (seperti PHP atau ASP) dan sangat sedikit perpustakaan, jadi Anda harus menuliskan seluruh aliran respons HTTP ke server dengan setiap halaman. Parsing parameter GET dan POST diperlukan untuk menulis perpustakaan Anda sendiri. Itu membosankan, lambat, kerja keras dan sangat rawan kesalahan. Saya tidak ketinggalan sedikit pun!

Namun, saya juga merasakan kerangka kerja seperti ASP.NET web-bentuk abstrak seluruh sifat tanpa kewarganegaraan web ke titik di mana banyak pengembang web baru memiliki sedikit petunjuk tentang apa yang sebenarnya terjadi di bawah tenda. Ini mengarah pada kode yang tidak efisien dan membengkak yang berkinerja buruk karena pengembang memasang komponen bersama-sama menggunakan metodologi "drag'n'drop" tanpa menyadari apa yang terjadi di tingkat HTTP.

Jadi, saya percaya kerangka kerja sangat penting untuk mengembangkan perangkat lunak tingkat tinggi, tetapi mereka tidak membebaskan pengembang untuk memiliki pemahaman tentang apa yang sedang diabstraksi. Ya, kerangka kerja bisa membuat Anda bodoh, tetapi hanya jika Anda gagal memahaminya.


Tidak dapat setuju dengan "ASP.NET web-bentuk abstrak seluruh sifat tanpa kewarganegaraan web" ada begitu banyak kali saya bertemu pengembang yang tidak mengerti apa yang terjadi di bawahnya dan menyebabkan masalah konyol denganIsPostBack
billy.bob

14

Apakah transmisi otomatis atau wiper kaca sensor hujan membuat kita menjadi pengemudi yang lebih buruk?

Saya tidak berpikir pengkodean tanpa kerangka kerja menyiratkan pemahaman yang lebih baik dari sistem yang mendasarinya. Hal ini dibuktikan oleh pengusaha yang harus mengajukan pertanyaan koding sederhana pada wawancara hanya untuk memastikan kandidat dapat mengumpulkan metode yang koheren.

Pada akhirnya tergantung pada pengembang untuk belajar. Yang baik lakukan, yang buruk tidak.

Dan dalam nada yang sama, memilih kerangka kerja hanya karena ada di sana tanpa benar-benar menganalisis kemampuan dan pro / kontra juga merupakan tanda praktik pembangunan yang buruk.


11
Tranny otomatis membuat pengendara lebih buruk :)
Jé Queue

3
Saya tidak setuju hanya bertanya apakah kerangka kerja memungkinkan lebih banyak pengembang yang buruk?
Gratzy

2
@ Straty: Saya kira tidak. Saya pikir pengembang buruk yang sama akan tetap berkembang tanpa kerangka kerja, hanya dengan cara yang berbeda.
Adam Lear

3
Saya tidak setuju dengan Anna. Tanpa kerangka kerja programmer bahkan malas harus memperluas pengetahuan mereka. Kerangka kerja sebenarnya meningkatkan (mungkin hanya sedikit) jumlah programmer yang buruk.
Wizard

1
Untuk melawan argumen tranny otomatis: banyak pengemudi profesional tidak mengendarai mobil manual, dan banyak lagi yang akan menggeser pemukul dayung yang umumnya dikendalikan oleh komputer.
Steven Evers

10

Saya pikir masalahnya adalah bahwa programmer baru mulai pada tingkat abstraksi yang lebih tinggi dan lebih tinggi, dan dengan demikian tidak terkena bit dan byte dari hal-hal 'di bawah tenda'. Jadi mereka tidak mempelajari beberapa dasar-dasar pengkodean yang benar-benar dasar yang akan menjadi hal pertama yang dipelajari dalam beberapa tahun terakhir.

Saya menggelengkan kepala setiap kali di sini ketika seorang programmer yang jelas baru menanyakan sesuatu tentang, katakanlah, menyimpan beberapa data, dan semua orang segera memberi tahu mereka untuk menggunakan alat ORM . Tidak, tidak, tidak, tidak, tidak ... mereka perlu belajar bagaimana melakukannya sendiri terlebih dahulu.


4
Di mana mentalitas "Anda harus melakukannya sendiri" berhenti? Apakah setiap programmer perlu menulis kompiler mereka sendiri sebelum menggunakannya?
mipadi

2
Itu tidak berhenti. Pemrogram harus selalu belajar. Tidak semua programmer perlu menulis kompiler. Tetapi saya ragu ada banyak programmer hebat yang menjalani seluruh karir mereka begitu tidak tahu tentang kerajinan mereka sehingga mereka tidak pada suatu saat mencoba membuatnya.
GrandmasterB

6
Di bawah logika tidak menggunakan alat ORM sampai Anda "melakukannya sendiri" terlebih dahulu, saya mungkin juga tidak boleh menggunakan lapisan abstraksi database sampai saya sudah menulis panggilan ke database secara langsung? Atau sebenarnya, saya tidak boleh menggunakan database sampai saya menulis sistem penyimpanan menggunakan sistem file? Nah, sistem file itu juga abstraksi ... Di mana saya mulai? Untuk setiap generasi, mereka akan mulai pada tingkat abstraksi yang lebih tinggi, atau untuk mendapatkan lebih banyak hal menarik dilakukan dalam waktu yang lebih singkat.
RationalGeek

2
Saya pikir jika seorang programmer tetap berada pada level abstraksi yang lebih tinggi, mereka dapat menjadi programmer yang sangat kompeten dan membuat aplikasi bisnis yang berfungsi sempurna dari ruang fungsional yang sempurna. Tetapi saya ragu mereka akan menciptakan bahasa pemrograman berikutnya yang harus digunakan, atau yang akan menciptakan inovasi berikutnya dalam basis data, atau menulis game inovatif berikutnya yang mendorong teknologi grafis ke tepi.
GrandmasterB

2
@ jkohlhepp: Dalam setiap proyek penting yang pernah saya coba, abstraksi yang diberikan selalu bocor. Jika saya tidak memiliki dorongan untuk memahami hal-hal mendalam dari apa yang terjadi, saya akan tersesat dan tidak produktif. Jika Anda ingin melakukan hal - hal menarik , Anda harus tahu segalanya.
Paul Nathan

4

Mungkin distribusi "kebodohan" tidak benar-benar berubah, dan kami hanya membagikan cara yang lebih besar dan lebih rumit bagi pengembang untuk menembak diri mereka sendiri?


4

Bukan kerangka kerja yang meredam programmer. Pemrogram bodoh akan bodoh apakah mereka menggunakan kerangka kerja atau tidak.

Memang benar bahwa memahami pekerjaan tingkat rendah bahwa alat atau kerangka kerja membantu Anda merampingkan menjadikan Anda pengguna alat dan kerangka kerja yang lebih baik. Anda juga dapat men-debug masalah dengan lebih mudah, dan mengatasi kesenjangan fungsional yang tidak terhindarkan dari alat.

Sebagai contoh, saya mengambil kelas di Desain Kompiler di perguruan tinggi, di mana kami mengkodekan parser LR dari awal di C, sebelum belajar menggunakan generator parser seperti lex dan yacc. Itu sangat mendidik, dan sejak itu saya memiliki pemahaman dan apresiasi yang lebih baik untuk semua bahasa pemrograman yang saya gunakan.

Tapi saya tidak mengatakan setiap programmer diharuskan bekerja keras untuk memoles mobil Mr. Miyagi selama bertahun-tahun sebelum mereka diizinkan bekerja pada level tinggi. Banyak pekerjaan pemrograman bersifat intelektual, memutuskan apa yang perlu dilakukan perangkat lunak , bukan pekerjaan mekanis pengkodean dalam bahasa atau alat tertentu.

Karya intelektual itu adalah tempat kecerdasan vs kebodohan bahkan lebih penting.


4

Mengutip dari James Larus yang sangat baik "Dividen Pengeluaran Moore" (penekanan ditambahkan):

Tiga puluh tahun yang lalu, Bill Gates mengubah prompt di Altair Basic dari "READY" menjadi "OK" untuk menghemat 5 byte memori. Saat ini, tidak dapat dibayangkan bahwa pengembang akan menyadari tingkat detail program mereka, apalagi khawatir tentang hal itu, dan memang demikian, karena perubahan sebesar ini hari ini tidak terlalu mencolok ... Tidak ada cara kita bisa menghasilkan sistem hari ini menggunakan pengrajin, praktik buatan tangan yang mungkin (perlu) pada mesin dengan memori 4K.

Saya pikir mungkin menyesatkan untuk mengatakan bahwa kerangka kerja memungkinkan Anda menghindari keterampilan yang diperlukan untuk menyelesaikan masalah yang sulit atau membiarkan Anda menghindari pemahaman yang mendalam. Sebaliknya, satu - satunya alasan kami dapat membangun sistem yang kompleks saat ini (yang kompleksitasnya dapat menghasilkan masalah sulit dan menentang pemahaman mendalam) adalah karena kami memiliki kerangka kerja (dan bahasa pengumpul sampah tingkat tinggi OO, dan IDE dengan bantuan konteks-sensitif dan on-the-fly memeriksa sintaksis, dan semua kemajuan pengembangan perangkat lunak lain yang kadang-kadang dikritik sebagai mematikan programmer).


2

Kerangka kerjanya bagus. Tapi Anda harus tahu apa yang ada di balik tudung. Jadi masalahnya adalah bahwa programmer terlalu bergantung pada kerangka kerja, tanpa memiliki pengetahuan yang cukup tentang sistem yang mendasarinya.

Contoh yang agak ketinggalan jaman adalah MFC : seorang programmer dapat menghemat banyak waktu dengan menggunakan MFC daripada Windows API, tetapi tanpa sepengetahuan API (yang berarti memiliki latar belakang pekerjaan nyata dengan API mentah), mereka seringkali akan mandek . Hampir tidak pernah bahagia, karena programmer MFC yang khas memiliki pengetahuan Windows API.

Namun, dengan Formulir Windows di .NET , berkat enkapsulasi dan model objek yang lebih baik, seorang programmer hampir dapat mengabaikan bahwa ia hanya menggunakan pembungkus Windows API. Jadi ada sedikit kemungkinan terjebak, tetapi ketika itu terjadi, itu mungkin menyakitkan.

Sayangnya, waktu untuk memasarkan selalu lebih pendek dan proyek semakin kompleks, sehingga programmer tidak punya waktu untuk masuk lebih dalam. Itulah keadaan menyedihkan dari industri perangkat lunak ...


1

Ini menempatkan kecerdasan di tempat yang seharusnya. Seseorang tidak perlu memahami mekanika kuantum dan fisika Newton untuk mengatur mekanisme yang menjatuhkan bola dari atas sebuah bangunan. Setiap lapisan baru dalam perangkat lunak harus dibangun di atas yang terakhir dan menghapus boilerplate dari pembangunan aplikasi yang berguna.

Mereka yang membutuhkan atau ingin tahu "hal-hal" di balik kerangka kerja akan belajar dan menyelidiki dengan cara apa pun.


1

Tidak, sama sekali tidak. Kerangka kerja, pada intinya, merupakan kombinasi dari perpustakaan subrutin dan templat, dua alat programmer yang telah terbukti benar. Ini adalah pekerja miskin menyalahkan alatnya ...

... dan ada banyak pekerja miskin yang menggunakan dan menyalahkan kerangka kerja.


Saya pikir Anda mungkin kehilangan titik pertanyaan saya tidak menyarankan bahwa kerangka kerja bukan alat yang baik karena ada begitu banyak alat di luar sana menyediakan begitu banyak abstraksi itu memungkinkan lebih banyak orang untuk menyalahkan alat mereka.
Gratzy

3
@ Straty: baik, tentu saja. Semakin banyak orang menggunakan alat, semakin banyak jalang tentangnya. Ketika komputer itu besar, mahal dan jarang, hanya segelintir orang di dunia yang bisa mengeluh tentang betapa sulitnya mereka menggunakannya - sekarang semua orang melakukannya. Demikian pula, kerangka kerja tidak harus membuat programmer bodoh - mereka hanya menarik banyak dan banyak programmer bodoh.
Shog9

1

Saat membangun perangkat lunak, kerangka kerja menghemat waktu. Saat belajar membangun perangkat lunak, kerangka kerja menghalangi pemahaman.

Saya pikir masalahnya terutama salah satu komputer sudah terlalu kuat. Bagi sebagian besar programmer tidak ada alasan yang masuk akal lagi untuk "turun ke dasar-dasar". Hanya membutuhkan lebih banyak waktu untuk melakukan hal yang sama, dan pada saat berjalan tidak ada perbedaan yang berarti. Satu-satunya cara untuk menyelesaikannya adalah dengan memperkenalkan batasan buatan, seperti yang dilakukan kompetisi seperti js1k.

Mungkin sekolah harus memiliki subjek "desain yang dioptimalkan" khusus di mana Anda harus membangun program di bawah batasan ruang dan waktu yang kuat?


-1

Tidak, mempelajari kerangka kerja meningkatkan keterampilan seorang programmer. Kerangka kerja adalah perpanjangan dari bahasa pemrograman. Beberapa bahasa sudah berbasis kerangka kerja. Saya bekerja dengan PHP dan Java. PHP membutuhkan kerangka kerja seperti mesin templat (kadang-kadang). Java tidak membutuhkan kerangka kerja (paling sering), sudah memiliki banyak metode dan perpustakaan.

Sebagian besar Kerangka akan memiliki fungsi yang digunakan programmer berulang kali.


1
Aww, Anda tidak salah lagi dengan jawaban Anda.
NB

-1

Untuk kelihatannya berperan sebagai advokat iblis di sini, saya pikir kerangka kerja (yang "bagus", sebenarnya) dapat benar-benar berjalan menuju memajukan pendidikan seorang programmer. Kerangka kerja yang direkayasa dengan baik akan memecahkan banyak masalah, dan dengan menggunakan kerangka kerja, programmer dapat memahami masalah apa yang sedang dipecahkan, dan bagaimana caranya. Dalam pikiran saya, kerangka kerja adalah (/ harus) kristalisasi pemrograman praktik terbaik, dan dapat mengajar seorang programmer dengan contoh.


Mengapa downvote? Hanya karena Anda tidak setuju? Boo.
Chris Allen Lane
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.