Trong bài viết đầu tiên trong chuỗi này, bạn tạo một script Bash rất nhỏ, một dòng, và khám phá lý do tạo shell script và tại sao chúng là lựa chọn hiệu quả nhất cho system administrator, thay vì chương trình biên dịch.
Trong bài viết thứ hai này, bạn sẽ bắt đầu tạo template Bash script có thể dùng như điểm khởi đầu cho các script Bash khác. Template cuối cùng sẽ chứa cơ sở Help, tuyên bố cấp phép, một số hàm đơn giản, và logic xử lý các tùy chọn đó và những cái khác có thể cần cho các script dựa trên template này.
Tại sao tạo template?
Giống như automation nói chung, ý tưởng đằng sau tạo template là trở thành "sysadmin lười." Template chứa các thành phần cơ bản bạn muốn trong tất cả script của mình. Nó tiết kiệm thời gian so với thêm những thành phần đó vào mọi script mới và làm cho việc bắt đầu script mới dễ dàng.
Mặc dù có thể cám dỗ chỉ ném một vài câu lệnh Bash dòng lệnh vào file và làm nó thực thi, điều đó có thể phản tác dụng trong dài hạn. Một chương trình Bash viết tốt và comment tốt với cơ sở Help và khả năng chấp nhận tùy chọn dòng lệnh cung cấp điểm khởi đầu tốt cho sysadmin duy trì chương trình, bao gồm các chương trình bạn viết và duy trì.
Yêu cầu (The requirements)
Bạn nên luôn tạo một tập yêu cầu cho mọi dự án bạn làm. Điều này bao gồm script, ngay cả khi đó chỉ là danh sách đơn giản với hai hoặc ba mục. Tác giả đã tham gia nhiều dự án hoặc thất bại hoàn toàn hoặc không đáp ứng nhu cầu khách hàng, thường do thiếu tuyên bố yêu cầu hoặc tuyên bố viết kém.
Yêu cầu cho template Bash này khá đơn giản:
- Tạo template có thể dùng như điểm khởi đầu cho các dự án lập trình Bash tương lai.
- Template nên tuân theo thực hành lập trình Bash tiêu chuẩn.
- Nó phải bao gồm:
- Phần heading dùng để mô tả chức năng chương trình và changelog
- Tuyên bố cấp phép
- Phần cho hàm
- Hàm Help
- Hàm test xem người dùng chương trình có phải root
- Phương pháp đánh giá tùy chọn dòng lệnh
Cấu trúc cơ bản (The basic structure)
Một script Bash cơ bản có ba phần. Bash không có cách để phân định các phần, nhưng ranh giới giữa các phần là ngầm hiểu.
- Tất cả script phải bắt đầu với shebang (#!), và đây phải là dòng đầu tiên trong bất kỳ chương trình Bash nào.
- Phần hàm phải bắt đầu sau shebang và trước thân chương trình. Là một phần của nhu cầu tài liệu hóa mọi thứ, tác giả đặt comment trước mỗi hàm với mô tả ngắn về ý định của nó. Tác giả cũng bao gồm comment bên trong hàm để giải thích thêm. Chương trình ngắn, đơn giản có thể không cần hàm.
- Phần chính của chương trình đến sau phần hàm. Điều này có thể là một câu lệnh Bash đơn lẻ hoặc hàng nghìn dòng code. Một chương trình của tác giả có hơn 200 dòng code, không tính comment. Chương trình đó có hơn 600 dòng comment.
Đó là tất cả—chỉ có ba phần trong cấu trúc của bất kỳ chương trình Bash nào.
Comment đầu (Leading comments)
Tác giả luôn thêm nhiều hơn điều này vì nhiều lý do. Trước hết, tác giả thêm một vài phần comment ngay sau shebang. Các phần comment này là tùy chọn, nhưng tác giả thấy chúng rất hữu ích.
Phần comment đầu tiên là tên chương trình và mô tả và lịch sử thay đổi. Tác giả học định dạng này khi làm việc tại IBM, và nó cung cấp phương pháp tài liệu hóa phát triển lâu dài của chương trình và các sửa lỗi áp dụng cho nó. Đây là khởi đầu quan trọng trong tài liệu hóa chương trình của bạn.
Phần comment thứ hai là tuyên bố bản quyền và cấp phép. Tác giả dùng GPLv2, và đây dường như là tuyên bố tiêu chuẩn cho chương trình cấp phép dưới GPLv2. Nếu bạn dùng giấy phép open source khác, đó là tốt, nhưng tác giả gợi ý thêm tuyên bố rõ ràng vào code để loại bỏ bất kỳ sự nhầm lẫn nào về cấp phép. Bài viết The source code is the license của Scott Peterson giúp giải thích lý do đằng sau điều này.
Vậy bây giờ script trông như thế này:
#!/bin/bash
################################################################################
# scriptTemplate #
# #
# Use this template as the beginning of a new program. Place a short #
# description of the script here. #
# #
# Change History #
# 11/11/2019 David Both Original code. This is a template for creating #
# new Bash shell scripts. #
# Add new history entries as needed. #
# #
# #
################################################################################
################################################################################
################################################################################
# #
# Copyright (C) 2007, 2019 David Both #
# LinuxGeek46@both.org #
# #
# This program is free software; you can redistribute it and/or modify #
# it under the terms of the GNU General Public License as published by #
# the Free Software Foundation; either version 2 of the License, or #
# (at your option) any later version. #
# #
# This program is distributed in the hope that it will be useful, #
# but WITHOUT ANY WARRANTY; without even the implied warranty of #
# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the #
# GNU General Public License for more details. #
# #
# You should have received a copy of the GNU General Public License #
# along with this program; if not, write to the Free Software #
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA #
# #
################################################################################
################################################################################
################################################################################
echo "hello world!"
Chạy chương trình sửa đổi để xác minh nó vẫn hoạt động như mong đợi.
Về testing (About testing)
Bây giờ là lúc tốt để nói về testing.
"Luôn luôn còn một bug nữa."
— Luật Cybernetic Entomology của Lubarsky
Lubarsky—ai đó cũng vậy—đúng. Bạn không bao giờ tìm thấy tất cả bug trong code của mình. Với mỗi bug tác giả tìm thấy, dường như luôn có bug khác nảy sinh, thường vào thời điểm rất không thích hợp.
Testing không chỉ về chương trình. Nó cũng về xác minh rằng vấn đề—dù do phần cứng, phần mềm, hoặc những cách dường như vô tận user tìm ra để phá vỡ mọi thứ—được cho là đã giải quyết thực sự đã được giải quyết. Cũng quan trọng như vậy, testing cũng về đảm bảo code dễ dùng và interface có ý nghĩa với user.
Tuân theo quy trình xác định rõ khi viết và test shell script có thể góp phần vào kết quả nhất quán và chất lượng cao. Quy trình của tác giả đơn giản:
- Tạo kế hoạch test đơn giản.
- Bắt đầu test ngay từ đầu phát triển.
- Thực hiện test cuối khi code hoàn tất.
- Chuyển sang production và test thêm.
Kế hoạch test (The test plan)
Có rất nhiều định dạng khác nhau cho kế hoạch test. Tác giả đã làm việc với toàn bộ phạm vi—giữ tất cả trong đầu; đến một vài ghi chú vội trên giấy; và tất cả đường đến bộ form phức tạp yêu cầu mô tả đầy đủ mỗi test, code chức năng nào nó sẽ test, test sẽ hoàn thành gì, và input và kết quả nên là gì.
Nói như một sysadmin đã từng (nhưng không còn) là tester, tác giả cố gắng lấy middle ground. Có ít nhất một kế hoạch test viết ngắn gọn sẽ đảm bảo nhất quán từ lần chạy test này sang lần khác. Bao nhiêu chi tiết bạn cần phụ thuộc vào mức độ chính thức của chức năng phát triển và test của bạn.
Tài liệu mẫu kế hoạch test tác giả tìm thấy dùng Google phức tạp và dành cho tổ chức lớn với quy trình phát triển và test rất chính thức. Mặc dù những kế hoạch test đó tốt cho người có "test" trong chức danh, chúng không áp dụng tốt cho điều kiện làm việc hỗn loạn và phụ thuộc thời gian của sysadmin. Giống như hầu hết khía cạnh khác của công việc, sysadmin cần sáng tạo. Vậy đây là danh sách ngắn những điều cân nhắc đưa vào kế hoạch test. Sửa đổi cho phù hợp nhu cầu:
- Tên và mô tả ngắn phần mềm được test
- Mô tả tính năng phần mềm được test
- Điều kiện khởi đầu cho mỗi test
- Hàm thực hiện cho mỗi test
- Mô tả kết quả mong muốn cho mỗi test
- Test cụ thể thiết kế để test kết quả tiêu cực
- Test cách chương trình xử lý đầu vào bất ngờ
- Mô tả rõ ràng điều gì cấu thành pass hoặc fail cho mỗi test
- Fuzzy testing, được mô tả dưới đây
Danh sách này nên cho bạn một số ý tưởng tạo kế hoạch test. Hầu hết sysadmin nên giữ nó đơn giản và khá không chính thức.
Test sớm—test thường xuyên (Test early—test often)
Tác giả luôn bắt đầu test shell script ngay khi hoàn thành phần đầu tiên có thể thực thi. Điều này đúng dù viết chương trình dòng lệnh ngắn hoặc script file thực thi.
Tác giả thường bắt đầu tạo chương trình mới với template shell script. Tác giả viết code cho hàm Help và test nó. Đây thường là phần tầm thường của quy trình, nhưng nó giúp tác giả bắt đầu và đảm bảo những thứ trong template hoạt động đúng từ đầu. Tại thời điểm này, dễ dàng sửa vấn đề với phần template của script hoặc sửa đổi nó để đáp ứng nhu cầu template tiêu chuẩn không đáp ứng.
Một khi template và hàm Help hoạt động, tác giả chuyển sang tạo thân chương trình bằng cách thêm comment để tài liệu hóa các bước lập trình cần thiết để đáp ứng spec chương trình. Giờ tác giả bắt đầu thêm code để đáp ứng yêu cầu nêu trong mỗi comment. Code này có thể yêu cầu thêm biến được khởi tạo trong phần đó của template—đang trở thành shell script.
Đây là nơi testing nhiều hơn chỉ nhập dữ liệu và xác minh kết quả. Nó mất một chút công sức thêm. Đôi khi tác giả thêm lệnh đơn giản in kết quả trung gian của code vừa viết và xác minh nó. Đối với script phức tạp hơn, tác giả thêm tùy chọn -t cho "test mode." Trong trường hợp này, code test nội bộ chỉ thực thi khi tùy chọn -t được nhập trên dòng lệnh.
Test cuối (Final testing)
Sau khi code hoàn tất, tác giả quay lại làm test hoàn chỉnh tất cả tính năng và hàm dùng input đã biết để tạo output cụ thể. Tác giả cũng test một số input ngẫu nhiên để xem chương trình có xử lý được đầu vào bất ngờ không.
Test cuối nhằm xác minh chương trình hoạt động về cơ bản như dự định. Phần lớn test cuối là đảm bảo các hàm hoạt động trước trong chu kỳ phát triển không bị phá vỡ bởi code được thêm hoặc thay đổi sau trong chu kỳ.
Nếu bạn đã test script khi thêm code mới, bạn có thể nghĩ không nên có bất kỳ bất ngờ nào trong test cuối. Sai! Luôn có bất ngờ trong test cuối. Luôn luôn. Mong đợi những bất ngờ đó, và sẵn sàng dành thời gian sửa chúng. Nếu không bao giờ có bug được khám phá trong test cuối, sẽ không có ý nghĩa làm test cuối, phải không?
Test trong production (Testing in production)
Huh—cái gì?
"Chỉ khi chương trình đã trong production ít nhất sáu tháng thì lỗi hại nhất mới được khám phá."
— Giả thiết lập trình của Troutman
Vâng, test trong production giờ được coi là bình thường và mong muốn. Đã từng là tester, điều này dường như hợp lý. "Nhưng đừng! Đó nguy hiểm," bạn nói. Kinh nghiệm của tác giả là nó không nguy hiểm hơn test rộng rãi và nghiêm ngặt trong môi trường test chuyên biệt. Trong một số trường hợp, không có lựa chọn vì không có môi trường test—chỉ production.
Sysadmin không lạ việc test script mới hoặc sửa đổi trong production. Bất cứ khi nào script chuyển vào production, đó trở thành test tối thượng. Môi trường production cấu thành phần quan trọng nhất của test đó. Không gì tester có thể mơ tưởng trong môi trường test có thể sao chép hoàn toàn môi trường production thực sự.
Thực hành được cho là mới của test trong production chỉ là sự nhận ra những gì sysadmin đã biết từ trước. Test tốt nhất là production—miễn là nó không phải test duy nhất.
Fuzzy testing
Đây là một trong những từ khóa buzzword ban đầu khiến tác giả lật mắt. Ý nghĩa cốt lõi của nó đơn giản: để ai đó gõ phím bừa cho đến khi có chuyện xảy ra, và xem chương trình xử lý nó thế nào. Nhưng thực sự có nhiều hơn thế.
Fuzzy testing hơi giống lần con trai tác giả phá mã game trong chưa đầy một phút với input ngẫu nhiên. Điều đó chấm dứt nỗ lực viết game cho con của tác giả.
Hầu hết kế hoạch test dùng input rất cụ thể tạo ra kết quả hoặc output cụ thể. Bất kể test định nghĩa kết quả dương hoặc âm như thành công, nó vẫn được kiểm soát, và input và kết quả được chỉ định và mong đợi, như thông báo lỗi cụ thể cho chế độ thất bại cụ thể.
Fuzzy testing là về xử lý ngẫu nhiên trong mọi khía cạnh của test, như điều kiện khởi đầu, input rất ngẫu nhiên và bất ngờ, tổ hợp ngẫu nhiên tùy chọn chọn, bộ nhớ thấp, mức CPU cao cạnh tranh với chương trình khác, nhiều instance của chương trình dưới test, và bất kỳ điều kiện ngẫu nhiên nào bạn có thể nghĩ ra áp dụng cho test.
Tác giả cố gắng làm một chút fuzzy testing từ đầu. Nếu script Bash không thể xử lý ngẫu nhiên đáng kể ở giai đoạn rất sớm, thì nó khônglikely sẽ tốt hơn khi bạn thêm code. Đây là lúc tốt để bắt vấn đề và sửa chúng khi code còn đơn giản. Một chút fuzzy testing ở mỗi giai đoạn cũng hữu ích định vị vấn đề trước khi chúng bị che lấp bởi thêm code.
Sau khi code hoàn tất, tác giả thích làm fuzzy testing rộng rãi hơn. Luôn làm một chút fuzzy testing. Tác giả chắc chắn đã bị bất ngờ bởi một số kết quả. Dễ dàng test cho điều mong đợi, nhưng user không thường làm điều mong đợi với script.
Tiên triến (Previews of coming attractions)
Bài viết này hoàn thành một chút về tạo template, nhưng chủ yếu nói về testing. Điều này vì testing là phần quan trọng của tạo bất kỳ loại chương trình nào. Trong bài viết tiếp theo trong chuỗi này, bạn sẽ thêm hàm Help cơ bản cùng với code phát hiện và hành động trên tùy chọn, như -h, vào template Bash script của bạn.
Tài nguyên (Resources)
- Cách lập trình với Bash: Cú pháp và công cụ
- Cách lập trình với Bash: Toán tử logic và mở rộng shell
- Cách lập trình với Bash: Vòng lặp
Chuỗi bài viết này một phần dựa trên Volume 2, Chapter 10 của khóa tự học Linux ba phần của David Both, Using and Administering Linux—Zero to SysAdmin.