Роберт Мартин, Таза кодекс. Иштеп чыгуучулар үчүн "кунг-фу коду" боюнча китепти карап чыгуу

Саламатсыздарбы Жаравашевтер! Бул макала Роберт Мартиндин "Таза codeекс" китебине сереп салуу. Кодуңузду жакшыртуу жана оптималдаштыруу жолдорун бирге карап чыгабыз, акырында сизди кичинекей, бирок кызыктуу тапшырма күтүп турат. Күн сайын, биз сиздин code редакторуңузду ачканда, биз көптөгөн класстарга, функцияларга жана өзгөрмөлөргө туш болобуз. Эң жакшы вариант - бул нөлдөн баштап жазылган, бир жолу жазылган codeуңуз болсо, анда бир нече саптар бар, сиз анын үстүндө жалгыз иштеп жатасыз, эч кандай оңдоолор жана кардар тарабынан мындан ары колдоо жок. БИРОК! Практика көрсөтүп тургандай, ооба, менимче, сиз өзүңүз түшүнүп жатасыз деп ойлойм. Негизинен, биз кандайдыр бир жол менен биздин команданын мүчөлөрү менен өз ара аракеттенишибиз керек, "индус" codeун сактап, миллиондогон саптарга өнүмдөрдү талдоо керек. Мен машыктыруучу кесиптештеримден мындай жоопторду көп уктум: "Бул codeду мен жазганмын, мен аны эч кимге көрсөтпөйм", бирок мен мындай code менен Жардам сурап кайрылгандарды көргөндө, бул абдан көп убакытты талап кылат. убакыт (кээде чындап эле көп убакыт) изилдеп, түшүнүү үчүн, ал адам мага эмнени айткысы келген, мен ал тургай "тазалап, кайра жаз" деп айткым келет! Сага жардам бергиси келген адамдардын убактысын жана күчүн баалай бил, туура жаз, жана кантип билбесең, үйрөнүүгө эч качан кеч эмес. Роберт Мартиндин китеби бул форматтагы китептердин ичинен Java тorндеги көптөгөн мисалдарды камтыганы менен өзгөчөлөнөт. Бул мен үчүн бир аз фанатикалык билдирүү болушу мүмкүн, бирок ал OOP стorнде, тактап айтканда, бөлүктөрдү жана бөлүмдөрдү жазууда жазылган. Түшүнүү жана окуу оңой, китепти жолдо же кечинде уктаар алдында окуу оңой. Таза code 3 бөлүккө бөлүнөт. Биринчи бөлүктө бизден китептин теориясын карап чыгуу, дизайн үлгүлөрү жана жакшы жүрүм-турум эрежелери менен таанышуу сунушталат. Экинчи бөлүк бизди рефакторинг жана жазуу практикасына чакырат, ал эми үчүнчү бөлүк - мисалдардагы "жыт" codeунун акыркы корутундусу. Ооба, автор сиз негизинен Java Core бorмин талап кыла турган көптөгөн темаларды козгоду, бирок JUnit Unit Tests, Log4j Logging, дизайндагы эң жөнөкөй үлгүлөрдү билүү (бирок мен жогоруда айткандай, бул жерде жок) арналган бөлүмдөр бар. алардын көбү жана түшүнүксүз нерселердин бардыгын ийгorктүү Google издөөгө болот, ооба жана JavaRush курсунда талдоо). Китептин бардык бөлүмдөрү бири-бирине байланыштуу эмес, сиз өзүңүзгө жаккан бөлүмдөн ийгorктүү окууну баштасаңыз болот. Мен китептен алган негизги идеялардын кыскача баяндамасы. Мен бул билдирүүлөр боюнча өз көз карашыңыз менен бөлүшө аласыз, алар боюнча комментарийлериңиз үчүн ыраазы болмокмун.

1. Комментарийлер == жаман.

Көпчүлүк учурларда, комментарийлер балдак болуп саналат, алар менен биз жаман codeубузду жабууга аракет кылабыз. Ал эми кээ бир учурларда, эгер туруктуу code рефакторинги бар болсо, алар методдордун же өзгөрмөлөрдүн максаты жөнүндө да калп айтышат.

2. Комментарийленген code, өлүк code.

Колдонмоңузда codeдун бул бөлүктөрүн калтыруу таштандыга барабар. Колдонулбаган code убакыттын өтүшү менен топтолуп, колдонмоңуздун тазалыгына тоскоол болот, мындай модулдардын codeун мезгил-мезгor менен текшерип туруңуз.

3. Методдордун, класстардын жана өзгөрмөлөрдүн аталыштары.

Бул теманы талкуулоо үчүн өзүнчө макалалар арзырлык. Жалкоо болбоңуз жана алардын максаты жөнүндө айтып бере турган ысымдарды жазыңыз. Орфографиялык аталыштардагы кээ бир стандарттарды үйрөнүңүз. Бул тема деталдуу изилдөө үчүн "болушу керек".

4. Ар бир методдун жана өзгөрмөнүн класс иерархиясында өз орду бар.

Адатта, класс өзгөрмөлөргө жана методдорго (статикалык жана статикалык эмес), конструкторго, уяланган жана ички класстарга жана энумдарга ээ болушу мүмкүн. Кыскасы, маалымат көп, ар бир адамдын класстагы ордун аныктоо керек. Эгерде сиз java негизги класстарын карасаңыз, структуранын так структураланганын көрөсүз, биз ар бир бөлүгүн өз ордунда көрө алабыз, албетте сиздин долбоорлоруңузда ал долбоордун ичинде өзгөрүшү мүмкүн, бирок ар бир класста эмес. Мен өзүм үчүн төмөнкү курулуш структурасын аныктадым: Класстын башында менде статикалык өзгөрмөлөр бар, андан кийин an object өзгөрмөлөрү + Enums бар болсо. Өзгөрмөлөрдөн кийин мен класстын конструкторлорун аныктайм. Анан класс менен иштөө ыкмаларын жазам. Методдордон кийин мен алгычтарды жана сеттерди жазам. Анан эң аягында менде ички класстар бар. Менин структурамды колдонсоңуз болот же комментарийге өзүңүздүн оюңузду жазсаңыз болот.

5. Методдордун абстракциясынын деңгээли.

Мен үчүн бул №1 ачылыш болду. Ар бир ыкма абстракциянын бир деңгээлиндеги операторлорду камтыйт. Сиз көп баскычтуу операцияларды аралаштырбашыңыз керек.

6. Ката менен иштөө.

Текшерилген же Текшерилбеген өзгөчөлүктөр, кайсынысын долбоордо колдонгон жакшы (сиз кандай ойлойсуз?, комментарий жазыңыз)? Мен текшерилгендердин жактоочусумун, бирок китеп Текшерилбеген өзгөчөлүктөргө сырттан кароого жардам берет. Чынында эле, белгиленбеген Exception метод кол тамгасын дефигурациялаbyte, өзгөчө өзгөчөлүктөр бир эле учурда бир нече катмарды "тешет". Кичинекей өзгөрүүнүн ыңгайсыздыгы аны кармаганга чейин бардык ыкмалардын чынжырын кайра аныктоого алып келет, бул көп учурларда өнүктүрүү үчүн өтө ыңгайсыз.

7. Кодду форматтоо.

Туура форматталган code ачык-айкын гана эмес, ошондой эле абдан окула турган. Сиз дароо эле кашаалар жана ичиндеги аракеттер жөнүндө түшүнүк аласыз. If, else конструкцияларындагы шарттардын мисалын колдонуп, баарын бир сапта жазбаш керек, узун чынжырларды жылдырган жакшы.

8. Шарттагы негативдер.

Шарттарда баш тартуудан качууга аракет кылыңыз, бул психологиялык фактор, мээбиз танууну жакшы кабыл алbyte, ооба! сөз айкашы байкалбай калышы мүмкүн алдында. Мисалы, жокко чыгаруу (!condition.isTrue) методду кайра жазуу жакшыраак болсо, бул аны ушунча жеңилдетет (condition.isFalse)

9. Функциялар бир операцияны аткарышы керек.

Эгерде сиздин методуңуз көп операцияларды аткарса, анда аларды бир операциялык ыкмаларга бөлүңүз. Бул ыкмаларды колдоо үчүн абдан жеңил, сыноо үчүн жеңил, жана зарыл болсо, алмаштырылат же алынып салынат.

10. Өзүңүздү кайталабаңыз.

DRY codeун кайталабаңыз (Өзүңүздү кайталабаңыз). Бул сиздин codeуңузду олуттуу түрдө азайта турган негизги эрежелердин бири, аны унутпаңыз. Бардык кайталануучу code бөлүктөрүңүздү өзүнчө функцияга салууга аракет кылыңыз. Албетте, биз DRY, KISS(Keep it simple Stupid), SOLID , YAGNI жөнүндө көбүрөөк айта алабыз . Бул терминдер түшүнүү жана дизайн үчүн абдан маанилүү. Алар өзүнчө макалага арзыйт, балким, мен алар жөнүндө дагы жазам, анткени бул макала "Таза codeекс" китебин карап чыгууга арналган. Убада кылгандай, сиз үчүн кичинекей жана оңой иш. Программа берилген маалыматтардын негизинде семирүү индексин эсептөө керек. Коддогу каталардын жана оңдоолордун санын комментарийлерге жазыңыз. P.S. Код иштеп жатат жана туура колдонулса, өз милдетин аткарат.

//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;
    }
}