Sai lầm thứ nhất: viết một bản đặc tả kỹ thuật thay vì một câu
Những người từng bị phần mềm kém làm cho khổ sở thường mở bộ dựng trang lên và gõ cả một đoạn văn. Hệ thống chấm điểm, đơn vị đo lường ưa thích, chế độ ngoại tuyến, bảng màu, tất cả đều được nêu ra trước cả khi phản hồi đầu tiên quay lại. Điều đó cảm giác như có trách nhiệm. Nhưng không phải vậy. Bộ dựng trang đọc câu duy nhất của bạn, suy luận ra điều bạn có khả năng muốn, và quay lại với một kế hoạch trong khoảng mười lăm giây — "một nhật ký tập luyện cho người leo núi" biến thành nhật ký buổi tập, một giao diện theo dõi cấp độ khó, và một bảng điều khiển tổng quan, với thang V cho leo núi tự do (bouldering) và các tuyến YDS được chọn làm mặc định vì đó là những gì hầu hết người leo núi thực sự sử dụng. Nó cho bạn biết nó đã chọn gì, ngay trong bản kế hoạch, để bạn có thể sửa lại chỉ với một dòng nếu bạn là trường hợp ngoại lệ. Việc viết cả đoạn văn trước không bỏ qua được bước đó. Bạn vẫn nhận được một kế hoạch, vẫn phải đọc nó, và giờ bạn đã mất ba phút gõ các ràng buộc mà bản kế hoạch đằng nào cũng sẽ nêu ra cho bạn, theo đúng thứ tự thực sự quan trọng cho bản build của bạn.
Bản kế hoạch không phải là một biểu mẫu để bạn điền vào chỗ trống. Đó là văn xuôi, và bạn cũng phản hồi bằng văn xuôi. "Thực ra hãy đổi sang thang điểm Font, tôi đang ở châu Âu" là một chỉnh sửa hoàn chỉnh. "Thêm trường bạn leo/nhật ký belay, tôi leo cùng nhiều người khác nhau" cũng vậy. Mỗi chỉnh sửa sẽ tái tạo lại kế hoạch, chứ không phải bản build — bạn đang định hướng trước khi phần tốn kém bắt đầu, chứ không phải khởi động lại nó. Phê duyệt kế hoạch đó là quyết định cuối cùng bạn bắt buộc phải đưa ra. Mọi thứ sau đó là quá trình tạo dựng và kiểm tra.
Sai lầm thứ hai: nhìn chằm chằm vào luồng hoạt động như thể một terminal bị treo
Quá trình build chạy phía máy chủ, và cảm giác "đổ vỡ" ở đây gần như luôn là báo động giả: ai đó nhìn chằm chằm vào luồng hoạt động im lặng trong hai phút và cho rằng nó bị treo. Không phải vậy — nó đang ở một giai đoạn không tạo ra đầu ra hiển thị mỗi giây, và luồng hoạt động ghi rõ bạn đang ở giai đoạn nào chính vì lý do này. Bạn có thể đóng hẳn tab. Tiến trình không nằm trong trình duyệt của bạn.
Những gì bạn thực sự nên kỳ vọng phụ thuộc rất nhiều vào hình dạng của dự án. Nhật ký leo núi — vài trang, mô hình dữ liệu cục bộ, không gọi đến API bên ngoài — hoàn thành trong chưa đầy ba phút, đây là điều điển hình cho bất cứ thứ gì về cơ bản chỉ là "ghi lại cái này, biểu đồ hóa cái kia, hiển thị cho tôi một danh sách". Ngay khi một bản build cần một backend thực sự, xác thực, cơ sở dữ liệu có quan hệ, tác vụ nền, bạn sẽ mất từ tám đến mười hai phút, vì lúc này có thêm việc tạo và di chuyển schema, và bước kiểm tra chạy lần thứ hai đối với mã máy chủ chứ không chỉ markup. Các trò chơi thậm chí còn chậm hơn, vì chúng cần tạo tài nguyên: sprite, hiệu ứng âm thanh, đôi khi là một lượt xử lý hình ảnh thứ hai nếu lần thử đầu tiên không hiển thị đúng ở kích thước dự kiến. Và việc đóng gói native, một APK thực sự có thể cài đặt, chứ không phải web view bọc trong một lớp vỏ, sẽ được chuyển giao cho một bộ công cụ thực thụ. Gradle, ký số, tất cả. Riêng bước đó có thể cộng thêm năm đến mười phút vào tổng thời gian, và đây là giai đoạn duy nhất mà luồng hoạt động im lặng có nghĩa là bộ công cụ đang làm những việc của bộ công cụ, chứ không phải có gì đó bị hỏng.
Cái giá thực sự của mô hình này là bạn mất đi phản hồi tức thời, từng ký tự khi xem mã được viết trực tiếp vào trình soạn thảo. Thay vào đó là một hệ thống có thể tồn tại qua việc laptop của bạn ngủ và wifi bị rớt, mà bạn có thể kiểm tra từ điện thoại, và tiếp tục chạy dù bạn có đang theo dõi hay không. Với một bản build chín mươi giây, sự đánh đổi đó gần như không đáng kể. Với bản build backend mười hai phút, đó là sự khác biệt giữa việc canh chừng một terminal và việc đi lấy một tách cà phê.
Sai lầm thứ ba: nhầm lẫn giữa "đã được tạo ra" với "đã hoàn thành"
Đây là phần tốn kém nhất. Một bản dựng hoàn thành nhanh mà chưa được kiểm tra không phải là một bản dựng hoàn chỉnh, mà là một bản nháp tình cờ chạy được — và khoảng cách giữa hai điều đó chính là nơi hầu hết các công cụ dựng site nhanh mang tiếng xấu, khi tung ra các biểu mẫu không có sanitization và các nút mà không thể truy cập bằng bàn phím. Trước khi nền tảng này gọi bất cứ điều gì là xong, các agent kiểm định riêng biệt sẽ xem xét lại nó: code, bảo mật, liên kết, SEO, khả năng tiếp cận (accessibility), và mức độ tuân thủ so với kế hoạch bạn đã duyệt. Đó là một lượt kiểm tra thực sự riêng biệt, không phải cùng một agent đọc lại kết quả của chính nó rồi gật đầu.
Kiểm tra bảo mật săn tìm những lỗi tưởng chừng đơn giản nhưng thực sự gây hại trong môi trường production: một API key bị commit vào code phía client, một biểu mẫu chấp nhận input mà không có sanitization, một endpoint tin tưởng vào user ID do client cung cấp thay vì lấy từ session. Kiểm tra khả năng tiếp cận không phải là một linter mà bạn có thể tắt bằng một comment — nó kiểm tra tỷ lệ tương phản thực tế và liệu các phần tử tương tác có thể truy cập được bằng bàn phím hay không.
Kiểm tra tuân thủ (conformance) là điều mà mọi người thường đánh giá thấp nhất. Rất dễ để một lượt tạo sinh âm thầm bỏ sót điều bạn yêu cầu — chẳng hạn như trường nhật ký partner/belay-log từ bản chỉnh sửa kế hoạch của bạn — ba tệp sau khi bắt đầu dựng, bị hạ ưu tiên mà không ai chủ động quyết định bỏ nó. Kiểm tra tuân thủ đọc lại kế hoạch đã được duyệt của bạn và đối chiếu với kết quả thực tế để phát hiện khoảng trống đó. Khi tìm thấy một lỗi, bản sửa sẽ được áp dụng và kiểm tra lại tự động; bạn không nhận được một danh sách việc cần làm, mà nhận được hoặc là một bản sửa bạn không bao giờ thấy, hoặc là không có gì sai ngay từ đầu. Cơ chế chi tiết của từng bước kiểm định, và điều gì xảy ra khi một mục thất bại hai lần liên tiếp, được trình bày trong Cách các bản dựng tự kiểm chứng. Điều đáng nhớ nhất trong phần này: xong nghĩa là đã vượt qua kiểm tra, không phải đã được tạo ra. Nếu bạn coi hai điều đó là một, cuối cùng bạn sẽ phát hành một key bị lộ hoặc một nút không thể truy cập.
Những gì bạn nhận được nếu tránh được cả ba sai lầm
- Một sản phẩm hoạt động trong bản xem trước thực sự mà bạn có thể nhấp qua — một phiên bản đang chạy thật sự với dữ liệu của bạn được kết nối sẵn, không phải ảnh chụp màn hình mô phỏng giao diện sẽ trông như thế nào.
- Một luồng chat gắn liền với nó, nơi câu "làm header tối hơn và thêm trang thống kê" sẽ tạo ra phiên bản hai cạnh phiên bản một. Phiên bản cũ không biến mất; nó vẫn còn đó như một phương án dự phòng trong khi phiên bản mới thay thế bản xem trước trực tiếp.
- Các nút thực sự làm được việc: phát hành trực tiếp, tải mã nguồn, dựng trình cài đặt gốc, đưa lên cửa hàng. Không phải các cửa sổ mời chào nâng cấp được ngụy trang thành nút bấm.
Nút tải mã nguồn đáng để xem xét kỹ hơn, vì đó chính là điều phân biệt một công cụ bạn có thể tin tưởng cho việc thực sự nghiêm túc với một công cụ chỉ dùng cho các bản mẫu dùng một lần rồi bỏ. Nếu mã nguồn thực sự là của bạn để mang đi, cấu trúc tệp dễ đọc, không có sự khóa buộc kỳ lạ nào ngoài những gì bạn thực sự yêu cầu, thì nền tảng đó buộc phải tiếp tục xứng đáng với phiên làm việc tiếp theo của bạn thay vì ỷ lại vào việc bạn đã bị mắc kẹt sẵn bên trong nó.
