Pengembang WordPress: Mulai Di Sini!

Selamat datang di panduan pemula kami untuk pengembang WordPress! Apakah Anda bekerja sebagai pekerja lepas atau sebagai bagian dari agensi media. Pada artikel ini, kami akan membahas berbagai topik yang terkait dengan pengembangan WordPress bersama dengan beberapa sumber daya dan alat yang tersedia.
Teks diatur di sekitar tahapan berbeda yang mengalir antara generasi ide dan pengiriman. Kita akan berbicara tentang brainstorming, pembuatan prototipe, pengembangan, dan terakhir tentang penerapan. Semua ini, dalam konteks pengembangan produk. Kami percaya bahwa antara firasat pertama dari sebuah ide dan eksekusi akhirnya ada banyak area halus. Beberapa dibiarkan tidak dibahas paling baik dan yang lain benar-benar belum dijelajahi, dalam literatur WordPress saat ini.  

Jika Anda adalah klien Pressidium, Anda dapat segera mulai menggunakan alat yang telah kami buat di sekitar platform kami, sehingga Anda dapat menikmati manfaat integrasi tingkat tinggi. Kami akan berbicara tentang apa alat-alat ini juga.   Harap diingat bahwa ini adalah dokumen langsung dan harus diperlakukan seperti itu.

Pertama dan terpenting tujuan kami adalah agar dokumen ini berguna untuk latihan Anda sebagai pengembang WordPress, dan kedua untuk menunjukkan kepada Anda beberapa hal keren yang kami buat hanya untuk Anda.

Dari ide hingga penerapan  

Baik Anda mengerjakan produk baru atau telah mengambil beberapa pekerjaan klien, proses beralih dari ide ke penerapan terdiri dari 4 tahap. Meskipun tahapan ini terpisah, mereka tumpang tindih secara signifikan dan tidak linier. Kami akan membahas ini lebih lanjut dalam teks:  

1. Brainstorming dan elisitasi persyaratan.
2. Membuat prototipe.
3. Perkembangan.
4. Penyebaran.

Proses brainstorming asosiatif bebas digunakan ketika Anda ingin mulai membangun produk, atau proyek dan Anda membutuhkan ide. Pengumpulan persyaratan, bagaimanapun, terjadi ketika Anda ditugaskan untuk membangun sebuah proyek untuk klien atau menyimpulkan sebuah ide setelah sesi brainstorming. Anda masih dapat mengatur sesi brainstorming setelahnya untuk memecahkan masalah tertentu, tetapi sesi tersebut akan lebih dibatasi.

Prinsip dasar brainstorming ada dua. Pergi untuk kuantitas, dan tunda penilaian untuk nanti. Kami telah menulis di masa lalu tentang bagaimana Anda dapat memfasilitasi sesi seperti itu, bagaimana membangun pola pikir yang tepat, dan beberapa alat yang funky untuk membantu Anda.

Memunculkan persyaratan

Ada beberapa metodologi yang digunakan untuk memperoleh persyaratan, dan secara tradisional ini selalu menjadi pekerjaan seorang analis bisnis. Meskipun merupakan tanggung jawab klien untuk memberikan informasi tentang persyaratan proyek, pemahaman bersama perlu dibangun untuk semua pemangku kepentingan. Persyaratan elisitasi adalah proses yang berbeda dari pengumpulan persyaratan. Ini lebih tentang membawa keluar informasi yang diperlukan melalui partisipasi aktif. Dan ini bukan tentang mengumpulkan secara pasif ke dalam dokumen apa yang dikatakan klien kepada Anda dan meneruskannya ke tim pengembangan.

Bergantung pada ruang lingkup dan sifat proyek, Use Cases adalah cara yang bagus untuk menangkap fungsionalitas. Use Cases adalah teknik yang digunakan dalam diagram UML sebagai cara untuk menggambarkan interaksi antara pemangku kepentingan dari suatu sistem, dan sistem itu sendiri. Karena mereka adalah kumpulan skenario yang ditulis dalam bahasa Inggris yang sederhana namun terstruktur, tidak hanya mereka tidak terlalu rumit tetapi juga merupakan cara yang cepat dan efisien untuk mulai mendiskusikan dan membuat sketsa fungsionalitas sistem.

Anda mungkin perlu menyiapkan wawancara terstruktur dengan semua pemangku kepentingan jika Anda ingin menangkap persyaratan untuk produk yang kompleks. Untuk ini, Kisah Pengguna adalah cara yang sempurna. Mereka adalah bagian dari pola pikir Agile dan merupakan cara informal untuk mulai berbicara tentang persyaratan, untuk membangun pemahaman bersama. Deskripsi singkat fungsi ditulis dalam kartu kertas, biasanya Post-It Notes, dan dikocok di papan tulis untuk membuat narasi perjalanan pengguna. Cerita pengguna dihasilkan di tempat, melalui partisipasi, diskusi, dan manipulasi kartu di papan tulis. Detailnya perlahan disempurnakan dan akhirnya ditambahkan sebagai fitur di backlog produk. Jeff Patton telah menulis buku yang sangat bagus tentang Pemetaan Cerita Pengguna yang sangat kami rekomendasikan jika Anda ingin mengetahui lebih banyak tentang subjek tersebut dan mulai menggunakannya dalam proyek Anda.

Cerita pengguna bukanlah hal statis yang pernah dibuat selamanya dilupakan. Sebaliknya, mereka adalah peta dinamis, di mana tim pengembangan dan produk dapat kembali lagi dan lagi, saat tahap pembuatan prototipe terjadi, dan produk mulai terbentuk.

Pentingnya prototipe adalah untuk menjawab pertanyaan. Meskipun ada beberapa metodologi prototyping, kami percaya bahwa metodologi evolusioner adalah yang paling tepat untuk tujuan kami dan yang dapat diadaptasi ke dalam jalur pengembangan perangkat lunak Agile modern. Dalam metodologi prototipe evolusioner, prosesnya bersifat siklus, di mana prototipe menjadi semakin disempurnakan melalui setiap siklus.

Setiap iterasi prototipe bergerak dari fase desain ke fase pengembangan dan evaluasi. Ini memunculkan masalah desain awal dan memberikan sesuatu yang nyata yang dapat ditunjukkan orang dan berbicara tentang apa yang dapat ditingkatkan. Wawasan yang dikumpulkan dari fase evaluasi digunakan dalam iterasi prototipe berikutnya dan siklus berulang sekali lagi. Dengan demikian, prototipe perlahan-lahan berkembang ke sistem akhir hingga mencapai kematangan sebagai produk jadi.

Pembuatan prototipe biasanya terjadi dalam kecepatan pengembangan yang cepat dan menggunakan sistem boilerplate seperti Bedrock, Sage, dan Bootstrap dapat sangat mengurangi waktu pengembangan. Sistem seperti yang disebutkan di atas menyediakan kerangka aplikasi yang lengkap, dan rantai alat yang diperlukan sehingga Anda tidak perlu memulai dari awal setiap saat. Prototipe evolusioner tidak sama dengan prototipe yang dibuang begitu saja. Yang terakhir adalah prototipe yang hanya dibangun sekali sebagai bukti konsep dan kemudian dibuang. Jika Anda menghabiskan banyak waktu untuk membangun prototipe e-niaga, mengapa tidak mengabstraksikan fungsionalitas umum dan menggunakannya lagi di masa mendatang daripada membuang semuanya dan memulai dari nol?

Di sinilah Pressidium Cloning berguna. Ini memungkinkan Anda dengan cepat mengkloning situs web hanya dengan satu klik, dan mulai berkembang. Dengan begitu Anda dapat menyiapkan beberapa situs web template menggunakan boilerplate, memuatnya terlebih dahulu dengan plugin, tema, dan konfigurasi yang diperlukan, dan mengkloningnya setiap kali Anda membutuhkannya dalam sebuah proyek. Anda juga dapat mengkloningnya ke akun Pressidium yang berbeda, misalnya, dengan klien Anda, dengan cara yang sama. Jangan khawatir jika prototipe Anda berada di penyedia hosting WordPress terkelola yang berbeda. Cukup gunakan Alat Wisaya Migrasi kami dan impor ke akun Pressidium Anda!

Tidak masalah jika Anda mengembangkan proyek WordPress sendiri atau berkolaborasi dengan sesama pengembang dan desainer WordPress, dua poin terpenting yang berkontribusi pada keberlanjutan kerajinan Anda dalam jangka panjang, adalah sebagai berikut:

1. Mempraktikkan kebiasaan perangkat lunak yang baik.
2. Dan mengetahui apa semuanya, di mana itu, dan mengapa itu ada.

Praktik terbaik bervariasi mulai dari secara konsisten mengikuti panduan gaya perangkat lunak hingga berlatih menulis kode bersih alih-alih pintar, dan sampai ke perangkat lunak tingkat tinggi dan pilihan desain UI. Poin kedua hanyalah dokumentasi, dan banyak bentuk yang dapat diambil di dalam sebuah proyek.  

Mengikuti panduan gaya perangkat lunak, sangat mudah. Pelajari sumber resmi WordPress.org tentang masalah ini dan kemudian putuskan pedoman mana yang masuk akal bagi Anda untuk memasukkannya ke dalam gaya pengkodean Anda. Mengubah kebiasaan adalah proses yang lambat, dan Anda harus mulai dengan membuat perubahan kecil pada awalnya. Pada akhirnya memiliki seperangkat pedoman yang harus dipatuhi oleh kode Anda, berarti memperkenalkan tinjauan kode di beberapa titik.

Tinjauan kode adalah cara sistematis untuk membaca dan memeriksa kode yang berupaya menghilangkan kesalahan, menjelaskan bagian kode yang sulit dipahami, dan memastikan bahwa kode mematuhi standar dan konvensi. Hal ini juga paling baik dilakukan oleh orang lain dalam tim Anda dan bukan oleh Anda.

Host situs web Anda dengan Pressidium

GARANSI UANG KEMBALI 60 HARI

LIHAT RENCANA KAMI

Memilih kode bersih untuk pintar adalah pengembangan perangkat lunak "mutiara kebijaksanaan" yang sayangnya hanya dapat dihargai hanya setelah jatuh ke dalam perangkap kode pintar. Kesimpulannya adalah ini: Meskipun dalam beberapa kasus kode pintar dapat memberi Anda poin "peretas" dan tepukan di punggung, dan bahkan peningkatan kinerja dalam beberapa kasus, Anda akhirnya kalah dalam jangka panjang. Kode yang "retas" dan sulit dibaca akan menjadi tidak dapat dipahami di masa depan. Dan mungkin Anda harus membayar ketika Anda perlu memecahkan masalah bug yang sangat sulit dipahami. Menemukan keseimbangan antara menulis kode yang dioptimalkan dan bersih adalah sesuatu yang perlu Anda temukan sendiri, tetapi selalu lebih baik untuk berbuat salah di sisi yang bersih.

Juga karena kinerja situs WordPress sangat bergantung pada penggunaan cache browser yang benar, penting untuk mengetahui bagaimana penyedia hosting WordPress terkelola Anda menggunakan caching. Kode Anda kemudian akan bekerja secara sinergis dengan platform hosting Anda, sehingga memiliki kinerja terbaik. Namun, perlu diingat bahwa mengukur kecepatan situs web Anda dengan cara yang benar tidak semudah yang dibayangkan, dan mengandung beberapa gotcha!

Jadi, berbicara tentang praktik terbaik tingkat tinggi, keputusan yang menyebabkan WordPress memisahkan fungsionalitas intinya dan menyediakan REST API tentu saja dapat dianggap sebagai contoh praktik tersebut. Keputusan ini menandai langkah menuju era baru, menuju Sistem Manajemen Konten terprogram, dan pengembangan aplikasi WordPress "tanpa kepala".

  Kami telah menulis pengantar dan tutorial singkat untuk WordPress REST API dan cara sederhana untuk mulai mengutak-atiknya menggunakan plugin browser seperti Postman.

  Keputusan desain perangkat lunak ini tampak sederhana namun kuat. Pengembang WordPress sekarang dapat menggunakan WordPress untuk mengimplementasikan aplikasi dan fungsionalitas yang jauh melebihi situs web atau blog. Salah satu contoh yang sangat tepat adalah prototipe Kanban kami.

Kami menggunakan entitas WordPress seperti kategori, dan posting, untuk memodelkan papan Kanban dengan tugas, kolom, dan aliran nilai. Kami membuat sketsa API Kolom dan Kartu Kanban, yang menyatukan semuanya.

Dokumentasi

Orang akan berpendapat bahwa praktik perangkat lunak terbaik kondusif untuk menulis dokumentasi yang lebih baik, dari komentar kode sederhana, hingga hasil proyek dan berpuncak pada salinan produk.  

Tidak peduli bagaimana Anda melihatnya, dokumentasi adalah aset.  

Dalam hal dokumentasi teknis, bahasa yang digunakan secara tertulis jelas berbeda dari bahasa yang Anda gunakan saat berkomunikasi sehari-hari, atau bahasa yang Anda gunakan di tempat kerja. Bentuk penulisan ini disebut penulisan teknis, dan tidak digunakan dalam komputer atau rekayasa perangkat lunak saja. Faktanya, ini digunakan di semua profesi yang perlu mengkomunikasikan konsep teknis kepada audiens spesialis, seperti hukum, kedokteran, aeronautika, dan sebagainya. Ini adalah subjek besar, dan bahkan ada beberapa perguruan tinggi yang menawarkan sertifikasi penulisan teknis. Raison d'etre-nya adalah untuk mengkomunikasikan informasi teknis menggunakan bahasa yang jelas dan ringkas. Suara aktif lebih disukai daripada pasif, dengan yang terakhir digunakan dalam kasus di mana teks deskriptif diperlukan untuk menjelaskan konsep.

Seorang penulis teknis perlu diingat bahwa pembaca adalah seseorang, yang sering frustrasi saat mencari sedikit informasi tertentu. Akibatnya, tulisan Anda tidak perlu menghalangi. Tujuannya adalah untuk membuat proses ini mudah, lugas, dan bahkan menyenangkan!  

Meskipun Anda tidak perlu memiliki gelar atau menjadi penulis teknis profesional, mengetahui bagaimana mengkomunikasikan konsep secara ringkas dan sederhana sangat penting untuk karir Anda sebagai pengembang WordPress. Jadi, kapan pun Anda perlu menulis dokumentasi untuk plugin, tema, atau API yang telah Anda buat (dan bangga!), Anda harus memiliki dasar-dasarnya. Untuk alasan itu, kami telah menulis panduan singkat untuk mendokumentasikan plugin dan tema WordPress Anda, yang juga mencakup 5 prinsip dasar penulisan teknis.

Tetapi dokumentasi tidak berhenti di situ. Dalam kasus ketika tema atau plugin Anda adalah bagian dari proyek yang lebih besar, atau ketika mereka sendiri cukup kompleks, orang harus mulai berpikir dalam hal dokumentasi produk. Menambah kebenaran bahwa dokumentasi adalah aset, dokumentasi produk pada gilirannya adalah aset pemasaran. Ini dengan tepat dikemas dalam kutipan berikut oleh Mike PuterBaugh, Wakil Presiden Pemasaran di MindTouch, dalam artikel Mashable tentang pentingnya dokumentasi produk:

Ini bukan pekerjaan yang seksi, tetapi akan memberi Anda rasa hormat dari rekan-rekan Anda, manajemen perusahaan yang lebih efektif, dan tim yang lebih kolaboratif. Karena ini bukan tentang kuartal ini atau tahun ini, melainkan tentang mempengaruhi keunggulan kompetitif dan pertumbuhan jangka panjang.

Dalam hal produk, selain bentuk dokumentasi tertulis yang paling umum, ada beberapa lagi, seperti bantuan online, panduan gaya, konten mikro, dan sebagainya. Dokumentasi produk biasanya ditulis dalam kolaborasi oleh banyak orang yang berbeda, yang menambah lapisan kerumitan ekstra. Kami telah menulis panduan ekstensif yang membantu Anda mulai berpikir dan merencanakan cara ini juga.

Terakhir, saat kami beralih ke tahap terakhir dari proses, yaitu penerapan, kami menempatkan bagian terakhir dari teka-teki dokumentasi: Diagram Penerapan. Ini membantu Anda memiliki gagasan yang jelas dan bulat tentang apa semuanya itu, dan di mana seharusnya.

  Meskipun kebanyakan orang akan lari sambil berteriak ngeri setelah mendengar tentang UML (dan cukup dimengerti, spesifikasi lengkap UML sangat buruk), untuk pertahanannya, UML berisi subset alat notasi yang dapat menambah nilai pada sebuah proyek. Diagram penerapan adalah notasi yang sangat sederhana yang terdiri dari hanya node dan jalur komunikasi yang dapat menunjukkan kepada Anda secara sekilas, lingkungan berbeda yang ada dalam proyek Anda, dan di mana setiap komponen perlu digunakan.

Kami akan mempelajari UML lebih banyak di masa mendatang, terutama untuk notasi berguna lainnya yang disebut Diagram Urutan, serta contoh diagram skenario Use Case yang lebih mendetail untuk menyempurnakan persyaratan proyek, dan membangun prototipe.

Sebagian besar, jika tidak semua pengembangan dan penerapan modern menggunakan beberapa bentuk kontrol versi, seperti git dan SVN. Repositori kode sumber tidak hanya penting untuk tim saja, karena manfaatnya sangat luas bahkan jika Anda adalah pengembang WordPress tunggal.

Jika Anda adalah klien Pressidium, Anda dapat mengintegrasikan repositori Anda dengan akun Anda melalui SFTP, dengan menggunakan layanan eksternal seperti deploybot. Atau Anda dapat menggunakan SFTP untuk mentransfer file Anda ke akun Anda, karena ini adalah metode termudah dan paling mudah. Anda juga dapat membuat beberapa pengguna SFTP dan menetapkannya ke situs web dan lingkungan tertentu. Omong-omong, memiliki lingkungan pementasan untuk situs web Anda, memastikan bahwa proses pengembangan dan penerapan Anda lebih efisien, dan situs web produksi Anda tetap aman dari perubahan yang tidak diinginkan. Misalnya, setelah mengaktifkan pementasan untuk situs web Anda, Anda dapat menarik salinan dari produksi, lalu membuat akun SFTP untuk pengembang Anda yang hanya memiliki akses di lingkungan pementasan.

Menyiapkan alur pengembangan yang disederhanakan yang melewati beberapa lingkungan adalah salah satu perubahan yang dibawa gerakan DevOps ke lingkungan TI. Mengadopsi disiplin Pengiriman Berkelanjutan dan mendorong perubahan perangkat lunak secara bertahap dan sering, menghasilkan siklus penerapan yang lebih cepat, dan lebih sedikit kesalahan. Anda tidak perlu lagi memelihara arsip ZIP dengan berbagai versi aplikasi Anda. Dengan begitu, Anda dapat dengan mudah kehilangan jejak, dan menerapkan rangkaian perubahan yang salah yang dapat membahayakan sistem produksi Anda. Ada juga bahaya memiliki masalah dengan izin file yang menjadi rusak yang paling baik, dapat menyebabkan aplikasi Anda tidak berfungsi dengan baik, dan paling buruk, menimbulkan masalah keamanan.

Epilog

Kami tahu bahwa waktu luang Anda sebagai pengembang WordPress sangat terbatas. Itu sebabnya kami menggabungkan semuanya dalam satu dokumen karena kelebihan informasi itu nyata, dan tampaknya berdampak pada semua pekerja pengetahuan, dan bukan hanya pengembang WordPress. Kami menyebutkan di awal bahwa tujuan kami adalah pertama-tama memberikan informasi yang berguna, dan kedua untuk membahas topik yang kami rasa kurang terwakili dalam literatur WordPress saat ini. Menjadi pengembang WordPress adalah satu hal, tetap relevan, dan kompetitif adalah hal lain . Dan untuk melakukannya, Anda harus memiliki pandangan menyeluruh tentang rekayasa perangkat lunak sebagai suatu disiplin, dan memperoleh kebiasaan, metodologi, dan teknik yang baik yang akan melayani karir Anda dalam jangka panjang.