クリーンコード( th )

9794 ワード
cleancode テキストリンク
บทความนี้เป็นการสรุปเนื้อหาเท่าที่ผู้อ่านเข้าใจจากหนังสือ
クリーンコードของ ロバートCマーティンหรือลุง ボブ

目次


  • Introduction
  • Clean code คืออะไร
  • Bad code
  • หนี้สินทาง software คืออะไร
  • แนวคิดเรื่อง Clean code (สำคัญ)

  • หลักการการทำ Clean code
  • Meaningful Name
  • Function
  • Comments
  • Formatting

    • 導入

    บทความนี้เป็นการสรุปหนังสือ Clean Code Robert C. Martin
    ตามความเข้าใจหากผิดพลาดช่วย Comment กัได้นะเออ

    クリーンコードคืออะไร

    Clean code คือ code สะอาดครับ คำว่าสะสาดอาจจะหมายถึง อ่านง่าย แก้ไขง่าย ต่อยอดง่าย แต่เราจะทำยังไงให้มันได้อย่างที่เราบอกกันละ ก่อนอื่นเราต้องรู้จัก Bad code กันก่อน

    不良コード

    เราอาจจะเคยต้องอ่านโค๊ทต่อจากคนอื่น หรือ เราไม่ได้ทำ Project นั้นนานๆ แล้วกลับมาอ่านสิ่งที่เราจะเจอ

    • ตัวแปลตัวนี้คืออะไรวะ dowData อ่านชื่อแล้วงง
    • function นี้มันทำอะไรวะ genAcTcUserSta
    • อ่าน code แล้วต้องลงไปดูใน function เพราะชื่อไม่สื้อ
    • เรา check if เพื่ออะไรวะ for ตรงนี้ไม่เห็นจำเป็นต้องมีนิ
    • บางตัวแปลไม่ได้ใช้ประกาศทำไม
    • ฯลฯ

    สิ่งเหล่านี้ที่เราเจอมาล้วนเป็นหนี้สินทาง software ทั้งสิ้น

    หนี้สินทาง ソフトウェアคืออะไร

    มันคือสิ่งที่ทำให้เราช้าลง เพราะหนี้สินล้วนมีดอกเบี้ย สิ่งที่จะเกิดผลกระทบ

    • เวลาในการศึกษา code นั้นๆ จะมากขึ้น เช่น มีคนใหม่เข้าทีมอ่านทีหัวแตก (learning curve สูง)
    • การแก้ไขโปรแกรมทำได้ยาก ไม่ว่าจะเพิ่ม feature หรือ fix bug
    • เขียน test ยาก (ถึงกับไม่รู้จะเขียนยังไง)
    • อ่านยากมากๆ อ่าน code แล้วอยากลาออก
    • ฯลฯ

    วันหนึ่งจะมีคนพูดว่า "ถ้าอ่านยากขนาดนี้ เขียนใหม่ยังง่ายกว่า"

    แนวคิดเรื่อง クリーンコード

    ถ้าเราถามว่า code ทำงานได้ กับ code สวย อะไรสำคัญกว่ากัน
    หลายคนคงตอบไม่ยากว่า งานเสร็จ code ทำงานได้สำคัญกว่าอยู่แล้ว
    ความเร็วในการออกของสำคัญมากยิ่งเราอยู่ในโลกของ agile และ scrum

    ผมก็จะบอกว่าถูกครับ

    เรามองว่า Clean code เป็นสิ่งเล็กๆ แต่คุณลองคิดถึงเวลาคุณมีบ้าน ที่ประตูปิดไม่สนิท เวลาปิดมีเสียง เอี๊ยดดดๆ เหมือนในหนังผี กระเบื้องห้องน้ำเรียงมั่ว ก๊อกน้ำน้ำรั่ว
    บางปลั๊กไม่มีไฟ ถามว่าเป็นบ้านไหม เป็น อยู่ได้ไหม ก็อยู่ได้ แต่ทุกสิ่งที่กล่าวมาล้วนปัดเป่าเสน่ของบ้านทั้งสิ้น

    จงให้ความสำคัญกับสิ่งเล็กๆ ในสิ่งเล็กๆ ล้วนสำคัญ
    คนธรรมดากับมืออาชีพ ต่างกันที่ความใส่ใจในรายระเอียด

    แต่เรามักถูกบีบด้วยเวลา และคนเดินมาเร่งมากมาย เวลาเกิดปัญหาเราก็จะบอกว่า

    • ผมมีเวลาแค่นี้ครับ
    • ได้แค่นี้ก็หรูแล้ว
    • มันทำงานได้ก็โอเคร

    จริงๆ แล้วไม่ใช่แค่ Programmer ที่จะต้องเข้าใจในคำว่า หนี้สินทาง software ขอเรียก software debt คำนี้มันเกิดตอนที่ ลุง Robert C. Martin อธิบายให้หัวหน้าฟังเพราะบริษัทที่ทำงานนั้นเกี่ยวกับด้านการเงินเลยเกิดคำนี้มาเพื่อให้หัวหน้าเข้าใจ มันแปลว่าหัวหน้า , PM ใครก็แล้วแต่ที่สั่งเรา ต้องเข้าใจ
    ในเรื่อง software debt ด้วยเพื่อใช้ในการประเมิณเวลาในการทำด้วย

    หลักการในการ クリーンコード

    意味のある名前


    การตั้งชื่อ

    意図を明らかにする


    ชื่อทุกสิ่งที่เราตั้งล้วนต้องมีความหมาย บ่งบอกถึงเจตนาของสิ่งนั้นๆ อย่างชัดเจน เช่น クラスファンクションหากชื่อพวกนั้นต้องการ コメントแสดงว่าชื่อนั้นยังไม่บอกเจตนาอย่างชัดเจน
    // Day of week
var dow 

or

var dayOfWeek

    発音できる名前を使う


    ชื่อต้องอ่านออกเสียงได้ หลีกเลี่ยงการใช้

    AシリーズA 1 A 2 A 3


    ノイズの言葉は別の意味の区別


    ลองนึกภาพว่าคุณมี 製品クラス.หากคุณมีชื่ออื่นที่เรียกว่า productinfoหรือ データคุณได้สร้างชื่อให้แตกต่างกันโดยไม่ทำให้มีความหมายแตกต่างกัน ข้อมูลและข้อมูลเป็นสัญญาณรบกวนที่ไม่ชัดเจน
    คำเช่น エーアンและ この
    อย่ากลัวที่จะตั้งชื่อยาวหากชื่อนั้นสร้างความแตกต่างอย่างมีความหมายได้

    ノイズの言葉が冗長です


    ไม่ควรใส่ 種類ของตัวแปลไปหลังชื่อ เช่น namestring , datelongเพื่อเลี่ยงการปิดเบือนข้อมูลเหมือน 会計係ด้านบน และ
    เพราะว่า 井出สมัยนี้หากเราเอาเมาส์ไปชี้ก็จะแสดง 種類ให้อยู่แล้วถ้าไม่ใช้ตัวแปร ダイナミックタイプ

    避けてください


    หลีกเลี่ยงการทำเกิดความเข้าใจผิด หรือทำให้ความหมายเปลี่ยนแปลง ต่างจากความหมายที่เราตั้งใจไว้ เช่น HP、AIX、SCOทั้งหมดนี้ล้วนเป็นชื่อของ プラットフォーム
    การตั้งชื่อโดยใส่คำว่า リスト会計係การตั้งชื่อแบบนี้เสี่ยงต่อการเข้าใจผิดได้ง่ายว่ามันคือ รายการบัญชีหรือกลุ่มของบัญชีหรือเปล่า เราอาจจะใช้ アカウントสำหรับ アレイアカウントหรือ 会計グループสำหรับกลุ่มของ アカウント

    意味のある区別をする


    ทำให้มีความหมายอย่างแตกต่างบางครั้งการตั้งชื่อให้แตกต่างกันมันก็ยาก ตัวแปรบางตัวที่ชื่อเหมือนกันจะโดนฟ้องโดยคอมไพเรอให้เปลี่ยนชื่อ

    検索名を使用する


    ใช้ชื่อที่ サーチได้ หลีกเลี่ยงการใช้ ตัวอักษรตัวเดียว และ ควรใช้ 定数แทน ตัวเลข มันไม่ง่ายเลยที่เราจะหาตัว 私ที่เราตั้งการใน โปรเจค
    หรือเราจะหาตัวเลข 1ในโปรเจค ควรตั้ง 定数แทน เช่น マキシングドライブ

    エンコードを避ける


    เลี่ยงการใช้ตัวย่อ เพราะว่ายากต่อการเข้าใจและออกเสียงไม่ได้ คิดถึงหนังสือพิมพ์ นย พตรอ นพ อะไรวะงงเยอะไปหมด

    メンバーperfix


    เลี่ยงการใช้คำนำหน้าเช่น ムーニー学生ถ้า 機能เราเล็กพอสิ่งนี้จะไม่เกิดแน่นอน

    クラス名


    ควรเป็นคำนามเท่านั้น ห้ามใช้กริยา

    メソッド名


    ควรเป็นกริยาเท่านั้น ห้ามเป็นคำนาม

    かわいいよ


    อย่าอวดฉลาดตั้งชื่อตัวแปลเท่ๆ เช่น ユレーカ、フェニックス、アイリーンแปลว่าแสงสว่าง)

    選択1ワードあたりの概念


    เป็นการนิยามชื่อ ProtoCalManagerและ protocolcontrollerดูเหมือนกันเลยแต่จะเอาอันไหนละ

    ソリューションドメイン名を使用する


    ใช้การต่อชื่อไปอย่างสอดคล้องกัน CreateMultiplendentMessage部分
    หากทำไม่ได้การเพิ่ม 名前空間ไว้ข้างหน้าจะเป็นทางออกสุดท้าย

    機能

    小さいต้องเล็ก


    1บรรทัดไม่เกิน 150อักษร
    1機能ไม่ควรเกิน 100บรรทัด
    แต่จะให้ดี ไม่เกิน 20บรรทัด

    ブロックとインデント


    もし他のステートメントがあればไม่ควรเกิน 1บรรทัด หากเกินควรแยก 機能

    一つ行う


    1機能ควรทำแยกสิ่งเดียว

    関数引数


    ควรน้อยที่สุดเท่าที่เปิดไปได้ และไม่ควรเกิน 3ถ้าเกินเราอาจจะสร้าง クラスมารองรับ

    動詞・キーワード


    เลือกชื่อที่ดีเป็นกริยาสำหรับ 機能

    副作用がない


    機能เราต้องไม่มี 副作用เพราะหากมีเราจะรู้เลยว่า 機能เราไม่ได้ทำสิ่งเดียว 一つ行う
    public class UserValidator {
 private Cryptographer cryptographer;
 public boolean checkPassword(String userName, String password) {
       User user = UserGateway.findByName(userName);
 if (user != User.NULL) {
       String codedPhrase = user.getPhraseEncodedByPassword();
       String phrase = cryptographer.decrypt(codedPhrase, password);
       if ("Valid Password".equals(phrase)) {
        Session.initialize();
       return true;
     }
   }
 return false;
}
    コードจาก クリーンコード:ロバーツCマチンหน้าที่ 44

    ブロックをキャッチ


    การ キャッチするลงใน 機能เลยอาจจะทำให้ดูน่าเกลียด
    หากเราไม่แยกการทำงานของ 機能ให้ทำงานเพียงอย่างเดียว
    (ในการ キャッチするควรมีแค่ 機能เดียวการทำงานเดียวที่เราดัก)
    いけない
    ในตัวอย่างนี้เราจะเห็นได้ว่าเรา キャッチするในหลาย 機能อาจจะทำให้เราสับสนได้ว่า エラーนี้มาจากกระบวนการไหนของ フローกันแน่
    function delete(page){
 try{
  deletePage(page);
  registry.deleteReference(page.name);
  configKeys.deleteKey(page.name.makeKey());
 }catch(error){
   throw Exception("can't delete page "+page.id+" error :"+error)
 }
}
    ドゥ
    function delete(page){
 try{
  deletePageAndAllReferences(page);
 }catch(error){
  throw Exception("can't delete page "+page.id+" error :"+error)
 }
}
function deletePageAndAllReferences(){
  deletePage(page);
  registry.deleteReference(page.name);
  configKeys.deleteKey(page.name.makeKey());
}
    เราควร

    自分を繰り返すな


    อย่าทำซ้ำ เช่นซ้ำซ้อนการทำงานต่างๆ 重複

    コメント

    code ที่ดีต้องไม่มี comment เราชอบคิดว่ามันซับซ้อนเลยต้องมี comment จริงๆ มันไม่ถูกซะทีเดียวเราควรทำให้ code ดีมากกว่าคิดว่ามันซับซ้อนอ่านยากเลยต้อง comment
    comment ที่ควรเขียนมีแค่ Copyright กับ authorship statement

    หรือข้อยกเว้นหากเราเขียน libary ที่ซับซ้อนมากๆ การ comment ก็ไม่แปลกอะไรแต่ทางที่ดีที่สุดคือ ทางที่เราไม่ใส่ comment

    書式設定

    The coding style and readability เราควรจะจัด code style ให้ตรงกัน ซึ่งสามารถกำหนดใน IDE ได้
    เช่น 150 ตัวอักษรสำหรับ 1 บรรทัด ฯลฯ

    ทั้งหมดทั้งมวลนี้อาจจะไม่สอดคล้องกับสิ่งที่คุณรู้เชื่อ หรือเข้าใจ คุณอาจจะไม่เห็นด้วยกับบทความนี้ทั้งหมดก็ได้เพราะหลายคนประสบห์การต่างกันอาจจะมี trick ที่เทคนิคพิเศษที่ต่างกันไป
    TIL 3日目
    HTML入門基礎課(11)