Mastering Programming

Dịch từ bài viết “Mastering Programming” của tác giả Kent Beck.

Qua nhiều năm quan sát những lập trình viên bậc thầy, tôi đã nhận thấy những mô thức chung trong quy trình làm việc của họ. Qua nhiều năm huấn luyện những lập trình viên ở mức thạo nghề, tôi đã nhận thấy sự thiếu vắng những mô thức đó. Tôi đã thấy sự khác biệt (mà) khởi đầu cho những mô thức đó, có thể tạo ra.

Đây là những cách thức mà những lập trình thu được hiệu quả tốt nhất có thể từ hơn 3 tỉ giây quý báu của họ ở trên trái đất này (ý nói là thời gian trong 1 năm – lời người dịch).
Bài luận này sẽ làm bạn sáng tỏ hơn về những điều đó. Một “công nhân thạo nghề” học cách giải quyết những vấn đề lớn hơn bằng cách cùng một lúc giải quyết nhiều vấn đề hơn. Một bậc thầy học cách giải quyết những vấn đề còn lớn hơn thế bằng cách giải quyết ít vấn đề hơn cùng một lúc. Các phần của lời khuyên này sẽ được chia nhỏ sao cho việc tích hợp những giải pháp riêng biệt sẽ là một vấn đề nhỏ hơn việc chỉ giải quyết chúng đồng thời.

Thời gian

  • Phân chia. Lấy một dự án lớn, cắt nó thành các phần nhỏ, và sắp xếp lại các phần sao cho phù hợp với hoàn cảnh. Tôi luôn có thể phân chia các dự án nhỏ hơn và luôn tìm thấy những cách thay đổi trật tự của các phần mà phù hợp với các nhu cầu khác nhau.
  • Một việc tại một thời điểm. Chúng ta tập trung vào tính hiệu quả đến mức chúng ta giảm số lượng số vòng phản hồi (feedback cycles) trong một nỗ lực để giảm tổng chi phí. Điều này dẫn đến những tình trạng gỡ lỗi phức tạp mà chi phí của nó có thể còn lớn hơn tổng phí về số vòng phản hồi mà chúng ta đã tránh.
  • Viết chương trình chạy được, chạy đúng, và chạy nhanh (Make it run, make it right, make it fast). (Ví dụ của một việc tại một thời điểm, phân chia công việc, và dễ dàng sửa đổi).
  • Những sửa đổi dễ dàng. Khi bạn phải đối mặt với một sự thay đổi phức tạp, đầu tiên hãy làm cho nó dễ đi (tôi cảnh báo rằng điều này có khó), sau đó thực hiện việc sửa đổi dễ (ví dụ: phân chia công việc, làm một việc tại một thời điểm, tập trung, và sự cô lập. Đây là một ví dụ của việc phân chia công việc.
  • Sự tập trung. Nếu bạn cần thay đổi một vài thành phần, đầu tiên hãy sắp xếp lại mã chương trình sao cho sự thay đổi chỉ cần xảy ra trong một thành phần.
  • Sự cô lập. Nếu bạn chỉ cần thay đổi một phần của một thành tố, hãy trích xuất thành tố đó ra để thay đổi trên toàn bộ thành tố con đó.
  • Quản lý các hệ thống cơ sở. Bắt đầu các dự án bằng việc so sánh với những hệ thống đã có. Điều này có thể chống lại thiên hướng muốn bắt đầu sửa chữa mọi thứ của chúng ta, nhưng khi bạn xem xét các hệ thống cơ sở, bạn sẽ thực sự biết liệu có đúng là bạn đang làm công việc sửa chữa những thứ hiện có không.

Học tập

  • Trước khi thực thi chương trình, dự đoán chính xác điều gì sẽ xảy ra.
  • Các giả thuyết cụ thể. Khi chương trình hoạt động không đúng, hãy minh định những gì bạn cho là sai trong chương trình trước khi thực hiện sự thay đổi. Nếu bạn có hai hay nhiều hơn các giả thuyết, hãy phân tích sự khác biệt giữa các giả thuyết đó.
  • Loại bỏ chi tiết không liên quan. Khi báo cáo một lỗi, hãy tìm những bước ngắn nhất để sinh lại lỗi đó. Khi cô lập một lỗi, hãy tìm những ví dụ (test case) ngắn nhất. Khi sử dụng một API mới, bắt đầu từ những ví dụ đơn giản nhất. “Tất cả những thứ này không thành vấn đề” là một giả thuyết quá mạnh và có khi là sai lầm.
    • Ví dụ, hãy xem một lỗi trên mobile, sinh lại nó với chương trình curl.
  • Đa quy mô. Di chuyển tự do giữa các quy mô (ví dụ khi thực thi trên dữ liệu nhỏ sang thực thi trên dữ liệu lớn — cách hiểu của người dịch). Có thể đây là một vấn đề thiết kế, không phải là vấn đề kiểm thử. Có thể vấn đề này liên quan đến con người chứ không phải là một vấn đề công nghệ [Lừa đảo, điều này luôn đúng].

Những thứ vượt trên cả logic

  • Tính đối xứng. Những thứ gần như nhau có thể phân chia chia thành những phần giống hệt nhau và những phần khác biệt rõ ràng.
  • Tính thẩm mỹ.
  • Nhịp điệu. Chờ đợi cho đến thời điểm đúng bảo toàn năng lượng và tránh sự lộn xộn.
  • Cân bằng (tradeoffs). Tất cả những quyết định là chủ đề của việc tradeoff. Quan trọng hơn là biết quyết định phụ thuộc vào cái gì hơn là biết câu trả lời bạn lựa chọn hôm nay (hoặc câu trả lời này bạn đã lựa chọn hôm qua).
  • Danh sách niềm vui (Fun list). Khi các ý tưởng không thứ tự đến, hãy ghi chép chúng và quay trở lại làm việc nhanh chóng. Xem lại danh sách khi bạn tạm dừng.
  • Chăm sóc các ý tưởng. Các ý tưởng giống như là những chú chim nhỏ dễ sợ hại. Nếu bạn doạ chúng đi, chúng sẽ dừng việc đến với bạn. Khi bạn có một ý tưởng, hãy chăm chút nó một chút. Kiểm chứng để loại bỏ chúng nhanh nhất có thể, nhưng từ dữ liệu chứ không phải là từ sự thiếu sự say mê.
  • Nguyên tắc 80/15/5. Sử dụng 80% thời gian của bạn cho những công việc nguy cơ thấp hoặc những công việc được trả lương vừa phải. Sử dụng 15% thời gian của bạn cho các việc nguy cơ cao/trả lương cao có liên quan. Sử dụng 5% thời gian của bạn cho những việc làm cho bạn thích thú, không quan tâm tới kết quả. Hãy dạy những người tiếp nối bạn làm 80% công việc của bạn. Vào thời gian ai đó sẵn sàng để đảm nhận công việc, một trong số 15% thí nghiệm của bạn (hoặc ít thường xuyên hơn, một trong số 5% thí nghiệm) sẽ cho kết quả và trở thành phần 80% của bạn. Lặp lại điều đó.

Kết luận

Dòng chảy trong trong bản phác thảo này dường như bắt đầu từ việc giảm nguy cơ bằng việc quản lý thời gian đến việc chấp nhận mạo hiểm một cách có ý thức bằng cách sử dụng toàn bộ não bộ và nhanh chóng quyết định độ ưu tiên của các ý tưởng.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: