DEV Community: PRODIGY9

จะทำยังไงดีน้าาาา.. อยากแก้คำผิดใน commit message ที่ผ่านๆ มา

Gatuk S. Chattanon — Sat, 02 Oct 2021 09:20:20 +0000

เคยไหม... ในวันที่เราต้องแก้โค้ดอะไรสักอย่างหนึ่งในวันที่เร่งรีบ แล้วเผลอ commit message อย่างรัว จนทำให้พิมพ์อะไรผิดไปสักอย่างหนึ่ง

เคยไหม... ในวันที่เรามีไฟสุดๆ ตื่นเช้ามาเขียนโค้ด แล้ว commit code อย่างรัว ยังกับตัวเองเป็น hacker ยังไงยังงั้น แต่กลับมาเจอว่า แย่แล้ว! เราเขียน commit message หลายอันผิดไป!

หลายคนอาจจะเคย และหลายคนอาจจะไม่เคย แต่ถ้าหากเคยเป็น เราก็มี choice แค่ไม่กี่อย่าง นั่นก็คือ ทิ้งมันไว้ตรงนั้นแหละ 🥲 กับอีกอย่างคือ ขอกลับไปแก้หน่อยน่าา 🤔

ถ้าหากเราเลือก choice "ขอกลับไปแก้หน่อยน่าา" นั่นแปลว่า blog นี้จะเป็นประโยชน์กับทุกคนที่ผ่านมาอ่านแน่ๆ 555 (เราเชื่อว่าแบบนั้น 😌)

ดังนั้น เราจะพาทุกคนไปทำความรู้จักกับ git interactive rebase mode สำหรับการแก้ไข commit message หลายๆ อันในอดีต

เราขอสมมติเหตุการณ์ กันเลยดีกว่า สมมติว่าเราสร้าง branch ใหม่ขึ้นมาชื่อว่า branch feature/user_login ไว้สำหรับการ login ของ user เข้าสู่ระบบ ซึ่งแน่นอนว่า การ login นั้น จะมี task หลายๆ task เกิดขึ้นมา โดยเราจะขอ commit 1 ครั้งเมื่อ task 1 task เสร็จเรียบร้อย และใช้งานได้ โดย commit message ที่เกิดขึ้น จะมี 4 อัน ดังนี้

commit ff6c9f5ac37d77bbe084a7f8cc0d5a34c96d89e4 (HEAD -> feature/login_user)
Author: Gatuk Chattanon <gatukgl@gmail.com>
Date:   Sat Oct 2 15:35:33 2021 +0700

    Login user to system when user is valid

commit b9c3458ff62d400f54005927c832cee063a3d682
Author: Gatuk Chattanon <gatukgl@gmail.com>
Date:   Sat Oct 2 15:35:16 2021 +0700

    Validate psw

commit c6cda7e462eba06b65fac5d5e176f10a06652eed
Author: Gatuk Chattanon <gatukgl@gmail.com>
Date:   Sat Oct 2 15:34:53 2021 +0700

    Validate email

commit d519a517e3c8b2967ffae6155f906ccea95af7fb
Author: Gatuk Chattanon <gatukgl@gmail.com>
Date:   Sat Oct 2 15:34:07 2021 +0700

    crate login form

จะเห็นได้ว่า ด้วยความรีบหรืออะไรก็ตาม ทำให้เราพิมพ์ commit message ผิดๆ ถูกๆ เห็นแล้วขัดใจเพื่อนร่วมทีมแน่ๆ review โค้ดกันที หรือกลับมาอ่าน commit อีกทีทีหลัง น่าจะปวดใจมากๆ เพราะฉะนั้นเรามาลองแก้ไขให้ถูกกัน โดยใช้ git interactive rebase นั่นเองจ้า!

$ git rebase -i HEAD~<number_of_commits> 
// หรือ
$ git rebase -i @~<number_of_commits>

ซึ่ง number_of_commits ด้านบนนั้น หมายถึง จำนวน commit message ที่เราต้องการจะย้อนไปเริ่มแก้ไข โดยใน branch feature/login_user นั้น เราได้สร้าง commit message ขึ้นมาทั้งหมด 4 อัน และอยากจะย้อนกลับไปแก้ไข ตั้งแต่ commit เริ่มต้นเลย ซึ่งก็ย้อนไป 4 อันนั่นเอง เพราะฉะนั้นเราจะต้องใช้ command ด้านล่างนี้

$ git rebase -i @~4

หลังจากนั้น ก็ต้องใช้ทักษะ ความเชี่ยวชาญชำนาญด้าน vim เล็กน้อย ถึงปานกลาง 5555 เพราะว่าเมื่อเข้าสู่ interactive mode น้อง terminal ก็จะเปิด vim editor ขึ้นมาให้เรานั่นเองเป็นอัตโนมัติ ซึ่งก็จะมี commit message ต่างๆ เหล่านี้ขึ้นมา (อันนี้ใครที่ไม่ค่อยถนัดใช้ vim เรามีวิธีการเปลี่ยนให้ terminal ไปเปิด editor ตัวอื่นได้เช่นกันค่ะ อ่านวิธีได้ที่นี่)

pick d519a51 crate login form
pick c6cda7e Validate email
pick b9c3458 Validate psw
pick ff6c9f5 Login user to system when user is valid

ส่วนด่วนล่าง commit ที่เราเลือกมา 4 อันนั้น เป็นคำอธิบายการใช้ command ต่างๆ ซึ่งที่เราจะเลือกหยิบมาใช้ใน blog นี้นั้น ก็คือ reword นั่นเองค่ะ ซึ่งเป็นการ edit commit message

โดยดูจาก commit message แล้วเนี่ย... มี commit ที่เราอยากจะแก้อยู่ 2 อัน นั่นก็คือ

d519a51 crate login form อยากจะแก้ให้เป็น Create login form
b9c3458 Validate psw อยากจะแก้ให้เป็น Validate password

ทำได้โดยการนำ reword ไปไว้ด้านหน้า commit message ที่เราอยากจะแก้ไข แบบนี้

reword d519a51 crate login form
pick c6cda7e Validate email
reword b9c3458 Validate psw
pick ff6c9f5 Login user to system when user is valid

หลังจากนั้นให้ save & quit ออกจาก vim editor หลังจากนั้นเราจะเห็นว่า terminal ของเราได้เปิด vim editor หน้าใหม่ขึ้นมาให้เราโดยอัตโนมัติ ให้เราแก้ commit message นั่นเองจ้า ทีนี้ ก็แก้ไขแล้วก็กด save & quit ออกมาทีละ message จนครบทุก commit ที่เราเลือก เพียงเท่านี้ ก็ได้ commit message ใหม่ ไฉไลกว่าเดิม

หากใครยัง งงๆ อยู่ นั้นเราจะขออัดเป็น gif สั้นๆ ให้ดูกันละกันนะคะ ^^ (ขออภัย รูปเล็กไปนิดนึง)

เราขอบอกก่อนว่า ถ้าเกิดใครที่รู้ตัวทัน อยากจะแก้ไขแค่เฉพาะ 1 commit ก่อนหน้าเพียงแค่อันเดียว ไม่จำเป็นต้องใช้ interactive rebase mode ก็ได้ค่ะ เพราะว่าเราสามารถกลับสู่สามัญ แล้วไปใช้ amend ได้ ตัวอย่างเช่นด้านล่างนี้

$ git commit --amend -m 'new commit message'

// หรือ

$ git commit --amend  // อันนี้จะไปเปิด vim editor

Reference:

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

มารู้จักกับ Clean Architecture กันดีกว่า!

Gatuk S. Chattanon — Sun, 15 Aug 2021 10:21:35 +0000

⭐️ วันนี้เราจะพาทุกคนมารู้จักกับ Clean Architecture นั้น ที่เป็น 1 article ของ Robert C. Martin หรือว่า Uncle Bob กันค่ะ!

Clean Architecture คืออะไรกันนะ?

อย่างที่บอกไปข้างบนก่อนหน้าที่เราจะมารู้จัก Clean architecture มากขึ้นใน section นี้.. Clean Architectuกre ถูกเขียนขึ้นในบทความหนึ่งของ Robert C. Martin ซึ่งเป็นผู้ที่เรียกได้ว่าเป็นผู้ที่มีอิทธิพลในเรื่องของการเขียนโค้ดที่ดี หรือที่เค้าเรียกว่าเขียนโค้ดให้ clean นั่นเอง บทความนี้ชื่อว่า "The Clean Architecture" ถูก publish มาตั้งแต่ปี 2012 (เกือบจะ 10 ปีแล้ว)
.
จุดประสงค์ของการใช้ Clean Architecture จะช่วยให้เราสามารถแยก layer ของโค้ด โดยในแต่ละ layer ก็จะทำงานของตัวเองอย่างชัดเจนไปเลย หรือที่เราเรียกว่า separation of concern นั่นเอง

ทำไมเราถึงมาใช้ Clean Architecture ล่ะ?

อย่างแรก คือ "Independent of Frameworks" หมายความว่า โค้ดที่เราเขียนจะไม่ผูกติดอยู่กับ framework ไปทุกส่วนของโค้ด ในวันไหนที่เราอยากจะเปลี่ยนไปใช้ framework อื่นๆ จะได้ปรับเปลี่ยนได้อย่างง่ายขึ้น
.
อย่างที่สอง ได้แก่ "Testable" หมายถึง เราจะสามารถ test code ของเราง่ายขึ้น ตัวอย่างเพื่อให้เห็นภาพมากขึ้น คือ การแยกส่วนของ business logic ออกจากส่วนอื่นๆ เช่น UI หรือ database เวลาที่เราเขียน test ส่วนของ business logic ก็จะง่ายขึ้น เพราะไม่ต้องสนใจเรื่อง UI ว่าจะต้อง render อย่างไร หรือว่าจะต้องไปต่อกับ database ตัวไหน เป็นต้น
.
อย่างที่สาม คือ "Independent of UI" เมื่อเราแยกส่วนของ UI ออกจาก business logic แล้ว สิ่งที่ง่ายขึ้นก็คือ เราสามารถเปลี่ยนแปลง UI ได้โดยไม่ต้องกังวลว่า business logic จะพังทลายไปด้วยหรือเปล่า
.
อย่างที่สี่ คือ "Independent of Database" เป็นการแยกส่วนที่ติดต่อกับ database ออกมา สมมติเหตุการณ์สักหน่อย ก็คงจะนึกถึง case ของ เวลาเราสร้าง project ขึ้นมาใหม่ เราใช้ database sqlite แต่นานวันเข้า sqlite ไม่ตอบโจทย์ของการใช้งานของ user จริงๆ บน production เราจะต้องเปลี่ยน database ไปใช้ Oracle แทน เราก็สามารถทำได้ง่าย เพราะเราได้แยก layer ไว้อยู่ที่ layer เดียวแล้ว
.
อย่างสุดท้าย คือ "Independent of any external agency" หมายถึง business logic ต่างๆ จะไม่รู้ว่าเกิดอะไรขึ้นภายในโค้ดที่ business logic สนใจเลยยย
.
โดยเหตุผลเหล่านี้ ก็ถูกเขียนอยู่ในบทความ The Clean Architecture ด้วยเช่นกัน ใครอยากอ่าน version ต้นฉบับ ก็สามารถเข้าไปตามอ่านกันได้ ที่นี่ เลยจ้า

The Dependency Rule ของ Clean Architecture

จากภาพข้างบน เราจะเห็นได้ว่า แต่ละวงกลมจะสื่อถึง layer ต่างๆ เวลาที่เราทำ software ใดๆ ก็ตาม โดยวงกลมที่อยู่ด้านนอกๆ จะสื่อถึง layer ที่สูงๆ ซึ่งโดยทั่วไปก็จะเป็นส่วนที่ติดต่อกับคนที่ใช้งาน ส่วนวงกลมที่อยู่ด้านในๆ ก็จะเป็นส่วนที่ low level มากๆ อย่างเช่น ส่วนที่ติดต่อกับ database เป็นต้น
.
เรามาทำความรู้จักมากขึ้นกับวงกลมแต่ละ layer ให้มากขึ้นกันดีกว่า 🎉

Entities

ส่วนนี้เป็นส่วนที่ติดต่อกับ Enterprise Business Rules ซึ่งโค้ดที่เกิดขึ้นใน layer นี้ อาจจะเป็น model ที่เก็บ data structure ของข้อมูลในองค์กรของเราก็ได้ โดยส่วนนี้จะมีการเปลี่ยนแปลง และกระทบน้อยที่สุด เนื่องจากเป็นชั้นด้านในที่สุดเลย เช่น ถ้าหากเราเปลี่ยนแปลง UI จาก design แบบหนึ่ง ไปเป็นอีกแบบหนึ่ง ก็จะมีโอกาสน้อยมากที่ structure ของ data ของเราจะเปลี่ยนแปลงไปตาม

Use Cases

ส่วนนี้จะเป็นส่วนที่มี Application Business Rules อยู่ ซึ่งโค้ดใน use case เหล่านี้ก็จะเป็นส่วนที่ควบคุมว่าจะมี data อะไรที่จะนำออกจาก.. หรือนำเข้าไป entities บ้าง โดยที่จะทำให้ได้ผลลัพธ์อย่างที่โปรแกรมของเราต้องการ

Interface Adapters

ส่วนนี้จะประกอบไปด้วยส่วนที่เอาไว้ใช้ convert data จาก format ใดๆ ก็ตาม ให้เป็น format ที่ application ของเราเข้าใจและใช้ได้ง่าย เช่นการแปลงจาก json format ให้เป็น object ที่เราต้องการ เราจะเรียกสิ่งที่ทำหน้าที่เหล่านี้ว่า Adapter ซึ่ง Adapter ถ้าแปลเป็นไทยก็คือ "ตัวแปลง" นั่นเอง

Frameworks and Drivers

เป็นส่วนที่จัดการกับ framework ที่เราใช้ในโปรเจกต์ ในส่วนนี้เราอาจจะไม่ได้เขียนโค้ดมาก แต่ก็เป็นส่วนที่สำคัญ เพราะเราเอาไว้ใช้ ติดต่อกับ framework ต่างๆ ที่เราใช้ เช่น การเขียนโค้ดเพื่อสร้าง database connection เป็นต้น
.

และนี่ก็คือ... แทบจะเป็นทฤษฎีของ The Clean Architect ที่เราลองเขียนสรุปตามความเข้าใจของเรามาให้ทุกคนได้ลองรู้จักกับสิ่งนี้ เพื่อให้การเขียนโค้ดของเราดีขึ้นนะคะ และจริงๆ แล้ว ถ้าจะเล่าให้ฟังให้เห็นภาพมากขึ้น เราน่าจะต้องทำความเข้าใจในการ apply ด้วยว่าถ้าจะเอา Clean Architecture ไปใช้งานจริงๆ แล้วเราจะทำยังไงกันนะ...
.
ซึ่งเราขอ spoil ตอนต่อไปเลยละกันว่า.. เราจะพาทุกคนไปทำความคุ้นเคยมากขึ้น ว่าถ้าเกิดเอาไปใช้กับโปรเจกต์ที่เขียนด้วย golang ล่ะ มันทำยังไงกัน! เพราะฉะนั้นติดตามตอนต่อไปได้เลยจ้าาาา 😎

Reference

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Comparing Boolean Expression to True

Chakrit Wichian — Wed, 17 Mar 2021 17:47:19 +0000

This has to be the oldest trick in the book in the sense that only really early beginner make these mistakes.

Instead of

class User
  attr_reader :username
  attr_reader :email

  def is_valid?
    valid = !self.username.blank? && !self.password.blank?
    valid == true
  end
end

Do this

class User
  attr_reader :username
  attr_reader :email

  def is_valid?
    !self.username.blank? && !self.password.blank?
  end
end

Why?

Boolean expressions eventually resolve to either true or false. Comparing them again to true wastes computation and adds extra cognitive load without actually adding to the readability or explicitlness.

Why Not?

Sometimes you don't always have a binary true or false values. For example, you can have undefined, null or nil values in other languages. In which case, comparing them to true do have a use because you want to avoid the other two (or three) possibility of the value not existing, or the value being false at the same time.

let result = render(template);                  // default options `{}`
result = render(template, { escape: true });    // explicit options

function render(content, options = {}) {
  if (options['escape'] === true) {
    content = htmlEscape(content)
  }

  // ...
}

It may, however, confuses the reader because the absence of value is implicit in this context. Calling out implicitness usually improves readability but reduce succintness and adds conginitive load. So depending on your situation, shorter may be better or explicit may be better.

One way to make this explicit is to split apart the two concerns in the code:

Checking for absence of value
Checking for the value itself

Like so:

function render(content, options = {}) {
  if (typeof options['escape'] !== 'undefined' && options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

This code calls out to the reader to be on the lookout for the absence of values in the options hash. That not all options maybe passed into the function.

Alternatively, we can eliminate 1) entirely by supplying defaults:

function render(content, options = {}) {
  if (!options.hasOwnProperty('escape')) {
    options['escape'] = defaults['escape']
  }

  // now we are sure the 'escape` option will always be specified
  // our check is now straightforward
  if (options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

An experienced coder will also notice that the pattern of "applying defaults" can be made more generic and applied uniformly throughout the codebase. This is exactly the usecase of lodash's _.defaults() method which we can use to make the code more succinct:

function render(content, options = {}) {
  _.defaults(options, defaults); // eliminate any "absence of value" cases

  if (options['escape']) {
    content = htmlEscape(content)
  }

  // ...
}

We can avoid Lodash entirely and use null-coalescing operator ?? if your language supports them:

function render(content, options = {}) {
  if (options['escape'] ?? false) {
    content = htmlEscape(content)
  }

  // ...
}

[WIP] Write Better Code

Chakrit Wichian — Wed, 17 Mar 2021 17:46:37 +0000

This series is meant to be a collection of tips, tricks and techniques for writing a more readable and maintainable code. The content will focus exclusively on the style and other subjective elements of code writing. There are already many other content on the web that talk about the semantics and how a piece of code or an algorithm "works". We focus, here, instead on how the code "reads".

That being said, this does not mean we will forego the concern of making sure the code work entirely. We believe, rather, that correctly working code are a result of not only it having correct semantics, but also because the programmer writing/maintaining it can reason about it easily because the code was written with such high readability standards.

In other words, we believe making the code more readable makes it more correct as well.

The content are purely derived from my own personal experience writing, reading and debugging unbelievable number of lines of code over 20+ years. Contributions are, of course, welcome and if this proves to be useful to many people, I'd be happy to open source and license it.

Some of the content found here may feels familiar to readers of coding style books, but, again, I'd like to emphasize that this is distilled from my personal experience only and not summarized from any book. It also have no set plans or publishing schedule, I'll add to it as I have time and feel like I have something useful to contribute. Other times, it may stay static for months or years.

I do believe, however, that there is an ultimate answer to all code styling issues. I believe that after a certain point in the career of programming and software development, most of us eventually come to the same or similar realization/conclusion. So it should be of no coincidence that some concepts found here may have already been explained in some book or some blog post somewhere on the interwebs. In which case , I'll add links and references to the relevant pages.