These tools will help you write clean code
09-Nov-18
คัมภีร์เทพ IT
See the original english version Click here!
การเขียน Code ได้ ต่างกับ การเขียน Code ที่ดี ซึ่งการเขียน Clean Code ถึงเป็นเป้าหมายสำคัญที่เหล่า Coder แทบทุกคนอยากที่จะทำให้ได้ วันนี้เรากันว่า 5 เครื่องมือ ที่ช่วยให้เขียน Clean Code ง่ายขึ้น มีอะไรบ้าง แม้บทความค่อนข้างยาว เนื่องจากมี Tutorial แนะนำว่าคุณควรทำอะไรบ้าง แต่มันจะเป็นประโยชน์กับคุณแน่นอน
1. Prettier

- ทำการ Clean Code ที่มีอยู่
- ใช้งานง่าย: เนื่องจากที่เป็น Open source จึงทำให้มีหลายๆ คนได้ใช้งานมันและปรับปรุงแก้จากประสบการณ์ของพวกเขา จนทำให้มันใช้งานง่าย
- ไม่ทำให้เสียเวลา: สิ่งที่หลายคนไม่ค่อยตระหนัก คือพวกเขาใช้เวลาในการจัดรูปแบบ Code ไปโดยไม่จำเป็น แต่หากคุณปล่อยให้ Prettier จัดการกับมันจะทำให้คุณมีเวลาทำอย่าง
- เป็นตัวช่วยสำหรับมือใหม่: หาก Developer มือใหม่ต้องทำงานร่วมกับ Engineer เก่งๆ และต้องการให้ดูเก่งในการเขียน Clean Code ขอแนะนำให้ใช้ Prettier




- จัดรูปแบบและจัดเยื้อง/ย่อหน้าใน Code ด้วยตนเอง
- ใช้เครื่องมืออัตโนมัติ
- ปล่อยมันไป ไม่ต้องทำอะไร (หวังว่าคุณจะไม่เลือกหัวข้อนี้)






2. ESLint
Code linting เป็นเครื่องมือที่ช่วยการวิเคราะห์โครงสร้างของ Code ซึ่งมักใช้เพื่อค้นหารูปแบบของปัญหาที่อาจะเกิดขึ้น หรือ Code ที่เป็นปัญหาซึ่งไม่เป็นไปตาม Style Guidelines สำหรับ Code Linter ที่น่าสนใจและพูดถึงในบทความนี้คือ ESLint ซึ่ง Linting tools ที่จะช่วยให้ Developer สามารถค้นหาปัญหาเกี่ยวกับ JavaScript Code ได้โดยไม่ต้อง Execute มัน
ทำไม ESLint ถึงมีความพิเศษ?
ทุกอย่างใน ESLint สามารถใส่เพิ่มเติมได้ คุณสามารถเพิ่ม Rules ได้ (ไม่ใส่ Rules และ Formatter เข้าไปก็ได้) และทุกๆ Linting Rule ที่คุณเพิ่มเข้าไปเป็นแบบ Stand alone สามารถเปิด-ปิดได้ และแต่ละ Rule สามารถ Set ให้แสดง Warning หรือ Error ได้ นอกจากนี้การใช้ ESLint จะทำให้คุณสามารถปรับแต่ง Style Guide ได้ตามที่คุณต้องการ โดยปัจจุบันมี 2 Style Guide ที่เป็นที่นิยมคือ Google JavaScript Style Guide และ Airbnb JavaScript Style Guide




- env: Environment กำหนดตัวแปร Global ที่ถูกกำหนดไว้ล่วงหน้า Environment ที่มีอยู่ - ในกรณีนี้คือ es6, browser และ node
- extends: Array ของ Strings – แต่ละ Configuration ที่เพิ่มเติมเข้าไป จะช่วย Extend ตัว Configuration ก่อนหน้านี้ ตอนนี้เรากำลังใช้ Linting Rules โดย airbnb ซึ่งจะถูก Extend ไปยัง jest และจากนั้น Extend ไปยัง jest-enzyme
- plugins: plugins เป็น Linting Rules พื้นฐานที่เราต้องการใช้ ตอนนี้เรากำลังใช้ Babel, Import, jsx-a11y, React, Prettier ซึ่งได้อธิบายไปข้างต้นแล้ว
- parser: โดย Default แล้ว ESLint ใช้ Espree แต่เนื่องจากเราใช้ Babel จึงจำเป็นต้องใช้ Babel-ESLint
- parserOptions: เมื่อเราเปลี่ยน default parser สำหรับ Espree ไปยัง Babel-eslint เราจำเป็นต้องระบุ parserOptions ด้วย
- rules *: rules ทั้งหมดที่เราได้ Extend และเพิ่มเข้าไปด้วย plugins เราสามารถเปลี่ยนหรือแทนที่ได้
- /.git: กรณีไม่ต้องการให้ File ที่เกี่ยวข้องกับ Git ถูก Linted
- /.vscode: หากคุณใช้ VS code แล้วมีการ configuration เอง หากไม่ต้องการให้ configuration ของคุณถูก Linted ก็ใส่ Path นี้เข้าไป
- node_modules: กรณีไม่ต้องการให้ Dependency ถูก Lint ก็สามารถเพิ่มสิ่งนี้ลงในรายการ

- $ yarn lint : เมื่อ Run สั่งนี้ มันจะไปยัง File ทั้งหมดของคุณใน src/ และจะให้รายละเอียดการ Log in ในแต่ละ File ที่พบ Error ซึ่งคุณสามารถเข้าไปแก้ไขด้วยตนเองได้http://images.techstarthailand.com/images/blog/Article2018/CleanCodeTools/2.ESLint06.gif
- $ yarn lint:write : เมื่อ Run สั่งนี้ มันจะทำเช่นเดียวกับคำสั่งด้านบน แต่สิ่งที่เพิ่มเติมเข้ามา คือมันจะช่วยแก้ไข Error ใน Code ให้ถูกต้อง ซึ่งมันจำช่วยแก้ไขเท่าที่จะทำได้
3. Automate Format & Lint on Save
- จัด Format และ Lint Code โดยกด “ctrl + s” ใน Editor ของคุณ
- ทุกครั้งที่คุณ Commit Code ให้ Execute ตัว Pre-command โดยอัตโนมัติ เพื่อ Lint และจัด Format Code ของคุณ
- ติดตั้ง Plugin ที่เรียกว่า ESLint extension

- editor.formatOnSave จากตัวอย่าง ที่ตั้งตรงนี้เป็น False เนื่องจากไม่อยากให้ Default Editor Configuration ของ File Format ไปเกิด Conflict กับ ESLint และ Prettier
- eslint.autoFixOnSave จากตัวอย่าง ที่ตั้งตรงนี้เป็น True เนื่องจากต้องการติดตั้ง Plugin ให้มันทำงานทุกครั้งที่กด Save เมื่อ ESLint ถูก Config ค่ากับ Prettier Configurations แล้ว ทุกครั้งที่คุณกด Save มันจะจัด Format และ Lint Code ของคุณ
4. Husky
Husky คืออะไร?
โดยพื้นฐานแล้ว มันจะช่วยเมื่อคุณต้องทำงานกับ Git นั่นหมายถึง คุณสามารถทำบางสิ่งบางอย่าง เมื่อคุณกำลังจะ Commit หรือเมื่อคุณกำลังจะ Push Code ไปที่ Branch
ก่อนอื่นคุณต้องทำการ Install Husky ซะก่อน:
และในไฟล์ package.json ให้เพิ่ม snippet เข้าไป:
ดังนั้นทุกครั้งที่คุณ Commit หรือทำการ Push มันจะ Execute บาง Script หรือคำสั่ง เหมือนอย่างการ Run ตัว Test Cases หรือจัด Format Code ของคุณ โดยคุณสามารถอ่านเพิ่มเติมเกี่ยวกับ Husky ได้ที่นี่
5. Lint-staged
Lint-staged คืออะไร?
Lint-staged จะช่วยให้คุณ Run Linters บน Staged Files ดังนั้น Bad Code จึงไม่ถูกส่งไปที่ Branch
ทำไมต้อง Lint-staged?
การ Linting ทำให้เราคิดว่ามีการ Run ก่อนที่จะ Commit Code การทำเช่นนี้คุณจะมั่นใจได้ว่าจะไม่มี Error ใดๆ ที่เกิดขึ้นใน repository แต่การ Run กระบวนการ Linting ใน Project ทั้งหมดทีเดียวส่งผลทำให้ทุกช้าลง และผลที่ออกมาก็อาจไม่ดีอย่างที่ควรจะเป็นด้วย ในท้ายที่สุดคุณเพียงต้องการ Linting ไฟล์ที่ผ่านการ Commit แล้ว
Project นี้มี Script ที่จะ Run Shell Talk ได้เสมอโดยใช้ List ของ Staged Files เป็น Argument และถูกกรองโดย glob pattern คุณสามารถอ่านเพิ่มเติมได้ที่นี่
สิ่งที่คุณต้องทำคือติดตั้ง Lint-staged:
จากนั้น เพิ่มสิ่งนี้ลงไปในในไฟล์ package.json ของคุณ:
สิ่งที่คำสั่งนี้จะทำคือ Run คำสั่ง lint:write ก่อน จากนั้นจะเพิ่มมันเข้าไปใน Staging Area มันจะ Run คำสั่งนี้สำหรับไฟล์ .js และ .jsx เท่านั้น แต่คุณสามารถแบบนี้สำหรับไฟล์อื่นได้เช่นกันถ้าคุณต้องการ
6. With Husky & Lint-staged Combined
ทุกๆ ครั้งก่อนที่จะ Commit Code มันจะ Run Script ที่เรียกว่า Lint-staged โดยจะ Run ตัว npm run lint:write ซึ่งจะ Lint และจัด Format Code ของคุณ แล้วเพิ่มมันลงใน staging area แล้วถึง Commit
สุดท้ายแล้ว ไฟล์ package.json ของคุณควรมีลักษณะดังนี้ และนี่ก็เป็นตัวอย่างเดียวกับที่ได้แชร์ไว้ด้านบน:
นี่คือสิ่งที่คุณทำมันทุกครั้ง:
มันจะ Lint และจัด Format Code ของคุณ ตาม Rule ทั้งหมดที่ใส่ในไฟล์ .eslintrc.js ด้วยเหตุนี้คุณจึงมั่นใจได้ว่า จะไม่มี Bad Code ถูก Push เข้าไปในขั้นตอน Production
ในสิ่งที่ Section นี้ได้สรุปไว้ ตอนนี้คุณมี Prettier, ESLint และ Husky ถูก Integrate อยู่ใน Code ของคุณ
7. EditorConfig ?
เริ่มต้นด้วยการสร้างไฟล์ .editorconfig ในโฟลเดอร์ root app/ แล้วให้วาง Code ที่อยู่ด้านล่างลงไปในไฟล์ดังกล่าว:
EditorConfig คืออะไร?
คงไม่ใช่ทุกคนที่จะใช้งาน VS Code และคุณก็ไม่ควรไปบังคับให้พวกเขาใช้ด้วย เพื่อให้ทุกคนเข้าใจและทำในสิ่งเดียวกันในเรื่องของสิ่งที่เป็น Defaults เช่น tab space หรือตัวสิ้นสุดบรรทัดที่ควรจะเป็น เราใช้ .editorconfig เพื่อทุกอย่างยังอยู่ใน Rule ที่ตั้งไว้
นี่คือ List ของ Editor ทั้งหมดที่ Support EditorConfig ซึ่ง Editor เหล่านี้มีทั้ง Web storm, App code, Atom, eclipse, emacs, bbedit และอื่นๆ
การ Configuration ตาม List ด้านบน จะทำตามนี้:
- ตัดช่องว่างด้านท้าย จากไฟล์ .md & .js
- ตั้งค่ารูปแบบการเยื้อง (Indent Style) ด้วย Space แทนการใช้ Tab
- ขนาดการเยื้องเป็น 2
- เพื่อให้สิ้นสุดบรรของทุกคนเหมือนกัน (โดยไม่คำนุงถึง OS) ให้ลองอ่านเพิ่มเติม ที่นี่
- ควรมีบรรทัดใหม่เมื่อสิ้นสุดไฟล์
- ความยาวสูงสุดของแต่ละบรรทัดไม่ควรเกิน 100 อักขระ
เชื่อว่าบทความนี้ น่าจะเป็นประโยชน์ให้คุณนำไปประยุกต์ใช้ได้ในงานของคุณนะครับ
ที่มา: https://medium.freecodecamp.org/
รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert
อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ
บทความที่เกี่ยวข้อง