Nhưng lưu ý khi thiết kế một công cụ CLI tối giản

"Làm một việc và làm tốt việc đó"

#tty

Triết học UNIX được đề cao khi thiết kế công cụ CLI vì nó giúp gắn kết các công cụ riêng biệt thành một hệ sinh thái TTY thống nhất. Mỗi công cụ chỉ "Làm một việc và làm tốt việc đó", điều đó giúp mọi công cụ có thể được kết nối hài hòa với nhau. Tuy vậy mình vẫn thấy không ít công cụ CLI cũ và mới có một số những tính năng hơi thừa, những tính năng này được cho vào có chủ đích là để việc sử dụng nó tiện lợi hơn nhưng trên thực thế người dùng có thể sử dụng những tính năng đó thông qua các công cụ có sẵn mà vẫn tiện không kém. Những tính năng thừa trong một công cụ CLI chỉ làm cho công cụ đó trở nên cồng kềnh phức tạp hơn.

Điều hướng

Nếu công cụ của bạn làm việc với string chứ không cụ thể là với file, công cụ đây không cần flag để đọc file như -f, --file, -i, --input... Vì nó không cần thiết và còn làm công cụ của bạn trở nên phức tạp hơn một chút. Thay vì thế bạn nên cho phép công cụ của bạn đọc stdin, syntax này có thể được sử dụng một cách thống nhất giữa các công cụ và hầu hết các shell đều có hỗ trợ điều hướng dữ liệu từ một file vào phần mềm:

tool < input.txt
cat input.txt | tool
cat input1.txt input2.txt | tool

Tương tự với đọc file, hầu hết các shell đều có hỗ trợ điều hướng dữ liệu từ phần mềm vào file:

tool > output.txt
tool >> output.txt
tool | tee output1.txt output2.txt
tool < input.txt >> output.txt

Clipboard

Công cụ CLI của bạn không nên có tính năng lấy hoặc xuất dữ liệu ra clipboard vì mọi người sẽ dùng công cụ của bạn ở đủ mọi loại môi trường, bạn sẽ chết mệt nếu đi hỗ trợ từng trình quản lý clipboard ở các môi trường đấy. Mà đăng nào nếu người dùng muốn công cụ của bạn tương tác với clipboard, họ sẽ muốn pipe nó ra / vào trình quản lý clipboard mà họ đang dùng hơn:

cb | tool
tool | cb

File cài đặt

Đừng bịa ra một định dạng hay một ngôn ngữ riêng để cài đặt:

  • Nếu file cài đặt chỉ lưu trữ giá trị, hãy dùng JSON, TOML, YAML hoặc KDL. INI cũng được nhưng định dạng này có nhiều hạn chế và nó không được sử dụng thông nhất cho lắm. Sử dụng định dạng phổ biến đương nhiên sẽ tốt hơn cho cả người phát triển lẫn người dùng. Các công cụ quản lý dotfiles như Home Manager cũng dễ dàng làm việc với các định dạng này hơn.
  • Nếu nó cần scripting, hãy tạo ra một giao diện CLI để mọi ngôn ngữ có thể gọi nó. Hoặc tạo ra một thư viện hay API cho Lua, Python, Ruby... Đừng tạo ra một ngôn ngữ lập trình riêng chỉ để cài đặt công cụ của bạn vì ngôn ngữ đó kiểu gì cũng thiếu thốn, ọp ẹp hơn so với một ngôn ngữ lập trình hẳn hoi.

Hiển thị màu

Nếu công cụ của bạn hỗ trợ hiển thị màu, làm ơn hay sử dụng màu 3-bit và 4-bit làm mặc định! Mình biết là màu mặc định của TTY rất là xấu nhưng hầu hết mọi người dùng terminal đều dùng theme, và khi họ dùng theme họ muốn mọi phần mềm đều hiển thị bằng màu trong theme đấy, chứ không phải là một đống màu nào đó. Có rất nhiều công cụ CLI không tuân theo điều này và chọn sử dụng màu của theme Monokai, Gruvbox hoặc tự dùng những màu rất rợ! Dùng terminal mà thấy vài tool có màu lệch tông ra khỏi theme của terminal trông rất là cộm.

Đọc thêm

Mình rất khuyến khích mọi người đọc qua Command Line Interface Guidelines, bài viết không chỉ có hướng dẫn mà còn đưa ra các triết lý khi thiết kế CLI.