ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Sử dụng khi viết hoặc thay đổi mã, trước khi gọi là hoàn thành nhiệm vụ, bất cứ khi nào thay đổi thêm một tên được xuất hoặc có thể nhập, tạo một module, lớp, thành phần, helper, hook, dịch vụ hoặc wrapper, hoặc tập trung mã lặp lại. Danh sách kiểm tra thời gian tác giả để xây dựng các module sâu: đặt tên cho quyết định mà ranh giới che giấu, vượt qua các bài kiểm tra độ sâu và bất biến, sửa lỗi thay vì di chuyển chúng, không bao giờ chia nhỏ chỉ dựa trên kích thước, và kết thúc với một ghi chú thiết kế ngắn. Bạn đồng hành gọn nhẹ với ousterhout-quality-program, vốn là thấu kính đánh giá toàn diện.
---

# Build it deep (Ousterhout, author-time)

Bạn đang viết code, không phải review nó. Hãy chạy thử trên thay đổi của bạn trước khi gọi task là xong.

## 1. Gate

Thay đổi có thêm tên xuất khẩu/nhập khẩu, tạo module, class, component, helper, hook, service hoặc wrapper, hoặc tập trung mã lặp lại không? Nếu không, bỏ qua kỹ năng này. Đổi tên, codemods, chỉnh sửa config/dữ liệu và sửa lỗi một dòng được miễn.

## 2. Trước khi bạn viết boundary

- Tìm cách repo này đã giải quyết vấn đề dạng này như thế nào và theo đó trừ khi bạn có thể nói tại sao không. Đọc tài liệu và kiểu hiện tại của dependency: API nhớ trong đầu chỉ là một khẳng định, không phải nguồn.
- Viết comment giao diện trước: nó hứa gì, nó ẩn gì. Nếu bạn không thể đặt tên quyết định ẩn (một định dạng, chính sách, quy tắc, lựa chọn schema), boundary không nên tồn tại. Viết inline.
- Đặt tên theo ngôn ngữ miền. Nếu tên trung thực duy nhất là `utils`, `helpers` hoặc `manager`, thì chỗ cắt không đúng.

## 3. Hai bài test

- **Độ sâu.** Giao diện phải ẩn nhiều hơn là phơi bày. Một wrapper chỉ chuyển tiếp đối số là chi phí không lợi ích; xóa nó.
- **Bất biến.** Trích xuất mã dùng chung chỉ khi nó bảo vệ một quy tắc dùng chung. Bằng chứng là thay đổi cùng lúc: các bản sao được sửa hoặc thay đổi cùng nhau trong lịch sử. Các bản sao giống nhau thay đổi độc lập thì vẫn giữ nguyên.

## 4. Một sửa lỗi phải loại bỏ vấn đề, không di chuyển nó

- Sáu phép ép kiểu gom vào một helper ép kiểu generic vẫn là sáu phép ép kiểu. Viết mapper có kiểu mà các phép ép kiểu đang che đậy.
- Không thêm tham số hoặc cờ đẩy quyết định cho caller trừ khi caller thực sự biết điều bạn không biết. Hấp thụ trường hợp khó bên trong.
- Ưu tiên ngữ nghĩa mà trường hợp lỗi không thể xảy ra hơn là bắt mọi caller xử lý nó.
- Di chuyển độ phức tạp miền thiết yếu sang file khác không phải là đơn giản hóa.

## 5. Dưới áp lực "dọn dẹp" hoặc "file này quá lớn"

Không bao giờ tách chỉ dựa trên kích thước. Một module 400 dòng ẩn một quyết định tốt hơn bốn module 100 dòng rò rỉ cùng các điểm nối. Hỏi quyết định nào mỗi phần tách ẩn; nếu không có, đừng tách.

## 6. An toàn

Code hiện có: khóa hành vi hiện tại bằng test trước khi làm sâu hơn. Code mới: viết test định nghĩa hành vi dự kiến.

## 7. Báo cáo

Nếu gate kích hoạt, kết thúc tin nhắn cuối cùng của bạn bằng một ghi chú thiết kế 2-4 dòng: mỗi boundary bạn thêm và quyết định nó ẩn; sự trùng lặp bạn để lại có chủ ý và lý do; bất cứ điều gì nông bạn chấp nhận và lý do.

Đối với cuộc gọi tranh cãi hoặc review toàn diện, tải `ousterhout-quality-program`.

Tag