Kita semua memiliki kebiasaan buruk. Pada artikel ini, kita akan membahas daftar praktek-praktek buruk yang layak dikaji, dievaluasi, dan memperbaiki segera.


Kamu Pikir Kamu Siapa?

Setiap kali saya membuka proyek yang bukan milikku, selalu disertai dengan ketakutan bahwa aku berjalan ke dalam beberapa jenis skenario yang buruk, penuh dengan pintu perangkap, kode rahasia, dan bahwa setelah perubahan satu baris kode, berpengaruh ke seluruh applikasi.

Ketika kita salah, dan semuanya baik-baik saja terlepas dari beberapa perbedaan kecil dalam “bagaimana saya akan melakukannya,” kita menghirup napas lega, menggulung lengan baju, dan menyelam ke dalam proyek.


Jawabannya Mungkin Akan Mengejutkanmu

Kode mengerikan adalah akumulasi dari beberapa cara pintas kecil atau konsesi.

Insting pertama Anda mungkin menganggap bahwa orang yang membangun proyek ini adalah seorang pemula, atau mungkin dia hanya idiot. Tapi itu tidak selalu terjadi.

Bahkan yang lebih menakutkan, ini bisa berarti bahwa di beberapa titik, seseorang mewarisi kode Anda dan segera menangis.


Kamu bisa lebih baik dari itu, Sayang!

Tidak ada salahnya untuk menguji kembali praktik Anda saat ini dan pastikan Anda tidak mengambil jalan pintas yang dapat berkontribusi terhadap orang lain kehilangan tidurnya.

Let’s take a few minutes and go over some common shortcuts, concessions, and other bad practices to ensure that our projects aren’t striking fear into the hearts of the villagers.

Mari kita mengambil beberapa menit dan menjelajahi beberapa shortcut umum, konsesi, dan praktek-praktek buruk lainnya untuk memastikan bahwa proyek-proyek kami tidak membawa ketakutan ke dalam hati penduduk desa.


1. Kamu tidak memiliki rencana sebelum memulai koding

Sebelum Anda menulis satu baris kode, Anda harus memiliki rencana yang solid.

Sebelum Anda menulis satu baris kode, Anda harus memiliki rencana yang solid. Ini membantu menjaga Anda pada jalur dan menghindari berkeliaran kode yang akan membingungkan nanti.

Salah satu pendekatan yang telah menyelamatkan waktu saya – baik dalam pengembangan dan dalam mengomentari – adalah untuk menulis sebuah garis besar pada komentar pertama kali:

    <?php
    // Include necessary data
    // Initialize the database connection
    // Include the common header markup
    // Determine the page variables from the POST data
    // Load the proper database info using the page vairiables
    // Loop through the loaded rows
        // Format the images for display
        // Create a permalink
        // Format the entry for display
        // Add the formatted entry to the entry array
    // Collapse the entry array into page-ready markup
    // Output the entries
    // Include the common footer markup

Seperti yang Anda lihat, tanpa menulis satu baris kode, saya sudah tahu hampir persis file tersebut akan terlihat seperti apa. Yang Terbaik dari semua, Anda dapat merencanakan seluruh aplikasi dengan cara ini, dan jika Anda mendapatkan titik di mana satu fitur memerlukan fungsi tweak ke yang lain, yang harus Anda lakukan adalah mengubah komentar.

Hal ini membutuhkan suatu pergeseran dalam cara Anda mendekati pembangunan kode program, tetapi itu akan membuat keterampilan organisasi proyek Anda lebih baik lagi.

Catatan:

Beberapa komentar ini tidak diperlukan, beberapa dari mereka akan berubah, yang lain akan perlu ditambahkan – yang diharapkan. Ini adalah jenis seperti menulis outline untuk kertas atau menulis daftar belanjaan: itu hanya membuat Anda di jalur yang benar ketika Anda pergi untuk menyelesaikan pekerjaan.

 


2. Kamu tidak mengomentari apapun

Namun masalah terburuk dengan sebagian besar kode yang saya hadapi adalah kode itu memiliki komentar yang buruk, atau tidak berkomentar sama sekali.

Itu membuat saya sedih bahwa saya harus menulis ini. Ketika sesuatu semudah komentar, tidak harus menjadi sesuatu yang kita harus saling mengingatkan untuk melakukan.

Ini tidak hanya menambah waktu untuk sosialisasi awal dengan proyek, tapi cukup banyak jaminan bahwa kode yang dibuat menggunakan metode tidak konvensional akan membingungkan saya. Lalu, jika saya akhirnya melakukan refactoring apapun, saya akan sengaja mematahkan app karena saya tidak menemui keadaan khusus yang membutuhkan perbaikan.

Proses ini bisa berlangsung dari 10 menit sampai 6 jam. (Dan Anda telah melakukan ini padaku, aku tahu di mana Anda tinggal. Aku akan datang kepada Anda.)

Jadi katakan ini keras-keras

Aku, [sebutkan nama], dengan ini bersumpah untuk membuat komentar dalam setiap situasi dimana tujuan dari kode yang saya tulis menjadi tidak jelas jika tidak diberikan komentar.

“Segera jelas” mengacu pada kode yang tidak dapat mendokumentasikan diri (karena tidak akan masuk akal untuk melakukannya) dan / atau tidak menyelesaikan tugas sangat-sederhana.

Untuk mengilustrasikan poin saya, saya akan menggunakan contoh dibawah ini :

$pieces = explode('.', $image_name);
$extension = array_pop($pieces);

Apa yang  dilakukannya? Apakah kamu berhenti  dan berpikir tentang hal itu? Apakah kamu masih tidak tahu apa yang disimpan di $extension?

Lihatlah potongan itu lagi, tapi dengan satu komentar singkat:

    // Get the extension off the image filename
    $pieces = explode('.', $image_name);
    $extension = array_pop($pieces);

Lima detik pada suatu waktu akan menambahkan nilai lebih pada keseluruhan proyek.

Sekarang melirik kode ini tidak memerlukan kekuatan otak tambahan: Anda melihat komentar, lihat kode tersebut, dan tidak perlu mempertanyakan maksudnya.

Ini mungkin hanya menghemat lima detik kontemplasi, tetapi jika Anda punya aplikasi yang kompleks, lima detik pada suatu waktu akan menambahkan nilai lebih pada keseluruhan proyek.

Jadi berhenti membuat alasan. Tuliskan komentar sialan itu.


3. Kamu Mengorbankan Kejelasan Untuk Keringkasan

Contoh yang baik dari mengorbankan kejelasan untuk meringkas termasuk nama variabel tidak jelas dan menghilangkan kurung kurawal.

Ini adalah godaan universal untuk mendapatkan sesuatu dilakukan sebagai karakter sesedikit mungkin, tetapi godaan itu adalah jenis godaan seperti untuk hanya memiliki satu pasang pakaian dalam: yakinlah, mencuci akan dilakukan dengan cepat, tetapi masalah yang timbul dari pilihan Anda sangat lebih besar daripada manfaat.

Good examples of sacrificing clarity for brevity include short, unclear variable names (such as $a — what does $a store?) and dropping the curly braces.

Contoh yang baik dari mengorbankan kejelasan untuk keringkasan termasuk nama variabelyang pendek dan tidak jelas (seperti $a – apa yang disimpan $a?) Dan menghilangkan kurung kurawal.

Menghilangkan kurung kurawal dari struktur kontrol adalah mengesalkan saya. Jika Anda tidak suka kurung kurawal, beralih ke Python. Dalam PHP, terlalu mudah kehilangan makna tanpa mereka.

Sebagai contoh, lihatlah set bersarang pernyataan if-else tanpa kurung kurawal:

    <?php
    $foo = 8;
    if( $foo<10 )
        if( $foo>5 )
            echo "Greater than 5!";
        else
            echo "Less than 5!";
    else
        echo "Greater than 10!";
        echo "<br />Another note.";

At a glance, it looks like the last line should only fire if the value of $foo is greater than 10. But what’s actually happening is a case of improper indenting; the last echo statement will fire no matter what

Sepintas, sepertinya baris terakhir seharusnya hanya dieksekusi jika nilai $foo adalah lebih besar dari 10. Tapi apa yang sebenarnya terjadi adalah kasus Indentasi yang tidak benar, pernyataan echo terakhir akan dieksekusi tidak peduli apapun yang disimpan $foo.

Dapatkah Anda mencari tahu jika Anda melihat itu selama beberapa detik dan tahu bahwa pernyataan if-else tanpa kurung kurawal hanya mempengaruhi langsung baris berikutnya? Tentu saja.

Haruskah kamu membuang energi hanya untuk mencari tahu? Tentu saja tidak.

Menambahkan kurung kurawal menambahkan beberapa baris, tetapi menjelaskan pernyataan sangat, bahkan dengan identasi yang aneh:

    <?php
    $foo = 8;
    if( $foo<10 )
    {
        if( $foo>5 )
        {
            echo "Greater than 5!";
        }
        else
        {
            echo "Less than 5!";
        }
    }
    else
    {
        echo "Greater than 10!";
    }
    echo "<br />Another note.";

Ya, itu adalah hal yang baik untuk menjaga kode Anda ringkas, tetapi tidak dengan mengorbankan kejelasan. Ini perlu garis ekstra untuk memastikan tidak ada yang harus membenturkan kepala mereka terhadap keyboard ketika mencoba untuk menyaring kode Anda.


4. Kamu Tidak Mengikuti Coding Standard

Pilih standard dan mentaatinya

Melucu dengan format kamu bisa memuaskan artistik kamu, tapi itu tidak baik bagi siapa pun. Pilih standar (saya sarankan standar pengkodean PEAR) dan menaatinya. Semua orang akan berterima kasih. (Termasuk diri sendiri, suatu hari nanti.)

Percayalah. Saya adalah pria yang pernah – saya ingin memiliki “gaya pemrograman sendiri” – dan aku menyia-nyiakan banyak jam memperbaiki format mengerikan saya nanti. Ada waktu untuk menjadi berbeda dan waktu untuk melakukannya seperti orang lain.

When it comes to programming, think of it like a spoken language. Grammar and punctuation exist for a reason: so we can clearly understand each other when we write things down. Think of coding standards like a geeky version of Strunk & White’s Elements of Style — following the guidelines means people understand what you’re trying to say, not that you’re a boring person.

Ketika datang ke pemrograman, pikirkanlah ia seperti bahasa lisan. Tata bahasa dan tanda baca ada karena suatu alasan: sehingga kita dapat dengan jelas memahami satu sama lain ketika kita menulis suatu hal. Mengikuti pedoman berarti orang mengerti apa yang Anda katakan, tidak bahwa Anda adalah orang yang membosankan.


5. Kamu Menggandakan Kode

Anda salah melakukannya.

Jika Anda punya kode untuk melakukan hal yang sama di lebih dari satu tempat di app Anda, Anda salah melakukannya.


6. Kamu Tidak Mengikuti Pola Pengembangan

Kamu harus selalu memiliki struktur ketika membuat kode program

Anda harus selalu memiliki struktur ketika Anda membuat kode program. Saya tidak bermaksud mengatakan bahwa Anda harus mengikuti pola MVC atau sesuatu yang sama kaku, tapi yang saya maksud Anda harus tahu bagaimana mengklasifikasikan komponen dan di mana mereka harus pergi.

Dengan mengikuti pola pengembangan yang logis, banyak keputusan menjadi otomatis, dan seseorang datang ke dalam kode Anda tidak perlu menebak banyak ketika mencari fungsionalitas tertentu dalam basis kode Anda.

Tidak butuh waktu lama, dan itu benar-benar akan memperjelas aplikasi Anda di lingkup yang lebih besar.


7. You’re Too Clever for Your Own Good

Solusi paling sederhana biasanya yang paling tepat

Your super-sweet solution does, however, pose a problem in which someone else may not have seen that particular solution and will just get lost. It’s not because they’re not as smart as you, either; it’s likely because they didn’t see that particular article or weren’t trying to force a square concept into a round problem.

Don’t dumb yourself down, but remember to avoid overcomplicating things “just ’cause.”

Itu selalu menggoda untuk mencoba beberapa trik baru yang telah Anda pelajari, tetapi kita harus menahan keinginan untuk memaksa solusi yang kompleks ke ruang di mana yang sederhana sudah cukup.

Pada tingkat dasar, solusi yang paling sederhana biasanya yang paling sesuai. Anda mencoba untuk mendapatkan dari titik A ke titik B – mengambil jalan memutar yang menyenangkan, tapi benar-benar tidak menambahkan manfaat apapun.

Solusi super-manis kamu, bagaimanapun, menimbulkan masalah di mana orang lain mungkin tidak melihat solusi itu dan hanya akan tersesat.


8. Kamu adalah seorang Wang

Hindari membuat kode yang sulit untuk dipahami.

Ketika saya pertama kali masuk ke dalam pengembangan, saya bekerja dengan seorang pria yang adalah memproklamirkan diri “programmer ahli”. Setiap kali saya punya pertanyaan tentang konsep, ia tidak pernah memberi saya jawaban langsung, untuk mendapatkan jawaban atas pertanyaan asli saya, saya harus menjawab beberapa pertanyaan awal untuk “membuktikan bahwa Anda dapat menangani jawabannya.”

Orang ini juga benar-benar bagus ketika menulis kode yang  samar, mengaburkan, dan umumnya hanya membingungkan.

File seperti itu adalah hasil dari programmer yang berpikir bahwa mereka perlu membuat kode mereka sulit untuk dibaca dalam rangka “menjaga idiot keluar.”

Filosofi umum di belakang ini cenderung menjadi, “Jika Anda tidak cukup cerdas untuk memahami kode ini, Anda tidak harus di dalam tempat pertama.”

Ini adalah pendekatan yang sangat sesat dan anti-sosial untuk pemrograman. Ini adalah cara yang sangat elitis melihat hal-hal, dan itu menunjukkan bahwa programmer telah kehilangan kontak dengan akar pemula, ketika ia sendiri membutuhkan bantuan.

Hindari membuat kode yang sulit untuk dipahami. Ini tidak membuat Anda lebih keren atau lebih cerdas, dan tidak meningkatkan rasa hormat. Itu hanya membuat Anda wang.


9. Bung, apa yang kamu bicarakan?

Jika Anda berhenti belajar, maka proyek Anda akan terjebak dalam periode waktu apa pun yang Anda putuskan untuk berhenti.

Selain cara pintas dan kemalasan umum di atas, hal lain yang mungkin menahan Anda adalah kurangnya pembelajaran lanjutan dan kemajuan ke depan.

Teknologi tidak berubah karena masyarakat pada umumnya bosan dan kami memutuskan untuk mendekorasi ulang, sebagian besar teknologi baru muncul untuk lebih efisien dan mudah memecahkan masalah yang ada. Memilih untuk mengabaikan kemajuan memilih untuk memulai proses yang lambat laun meminggirkan kemampuan Anda.


10. Kamu Mencoba Melakukan Semuanya Sendiri

Cari tahu programmer mana yang memiliki pendekatan sama dan membiarkan mereka mengisi waktu Anda.

Anda tidak dapat bersaing dengan seluruh masyarakat. Sebagai orang yang pernah mencoba untuk bersaing dengan berlangganan ke 200 + tech blog akan memberitahu Anda, itu tidak dapat dilakukan dalam jangka waktu yang wajar.

Untungnya, ada orang-orang dalam masyarakat yang mendedikasikan waktu mereka untuk menonton perkembangan teknologi dan melaporkan temuan mereka. Jika Anda meluangkan waktu untuk mengetahui programmer ini memiliki pendekatan dan gaya yang serupa, Anda dapat membiarkan mereka mengisi waktu anda.

Menonton 2-5 dari jenis blogger “early adopter” dapat lebih menguntungkan daripada berlangganan setiap blog teknologi yang Anda jumpai untuk beberapa alasan:

  • Jika Anda percaya pendapat mereka, mereka akan menampilkan teknologinya untuk Anda.
  • Jika teknologi muncul di lebih dari satu blog tersebut, Anda tahu bahwa Anda setidaknya harus mengambil beberapa menit untuk mempelajari lebih lanjut tentang hal itu karena itu jelas populer.
  • Seringkali, blog ini akan menampilkan intro tutorial cepat, yang dapat menghemat sakit kepala mulai dari nol dengan teknologi baru.

Diantara blogger PHP yang saya percayai adalah David Walsh dan Chris Shiflett.


11. Anda Tidak Keluar Dari Zona Nyaman Anda

Saya hanya bermaksud mengatakan bahwa Anda akan merasa lebih puas sebagai programmer dan melihat bakat Anda lebih maju dan lebih lagi  jika Anda memilih untuk selalu melihat ke tingkat berikutnya dalam pemrograman.

Jika Anda tidak melakukan sesuatu yang menantang Anda, ada sesuatu yang salah. Mencari tantangan baru dalam proyek adalah sebagian besar dari apa yang membuat pemrograman menguntungkan (atau setidaknya begitu).

Cobalah bertanya pada diri sendiri pertanyaan-pertanyaan berikut ketika Anda mulai melihat proyek baru:

  • Apakah ada teknologi baru yang menarik bagi saya untuk diterapkan di sini?
  • Apakah saya telah belajar cara yang lebih baik untuk melakukan hal ini sejak terakhir kali saya mengambil proyek seperti ini?
  • Apakah ada praktek terbaik yang saya perlu untuk menegakkan bahwa saya bisa pastikan untuk mengikuti seluruh proyek ini?

Perlu diingat: Saya tidak berbicara tentang melakukan sesuatu terlalu kompleks, di sini.

Bisa sederhana seperti mengingat untuk menambahkan Docblocks ke objek Anda, atau serumit membuat aplikasi Anda kompatibel dengan XMLRPC sehingga lebih mudah bagi pengguna untuk posting update.


12. Kamu Tidak Berbagi

Selalu membahas kode Anda dengan sesama programmer Anda.

Cara terbaik untuk meningkatkan diri adalah membahas kode Anda dengan sesama programmer Anda. Hal ini dapat dilakukan melalui beberapa jalan: menulis tutorial atau merilis sebuah proyek open-source, jika Anda tidak merasa sampai dengan sesuatu skala itu, mungkin Anda bisa nongkrong di sebuah forum komunitas dan menawarkan bantuan kepada pendatang baru.

“Bagaimana membantu noobs bisa membantu saya maju?” Anda bertanya. Biasanya, jika Anda memposting sebuah solusi yang dapat dioptimalkan, programmer berpengalaman lain akan melompat masuk dan menawarkan tweak. Jadi pendekatan ini adalah kedahsyatan ganda: Anda tidak hanya membantu kemajuan masyarakat dengan menawarkan pengetahuan Anda untuk pemula, tapi kau mengasah skillset Anda sendiri dari semua orang untuk melihat dan membantu Anda mengembangkan.


13. Anda Tidak Memiliki Proyek Sampingan

Cara terbaik untuk belajar adalah untuk memulai sebuah proyek sampingan yang menggunakan teknik tersebut

Dengan begitu, Anda dapat mengembangkan diri Anda sendiri secara cepat, di waktu luang Anda, dan tidak pernah risiko hilang batas waktu atau “salah melakukannya.”


14. Kita Semua Bersalah

If we’re doing it right, we should always be improving. And logic tells us that if we’re better now, then we were worse before. And if we follow that line of reasoning back far enough, there was a point where we were terrible.

I know that when I look back at some of the code I wrote in the past, I’m horrified.

Jika kita melakukannya dengan benar, kita harus selalu memperbaiki. Dan logika memberitahu kita bahwa kita lebih baik sekarang, maka kita lebih buruk sebelumnya. Dan jika kita mengikuti bahwa garis penalaran mundur cukup jauh, ada titik di mana kita mengerikan.

Aku tahu bahwa ketika saya melihat kembali pada beberapa kode saya tulis di masa lalu, aku ngeri.


Jadi… Hentikanlah Melakukan Praktek Pemrograman Yang Buruk.

 

Diterjemahkan secara bebas dari http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/

Advertisements

About phpgeek programmer

pemimpi yang berharap menjadi the best programmer di zamannya

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s