Isu dari topik ini sangat luas dan beragam dalam pendekatan yang memungkinkan sehingga jawaban realistis apa pun untuk pertanyaan yang tak terhindarkan hanya dapat menunjukkan jalan keseluruhan.
Banyak orang saat ini ingin dan berharap untuk membangun kehadiran web yang dinamis (berbasis data), arsitektur yang siap mengakomodasi materi baru, revisi, dan interaksi pengunjung. wikiHow misalnya adalah situs web dinamis. Sementara tujuan proyek berkualitas berada dalam jangkauan semua orang yang rajin, adalah kesalahan untuk meremehkan apa yang pada akhirnya merupakan tugas yang sangat menantang, terutama dalam objek teknis dari setiap proyek prospektif. Bahkan kehadiran web dinamis yang paling sederhana pun membutuhkan keterampilan yang memadai dalam berbagai disiplin ilmu.
Dalam memenuhi tujuan yang sangat diperlukan, tidak ada yang bisa menyimpang dari desain database yang baik. Mempersiapkan diri kita sendiri dalam disiplin ini saja sudah merupakan pekerjaan yang substansial (tetapi bukan merupakan hal yang mutlak). Setelah kita memiliki ringkasan tujuan proyek, kita harus membayangkan cara yang baik untuk mencapainya. Kemudian kami memiliki bahasa pemrograman atau alat untuk dipilih, berdasarkan visi untuk arsitektur proyek yang ideal.
Melihat keseluruhan gambar dari awal, adalah keterampilan yang paling penting dari semuanya.
Langkah
Langkah 1. Dapatkan otak Anda tentang alat dan proses seperti apa yang akan mencapai tujuan Anda
Karena inti paling sentral dari setiap kehadiran web dinamis adalah basis data dan pemrosesan datanya, tujuan vital pertama kami adalah membuat keputusan jangka panjang tentang mesin basis data. Bukanlah ide yang baik untuk berharap dengan santai membuat keputusan seperti itu hanya dengan cara awal yang tampaknya paling masuk akal.
- Objek penting dari keputusan pertama ini adalah untuk merencanakan proyek kami dengan cara (dengan alat dan mesin database) yang akan mendukung kebutuhan Anda sepanjang jalan melalui masa depan, di mana, karena Anda membuat keputusan awal yang tepat, Anda akan membangun secara efektif di atas fondasi awal Anda, secara efisien dan tanpa hambatan. Ini berarti bahwa idealnya misalnya, mesin database yang Anda pilih tidak hanya mudah, atau tampaknya sederhana untuk digunakan hari ini; sejak awal itu harus menjadi mesin yang akan mendukung tuntutan pemrosesan hilir Anda.
- Terkadang pertimbangan komersial lebih jauh mempengaruhi pilihan tersebut. Mesin apa yang membutuhkan kehadiran intensif (dan mahal)? Mesin apa yang hampir bebas kehadiran dalam implementasi yang mendukung tujuan pemrosesan yang harus dipertahankan oleh proyek akhir Anda? Umumnya, pola yang harus diikuti adalah memilih mesin Anda berdasarkan salah satu dari dua kemungkinan disposisi.
- Untuk melakukannya, Anda harus terlebih dahulu memetakan kebutuhan tabel dasar Anda. Seorang profesional bahkan tidak perlu membuat peta ini (meskipun ratusan atau ribuan tabel terlibat), karena mereka biasanya akan segera melihat apakah arsitektur dan kebutuhan masa depan yang perlu Anda dukung bersifat intensif baca atau tulis. Anda kemudian akan memilih database yang sesuai, berdasarkan disposisi keseluruhan ini, dan mungkin lebih lanjut berdasarkan selera dan pengalaman pribadi, karena bekerja dengan alat pengembangan perangkat lunak masing-masing dapat menjadi predikat. MySQL adalah pilihan biasa untuk implementasi intensif baca. Banyak pengembang melihat ke database seperti PostgreSQL untuk implementasi intensif penulisan yang andal. Kami mengembangkan disposisi kami terhadap alat vital seperti itu dengan penelitian yang cermat, dan dengan memanfaatkan kumpulan pengalaman industri pengembangan perangkat lunak umum. Pengeluaran biasanya dapat dihindari, karena tersedianya alat yang sangat bagus secara gratis. Apa yang kami cari adalah kinerja dalam lingkungan intensif baca atau tulis, keandalan, kemudahan dan minimalisasi administrasi, dan integrasi yang siap dengan alat pengembangan perangkat lunak yang prospektif.
Langkah 2. Pilih alat pengembangan perangkat lunak Anda
Ada dua pola yang perlu dipertimbangkan dalam memilih alat pengembangan perangkat lunak. Alat yang konon "mudah" jarang sebenarnya mudah, ketika sebuah proyek mau tidak mau merusak pemeran pengembangan dan pola fungsionalitas alat "mudah" umumnya terbatas. Jika Anda ingin melakukan sesuatu di luar alat "mudah" seperti memasukkan bahasa atau parameter terjemahan dalam URL yang dibuat secara dinamis, mungkin jauh lebih sulit untuk mencapai alat "mudah" yang mungkin memerlukan keterampilan pemrograman yang sangat canggih untuk melakukannya. seperti mengelabui pola yang mudah untuk melakukan hal-hal yang lebih kompleks. Kita harus menguasai alat kita untuk membangun proyek yang bagus. Ini tidak membuat alat yang mudah menjadi pilihan terbaik, atau alat yang paling canggih menjadi proposisi yang sulit. Jebakan pembangunan "mudah" umumnya terdiri dari keterbatasan yang menjadi sangat mahal untuk diatasi dalam evolusi proyek yang tak terhindarkan. Berbagai macam alat tersebut umumnya muncul, seolah-olah memenuhi kebutuhan tersebut. Tetapi pola ketekunan alat-alat itu menunjukkan fakta nyata bahwa telah mencapai tujuan ini; jadi, umumnya kita menemukan bahwa alat yang paling canggih dan kuat, mengikuti pola yang baik (atau ketersediaan objek dan perpustakaan), tidak hanya mengurangi hambatan praktis yang tak terelakkan untuk alat yang mudah, tetapi juga membuat "sampai di sana" proses yang jauh lebih mudah. Ketika kami memeriksa ruang lingkup alat yang tersedia, umumnya model yang kurang komprehensif disajikan dalam konsep pengembangan awal, dan konsep yang lebih baik ditawarkan oleh alat yang muncul kemudian (atau mereka tidak akan memiliki kesempatan untuk bertahan di pasar yang telah dimenangkan). Jika kita memilih alat yang konon mudah, apa yang kita cari adalah pola pengembangan yang dapat digunakan dan tanpa hambatan. Paradoks bagi orang baru kemudian adalah kesulitan untuk melihat sejauh ini sehingga kita dapat merasakan hambatan pemrograman pada perangkat alat tertentu. Beberapa orang percaya bahwa alat terbaik adalah yang paling kuat dan paling tidak membatasi dalam hal pendekatan proyek. Kebebasan untuk mengembangkan apa yang Anda inginkan dan butuhkan sering kali berarti mematahkan model umum dari alat yang tampaknya sederhana, tantangan yang secara praktis dapat mematahkan otak insinyur perangkat lunak yang paling berpengalaman dan canggih, karena berhasil dalam objek seperti itu berarti membuat "sederhana" model melakukan sesuatu yang mungkin tidak memiliki kapasitas asli untuk mendukung. Apakah "Ruby" misalnya benar-benar alat yang lebih mudah daripada C++ atau C# mendasar? Tidak. Tidak juga, terutama jika Anda harus memecahkan model sederhana Ruby untuk menghadirkan fungsionalitas vital. Seperti Ruby, GCC gratis untuk Linux dan OSX. Ruby juga hadir di OSX Anda hanya perlu menemukannya di sistem Anda. Dari alat yang konon lebih mudah, pilihan pribadi saya adalah Ruby. Dari alat yang benar-benar canggih, C++ dan C# akan berkuasa lama di masa depan; dan sebenarnya, ini adalah satu-satunya kendaraan untuk pembangunan tanpa halangan. Jadi duduk tegak dan bersiaplah untuk belajar serius, karena terlepas dari jalan yang Anda pilih, Anda tidak hanya harus menguasai alat-alat Anda, tetapi juga model-model yang berpotensi membatasi yang pada akhirnya akan membebani Anda dengan alat-alat itu. Ruby mungkin jauh lebih bersih daripada hampir semua rekan "mudahnya". C++ adalah alat keunggulan yang tidak terbebani; dan pada kenyataannya, guru berpengalaman akan menghasilkan proyek yang tak tertandingi mungkin dengan kesulitan yang jauh lebih sedikit daripada yang mungkin mereka capai tujuan yang sama dengan alat yang konon mudah. Pada akhirnya, pengembang yang menyimpang dari pengamatan ini membayar beberapa harga: baik memilih alat "mudah" yang paling kondusif, atau kurang khawatir atas kebebasan dari beban di alat yang paling canggih. Dalam kasus terakhir, Anda menguasai objek Fast CGI, mengambil bola dan berlari. Konsep besar sering diimplementasikan dengan sedikit kode. Ya, alat sederhana membuat klaim yang sama, tetapi dengan mengabstraksikan kesulitan yang nyata dari kita sedemikian rupa sehingga menyimpang dari pola yang biasanya tunggal menimbulkan tantangan rekayasa yang sangat sulit, selain cacat kinerja yang diselesaikan oleh C++.
Langkah 3. Dalam menyelesaikan pertanyaan-pertanyaan ini, mau tidak mau kita harus memeriksa model-model atau pola-pola dasar dari proyek-proyek yang sedang berkembang yang sifatnya ingin kita wujudkan
Ini berarti mengambil literatur terbaik untuk alat yang ingin kita bandingkan, dan setidaknya memberikan konsep kita beberapa bentuk yang mungkin diperlukan dalam seperangkat alat tertentu, dibandingkan dengan yang lain. Sebelum Anda memilih Ruby misalnya, Anda mungkin mengambil buku-buku penting seperti "The Ruby Programming Language," dan "Agile Web Development with Rails." Studi awal Anda tidak hanya harus cukup menguasai alat, tetapi juga harus membayangkan bagaimana Anda bisa sampai di sana bagaimana Anda dapat menyediakan fungsionalitas yang diinginkan dengan alat yang mungkin Anda pilih. Ini adalah tugas yang menakutkan bagi para inisiat. Jika Anda akan membandingkan lingkungan pengembangan yang konon mudah dengan yang terbaik dari yang terbaik, Anda juga harus mengevaluasi alat C terbaik. Jika Anda benar-benar akan menjadi insinyur berpengalaman, Anda akan memilih C karena kebebasannya dari batasan. Apakah C benar-benar lebih sulit? Tidak. Sintaks adalah sintaks. Pada akhirnya, Anda harus menguasai mengekspresikan fungsi yang sama; dan sebenarnya, keluarga bahasa C sangat bagus. Hal yang sulit tentang unggul langsung di C++ adalah meletakkan tangan Anda pada model yang mungkin perlu Anda bangun. Awal yang sangat baik dari hampir 15 tahun yang lalu adalah komponen FastCGI asli yang tersedia di CPPBuilder Borland mungkin masih merupakan C++ terbaik untuk Windows. Bahkan inisiat C dapat melangkah jauh dengan pendekatan berorientasi objek seperti itu, karena model umum dari fungsi pendukung dibangun ke dalam hal-hal yang Anda kerjakan. Pekerjaan Anda jauh lebih mengalir bebas daripada di Ruby misalnya, kapan pun Anda mungkin merusak atau melampaui model Ruby dalam pendekatan Anda. Di sisi lain, teknik perancah Rails mempercepat banyak pekerjaan untuk orang baru, jika dan hanya jika proyek sesuai dengan cetakan umum Ruby dan Rails. Perkenalkan ketentuan keamanan dasar misalnya, yang dikenali di semua antarmuka Ruby Anda, dan hal berikutnya yang Anda tahu, Anda menulis ulang seribu baris kode Ruby yang dibuat secara otomatis untuk setiap tabel yang dinegosiasikan oleh aplikasi Anda. Apakah itu mudah? Yah, saya melakukannya dengan editor Windows bernama NoteTab Pro, yang beroperasi pada proyek Ruby yang berada di sistem OSX; dan makro canggih membuat revisi saya mungkin dalam hitungan detik, menyesuaikan seribu baris kode menjadi hampir dua kali lipat. Namun, ini terkait dengan fungsionalitas dasar yang relatif sederhana, yang dibatasi oleh proyek. Faktanya adalah, dalam C++ kita dapat menulis objek kita sendiri yang menangani tugas-tugas ini benar-benar universal Anda bahkan tidak perlu mereplikasi proses ini. Jadi ini adalah trade-off. Pada akhirnya, C berorientasi objek adalah yang paling kuat dan efisien. Yang berarti itu adalah pekerjaan yang paling sedikit juga.
Langkah 4. Apa pun pilihan alat pemrograman Anda, tidak ada cara untuk menghindari ketergantungan pada penguasaan HTML dan CSS yang wajar
Umumnya, pengembang berpengalaman mengandalkan W3C.org untuk materi penting. halaman web
Video - Dengan menggunakan layanan ini, beberapa informasi dapat dibagikan dengan YouTube
Tips
- Bagian penting dari pencarian Anda adalah mendapatkan sumber daya terbaik. Saya akan mulai dengan Ruby; dan jika Anda ingin unggul, Anda harus mengevaluasi bahasa C berorientasi objek, dan lingkungan di mana proyek yang ditulis dengan baik akan mengungguli semua rekan.
- Oleh karena itu, tidak ada yang dapat menggantikan studi dan evaluasi yang menyeluruh.
Peringatan
- Hambatan lebih lanjut untuk benar-benar menguasai alat sederhana adalah perilaku tidak profesional di banyak forum. Ada perbedaan besar antara pengetahuan profesional dan keterampilan pura-pura yang sering kali dapat menyesatkan Anda jauh dari jalan yang benar. Sumber informasi terbaik umumnya adalah rekan-rekan yang paling berhasil, bukan ahli berpura-pura alat sederhana yang hanya menganjurkan untuk tetap berpegang pada satu pola yang tersedia bagi mereka. Alasan utama Anda akan mengirimkan pertanyaan ke forum adalah Anda harus melampaui (dengan demikian mematahkan) model yang terdiri dari pendekatan yang konon sederhana. Ketika Anda pasti mengalami kebutuhan ini, Anda memerlukan saran terbaik.
- Jangan pernah berpikir bahwa jalan pintas yang tampak benar-benar mempercepat pekerjaan. SANGAT sering, kebalikannya yang benar.
