Robert Martin, Clean Code. Pagsusuri ng aklat sa “kung fu code” para sa mga developer

Hello Javarashevites! Ang artikulong ito ay rebyu ng aklat na “Clean Code” ni Robert Martin. Sama-sama nating titingnan ang mga paraan upang pagbutihin at i-optimize ang iyong code, at sa huli isang maliit ngunit kawili-wiling gawain ang naghihintay sa iyo. Araw-araw, kapag binuksan namin ang iyong code editor, nahaharap kami sa maraming klase, function at variable. Ang pinakamahusay na pagpipilian ay kung ito ang iyong code na isinulat mula sa simula, isinulat nang isang beses, mayroong ilang mga linya sa loob nito, ginagawa mo ito nang mag-isa, walang mga pag-edit at walang karagdagang suporta mula sa customer. PERO! Tulad ng ipinapakita ng pagsasanay, oo, sa palagay ko naiintindihan mo mismo na hindi ito nangyayari. Sa pangkalahatan, kailangan nating makipag-ugnayan sa anumang paraan sa mga miyembro ng aming koponan, panatilihin ang code na "Hindu", at i-parse ang mga produkto sa milyun-milyong linya. Madalas akong nakarinig ng mga sagot na tulad nito mula sa aking mga kasamahan sa pagsasanay: "Ang code na ito ay isinulat ko, at hindi ko ito ipapakita sa sinuman," ngunit kapag nakakita ako ng mga kahilingan sa Tulong para sa Tulong na may ganoong code, ito ay tumatagal ng napakatagal. time (minsan talagang matagal) para bungkalin at intindihin Kung ano ang gustong sabihin sa akin ng tao, gusto ko pang sabihin na “erase and rewrite again”! Pahalagahan ang oras at lakas ng mga taong gustong tumulong sa iyo, magsulat ng tama, at kung hindi mo alam kung paano, hindi pa huli ang lahat para matuto. Namumukod-tangi ang aklat ni Robert Martin sa mga aklat na may ganitong format dahil naglalaman ito ng maraming halimbawa sa Java. Ito ay maaaring medyo panatikong pahayag sa aking bahagi, ngunit ito ay isinulat sa istilong OOP, lalo na sa pagsulat ng mga bahagi at seksyon. Madaling maunawaan at basahin, ang libro ay madaling basahin on the go o sa gabi bago matulog. Ang Clean Code ay nahahati sa 3 bahagi. Sa unang bahagi, hinihiling sa amin na dumaan sa teorya ng aklat, alamin ang tungkol sa mga pattern ng disenyo at mga tuntunin ng mabuting asal. Ang ikalawang bahagi ay nag-aanyaya sa amin na magsanay ng refactoring at pagsulat, at ang ikatlong bahagi ay ang huling buod ng code na "amoy" sa mga halimbawa. Buweno, hinawakan ng may-akda ang maraming mga paksa kung saan kakailanganin mo ang kaalaman sa Java Core, ngunit mayroon ding mga seksyon na nakatuon sa JUnit Unit Tests, Log4j Logging, kaalaman sa pinakasimpleng mga pattern sa disenyo (ngunit tulad ng sinabi ko sa itaas, walang marami sa kanila, at lahat ng hindi maintindihan ay maaaring matagumpay na ma-google, oo at pag-aralan ito sa kursong JavaRush). Ang lahat ng mga kabanata ng aklat ay hindi nauugnay sa isa't isa; maaari mong matagumpay na simulan ang pagbabasa mula sa kabanata na gusto mo. Isang maikling buod ng mga pangunahing ideya na kinuha ko mula sa aklat. Magpapasalamat ako sa iyong mga komento sa mga ito, kung saan maaari mong ibahagi ang iyong sariling pananaw sa mga pahayag na ito.

1. Mga Komento == kasamaan.

Sa karamihan ng mga kaso, ang mga komento ay mga saklay kung saan sinusubukan naming pagtakpan ang aming masamang code. At sa ilang mga kaso, nagsisinungaling din sila tungkol sa layunin ng mga pamamaraan o mga variable kung mayroong patuloy na refactoring ng code.

2. Nagkomento code, patay na code.

Ang pag-iwan sa mga piraso ng code na ito sa iyong aplikasyon ay katumbas ng basura. Ang hindi nagamit na code ay nag-iipon sa paglipas ng panahon at nakakasagabal sa kalinisan ng iyong aplikasyon, suriin ang code para sa mga naturang module paminsan-minsan.

3. Mga pamagat ng mga pamamaraan, klase at mga variable.

Ito ay nagkakahalaga ng hiwalay na mga artikulo upang talakayin ang paksang ito. Huwag maging tamad at magsulat ng mga pangalan na maaaring sabihin tungkol sa kanilang layunin. Matuto ng ilang pamantayan sa mga pamagat ng pagbabaybay. Ang paksang ito ay "Dapat Magkaroon" para sa detalyadong pag-aaral.

4. Ang bawat pamamaraan at variable ay may lugar sa hierarchy ng klase.

Karaniwan, ang isang klase ay maaaring magkaroon ng mga variable at pamamaraan (static at non-static), isang constructor, nested at panloob na mga klase, at mga enum. Sa madaling salita, maraming impormasyon, at kinakailangan upang matukoy ang lugar ng lahat sa klase. Kung titingnan mo ang mga pangunahing klase ng java, makikita mo na ang istraktura ay malinaw na nakabalangkas, makikita natin ang bawat bahagi sa lugar nito, siyempre sa iyong mga proyekto maaari itong magbago sa loob ng proyekto, ngunit hindi sa bawat klase. Para sa aking sarili, tinukoy ko ang sumusunod na istraktura ng konstruksiyon: Sa simula ng klase mayroon akong mga static na variable, pagkatapos ay mga variable ng object + Enums kung mayroon sila. Pagkatapos ng mga variable, tinukoy ko ang mga konstruktor ng klase. Pagkatapos ay nagsusulat ako ng mga pamamaraan para sa pagtatrabaho sa klase. Pagkatapos ng mga pamamaraan ay nagsusulat ako ng mga getter at setter. At sa pinakadulo may mga inner classes ako. Maaari mong gamitin ang aking istraktura o isulat ang iyong sarili sa mga komento.

5. Mga antas ng abstraction ng mga pamamaraan.

Para sa akin ito ang pagtuklas No. 1. Ang bawat pamamaraan ay naglalaman ng mga operator sa isang antas lamang ng abstraction. Hindi mo dapat pagsamahin ang mga multi-level na operasyon.

6. Error sa paghawak.

May check o Unchecked Exceptions, alin ang mas mainam na gamitin sa proyekto (ano sa palagay mo?, magsulat ng mga komento)? Ako ay tagasuporta ng naka-check, ngunit nakakatulong ang aklat na tingnan ang Mga Hindi Na-check na Exception mula sa labas. Sa katunayan, ang walang check na Exception ay hindi nakakasira sa paraan ng signature, lalo na kung isasaalang-alang na ang mga exception ay "tumusok" sa ilang mga layer nang sabay-sabay. Ang abala ng pinakamaliit na pagbabago ay humahantong sa redefinition ng buong hanay ng mga pamamaraan bago ito mahuli, na lubhang hindi maginhawa para sa pag-unlad sa maraming mga kaso.

7. Pag-format ng code.

Ang wastong na-format na code ay hindi lamang malinaw, ngunit lubos ding nababasa. Makakakuha ka kaagad ng ideya ng mga bracket at ang mga aksyon sa loob. Gamit ang halimbawa ng mga kundisyon sa if, else constructs, hindi mo dapat isulat ang lahat sa isang linya, mas mainam na ilipat ang mahabang chain.

8. Negasyon sa kondisyon.

Subukan upang maiwasan ang pagtanggi sa mga kondisyon, ito ay higit pa sa isang sikolohikal na kadahilanan, ang ating utak ay hindi nakikita ng mabuti ang pagtanggi, at oo! bago ang ekspresyon ay maaaring hindi mapansin. Halimbawa, ang pag-negasyon kung (!condition.isTrue) ay mas mahusay na muling isulat ang pamamaraan, ito ay magiging mas madali tulad nito (condition.isFalse)

9. Ang mga function ay dapat magsagawa ng isang operasyon.

Kung ang iyong pamamaraan ay nagsasagawa ng maraming mga operasyon, pagkatapos ay hatiin ang mga ito sa mga single-operation na pamamaraan. Ang mga paraang ito ay napakadaling suportahan, madaling subukan, at, kung kinakailangan, papalitan o alisin.

10. Huwag ulitin ang iyong sarili.

Huwag ulitin ang code DRY (Huwag ulitin ang iyong sarili). Ito ay isa sa mga pangunahing panuntunan na makabuluhang bawasan ang iyong code, tandaan ito. Subukang ilagay ang lahat ng iyong paulit-ulit na piraso ng code sa isang hiwalay na function. Siyempre, marami pa tayong mapag-uusapan tungkol sa DRY, KISS(Keep it simple Stupid), SOLID , YAGNI. Ang mga terminong ito ay mahalaga para sa pag-unawa at disenyo. Ang mga ito ay nagkakahalaga ng isang hiwalay na artikulo, marahil ay isusulat ko muli ang tungkol sa kanila, dahil ang artikulong ito ay nakatuon sa pagsusuri ng aklat na "Clean Code". Tulad ng ipinangako, isang maliit at madaling gawain para sa iyo. Dapat kalkulahin ng programa ang Obesity Index batay sa ibinigay na data. Isulat sa mga komento ang bilang ng mga error at pag-aayos sa code. P.S. Ang code ay gumagana at gumaganap ng function nito kung ginamit nang tama.

//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}