Paggamit ng PHP CodeSniffer Gamit ang WordPress: Pag-unawa sa Code Smells

() translation by (you can also view the original English article)

Madalas, kung papaano tayo sumulat ng code ay depende sa ating kaalaman sa programming.

Halimbawa, kapag ang isang tao ay may pormal na edukasyon sa computing, sa malamang na alam nila ang iba’t ibang pangunahing pamamaraan para maiwasan nila ang pagsulat ng mahinang kalidad ng code. Hindi ito ang patakaran siyempre, obserbasyon lamang.

Katulad din ng gumagawa ng sarili nilang programming, sa labas ng pormal na edukasyon, ay madalas nauuwi sa pagtuturo sa sarili at pagkakaroon ng kaalaman galing sa iba’t ibang pagkukunan ng impormasyon.Minsan, nagiging dahilan ito ng problema sa uri ng code na nasusulat.

Para mas malinaw: Hindi ko sinasabi na ang pormal na edukasyon sa computing ay mas nakakahigit kaysa sa taong tinuruan lamang ang sarili, o kahit ang kabaliktaran nito. Ang ibang magagaling na programmers ay ang mga edukado; ang iba ay ang kaalaman ay galing sa sariling sikap.Subalit ang isang bagay na parehong nasa kanila ay wala silang dahilan para hindi makasulat ng code smells sa lahat ng oras.

Sa artikulo na ito, titingnan natin ang panimula sa code smells. Susuriin natin kung ano ito, ano ang itsura nito, at gaano kadalas ito nagagamit sa ginagawa natin. Gagamitin natin ang PHP bilang halimbawa.

Sa pangalawang bahagi ng serye na ito, titingnan natin kung papaano natin maiiwasang sumulat ng code smells. Tiyak na gagamitin ang PHP, iilang tools, at WordPress bilang napiling environment.

Subalit una bigyan natin ng panimula ang code smells.

Ano ang Code Smells?

Depende sa uri ng developer na itatanong mo, makakakuha ka ng iba’t ibang uri ng sumusunod na ibig sabihin:

Code smell, kilala din na bad smell, sa computer programming code, ay tungkol sa sintomas sa source code ng program na posibleng nagbibigay indikasyon ng mas malalim na problema.

Ang ibig sabihin na ito ay mula sa Wikipedia. Hindi na rin masama, subalit hindi ito ang paborito kong atake sa paksa.Sa halip, ang paborito kong ibig sabihin nito ay galing sa matagumpay at sikat na programmer na si Martin Fowler. Mababasa mo ang kanyang kabuuang pananaw sa paksa tungkol sa code smells sa artikulo na ito, subalit sinala ko ito sa mga sumusunod na punto:

“Ang mahabang pamamaraan ay magandang halimbawa nito- sa pamamagitan lamang ng pagtingin sa code at lumalaki ilong ko kapag nakakakita ako ng mahigit isang dosenang linya ng Java.”
Ang Smells ay hindi naman sadyang masama-madalas ay indikasyon ito ng problem sa halip na problema talaga.”
Ang “Data classes” (classes na may data ngunit walang behavior) ay magandang halimbawa.”

Kung hindi mo pa nababasa ang artikulo, ito ay nagtapos sa:

Isa sa magandang bagay tungkol sa smells ay madali itong makita ng taong walang masyadong kaalaman, kahit hindi nila masyadong alam kung may talagang problema o kung paano ito itama.

At sa tingin ko iyon ay pambihirang pahayag dahil ibig sabihin ang paksang ito ay tamang tama para sa mga programmers subalit hindi sigurado kung saan magsisimula pagdating sa pagkilala at pag gawa ng aksyon sa code smells.

Sa madaling salita, hindi malaki ang papel ng karanasan dito. Oo, iyong mas may karanasan ay sa mas malamang mas makakakita ng smells(dahil mas marami na silang nakitang ganoon), subalit iyong may mas kaunting karanasan ay dapat makakita din nito.

May mga Halimbawa Ka Ba?

Siyempre pag dating sa paksa tungkol sa code smells, mas madaling pag-usapan ito sa antas ng ideya lamang kaysa sa gawan ito ng paraan.Subalit hindi ito praktikal at hindi rin ito naaayon sa ating araw-araw na ginagawa.

At sa mga nasabing ito, bakit hindi natin tingnan ang ilang halimbawa ng code smells? Susuriin natin bakit ito ay problema at magbibigay tayo ng solusyon kung papaano matatanggal ang smell sa pamamagitan ng pag refactor ng code.

Halimbawa 1: Malinaw na Pagpangalan

Isa sa pinakamadaling makitang code smells ay kapag ang programmer ay piniling gamitin ang hindi malinaw na pangalan ng variable. Kung saan, sa ngalan ng code, hindi malinaw kung ang ano ang gamit ng nasabing variable.

Oo, may mga pagkakataong tinatanggap ito(katulad ng pag gamit ng i sa for na loop. Subalit sa mas mahabang pamamaraan, hindi ito katulad lang ng for na loop).

Halimbawa:

1	<?php
2	public function get_things( $x ) {
3
4	$l = array();
5
6	for ( $i = 0; $i < count( $x ); $i++ ) {
7
8	if ( true === $x[ $i ] ) {
9	array_push( $l, $x[ $i ] );
10	}
11
12	}
13
14	return $l;
15
16	}

Kung bibigyan ng mahabang oras, mas maiintindihan natin kung ano ang ginagawa nito. Una, ito ay naka simpleng paraan. Pangalawa, mababasa natin ang variables, blocks at return value para mas magka ideya tayo kung ano ang nangyayari.

Subalit kung ang hinahanap natin kung paano sumulat ng malinis na code na mas madaling maintindihan kung gusto nating balikan ito o ibang programmer ang gumawa nito, kung ganon ang pag gamit ng malinaw na pagpapangalan ay makakatulong. At ang code sa taas ay hindi gumagamit ng malinaw na pagpapangalan.

Sa halip, i-refactor natin ito para lalabas itong ganito:

<?php

public function get_flagged_items( $items ) {

  $flagged_items = array();

  for ( $i = 0; $i < count( $items ); $i++ ) {

    $current_item = $items[ $i ] ;

    if ( true === $current_item ) {
      array_push( $flagged_items, $current_item );
    }
  }

  return $flagged_items;

}

Mas madaling maintindihan, hindi ba?

Mapapansin na hindi nagbago ang algorithm, subalit ang function name at variable names ay nagbago. At ito ay may epekto sa pagbasa ng code na ito. Kung tatanungin kung ano dapat ang ginagawa ng code na ito, madali nating masasabi ang tulad nito:

Ibinabalik nito ang array ng items na naka mark na tama sa predefined na array ng items.

Hanggat maaari, iwasang gumamit ng generic na pangalan ng variable at gamitin ang kahit anong malinaw na pagpipilian para sa iyo at sa iyong kasama.

Halimbawa 2: Panatilihing DRY

Sa programming, pipigain ka na makahanap ng developer na hindi pa narinig ang KISS or DRY (alam mo na iyong, “don’t repeat yourself”). Sa kabila nito, madalas tayong mag-ulit ng sinasabi.

Indikasyon ito ng katotohanang ang pagsubok sa DRY na prinsipyo ay iba iba sa iba’t ibang uri ng programmers. At ayos lang ito! Walang natatanging paraan para ipakita kung papaano sumunod sa prinsipyong ito.

Subalit dahil maraming paraan para gawin ito, makakapagbigay tayo ng halimbawa kung ano ang dapat o hindi nitong itsura.

Kunwari para sa sumusunod na halimbawa na mayroong function na tinatawag na save_post at tumatanggap ito ng dalawang arguments: post ID at string na nagrerepresentang pamagat ng post. Ang code smell ay lalabas na ganito:

<?php

public function save_posts() {

  save_post( 1, 'Hello World!' );
  save_post( 2, 'Goodbye World!' );
  save_post( 3, 'What is this new world?' );

}

Subalit bakit isa isa nating isinusulat ang tawag sa save_post ng tatlong beses? Sa halip, mag set-up tayo ng associative array, i-iterate ito, at i-call ang method ng isang beses bawat iteration.

<?php

public function save_posts() {

  $posts = [
    1 => 'Hello World!',
    2 => 'Goodbye World!',
    3 => 'What is this new world?',
  ];

  foreach ( $post as $post_id => $post_title ) {
    save_post( $post_id, $post_title );
  }
  
}

Kahit ang pag call ng method ng isang beses ay maganda, ang method na ito ay mas maaari pang maging flexible sa pamamagitan ng pag tanggap ng array ng posts bilang argument at hayaang ang foreach loop ay intact, subalit hindi ito ang punto ng halimbawang ito.

Kung napapansin niyong gumagawa kayo ng parehong method call ng maraming beses sa function na may iba’t ibang parameters, maaaring mayroon kayong code smell. At kung mayroon, humanap ng paraan para i-refactor ito para isang beses lang ang pag-call sa method.

Dahil kung tutuusin, ayaw mo ng paulit ulit.

Halimbawa 3: Mahabang Listahan ng Paramater

Isa sa madalas nating laging makita sa programming, kahit ano pang language, ay kapag ang function ay tumatanggap ng malaking bilang ng parameters.

Ang iba’t ibang programmers ay may pagpipilian kung ano ang nararapat na bilang ng parameters ang dapat tanggapin ng function, subalit sa tingin ko tatlo(dalawa o higit, malamang) ay magandang bilang.

Una, tingnan natin kung ano ang itsura ng function na may mahabang listahan ng parameter.Malamang walang sorpresa sa sumusunod na code, at maaaring nakaharap mo na ang katulad nito sa isa sa iyong mga bagong proyekto:

<?php 

public function submit_order( $first, $last, $address1, $address2, $city, $state, $zip, $phone, $cc, $expiration ) {

  /* Attempt to submit the order. If the order is successful,
   * then return an instance of an Order object with the success status;
   * otherwise, return an instance of an Order object with the failed status 
   * and a message.
   */
  
}

Mapapansin sa halimbawa sa itaas na hindi tayo nakatuon sa implementasyon ng function. Sa halip, nakatuon tayo sa kung ilang parameters ang kailangan. Nangangahulugan ito ng maraming impormasyon na ipapadala, at magiging pangit din ang method call.

Hindi man lang nito nabigyan ng liwanag ang tungkol sa verification at validation. At hindi na ako nagtuon dito.

Papaano ito malilinis? Para sa akin, gusto ko ang pag-gawa ng class para ipakita ang koleksyon ng impormasyon katulad nito. Sa natatanging halimbawa na ito, maaari tayong gumawa ng class na magpapakita ng kontak impormasyon ng tao. At karagdagan dito, ang taong ito ay maaaring konektado sa credit card number.

Ang detalye nito ay maaaring ipatupad gamit ang logic kahit saan man sa application, subalit ang abstraction ay ganito ang magiging itsura:

<?php

class Contact_Information {
  /* Maintains attributes of the person's contact information. */
}

class Payment_Information {
  /* Maintains the credit card number and other information for a person. */
}

class Order {

  public function submit( $contact_info, $payment_info ) {

    /* Attempt to submit the order. If the order is successful,
     * then return an instance of an Order object with the success status;
     * otherwise, return an instance of an Order object with the failed status 
     * and a message.
     */
    
  }
}

Ang refractoring na ito, kahit na maliit, ay ang pinakamalaking nagawa natin sa naturang artikulo na ito. Mapapansin na nagawa natin ang mga ito:

Nakagawa ng Contact_Information class na nagbigay daan para maipakita ang bagay na naglalaman ng lahat ng impormasyon sa bayad ng isang tao.
Nakagawa ng Payment_Information class na nagbigay daan para mapanatili ang credit card o numero ng debit card ng tao at iba pang detalye na may kinalaman sa paraan ng pagbayad.
Nakagawa ng Order class, nailagay ang submit_order function sa loob nito, napalitan ng pangalan para maipadala (dahil magiging paulit-ulit ang submit_order), at mababawasan ang listahan ng parameter sa dalawang values: instance ng Contact_Information class at ng Payment_Information class).

Para mas malinaw, ang halimbawang ito ay hindi hawak ang verification ng kaugnayan ng impormasyon ng kontak at impormasyon ng bayad, o kaya kung ito ay nagpapakita ng ibang classes na maaaring mahalaga(katulad ng kung pumalpak ang pagbayad sa transaksyon).

Subalit hindi ito ang punto sa ehersisyong ito.

Sa halip, tinitingnan natin ang code smell na may mahabang listahan ng parameter at paano mababawasan ito gamit ang praktikal, mas madaling mapanatili na method na mayroon tayo.

Kapag sumusulatka ng function o gumagawa ng call sa function na kinakailangan ang malaking numero ng arguments, maghanap ng paraan para ma-refractor ang nasabing function. Madadagdagan nito ang cohesion ng code at mabawasan ang smell.

Konklusyon

Tandaan, iyan lamang ang nakita nating halimbawa sa itaas. Hindi kumpleto ang listahan, subalit ito ay ang mga karaniwang smells na malamang ay makita mo sa code na ginagawa mo or sinusulat mo. Aaminin ko salarin ako dito.

Bilang karagdagan, maraming maraming mapagkukuhanan na nariyan pagdating sa pagkilala at pag –ayos ng code smells. Sa kabutihang palad, marami tayong bilang ng tools na nariyan na makakatulong sa atin na madiskubre ito agad at para malinis ito.

At doon tayo papunta sa sunod. Tiyak nating gagamitin ang PHP CodeSniffer para matulungan tayo para maiwasan ang code smells sa ating code. Pagkatapos, makikita natin papaano maisama ang rules ng WordPress sa PHP CodeSniffer at paganahin ito sa IDE na ating napili.

Katulad ng nabanggit na kanina sa artikulo na ito, ang susunod na artikulo sa seryeng ito ay mas bibigyan ng atensyon ang code smells kapag nagsusulat ng code sa WordPress.Titingin tayo ng ibang tools at pagkukunan para masigurado na maiiwasan ang code smells, at para din masigurado na sumusulat tayo ng mas matibay na code.

Pansamantala, pag-aralan ang mga halimbawa sa itaas at tingnan ang mga pagkukunan na ibinigay ko dahil ang mga iyon ay magandang pagkuhanan ng impormasyon para mas matutunan ang smells at code refractoring sa tao at mga lugar na hindi kilala sa ating industriya.

Tandaan, mahahanap mo lahat ng kurso at pagtuturo sa aking profile page, at maaari mo akong sundan sa aking blog/o kaya Twitter sa @tommcfarlin kung saan tinatalakay ko ang iba’t ibang pagsasanay sa software development at papaano natin magagamit ito sa WordPress.

Pakiusap huwag mag-atubili na mag-iwan ng kahit anong katanungan o komento sa aking feed sa baba, at sisikapin kong sagutin ang bawat isa.