Saya seorang pengembang web aplikasi web SaaS kecil lokal. Saat ini memiliki sekitar setengah lusin klien.
Ketika saya terus merancang aplikasi, semakin sulit bagi saya untuk meyakinkan diri saya untuk berkomitmen kapan saja untuk proyek, yang telah terjadi pada tahap awal. Setelah tumbuh melekat pada proyek dan kode yang sudah saya tulis, saya takut bahwa semua pekerjaan tambahan yang saya lakukan akan dibatalkan dalam waktu dekat, ketika aplikasi ternyata tidak skala dengan baik seiring pertumbuhan bisnis.
Sebagai seorang mahasiswa yang melamar magang, majikan saya mempertanyakan pilihan saya untuk tidak menggunakan kerangka kerja web selama wawancara, yang hanya membuat saya semakin meragukan pekerjaan saya sebelumnya. Saya tidak tahu kerangka kerja web apa pun, dan tidak tahu mana yang harus mulai digunakan.
Saya telah mendapatkan program magang sebagai pengembang penuh pada bulan Januari, di mana saya akan mulai mempelajari kerangka kerja front-end, tetapi tekanan untuk menyelesaikan aplikasi semakin meningkat, dan saya sedang mempertimbangkan untuk menghapus aplikasi sepenuhnya dan memulai dari awal, yang merupakan sesuatu yang telah saya lakukan sebelumnya. Aplikasi saat ini dibangun dalam PHP dan jQuery (untuk panggilan AJAX) dan menggunakan MySQL untuk databasenya. Adakah pemikiran tentang bagaimana saya dapat mengatasi blok mental ini, dan untuk memastikan aplikasi saya dapat diskalakan? Terima kasih sebelumnya.
sumber
Jawaban:
Sempurna adalah musuh kebaikan.
Atau dengan kata lain, jangan khawatir tentang hal itu hari ini. Jika aplikasi Anda melakukan apa yang perlu dilakukan, maka tidak apa-apa. Ini bukan hal yang buruk untuk menulis ulang bagian-bagian dari perangkat lunak lebih bawah garis; pada saat itu Anda 1) tahu lebih jelas apa yang Anda coba bangun dan 2) tahu bit mana yang sebenarnya menjadi hambatan. Anda bisa menghabiskan banyak waktu untuk menulis aplikasi yang akan menskalakan hingga satu juta pengguna, tetapi itu tidak akan lebih baik untuk enam pelanggan Anda saat ini daripada apa yang Anda miliki hari ini .
sumber
Inti dari masalah ini bukan skalabilitas. Inti masalahnya adalah berpikir bahwa Anda akan memperbaikinya pertama kali .
Anda harus fokus pada penulisan kode bersih. Karena kode bersih memaksimalkan kenyamanan ketika Anda (mau tidak mau) harus mengubah sesuatu di masa depan. Dan itulah tujuan sebenarnya yang harus Anda miliki.
Apa yang Anda coba lakukan sekarang adalah mencoba memikirkan kode yang sempurna untuk ditulis. Tetapi bahkan jika Anda berhasil melakukan itu, siapa bilang persyaratannya tidak akan berubah, atau Anda mungkin membuat keputusan berdasarkan informasi yang salah atau komunikasi yang salah?
Anda tidak dapat menghindari membuat kesalahan, bahkan jika itu bukan kesalahan Anda. Berfokuslah pada penulisan kode yang nantinya mudah diubah, alih-alih berharap menulis kode yang tidak perlu Anda ubah di masa mendatang.
Saya benar-benar bersimpati dengan sentimen ini. Tetapi menjadi terlampir pada kode yang Anda tulis adalah masalah.
Satu-satunya hal yang harus konstan adalah keinginan Anda untuk memecahkan masalah tertentu . Bagaimana Anda menyelesaikan masalah itu hanyalah masalah sekunder.
Jika besok alat baru dirilis yang mengurangi basis kode Anda hingga 80%, apakah Anda akan kesal karena kode Anda tidak lagi digunakan; atau apakah Anda akan senang bahwa basis kode Anda telah menjadi lebih kecil dan jauh lebih bersih / lebih mudah dikelola?
Jika yang pertama, Anda memiliki masalah: Anda tidak melihat solusi untuk kode . Dengan kata lain, Anda berfokus pada kode dan tidak melihat gambaran yang lebih besar (solusi yang ingin diberikannya).
Itu adalah masalah yang berbeda untuk hari yang berbeda.
Pertama, Anda membangun sesuatu yang berfungsi. Kedua , Anda meningkatkan kode untuk memperbaiki kekurangan yang mungkin masih muncul. Apa yang Anda lakukan saat ini adalah menahan tugas pertama karena takut harus melakukan tugas kedua.
Tapi pilihan apa lagi yang ada? Anda tidak bisa mengatakan masa depan . Jika Anda menghabiskan waktu untuk merenungkan kemungkinan masa depan, Anda akan tetap menebak . Tebakan selalu cenderung salah.
Alih-alih, bangun aplikasi, dan buktikan bahwa memang ada masalah. Dan begitu masalahnya jelas, maka Anda mulai mengatasinya.
Dengan kata lain: Henry Ford tidak pernah membuat mobil yang sesuai dengan standar / harapan 2018. Tetapi jika dia tidak membangun Model T, mobil cacat dengan standar modern, tidak ada yang akan mulai menggunakan mobil, tidak akan ada industri mobil, dan tidak ada yang akan memiliki mobil yang kemudian dapat mereka coba tingkatkan.
Bagian penting di sini bukanlah kerangka mana yang Anda gunakan (majikan mana pun yang menilai Anda yang tidak melakukan pekerjaan mereka dengan benar). Bagian penting di sini adalah mengetahui apa yang Anda lakukan dan mengapa Anda melakukannya .
Misalnya, Anda bisa menghindari kerangka kerja yang ada secara khusus karena Anda ingin mempelajari mengapa kerangka kerja berguna dengan melakukannya dengan cara yang sulit terlebih dahulu. Atau Anda bisa mencoba membuat kerangka kerja sendiri.
Satu-satunya jawaban yang buruk di sini adalah "Saya tidak tahu", karena itu menunjukkan kurangnya membuat keputusan. Itu adalah bendera merah untuk majikan.
Masalah yang sama muncul di sini. Solusinya bukan berpikir lebih banyak, tetapi bertindak:
Untuk membaca lebih lanjut tentang ini, baca The doing mindset> the thinking thinking . Penulis menjelaskannya lebih baik daripada yang saya bisa.
Kecuali jika basis kode saat ini adalah kekacauan yang benar-benar tidak dapat dipelihara; Anda membuat keputusan sebaliknya.
Pengembang sering berpikir bahwa membuang sesuatu akan menjadi pilihan yang lebih baik. Perasaan yang sangat umum. Tapi ini jarang pilihan yang tepat.
Membuang kode dan memulai dari awal seperti terjebak kemacetan dalam perjalanan ke tempat kerja, khawatir Anda akan terlambat bekerja (ketinggalan tenggat waktu), dan sebaliknya pulang dan coba mengemudi di jalan yang sama lagi. Itu tidak masuk akal. Anda mungkin terjebak kemacetan, tetapi Anda masih lebih dekat dengan pekerjaan daripada saat Anda berada di rumah.
sumber
Meskipun sejumlah besar uang yang telah dituangkan Facebook dan Google ke pemasaran untuk meyakinkan Anda sebaliknya, kerangka kerja ujung depan ada karena dua alasan utama:
Anda mungkin hanya perlu meraih kerangka kerja untuk menyelesaikan masalah ini jika aplikasi Anda secara inheren stateful, jika jumlah negara aplikasi yang Anda simpan di sisi klien cukup kompleks, jika Anda mengharapkan banyak klien dengan latensi jaringan yang buruk (seluler, atau jauh dari server), atau jika ada kebutuhan bisnis yang kuat untuk mendukung CSS canggih atau pembuatan elemen dinamis.
Kerangka pemasaran ingin Anda percaya bahwa metode arsitektur khusus mereka meningkatkan kecepatan pengembangan dan membuat pemeliharaan lebih mudah. Ini jelas tidak benar untuk tim kecil yang mengerjakan proyek sederhana. Mengisolasi kode dan mengatur impor dapat membantu tim besar membawa produk ke pasar lebih cepat. Ini memberikan jauh lebih sedikit untuk tim pengembangan satu orang bekerja pada proyek yang sudah fungsional.
Anda akan menghabiskan lebih banyak waktu untuk mempelajari cara memasukkan kode fungsional yang ada ke dalam kerangka kerja daripada Anda benar-benar akan mengimplementasikan fitur, dan kemungkinan cukup bagus bahwa seseorang di suatu tempat akan memperbarui sesuatu, dan kode yang ditulis dalam kerangka itu akan berhenti berfungsi dalam waktu 18 bulan kecuali seseorang ada untuk terus mempertahankannya.
Vanilla JS, dan pada tingkat yang lebih rendah tetapi masih signifikan JQuery, jangan menderita masalah itu. Dengan beberapa pengecualian, aplikasi JQuery + AJAX tidak bergantung pada perilaku spesifik browser, dan melepaskan ketergantungan eksternal yang masuk akal, terus bekerja 10-15 tahun setelah semula ditulis dengan perubahan yang sangat kecil.
Kerangka kerja sangat bagus untuk startup biasa yang mendukung aplikasi web yang sedang berjalan, kompleks, dan terbuka untuk umum. Mereka membiarkan tim besar berkoordinasi dengan baik bersama-sama, berintegrasi dengan baik dengan kerangka kerja penambah vendor, dan mendukung widget dan paradigma desain baru yang mencolok untuk membantu Anda tetap kompetitif.
Tidak ada yang penting untuk alat perangkat lunak kecil dengan pemirsa tetap yang akan Anda tinggalkan. Mengambil kerangka kerja keduanya memperlambat kecepatan pengembangan Anda saat Anda beradaptasi dengan paradigma baru, dan memperkenalkan risiko kompatibilitas yang tidak perlu. Membuat kode sisi klien tetap sederhana, (dan idealnya di-host-sendiri) berarti bahwa area permukaan risiko kompatibilitas turun secara signifikan. Browser akan berubah, url CDN akan berhenti berfungsi, dependensi akan kedaluwarsa - Tetapi tidak ada yang menyentuh server itu, dan itu akan tetap berfungsi dengan baik.
Jangan mengadopsi kerangka kerja kecuali jika memecahkan masalah arsitektur spesifik yang Anda miliki hari ini atau dapat segera diramalkan, dan sangat mempertimbangkan mengatasi masalah itu dengan cara lain sebagai gantinya jika itu bisa dipertahankan.
sumber
Hal terbaik yang dapat Anda lakukan untuk "bukti masa depan" aplikasi Anda adalah mengikuti praktik terbaik dalam desain sistem Anda untuk memaksimalkan kopling longgar dan pemisahan masalah. Tidak ada bagian dari aplikasi Anda yang aman dari mulai ditinggalkan, tapi banyak yang dapat Anda lakukan untuk mengisolasi kode yang menjadi usang karena alasan X dari kode yang tidak tentu harus dipengaruhi oleh X.
Namun, saya berpendapat bahwa kekhawatiran Anda harus lebih sedikit untuk pertumbuhan / skalabilitas aplikasi Anda daripada tingkat pertumbuhan pengalaman dan kemampuan Anda sendiri. Blok mental yang Anda gambarkan terdengar bagi saya seperti belajar stagnasi atau kesadaran banyak orang yang tidak dikenal tanpa strategi atau alat untuk mengatasinya.
Kerangka kerja tidak terlalu cocok untuk memecahkan tantangan "pemeriksaan masa depan", meskipun mereka dapat memberikan panduan awal yang relevan untuk yang tidak berpengalaman, biasanya melalui pola desain tingkat tinggi seperti MVC. Sebaliknya, mereka cenderung lebih berguna sebagai cara untuk mempercepat pembangunan dengan memberikan kohesi yang kuat dan seringkali dengan mengorbankan kopling yang lebih ketat. Misalnya, Anda menggunakan beberapa sistem pemetaan objek-relasional yang disediakan kerangka kerja di seluruh aplikasi untuk berinteraksi dengan database Anda, lengkap dengan integrasi sistem caching. Mungkin nanti Anda perlu beralih ke data non-relasional dan sekarang semua yang menggunakannya terpengaruh.
Kekacauan yang Anda miliki sekarang tidak berasal dari apa yang Anda gunakan, tetapi dari mana Anda menggunakannya (mungkin cukup banyak di mana-mana di bagian belakang). Betapa jauh lebih baik Anda jika kode yang membuat halaman tidak pernah mengambil data yang dihasilkannya.
Misalkan Anda ingin menambahkan beberapa widget kecil ke halaman yang membutuhkan skrip dan sumber daya tambahan untuk bekerja dengan baik. Jika Anda menggunakan kerangka kerja, Anda dapat bertanya "Bagaimana Anda ingin menambahkan dependensi ke halaman untuk hal ini?" Jika tidak, maka pertanyaannya lebih terbuka: "Masalah teknis apa yang saya sentuh yang harus dipisahkan?" Pertanyaan itu membutuhkan lebih banyak pengalaman untuk dijawab, tetapi berikut adalah beberapa petunjuk:
Jika salah satu dari ini kedengarannya luar biasa, maka saya sarankan Anda harus menggunakan kerangka kerja untuk saat ini, bukan untuk aplikasi Anda tetapi demi pertumbuhan pribadi Anda sendiri. Namun jangan memulai dari awal. Alih-alih menggunakan kerangka kerja sebagai kurikulum untuk membantu memandu evolusi aplikasi Anda.
Hanya ada dua cara untuk belajar. Salah satunya adalah dengan coba-coba, dan yang lainnya adalah dengan belajar dari pengalaman orang lain. Trial and error tidak bisa dihilangkan. Pengembangan perangkat lunak pada dasarnya adalah bidang pembelajaran berkelanjutan dan kode apa pun yang tidak melakukan sesuatu yang baru atau berbeda menurut definisi tidak perlu. (Alih-alih menggunakan kode yang sudah ditulis.)
Kuncinya adalah menguranginya dengan secara proaktif mencari pengetahuan yang sudah ada sebelumnya (strategi, praktik terbaik, dan kode / perpustakaan / kerangka kerja) di setiap langkah proses pengembangan sehingga Anda tidak menemukan diri Anda terus-menerus menciptakan kembali roda.
Adapun aplikasi yang sedang Anda tulis, bagaimanapun, perhatian pertama Anda seharusnya hanya untuk menyelesaikannya dengan upaya duniawi minimum (yang merupakan semacam bau kode, tetapi untuk proses pengembangan). Mengingat sifat pembelajaran manusia, cara tercepat untuk mencapai kualitas tinggi adalah memulai dengan sesuatu . Jauh lebih mudah untuk memahami tujuan ketika Anda dapat membentuknya dengan mengkritik sesuatu yang sudah Anda miliki.
Jika Anda dapat menerima bahwa sebagian besar kode yang Anda tulis adalah proses belajar sekali pakai dan diperlukan untuk menemukan desain yang baik, yang akan sangat membantu memotivasi Anda untuk terus melakukannya. Lagi pula, tantangan penyelesaian masalah yang membuat pengembangan perangkat lunak menarik, dan tantangan itu selalu ada jika apa yang Anda lakukan bermanfaat (lihat pernyataan "pembelajaran berkelanjutan" di atas).
sumber
Di atas segalanya, "scrapping hal dan mulai lagi dari awal" adalah tidak pernah menjadi pilihan ... setelah semua, tidak Anda mengatakan bahwa Anda memiliki "setengah lusin klien?" Sudahkah Anda berhenti sejenak untuk mempertimbangkan apa yang mungkin mereka pikirkan tentang pernyataan Anda, mengingat bahwa mereka sekarang (mungkin) "sangat senang dengan pekerjaan Anda ?!"
Berikut ini analogi yang ingin saya gunakan:
"Pekerjaan saya adalah membangun rumah untuk orang-orang untuk tinggal, untuk orang-orang untuk membangun bisnis, dan sebagainya." Pekerjaan saya adalah membuat " potongan - potongan pasir yang luar biasa kecil, terlalu mulia " untuk melakukan pekerjaan yang bermanfaat. (Sama seperti pembangun rumah membuat rumah dari papan gipsum, ubin keramik, balok beton, dan 2x4-an.)
Namun, sementara "paku" yang digunakan pembuat rumah benar-benar tidak banyak berubah dalam dua ratus tahun (kecuali untuk berubah dari "persegi" menjadi "bundar," dan kemudian menjadi berguna dengan mesin paku pneumatik), teknologinya yang kami gunakan selalu berubah dan terkadang mengalami perubahan yang sangat mendalam. ("Begitu seterusnya.")
"Meskipun demikian, setiap rumah, setelah dibangun, akan selamanya-setelah harus tinggal di." Anda tidak dapat mengusir mereka. Setelah Anda membangunnya dan menyerahkan kunci, "itu bukan rumah Anda lagi." Ini adalah apa yang sekarang ini, dan itu akan bertahan untuk waktu yang sangat lama.
Sebagian besar dari bisnis saya hari ini adalah membantu klien untuk mengatasi perangkat lunak yang dibangun sepuluh, dua puluh, tiga puluh atau lebih tahun yang lalu, menggunakan teknologi "canggih" yang ada pada masa itu - (dan yang, ahem, Saya ingat) - dan yang masih dalam pelayanan (!) Hari ini.
sumber
Memastikan sesuatu adalah bukti di masa depan hampir mustahil. Namun, memeriksa bahwa aplikasi tersebut dapat diskalakan tidak terlalu sulit. Anda hanya perlu menulis beberapa tes kinerja untuk aplikasi dan melihat berapa banyak klien yang dapat menangani. Tes menulis pasti akan membuat aplikasi Anda lebih banyak bukti di masa depan karena Anda akan dapat mengukur bagaimana perilaku aplikasi setelah Anda menerapkan lebih banyak perubahan ke dalamnya.
wrt framework, saya tidak akan terlalu khawatir kinerja / skalabilitas. Ini adalah sesuatu yang Anda dapat dengan mudah memeriksa dan kemungkinan besar memperbaikinya. Masalah yang lebih besar adalah keamanan. Kerangka kerja web biasanya membantu Anda menulis kode otentikasi yang tepat, cookie, perlindungan CSRF, dll. Terutama mengingat kurangnya pengalaman Anda, fokus yang lebih baik di bidang itu.
sumber
Saya mulai menulis komentar tentang kerangka belajar, tetapi akhirnya berubah menjadi sesuatu yang lebih mirip jawaban, jadi ini dia.
Tidak mengetahui kerangka kerja seperti masalah. Pada dasarnya setiap pekerjaan webdev Anda harus bekerja dengan beberapa kerangka kerja. Belajar kerangka lain setelah Anda tahu satu tidak bahwa masalah besar, tetapi belajar yang pertama mungkin memerlukan waktu - yang mengapa majikan mungkin peduli tentang itu. Menghindari kerangka kerja mungkin mengindikasikan sindrom tidak ditemukan di sini , yang secara luas merupakan pendekatan yang tidak praktis.
Karena titik utama untuk mengetahui kerangka kerja pertama Anda adalah mempelajari bahasa umum, mungkin hanya mencoba mempelajari sesuatu yang populer di antara rekan-rekan Anda. Anda dapat mencoba memodifikasi beberapa proyek sederhana yang ditulis dalam suatu kerangka kerja. Memulai proyek dari awal dalam suatu kerangka kerja yang Anda tidak tahu adalah cara belajar yang sangat tidak efektif.
Sekarang, pertanyaan Anda yang sebenarnya adalah tentang proyek tertentu dan memindahkannya ke suatu kerangka kerja. Untuk itu, jawabannya sepertinya: itu tergantung, dan kami tidak bisa memberi tahu Anda. Namun, memindahkan barang ke kerangka kerja yang Anda tidak tahu hampir pasti adalah ide yang buruk, karena Anda bahkan tidak tahu apakah itu masuk akal . Oleh karena itu, tampaknya Anda harus membiarkannya apa adanya, dan meninjau kembali keputusan ini di beberapa titik, setelah Anda tahu dan menyukai beberapa kerangka kerja. Jawaban lain berisi poin bagus tentang apa yang harus Anda cari ketika membuat keputusan seperti itu.
sumber
Artikel ini mendapat banyak perhatian di Hacker News 2.5 tahun yang lalu: Tulis kode yang mudah dihapus, tidak mudah diperpanjang. Perspektif ini mungkin atau mungkin tidak membantu Anda menangani basis kode Anda saat ini, tetapi di masa depan, itu bisa membantu mencegah frustrasi yang berasal dari perfeksionisme / rekayasa berlebihan.
(penekanan milikku)
The benang artikel tentang Hacker News juga mungkin layak dibaca.
sumber
Sejauh menjadikannya bukti di masa depan dan menerapkan prinsip skala & kerangka kerja, ini adalah tugas yang berat untuk dilakukan sendiri, saya mungkin tidak khawatir tentang itu, tetapi jika Anda harus:
Jaga kode Anda tetap bersih, ikuti prinsip SOLID, KERING> google.
Terapkan load-balancer sesegera mungkin.
Berdiri paling tidak dua server web, menangani skenario load balancing dalam kode.
Dan yang tak kalah pentingnya, ada tumpukan yang lebih baik untuk menangani satu juta pengguna daripada LAMP, tapi saya yakin itu benar-benar bisa dilakukan.
Kasus dan titik, lihat: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Poinnya valid, tapi 10gb sepele sebagai subjek uji.
sumber