Giải pháp gần như đơn giản đến mức ngại ngùng:Luôn làm việc với ít nhất hai cửa sổ terminal (hoặc các khung chia), mỗi cái dành riêng cho một ngữ cảnh cụ thể.
Đây là cách tôi thiết lập:
Terminal 1 (Bên trái):Đây là terminal “thực thi” của tôi.
Nó nằm ở thư mục gốc dự án.
Đây là nơi tôi chạy máy chủ phát triển, thực thi lệnh build, chạy kiểm thử và làm công việc thực tế.
Terminal 2 (Bên phải):Đây là terminal “khảo sát” của tôi.
Nó là bảng nháp của tôi.
Tôi điều hướng đến bất cứ đâu tôi cần—thư mục log, file cấu hình, các kho lưu trữ khác nhau.
Tôi chạy các lệnh một lần, kiểm tra tài nguyên hệ thống, tìm kiếm qua các file.
Terminal này trở nên lộn xộn, và điều đó không sao.
Điều kỳ diệu xảy ra ở sự tách biệt.Terminal 1 luôn sạch sẽ và dễ đoán.
Tôi luôn biết nó ở đâu, nó đang chạy gì, và điều gì xảy ra khi tôi nhấn phím mũi tên lên.
Terminal 2 hấp thụ tất cả sự hỗn loạn của việc khám phá và điều tra mà không làm nhiễm bẩn không gian làm việc chính của tôi.
Hãy đẩy xa hơn với tmux hoặc terminal của IDE bạn:
- Tạo các phiên có tên cho các dự án khác nhau
- Chia khung cho các tác vụ liên quan (máy chủ ở trên, trình theo dõi file ở dưới)
- Sử dụng một terminal để chạy lệnh, một terminal khác để giám sát đầu ra
- Giữ một terminal thứ ba mở riêng cho các thao tác git
Ứng dụng thực tế:Khi tôi làm việc trên một dự án microservices, tôi sẽ có các terminal riêng biệt cho mỗi dịch vụ tôi đang phát triển tích cực, cộng thêm một cho các lệnh Docker, và một cho công việc khảo sát của tôi.
Nghe có vẻ quá mức cần thiết cho đến khi bạn trải nghiệm trạng thái dòng chảy của việc không bao giờ phảicdloanh quanh hoặc mất lịch sử lệnh.
Điểm mấu chốt:Công cụ của bạn nên phù hợp với mô hình tư duy về công việc.Nếu bạn đang nghĩ về nhiều ngữ cảnh cùng lúc, không gian làm việc của bạn nên phản ánh điều đó.
Nội dung chính
2. Giới hạn thời gian nghiêm ngặt: Kỹ thuật Pomodoro cho Lập trình viên (Lần này thực sự hiệu quả)
Tôi biết, tôi biết.
Bạn đã nghe về Pomodoro trước đây.
Hai mươi lăm phút làm việc, năm phút nghỉ, lặp lại đến phát ngán.
Nghe có vẻ tuyệt về lý thuyết, nhưng trong thực tế?
Bạn đã mười một phút vào một phiên lập trình tập trung thì hẹn giờ kêu, và bạn phải…
dừng lại?
Giữa chừng một hàm?
Trong khi bạn cuối cùng cũng đang ở trong vùng tập trung?
Ừ, điều đó không xảy ra đâu.
Nhưng đây là vấn đề:kỹ thuật Pomodoro truyền thống không được thiết kế cho công việc sáng tạo đòi hỏi sự tập trung sâu.Nó được phát triển cho các tác vụ bán hàng và hành chính nơi sự gián đoạn ít tốn kém hơn.
Lập trình viên cần một cái gì đó khác.
Hãy đón nhận:
Pomodoro cho Lập trình viên, hay còn gọi là “Giới hạn thời gian nghiêm ngặt.”
Thay vì các khoảng thời gian cứng nhắc 25 phút, bạn đang giới hạn thời gian dựa trên ranh giới công việc tự nhiên và duy trì các quy tắc nghiêm ngặt về điều gì xảy ra khi đồng hồ đếm về 0.
Đây là cách nó thực sự hoạt động:
Bước 1:
Xác định một tác vụ cụ thể, có thể hoàn thành.Không phải “làm việc trên tính năng xác thực” mà là “triển khai middleware xác thực JWT.” Một thứ bạn có thể hoàn thành hoặc đạt đến một điểm dừng rõ ràng.
Bước 2:
Ước tính một cách trung thực.Việc này sẽ mất 30 phút?
45?
90?
Hãy thực tế.
Thêm 25% vào bất cứ con số nào bạn nghĩ trong đầu vì có lẽ bạn đang đánh giá thấp.
Bước 3:
Đặt hẹn giờ và bắt đầu.Nhưng đây là phần quan trọng:bạn không dừng lại khi hẹn giờ kêu.Thay vào đó, bạn đang đánh giá.
Khi hẹn giờ reo:
- Bạn đang trong trạng thái dòng chảy?
Thêm một khoảng thời gian giới hạn nữa và tiếp tục. - Bạn đang bị kẹt?
Đây là điểm nghỉ tự nhiên của bạn.
Hãy bước ra xa.
Đồng hồ đã bắt được bạn—hãy thừa nhận sự trôi dạt và tập trung lại hoặc nghỉ ngơi.
Bước 4:
Sau 2-3 lần hộp thời gian liên tiếp (90-120 phút), hãy nghỉ giải lao thực sự.Không phải kiểu nghỉ “kiểm tra Slack”.
Mà là kiểu đi dạo quanh tòa nhà, để ánh nắng chiếu lên mặt, thực sự ngắt kết nối.
Phần “có răng”:Theo dõi mọi hộp thời gian trong một tài liệu đơn giản.
Ghi lại những gì bạn đã làm và liệu bạn đã hoàn thành hay chưa.
Điều này tạo ra trách nhiệm giải trình và, quan trọng hơn, là dữ liệu.
Sau một tuần, bạn sẽ thấy các mẫu hình.
Bạn sẽ nhận thấy rằng bạn luôn đánh giá thấp công việc cơ sở dữ liệu khoảng 40%.
Bạn sẽ thấy rằng các hộp thời gian buổi chiều kém hiệu quả hơn.
Bạn sẽ có bằng chứng thực tế để cải thiện việc lập kế hoạch của mình.
Công cụ giúp việc này trở nên dễ dàng:
- Toggl Track để ghi nhật ký thời gian với phân loại dự án
- Be Focused Pro (Mac) cho bộ hẹn giờ đồng bộ hóa trên các thiết bị
- Một cơ sở dữ liệu Notion đơn giản với các cột:
công việc, thời gian ước tính, thời gian thực tế
Lợi ích thực sự:Đây không phải là về bộ hẹn giờ hay những giờ nghỉ.
Mà là về việc xây dựng nhận thức về cách bạn làm việc.
Một khi bạn biết các mẫu hình của mình—khi nào bạn tập trung nhất, bạn có thể duy trì công việc sâu trong bao lâu, những nhiệm vụ nào luôn vượt quá ước tính—bạn có thể thiết kế các ngày làm việc của mình cho phù hợp.
Tôi lên lịch cho những công việc khó khăn nhất, đòi hỏi nhận thức cao nhất (triển khai tính năng mới, gỡ lỗi phức tạp) vào hai hộp thời gian đầu tiên trong ngày.
Việc xem xét mã và tài liệu diễn ra vào buổi chiều khi đầu óc tôi kém minh mẫn hơn.
Đây không phải là năng suất dựa trên động lực;
đó là vật lý.
Bạn làm việc theo nhịp điệu tự nhiên của mình thay vì chống lại chúng.
3. Quy Tắc 15 Phút: Vũ Khí Bí Mật Chống Lại Sự Trì Hoãn Và Các Ngõ Cụt
Mọi nhà phát triển đều có hai kẻ thù không đội trời chung:
nhiệm vụ bạn không muốn bắt đầu và nhiệm vụ bạn dường như không thể dừng lại.
Tình huống đầu tiên:
Bạn cần tái cấu trúc mô-đun di sản mà mọi người đều sợ chạm vào.
Mô-đun có 800 dòng trong một tệp duy nhất, không có kiểm thử và các chú thích bằng ba ngôn ngữ khác nhau.
Chỉ nghĩ về nó đã thấy mệt mỏi.
Vì vậy, bạn…
kiểm tra email.
Sắp xếp lại Dock của bạn.
Đột nhiên vệ sinh sâu bàn phím của bạn.
Bất cứ điều gì để tránh lao vào vực thẳm đó.
Tình huống thứ hai:
Bạn đang tìm hiểu lý do tại sao trang chủ tải chậm.
Chỉ cần kiểm tra một vài số liệu, sẽ mất mười phút.
Ba giờ sau, bạn đã xây dựng lại toàn bộ cơ sở hạ tầng giám sát, đọc mười hai bài viết về hiệu suất kết xuất trình duyệt và tạo môi trường thử nghiệm để so sánh ba nhà cung cấp CDN khác nhau—và bạn vẫn chưa sửa được vấn đề ban đầu.
Quy Tắc 15 Phút giải quyết cả hai vấn đề với một cam kết đơn giản:
Đối với các nhiệm vụ bạn đang tránh:Hứa với bản thân rằng bạn sẽ chỉ làm việc với nó trong 15 phút.
Thế thôi.
Sau 15 phút, bạn có quyền dừng lại mà không cảm thấy tội lỗi.
Đối với các nhiệm vụ bạn đang đầu tư quá mức:Đặt hẹn giờ 15 phút trước khi đi sâu vào bất kỳ ngõ cụt nào.
Khi chuông reo, hãy tự hỏi:
“Điều này có thực sự giải quyết vấn đề của tôi không, hay tôi chỉ đang tận hưởng việc khám phá?”
Tại sao điều này hiệu quả về mặt tâm lý:
Bắt đầu là phần khó nhất.
Bộ não của chúng ta được lập trình để tránh sự khó chịu, và những nhiệm vụ lớn, không xác định kích hoạt phản ứng tránh né đó mạnh mẽ.
Nhưng 15 phút?
Điều đó không đáng sợ.
Ai cũng có thể làm bất cứ điều gì trong 15 phút.
Bạn không cam kết hoàn thành—bạn cam kết bắt đầu.
Phần đẹp đẽ:Hầu hết thời gian, bạn sẽ không dừng lại ở 15 phút.Một khi bạn đã bắt tay vào làm, đà tiến sẽ tiếp diễn.
Bạn sẽ thấy nhiệm vụ không tệ như bạn tưởng tượng.
Hoặc bạn sẽ rơi vào trạng thái tập trung và quên mất bộ hẹn giờ.
Quy tắc 15 phút là một đòn bẩy tâm lý cho động lực của bạn.
Đối với các ngõ cụt, đó là vấn đề ngược lại.
Các nhà phát triển vốn dĩ là những người giải quyết vấn đề tò mò.
Chúng ta thấy một hướng đi thú vị và bộ não của chúng ta sáng lên:
“Ồ, mình có thể tối ưu hóa cái này!
Để mình nhanh chóng…” Rồi bốn giờ sau, bạn chưa đóng góp gì cho mục tiêu sprint thực tế của mình.
Điểm kiểm tra 15 phút buộc bạn phải trung thực một cách tàn nhẫn:
- Việc tái cấu trúc hàm tiện ích này có quan trọng đối với nhiệm vụ hiện tại của bạn không?
- Bạn có cần hiểu toàn bộ lịch sử của các bộ đóng gói JavaScript để sửa cấu hình webpack này không?
- Việc thiết lập cấu hình linting hoàn hảo đó có thực sự quan trọng hơn việc phát hành tính năng không?
Đôi khi câu trả lời là có!
Đôi khi bạncầnđi sâu.
Nhưng thường thì, câu trả lời là không, và Quy tắc 15 phút cho phép bạn đưa ra lựa chọn thực tế thay vì lựa chọn của người cầu toàn.
Triển khai trong thực tế:Giữ một danh sách “các nhiệm vụ 15 phút”.
Đây là những việc bạn đang tránh—viết tài liệu cho mô-đun đó, sửa lỗi kiểm thử khó chịu đó, cập nhật các phụ thuộc, có cuộc trò chuyện xem xét mã mà bạn đang trì hoãn.
Khi bạn có một khoảng trống kỳ lạ trong ngày (cuộc họp bị hủy, đang chờ triển khai, hoàn thành việc gì đó sớm hơn dự kiến), hãy hoàn thành một nhiệm vụ 15 phút.
Trong một tháng, bạn sẽ hoàn thành 20-30 nhiệm vụ nhỏ này mà lẽ ra sẽ tồn đọng mãi mãi.
Cơ sở mã của bạn trở nên lành mạnh hơn.
Nợ kỹ thuật của bạn giảm xuống.
Cảm giác thành tựu của bạn tăng lên.
Đối với các ngõ cụt:Khi bạn bắt gặp mình đang tìm hiểu điều gì đó không liên quan, hãy đặt hẹn giờ và tự hỏi:
“Tôi cần biết tối thiểu những gì để tiến lên?” Trả lời câu hỏi cụ thể đó, ghi lại những gì bạn đã học được trong một chú thích hoặc trang wiki để tham khảo sau, sau đó quay lại.
Bạn đã nắm bắt được kiến thức mà không bị chìm đắm trong đó.
Quy Tắc 15 Phút không phải là về sự cứng nhắc—mà là về sự có chủ đích.
Nó biến “Tôi nên làm việc này” thành “Tôi đang làm việc này” và “Tôi chỉ đang khám phá” thành “Tôi đang đưa ra lựa chọn có ý thức về nơi thời gian của tôi đi đến.”
4. Phát Triển Hướng Tài Liệu: Viết Tài Liệu Trước Khi Viết Mã
Điều này nghe có vẻ ngược đời cho đến khi bạn thử nó.
Sau đó, nó cảm thấy như một siêu năng lực.
Đây là quy trình làm việc truyền thống của nhà phát triển:
Viết mã, làm cho nó hoạt động, hoàn thiện nó, sau đó (có thể, nếu ai đó nhắc bạn hoặc có danh sách kiểm tra PR) viết tài liệu giải thích những gì bạn vừa xây dựng.
Tài liệu là hậu quả của quá trình phát triển, là rau củ bạn ăn vì chúng tốt cho bạn, chứ không phải vì bạn muốn.
Hãy đảo ngược điều này lại.
Tài liệu trước.
Trước khi viết một dòng mã triển khai nào, hãy viết tài liệu về cách tính năng hoặc hàm hoặc API của bạn sẽ hoạt động.
Mô tả nó làm gì, tham số nào nó nhận, nó trả về gì, các trường hợp đặc biệt nào nó xử lý và cách ai đó sẽ sử dụng nó.
Đây là điều xảy ra khi bạn làm điều này:
Sự rõ ràng xuất hiện ngay lập tức.Viết lách buộc bạn phải suy nghĩ thông qua các chi tiết theo cách mà việc nhìn chằm chằm vào IDE của bạn không bao giờ làm được.
Bạn sẽ phát hiện các vấn đề thiết kế trước khi chúng trở nên đắt đỏ để sửa chữa.
“Chờ đã, nếu người dùng truyền null vào đây, điều gì sẽ xảy ra?” trở thành một câu hỏi bạn trả lời trong quá trình thiết kế, không phải là một lỗi mà ai đó tìm thấy trong môi trường sản xuất.
API của bạn trở nên tốt hơn.Khi bạn viết tài liệu từ góc nhìn của người dùng trước, bạn tự nhiên thiết kế các giao diện trực quan hơn.
Bạn sẽ nhận thấy tên gọi khó hiểu, tham số bị thiếu hoặc các mẫu sử dụng vụng về vì bạn buộc mình phải giải thích chúng.
Việc triển khai trở nên dễ dàng hơn.Bạn đã suy nghĩ thông suốt logic.
Tài liệu chính là đặc tả của bạn.
Giờ bạn chỉ cần chuyển từ tiếng Anh rõ ràng (hoặc ngôn ngữ bạn chọn) sang mã.
Không còn phải nhìn chằm chằm vào một tệp trống và tự hỏi nên bắt đầu từ đâu.
Tài liệu của bạn không bao giờ lỗi thời.Bởi vì chúng được viết trước, chúng khớp với những gì bạn đã xây dựng.
Bạn không cố gắng dịch ngược tài liệu từ mã đã hoàn thành nơi bạn đã quên mất một nửa quá trình ra quyết định của mình.
Ví dụ:
Giả sử bạn đang xây dựng một phần mềm trung gian giới hạn tốc độ.
Thay vì nhảy ngay vào viết mã, bạn bắt đầu bằng cách viết điều này:
## Phần mềm trung gian RateLimiter Ngăn chặn lạm dụng API bằng cách giới hạn yêu cầu trên mỗi người dùng. Cách dùng: const limiter = new RateLimiter({ requestsPerMinute: 60 }); app.use(limiter.middleware()); Cấu hình: - requestsPerMinute: Số yêu cầu tối đa cho phép mỗi phút (mặc định: 100) - keyGenerator: Hàm để xác định người dùng duy nhất (mặc định: sử dụng địa chỉ IP) - onLimitExceeded: Bộ xử lý tùy chỉnh cho các yêu cầu bị giới hạn tốc độ Hành vi: - Theo dõi yêu cầu sử dụng bộ nhớ lưu trữ trong bộ nhớ (có thể nâng cấp lên Redis) - Trả về trạng thái 429 khi vượt quá giới hạn - Bao gồm tiêu đề Retry-After với số giây cho đến khi giới hạn được đặt lại - Đặt lại bộ đếm mỗi phút Bây giờ khi bạn triển khai điều này, bạn biết chính xác mình đang xây dựng gì.
Bạn đã đưa ra các quyết định thiết kế về mặc định, tùy chọn cấu hình và hành vi.
Mã của bạn tự viết ra vì tài liệu của bạn là một đặc tả.
Đi xa hơn nữa:
Đối với các tính năng phức tạp, hãy viết ba loại tài liệu trước khi viết mã:
- Tài liệu hướng người dùng:Cách một người sẽ sử dụng tính năng này
- Tài liệu API:Chữ ký hàm, tham số, giá trị trả về
- Nhật ký quyết định:Tại sao bạn đưa ra các lựa chọn thiết kế nhất định (điều này là vàng cho bạn trong tương lai)
Các công cụ hỗ trợ quy trình làm việc này:
- Viết tài liệu bằng markdown ngay bên cạnh mã của bạn
- Sử dụng JSDoc, TypeDoc hoặc tương tự để tạo tài liệu từ các bình luận
- Giữ một tệp
decisions.mdtrong thư mục gốc dự án của bạn - Đối với API, sử dụng đặc tả OpenAPI/Swagger như công cụ ưu tiên tài liệu của bạn
Sự thay đổi tư duy:Bạn không phải là nhà phát triển viết tài liệu.
Bạn là nhà thiết kế thể hiện thiết kế thông qua cả tài liệu và mã.
Tài liệu không phải là khoản thuế bạn phải trả sau khi xây dựng thứ gì đó—nó là bản thiết kế giúp việc xây dựng trở nên khả thi.
Tôi đã viết toàn bộ các tính năng mà commit đầu tiên chỉ là tài liệu thuần túy.
Commit thứ hai là các bài kiểm tra dựa trên tài liệu đó.
Commit thứ ba là triển khai làm cho các bài kiểm tra vượt qua.
Đến lúc tôi mở một PR, mọi thứ đều rõ ràng, đã được kiểm tra và ghi chép.
Việc xem xét mã trở nên tập trung vào nội dung, chứ không phải cố gắng tìm hiểu xem tôi đang cố gắng làm gì.
📅 Đánh dấu lịch của bạn:
Bài viết về Khởi nghiệp mà Mọi Nhà phát triển Cần đang đến
TheBitForge ・ 12 tháng 12
Hãy thử điều này với tính năng tiếp theo của bạn.
Viết README trước.
Viết các docstring của hàm trước phần thân hàm.
Viết tài liệu API trước các điểm cuối.
Nó sẽ cảm thấy kỳ lạ trong khoảng 30 phút, sau đó nó sẽ cảm giác như bạn đã được ban cho tầm nhìn X-quang.
5. Quy tắc 2 phút cho việc Xem xét Mã: Xem xét Sớm, Xem xét Thường xuyên, Xem xét Nhỏ
Xem xét mã là nơi những ý định tốt bị chết yểu.
Bạn biết mô hình này:
Ai đó mở một PR với 47 tệp thay đổi và 2.300 dòng mã.
Bạn thấy thông báo.
Bạn nghĩ “Tôi sẽ xem xét nó sau khi tôi có thời gian.” “Sau” không bao giờ đến.
PR nằm đó trong ba ngày.
Tác giả nhắn tin cho bạn trên Slack.
Cuối cùng bạn dành ra một giờ, mở PR, cảm thấy ngay lập tức choáng ngợp, lướt qua nó, phê duyệt với một “LGTM” chung chung, và chu kỳ tiếp tục.
Trong khi đó, bạn đã góp phần vào chính vấn đề khiến bạn thất vọng khi *bạn
* đang chờ đợi các lượt xem xét trên PR của mình.
Quy tắc 2 phút biến đổi động thái này:
Nếu một lượt xem xét mã mất ít hơn 2 phút, hãy làm ngay lập tức.
Không phải “khi bạn hoàn thành nhiệm vụ hiện tại.” Không phải “sau cuộc họp này.” Không phải “vào thời gian xem xét mã được chỉ định của bạn.” Ngay lập tức.
Ngay bây giờ.
Dừng việc bạn đang làm và xem xét nó.
Điều này hiệu quả vì:
Các lượt xem xét nhỏ rất nhanh.Một PR 30 dòng với ngữ cảnh rõ ràng?
Bạn có thể xem xét nó trong 90 giây.
Đọc mã, xác minh nó có ý nghĩa, để lại bình luận hoặc phê duyệt, xong.
Bạn đã mở khóa cho ai đó với chi phí chuyển đổi ngữ cảnh gần như bằng không.
Nó rèn luyện nhóm của bạn gửi các PR nhỏ hơn.Khi mọi người biết rằng các PR nhỏ được xem xét ngay lập tức và các PR lớn nằm trong hàng đợi mãi mãi, hành vi thay đổi một cách tự nhiên.
Nhóm của bạn tự nhiên bắt đầu chia nhỏ công việc thành các phần nhỏ hơn, dễ xem xét hơn.
Nó giảm tải nhận thức của bạn.Thay vì có mười hai lượt xem xét đang chờ ám ảnh bạn như nợ kỹ thuật, bạn giải quyết ngay những cái nhỏ.
Hàng đợi của bạn vẫn dễ quản lý.
Cảm giác tội lỗi về việc là một nút thắt cổ chai biến mất.
Nó cải thiện chất lượng mã.Phản hồi nhanh có nghĩa là các nhà phát triển lặp lại trong khi ngữ cảnh còn mới.
Họ vẫn đang nghĩ về vấn đề.
Họ chưa chuyển sang ba nhiệm vụ khác.
Phát hiện sớm các vấn đề khiến chúng rẻ hơn để sửa chữa.
Nhưng đây là mẹo:
Bạn cần làm cho các PR nhỏ dễ dàng nhận biết.
Làm việc với nhóm của bạn để thiết lập các quy ước:
- Các PR dưới 200 dòng nhận nhãn
small - Sử dụng tiền tố tiêu đề PR:
[SMALL],[QUICK], hoặc[REVIEW-NEEDED] - Thiết lập thông báo Slack hoặc email ping khác nhau cho PR nhỏ so với PR lớn
- Tạo một thỏa thuận nhóm:
PR nhỏ được xem xét trong ngày, PR lớn được xử lý theo lô
Đối với các PR lớn hơn 2 phút:
Lên lịch cho chúng.
Dành thời gian trên lịch của bạn cho công việc xem xét mã sâu.
Coi nó như bất kỳ nhiệm vụ quan trọng nào khác.
Nhưng đừng để các lượt xem xét lớn ngăn cản bạn thực hiện những lượt xem xét nhanh ngay lập tức.
Tác động theo cấp số nhân:
Khi nhóm của bạn áp dụng điều này một cách tập thể, tốc độ xem xét tăng vọt.
Vòng phản hồi chặt chẽ đó tăng tốc mọi thứ.
Các tính năng được phát hành nhanh hơn.
Kiến thức lan truyền đồng đều hơn.
Lỗi được phát hiện sớm hơn.
Sự hợp tác cảm thấy ít giống như quan liêu và giống như làm việc nhóm thực sự hơn.
Kỷ luật cá nhân được yêu cầu:
Phần khó nhất là thực sự dừng công việc hiện tại của bạn để xem xét một cái gì đó.
Bộ não của bạn chống lại việc chuyển đổi ngữ cảnh.
Nhưng một lượt xem xét 2 phút giống như kiểm tra gương chiếu hậu khi lái xe—đó là một sự chuyển hướng chú ý ngắn giúp mọi người an toàn và tiến về phía trước.
Mẹo triển khai:
- Giữ thông báo PR luôn hiển thị (Slack, email, tiện ích mở rộng trình duyệt)
- Sử dụng ứng dụng di động GitHub hoặc GitLab để xem xét các PR nhỏ trong giờ giải lao
- Tạo phím tắt để chuyển đến hàng đợi xem xét của bạn
- Theo dõi thời gian phản hồi xem xét của bạn trong một tuần—nhận thức tạo ra cải thiện
Bước tiến nâng cao:Tạo mẫu PR khuyến khích kích thước dễ xem xét.
Bao gồm một mục kiểm tra:
“PR này dưới 300 dòng hoặc đã được chia thành nhiều PR.” Biến ý thức về kích thước thành một phần văn hóa nhóm của bạn.
Tôi đã thấy các nhóm giảm thời gian xem xét PR trung bình từ 3 ngày xuống còn 3 giờ bằng cách áp dụng quy tắc này.
Đó không phải là sự phóng đại.
Hiệu ứng kép của phản hồi nhanh là một trong những cải tiến năng suất có đòn bẩy cao nhất mà một nhóm có thể thực hiện.
Quy tắc 2 Phút không chỉ là về việc xem xét mã—đó là một triết lý.
Giảm ma sát cho các hành động nhanh, và bạn sẽ thực hiện nhiều hơn.
Làm cho việc phản hồi trở nên dễ dàng, và bạn sẽ trở nên đáp ứng nhanh.
6. Bí danh và Script Terminal: Tự động hóa Thói quen Cơ bắp của Bạn
Kiểm tra nhanh:
Bạn gõ bao nhiêu lệnh mỗi ngày?
Nếu bạn giống như hầu hết các nhà phát triển, đó là những lệnh lặp đi lặp lại:
khởi động máy chủ phát triển, chạy kiểm thử, kiểm tra trạng thái git, xây dựng lại các phụ thuộc, theo dõi nhật ký, mở trình soạn thảo, kết nối với cơ sở dữ liệu.
Bạn gõ những lệnh này thường xuyên đến mức chúng đã tạo thành rãnh trong trí nhớ cơ bắp của bạn.
Đây là bí mật năng suất:
Mỗi lệnh lặp lại là thời gian lãng phí.
Không phải vì gõ chậm (mặc dù nó chậm), mà vì mỗi lệnh là một điểm quyết định.
“Cờ đó là gì nhỉ?
Mình có cần đặt biến môi trường không?
Hôm nay mình đang chạy cổng nào?” Những quyết định vi mô này tích lũy thành cái chết bởi một nghìn vết cắt giấy.
Giải pháp:
Tự động hóa triệt để mọi thứ bạn làm nhiều hơn hai lần.
Cấp độ 1:
Bí danh Terminal
Đây là những chiến thắng nhanh nhất của bạn.
Thêm những cái này vào.zshrchoặc.bashrccủa bạn:
# Lối tắt Gitaliasgs='git status'aliasgp='git pull'aliasgpo='git push origin'aliasgc='git commit -m'aliasgco='git checkout'aliasgb='git branch'# Điều hướng dự ánaliasproj='cd ~/projects'aliaswork='cd ~/projects/work'# Máy chủ phát triểnaliasserve='npm run dev'aliasserve:prod='npm run build && npm run start'# Kiểm thửalias test='npm test'aliastestw='npm test -
- --watch'# Tiện íchaliasll='ls -laGh'aliascl='clear'alias ..='cd ..'alias ...='cd ../..'Bắt đầu từ đây.
Nó có vẻ nhỏ nhặt cho đến khi bạn nhận ra mình đang gõgsthay vìgit statusbảy mươi lần một ngày.
Đó là 420 ký tự tiết kiệm mỗi ngày, 10,500 mỗi tháng, và—quan trọng hơn—không tốn chút năng lượng tinh thần nào cho cú pháp lệnh.
Cấp độ 2:
Hàm cho các Lệnh Phức tạp
Khi bí danh là không đủ, hãy viết các hàm:
# Tạo một nhánh mới và đẩy lên remote gnb(){ git checkout -b"$1" git push -u origin "$1"}# Tìm và kết thúc tiến trình trên một cổng cụ thể killport(){ lsof -ti:$1 | xargs kill-9}# Commit nhanh với thông điệp qc(){ git add . git commit -m"$1" git push }# Tạo thư mục và cd vào đó mkcd(){mkdir-p"$1"cd"$1"}Bây giờgnb feature/new-authtạo và đẩy một nhánh mới trong một lệnh.killport 3000giúp bạn không phải tìm kiếm câu thần chúlsofđó lần thứ 47.
Cấp độ 3:
Script Cụ thể cho Dự án
Tạo một thư mụcscripts/trong dự án của bạn và thêm các quy trình làm việc phổ biến:
#!/bin/bash# scripts/dev-setup.shecho"🚀 Đang khởi động môi trường phát triển..." docker-compose up -d npm installnpm run migrate npm run seed npm run dev Bây giờ./scripts/dev-setup.shxử lý toàn bộ thói quen khởi động buổi sáng của bạn.
Không còn quên các bước hoặc thắc mắc tại sao cơ sở dữ liệu của bạn trống rỗng.
Cấp độ 4:
Trình chạy Tác vụ Không phụ thuộc Công cụ
Sử dụng trình chạy tác vụ nhưmake,npm scripts, hoặcjustđể chuẩn hóa lệnh trên các dự án:
# Makefile.PHONY:dev test build deploy cleandev: npm install npm run dev test: npm run test:unit npm run test:integration build: npm run build docker build -t myapp . deploy: make build make test docker push myapp kubectl apply -f k8s/ Bây giờ mọi dự án đều cómake dev,make test,make deploy.
Bộ não của bạn ghi nhớ một bộ lệnh hoạt động ở mọi nơi.
Yếu tố nhân năng suất ẩn:
Nó không chỉ là về tốc độ.
Nó là về việc giảm mệt mỏi khi ra quyết định.
Khi bạn loại bỏ các quyết định vi mô (“Lệnh đó là gì nhỉ?”), bạn bảo toàn năng lượng tinh thần cho việc giải quyết vấn đề thực sự.
Bạn duy trì trạng thái tập trung lâu hơn.
Bạn chuyển đổi ngữ cảnh ít hơn.
Những gì cần tự động hóa:
- Thiết lập và dọn dẹp môi trường
- Thao tác cơ sở dữ liệu (đặt lại, seed, sao lưu, khôi phục)
- Quy trình triển khai
- Tạo mã (thành phần mới, điểm cuối API, kiểm thử)
- Tác vụ dọn dẹp (xóa nhánh, xóa bộ nhớ cache)
- Lệnh gỡ lỗi phổ biến
Những cái tôi thích nhất:
# Mở PR cho nhánh hiện tạialias pr='gh pr create --web'# Hiển thị lịch sử commit với đồ thịaliasgl='git log --oneline --graph --decorate --all'# Chạy test chỉ cho các file đã thay đổialiastestc='npm test -
- --changedSince=main'# Reset toàn bộ:
cài đặt lại mọi thứ sạch sẽaliasreset='rm -rf node_modules package-lock.json && npm install'Kỷ luật:
Mỗi lần bạn gõ một lệnh phức tạp lần thứ hai, hãy dừng lại.
Ngay lập tức tạo một alias hoặc script.
Đừng nói với bản thân rằng bạn sẽ làm sau.
Hãy làm ngay bây giờ.
Nó chỉ mất 30 giây và sẽ mang lại lợi ích mãi mãi.
Hãy giữ một file.aliasestrong kho dotfiles của bạn và đồng bộ nó trên các máy.
Khi bạn thiết lập một máy tính mới, bạn sẽ có ngay toàn bộ lớp năng suất cá nhân của mình.
Nâng cao:Sử dụngdirenvđể tự động tải các biến môi trường và alias cụ thể cho dự án khi bạncdvào một thư mục.
Mỗi dự án có bộ phím tắt riêng và chúng không bao giờ xung đột.
Những nhà phát triển giỏi nhất không phải là những người gõ nhanh hơn—họ đã tự động hóa mọi thứ không đòi hỏi suy nghĩ.
Terminal của họ là những cỗ máy quy trình làm việc được tùy chỉnh, tự động xử lý những việc lặp đi lặp lại, để dành năng lượng trí não cho những thứ sáng tạo.
Hãy bắt đầu từ những thứ nhỏ.
Thêm một alias hôm nay.
Thêm một cái nữa vào ngày mai.
Trong một tháng, bạn sẽ xây dựng được một lớp năng suất cá nhân khiến bạn hiệu quả hơn một cách rõ rệt.
Trong một năm, bạn sẽ tự hỏi làm sao mình từng làm việc mà không có nó.
7. Sức Mạnh Của Tài Liệu Họp Hằng Ngày (Thật Đấy)
Hãy kiên nhẫn với tôi về điều này.
Tôi biết “tài liệu” và “cuộc họp” trong cùng một câu sẽ kích hoạt chứng PTSD của lập trình viên.
Nhưng đây không phải là về thêm nhiều cuộc họp hay thủ tục hành chính—mà là về việc tạo ra một chức năng ép buộc cho sự rõ ràng, giúp cả ngày làm việc của bạn hiệu quả hơn.
Đây là thực hành:
Mỗi buổi sáng, trước khi viết bất kỳ dòng code nào, hãy dành 5 phút viết một ghi chú ngắn với ba phần:
- Những gì tôi đã hoàn thành hôm qua(hoặc ngày làm việc trước đó)
- Những gì tôi sẽ hoàn thành hôm nay
- Điều gì đang cản trở tôi
Chỉ vậy thôi.
Không có định dạng chính thức.
Không có mẫu cầu kỳ.
Chỉ ba điểm gạch đầu dòng trong một tài liệu, sổ tay, hoặc công cụ bạn chọn.
Tại sao điều này hiệu quả trong khi hầu hết tài liệu thì không:
Nó buộc bạn phải rõ ràng trước khi bạn cần.Trước khi lao vào code, bạn đang tự hỏi:
“Hôm nay tôi thực sự đang cố gắng hoàn thành điều gì?” Điều này ngăn chặn vấn đề cực kỳ phổ biến là làm việc chăm cả ngày nhưng không tập trung vào đúng việc.
Nó tạo ra trách nhiệm giải trình với chính bạn.Khi bạn viết “Hôm nay tôi sẽ triển khai xác thực người dùng,” bạn đã đưa ra một cam kết.
Không phải với quản lý của bạn (mặc dù họ có thể đánh giá cao điều đó), mà là với chính bạn.
Bạn đã biến những ý định mơ hồ thành kế hoạch cụ thể.
Nó tiết lộ những mẫu hình mà bạn không thể nhìn thấy bằng cách khác.Sau một tuần, hãy đọc lại các ghi chú của bạn.
Bạn sẽ nhận thấy:
- “Tôi đã bị cản trở bởi cùng một vấn đề API trong ba ngày—tôi nên báo cáo vấn đề này lên.”
- “Tôi cứ nói sẽ viết test nhưng không bao giờ làm—tôi cần thay đổi cách tiếp cận.”
- “Tôi hoàn thành nhiều hơn khi tôi xác định các nhiệm vụ cụ thể, nhỏ thay vì những nhiệm vụ lớn mơ hồ.”
Những hiểu biết sâu sắc này là vô hình khi mỗi ngày cứ mờ nhòe vào ngày tiếp theo.
Khi được viết ra, các mẫu hình sẽ xuất hiện.
Nó làm cho các cuộc họp đứng thực tế trở nên nhanh hơn và tốt hơn.Khi nhóm của bạn có một cuộc họp đứng (ảo hoặc trực tiếp), bạn không phải vội vàng nhớ lại những gì bạn đã làm.
Bạn chỉ cần đọc ghi chú của mình.
Các cuộc họp trở nên ngắn hơn.
Các bản cập nhật rõ ràng hơn.
Nhóm của bạn thực sự nhận được giá trị từ nghi thức này thay vì coi nó như một ô đánh dấu.
Nó tạo ra dấu vết cho việc chuyển đổi ngữ cảnh.Bị lôi vào một tình huống khẩn cấp?
Phải tham dự một cuộc họp bất ngờ?
Không vấn đề gì—ghi chú của bạn cho bạn biết chính xác bạn đang ở đâu và bạn đang làm gì.
Tiếp tục công việc ngay lập tức thay vì dành 20 phút cố gắng nhớ lại bạn đang làm gì.
Ví dụ thực tế:
## Ngày 10 tháng 12, 2025 Đã hoàn thành hôm qua: - Sửa lỗi phân trang trên bảng điều khiển người dùng (#2847) - Đã xem xét ba PR từ nhóm - Cập nhật tài liệu triển khai với các biến môi trường mới Sẽ hoàn thành hôm nay: - Triển khai giới hạn tốc độ trên endpoint xác thực (ưu tiên cao) - Viết unit test cho middleware xác thực mới - Làm việc cặp với Jordan về chiến lược caching Redis Đang bị cản trở: - Cần thông tin xác thực môi trường staging để kiểm thử - Đang chờ phản hồi thiết kế cho trang cài đặt Việc đó mất 90 giây để viết.
Nhưng bây giờ cả ngày của bạn đã có cấu trúc.
Bạn biết những ưu tiên của mình.
Bạn biết điều gì đang cản trở mình (và có thể chủ động gỡ bỏ nó).
Bạn có một định nghĩa rõ ràng về “hoàn thành” trong ngày hôm nay.
Các công cụ giúp việc này trở nên dễ dàng:
- Notion:Tạo một mẫu trang hàng ngày với ba phần đó
- Obsidian:Sử dụng ghi chú hàng ngày với một mẫu
- File văn bản đơn giản:Giữ một file
daily-log.mdtrong thư mục dự án của bạn - Linear/Jira:Sử dụng phần bình luận trên các ticket được giao cho bạn
- Slack:Đăng trong một kênh riêng tư bạn tạo cho chính mình
Công cụ không quan trọng.
Thực hành mới quan trọng.
Ứng dụng nâng cao:
Đánh giá hàng tuần:Mỗi thứ Sáu, hãy xem qua các ghi chú trong tuần của bạn.
Ăn mừng những chiến thắng.
Xác định các điểm cản trở lặp lại.
Lên kế hoạch cho tuần tới dựa trên những gì thực sự đã xảy ra, không phải những gì bạn hy vọng sẽ xảy ra.
Đánh giá hiệu suất:Khi đến lúc đánh giá hàng năm và ai đó hỏi “Bạn đã đạt được những gì?” bạn có bằng chứng.
Hàng tháng trời công việc được ghi chép, sắp xếp theo ngày.
Không còn phải vội vàng nhớ lại những gì bạn đã làm trong Q2.
Gỡ lỗi năng suất:Đang có một tuần tồi tệ?
Hãy xem các ghi chú của bạn.
Bạn có đang chuyển đổi ngữ cảnh quá nhiều?
Đảm nhận quá nhiều nhiệm vụ?
Liên tục bị cản trở?
Các ghi chú giúp việc chẩn đoán trở nên khả thi.
Đòn bẩy giao tiếp:Quản lý của bạn yêu cầu một bản cập nhật tình trạng.
Bạn gửi cho họ ghi chú của bạn trong ba ngày qua.
Họ có được ngữ cảnh đầy đủ trong 30 giây.
Bạn trông có vẻ tổ chức và chủ động.
Sự thay đổi tư duy:
Đây không phải là công việc bận rộn vô ích.
Đó là thời gian suy nghĩ chiến lược.
5 phút đó vào buổi sáng là lúc bạn trở thành kiến trúc sư của ngày làm việc của mình thay vì chỉ là một hành khách.
Bạn đang quyết định điều gì quan trọng, không để cho sự khẩn cấp và gián đoạn quyết định thay bạn.
Những phản đối thường gặp:
“Tôi không có thời gian.” Bạn chắc chắn có 5 phút.
Bạn dành nhiều thời gian hơn thế trên Slack.
Đây là việc đánh đổi thời gian giá trị thấp để lấy sự rõ ràng giá trị cao.
“Ngày của tôi quá khó đoán.” Đó chính xác là lý do bạn cần điều này.
Khi hỗn loạn ập đến, ghi chú của bạn sẽ neo giữ bạn.
Bạn có thể chủ động quyết định đi chệch khỏi kế hoạch thay vì vô tình lạc lối.
“Tôi sẽ không bao giờ xem lại những thứ này.” Có lẽ là không.
Nhưng viết chúng ra sẽ thay đổi hành vi hôm nay.
Việc xem lại là phần thưởng thêm;
còn việc lập kế hoạch mới là phần thưởng chính.
Bắt đầu từ ngày mai:Trước khi mở IDE, hãy mở một tài liệu.
Viết ba điểm gạch đầu dòng.
Biến nó thành một nghi thức tự động như tách cà phê buổi sáng của bạn.
Sau hai tuần, bạn sẽ không bắt đầu ngày mới theo cách nào khác.
Những nhà phát triển có vẻ cực kỳ ngăn nắp, luôn biết mình đang làm gì, và luôn hoàn thành công việc đều đặn?
Họ không phải siêu nhân.
Họ chỉ xây dựng những thói quen nhỏ tạo ra sự rõ ràng lớn.
Đây là một trong số đó.
8. Học IDE Như Một Nhạc Cụ: Phím Tắt, Đoạn Mã Mẫu và Trí Nhớ Cơ Bắp
Đây là một sự thật không mấy dễ chịu:
Hầu hết nhà phát triển sử dụng IDE của họ như ai đó gõ piano bằng hai ngón tay.
Chắc chắn, nó hoạt động.
Âm nhạc vang lên.
Nhưng so với người đã thành thạo nhạc cụ?
Nó khác một trời một vực.
IDE là giao diện chính của bạn với mã nguồn.
Bạn tương tác với nó hàng nghìn lần mỗi ngày.
Mọi hành động bạn thực hiện—mở tệp, điều hướng mã, tái cấu trúc, chạy kiểm thử—đều hoặc là trơn tru và tự động hoặc là vụng về và thủ công.
Sự khác biệt này tích lũy thành hàng giờ mỗi tuần, rồi trở thành hàng tuần mỗi năm.
Khoảng cách năng suất giữa người mới dùng IDE và bậc thầy IDE là rất lớn.Chúng ta đang nói đến sự khác biệt năng suất 2-3 lần, không phải cải thiện 10%.
Cấp độ 1:
Thành thạo các Phím Tắt Thiết yếu
Ngừng sử dụng chuột để điều hướng.
Nghiêm túc đấy.
Chuột dùng để chỉnh sửa mã, không phải để tìm nó.
Các phím tắt phải biết (điều chỉnh cho IDE của bạn):
-
Mở tệp nhanh:
Cmd/Ctrl + P— Gõ vài chữ cái của bất kỳ tên tệp nào và nhảy đến đó ngay lập tức.
Không còn phải nhấp qua cây thư mục như năm 1998 nữa. -
Điều hướng ký hiệu:
Cmd/Ctrl + Shift + O— Nhảy đến bất kỳ hàm, lớp hoặc biến nào trong tệp hiện tại.
Tìm thứ bạn cần trong một giây. -
Đi đến định nghĩa:
F12hoặcCmd/Ctrl + Click— Theo dấu vết qua cơ sở mã của bạn.
Xem cách một thứ hoạt động mà không bị mất vị trí. -
Tìm tất cả tham chiếu:
Shift + F12— Hàm này được gọi ở đâu?
Một phím tắt sẽ cho bạn thấy. -
Chỉnh sửa con trỏ đa điểm:
Cmd/Ctrl + D— Chọn lần xuất hiện tiếp theo.
Chỉnh sửa nhiều nơi cùng lúc.
Chỉ riêng phím tắt này sẽ làm bạn kinh ngạc và tiết kiệm hàng giờ. -
Bảng lệnh:
Cmd/Ctrl + Shift + P— Truy cập mọi tính năng IDE mà không cần ghi nhớ từng phím tắt riêng lẻ.
Nó giống như Spotlight cho IDE của bạn. -
Terminal tích hợp:
Ctrl + dấu huyền (`)— Chuyển đổi giữa mã và terminal ngay lập tức.
Thử thách bản thân:Trong một tuần, mỗi lần bạn với tay lấy chuột, hãy dừng lại.
Hỏi:
“Có phím tắt bàn phím cho việc này không?” Tra cứu nó.
Sử dụng nó.
Sau một tuần, nhiều hành động sẽ trở nên tự động.
Cấp độ 2:
Đoạn Mã Mẫu Tùy chỉnh cho Mã Lặp lại
Bạn viết đi viết lại các mẫu giống nhau:
các thành phần React, mã mẫu kiểm thử, các tuyến API, các khối xử lý lỗi.
Ngừng gõ chúng từng ký tự một.
Ví dụ:
Đoạn mẫu thành phần React:
Gõrfcvà nhấn Tab:
importReactfrom'react';constComponentName=()=>{return(<div></div>);};exportdefaultComponentName;Con trỏ của bạn sẽ nằm ởComponentName, sẵn sàng để đặt tên.
Nhấn Tab lần nữa, và bạn đã ở trong khối return.
Ba mươi giây gõ phím giảm xuống còn ba lần gõ phím.
Tạo đoạn mẫu cho:
- Bộ kiểm thử và trường hợp kiểm thử
- Các mẫu React/Vue/Angular phổ biến
- Mã mẫu điểm cuối API
- Mẫu truy vấn cơ sở dữ liệu
- Các mẫu xử lý lỗi
- Câu lệnh import cho các thư viện thường dùng
Mọi IDE đều có chức năng đoạn mẫu.
VS Code sử dụng tệp JSON.
Các IDE của JetBrains có mẫu trực tiếp.
Vim có UltiSnips.
Đầu tư một giờ để thiết lập những thứ này, và chúng sẽ tiết kiệm cho bạn hàng giờ mỗi tuần.
Cấp độ 3:
Các Tính năng IDE Bạn Có Lẽ Chưa Dùng
Công cụ tái cấu trúc:Đừng tự đổi tên một hàm và 47 lần sử dụng của nó một cách thủ công.
Sử dụng “Rename Symbol” và để IDE làm điều đó một cách an toàn, bao gồm cả qua các tệp.
Tương tự cho “Extract Method,” “Extract Variable,” và “Inline Variable.”
Con trỏ đa điểm:Thực sự thành thạo điều này.
Nó không chỉ làCmd + D.
Hãy học cách:
- Đặt con trỏ trên mọi dòng trong một vùng chọn (
Cmd/Ctrl + Shift + L) - Thêm con trỏ phía trên/dưới dòng hiện tại (
Cmd/Ctrl + Alt + Lên/Xuống) - Chọn tất cả lần xuất hiện trong tệp (
Cmd/Ctrl + Shift + LsauCmd/Ctrl + F)
Phím nóng điều hướng mã:
- Nhảy đến dấu ngoặc tương ứng
- Nhảy giữa các thay đổi
- Điều hướng đến vị trí con trỏ trước/sau (giống như nút quay lại/tiến của trình duyệt)
- Nhảy đến lỗi/cảnh báo
Tự động hóa tác vụ:Hầu hết IDE cho phép bạn tạo cấu hình chạy hoặc tác vụ.
Thay vì gõnpm run dev -- --port 3001 --debugvào terminal mỗi lần, hãy lưu nó như một tác vụ có tên và khởi chạy bằngF5hoặc một phím tắt.
Tích hợp Git:Ngừng chuyển đổi ngữ cảnh sang terminal cho mọi thao tác git.
Học cách stage từng phần, xem xét sự khác biệt, giải quyết xung đột và tạo commit trực tiếp trong IDE của bạn.
Chỉ riêng các công cụ so sánh trực quan cũng đáng để thành thạo.
Cấp độ 4:
Tối ưu hóa Không gian làm việc và Bố cục
Chia trình soạn thảo một cách thông minh:Đừng chỉ mở một tệp cùng lúc.
Chia màn hình của bạn để xem:
- Tệp triển khai bên trái, tệp kiểm thử bên phải
- Mã thành phần ở trên, kiểu dáng ở dưới
- Tuyến API ở trên, mô hình cơ sở dữ liệu ở dưới
Sử dụng nhóm trình soạn thảo và quản lý thẻ:
- Ghim các tệp thường truy cập để chúng không bị đóng
- Sử dụng chia dọc so với chia ngang dựa trên các tệp (cấu hình hẹp thì dọc, thành phần rộng thì ngang)
- Học cách chuyển qua lại giữa các thẻ mà không dùng chuột (
Cmd/Ctrl + Tab)
Tạo cài đặt cụ thể cho không gian làm việc:Các dự án khác nhau có nhu cầu khác nhau.
Thiết lập cho từng dự án cụ thể:
- Quy tắc định dạng mã
- Cấu hình kiểm tra lỗi
- Đoạn mã mẫu tùy chỉnh
- Tác vụ xây dựng
- Cấu hình gỡ lỗi
Cấp 5:
Tiện ích mở rộng và Plugin Thực Sự Quan Trọng
Đừng cài 47 tiện ích mở rộng làm chậm IDE của bạn.
Hãy thật tinh tế.
Đây là những danh mục đáng để khám phá:
Chất lượng mã:
- Công cụ kiểm tra và định dạng mã (ESLint, Prettier) chạy khi lưu
- Công cụ sắp xếp import
- Công cụ kiểm tra chính tả mã (đúng vậy
– lỗi chính tả trong tên biến thật đáng xấu hổ)
Năng suất:
- GitLens hoặc tương tự để xem lịch sử và người chỉnh sửa git ngay trong trình soạn thảo
- Công cụ tô màu cặp ngoặc
- Path IntelliSense để gợi ý import
- Công cụ đánh dấu TODO để theo dõi nợ kỹ thuật
Ngôn ngữ cụ thể:
- Bất cứ thứ gì làm cho ngôn ngữ chính của bạn cảm thấy tự nhiên (Tailwind IntelliSense, tiện ích mở rộng Python, công cụ Go, v.v.)
Mẹo chuyên nghiệp:Trước khi cài đặt một tiện ích mở rộng, hãy kiểm tra xem IDE của bạn đã có sẵn chức năng đó chưa.
Nhiều tính năng mà mọi người cài tiện ích mở rộng thực ra đã có sẵn nếu bạn biết tìm ở đâu.
Phương Pháp Thực Hành Có Chủ Đích
Tuần 1:Làm chủ điều hướng tệp.
Không dùng chuột để mở tệp.
Chỉ dùng phím tắt.
Tuần 2:Làm chủ điều hướng mã trong tệp.
Nhảy đến ký hiệu, định nghĩa, tham chiếu mà không cần cuộn.
Tuần 3:Làm chủ chỉnh sửa đa con trỏ.
Tìm cách sáng tạo để sử dụng nó.
Chỉnh sửa cấu hình JSON.
Đổi tên mẫu.
Biến đổi cấu trúc dữ liệu.
Tuần 4:Làm chủ công cụ tái cấu trúc.
Đổi tên hàm an toàn.
Trích xuất phương thức.
Di chuyển mã giữa các tệp.
Tuần 5:Làm chủ tích hợp git.
Chọn, commit, xem xét, giải quyết
– tất cả mà không cần rời khỏi IDE của bạn.
Tuần 6:Làm chủ gỡ lỗi.
Đặt điểm dừng, kiểm tra biến, bước qua mã, sử dụng biểu thức theo dõi.
Mỗi tuần, tập trung vào một lĩnh vực.
Đến cuối sáu tuần, bạn sẽ là một bậc thầy về IDE.
Tác động thực tế:
Tôi đã tính thời gian thực hiện các tác vụ phổ biến trước và sau khi thành thạo IDE của mình:
- Mở một tệp cụ thể:
8 giây → 2 giây - Tìm nơi một hàm được gọi:
30 giây → 3 giây - Đổi tên một biến trên nhiều tệp:
3 phút → 10 giây - Thiết lập một phiên gỡ lỗi:
2 phút → 15 giây
Đây không phải là những cải tiến nhỏ.
Hãy tính toán:
Nếu bạn thực hiện mỗi tác vụ này 10 lần một ngày, bạn tiết kiệm được hơn 6 phút.
Nhân với 5 ngày một tuần, 50 tuần một năm
– đó là 30 giờ mỗi năm chỉ với bốn tác vụ phổ biến.
Tư Duy Của Nhạc Công
Một nghệ sĩ piano chuyên nghiệp không nghĩ về vị trí các phím.
Ngón tay họ đã biết.
Họ nghĩ về âm nhạc.
Tương tự, khi bạn đã thành thạo IDE của mình, bạn ngừng nghĩ về việclàm thế nàođể làm mọi thứ và tập trung hoàn toàn vàocái bạn đang xây dựng.
Công cụ biến mất.
Bạn chỉ đang sáng tạo.
Đó không phải là về việc trở thành một “người gõ phím nhanh hơn”.
Đó là về việc loại bỏ ma sát giữa suy nghĩ và mã của bạn.
Ý tưởng tuôn trực tiếp từ não bạn ra màn hình mà không bị mắc kẹt trong các bước cơ học của điều hướng và chỉnh sửa.
Bắt đầu từ việc nhỏ:Chọn một phím tắt hôm nay.
Sử dụng nó một cách có chủ ý mỗi khi tình huống đó xảy ra.
Ngày mai, thêm một phím tắt khác.
Trong một tháng, bạn sẽ xây dựng được một lớp trí nhớ cơ bắp mới.
IDE là công cụ quan trọng nhất bạn sở hữu với tư cách là một nhà phát triển.
Hãy làm chủ nó như thể sự nghiệp của bạn phụ thuộc vào nó
– bởi vì theo một nghĩa rất thực tế, đúng là như vậy.
9. Gom Nhóm Công Việc Nhạy Cảm Ngữ Cảnh: Định Chủ Đề Cho Các Ngày và Giới Hạn Thời Gian Cho Các Nhiệm Vụ
Đây là một mẫu hình bạn có thể nhận ra:
Đó là 10 giờ sáng.
Bạn đang chìm sâu vào việc triển khai một tính năng phức tạp.
Trạng thái tập trung đang đạt đỉnh.
Bạn đang tạo ra tiến triển thực sự.
Rồi:
Thông báo Slack.
Ai đó cần xem xét mã.
Bạn chuyển đổi ngữ cảnh, dành 15 phút để xem xét, và quay lại với tính năng của mình.
Chỉ có bây giờ bạn mất thêm 15 phút để nhớ mình đang ở đâu và đang nghĩ gì.
Bạn đã mất 30 phút thời gian hiệu quả cho một sự gián đoạn 15 phút.
Đến 5 giờ chiều, bạn đã viết mã, xem xét ba PR, tham dự hai cuộc họp, trả lời một tá tin nhắn Slack, sửa một lỗi sản xuất và cập nhật một số tài liệu.
Bạn đã bận rộn cả ngày.
Nhưng tính năng bạn bắt đầu lúc 10 giờ sáng thì sao?
Vẫn chưa xong.
Bạn đã có tiến triển trên mười hai việc và hoàn thành không việc nào.
Đây là sự chuyên chế của việc chuyển đổi ngữ cảnh.Não của bạn không phải là máy tính.
Bạn không thể ngay lập tức hoán đổi giữa các kiểu suy nghĩ khác nhau mà không phải trả giá.
Mỗi lần chuyển đổi phải chịu một “hình phạt chuyển đổi nhận thức”
– thời gian cần thiết để tải lại ngữ cảnh, nhớ bạn đang ở đâu và quay lại đúng chế độ tinh thần.
Giải pháp:
Gom nhóm công việc tương tự lại với nhau và định chủ đề cho thời gian của bạn.
Định Chủ Đề Theo Ngày (Cho Người Mạnh Mẽ)
Nếu bạn có đủ quyền kiểm soát lịch trình của mình, hãy thử định chủ đề cho cả ngày:
- Thứ Hai:Lập kế hoạch và kiến trúc.
Các buổi thiết kế.
Viết đặc tả kỹ thuật.
Suy nghĩ tổng quan. - Thứ Ba/Thứ Tư:Ngày làm việc sâu.
Triển khai tính năng.
Giải quyết vấn đề phức tạp.
Tối thiểu hóa cuộc họp. - Thứ Năm:Ngày hợp tác.
Xem xét mã.
Lập trình cặp.
Thảo luận nhóm. - Thứ Sáu:Dọn dẹp và học hỏi.
Viết tài liệu.
Tái cấu trúc.
Học công cụ mới.
Lập kế hoạch tuần tới.
Điều này nghe có vẻ cứng nhắc, nhưng lại vô cùng tự do.
Khi thứ Ba đến, bạn biết mình sẽ viết mã cả ngày.
Không có sự không chắc chắn.
Không có sự mệt mỏi khi quyết định ưu tiên cái gì.
Bạn đã quyết định rồi.
Định Chủ Đề Nửa Ngày (Thực Tế Hơn)
Không thể kiểm soát cả ngày?
Hãy định chủ đề nửa ngày:
- Buổi sáng:Công việc sâu.
Các nhiệm vụ đòi hỏi nhận thức cao nhất của bạn.
Không họp.
Không Slack. - Buổi chiều:Công việc hợp tác.
Các cuộc họp, xem xét mã, thảo luận, công việc hành chính.
Não của bạn sắc bén nhất vào buổi sáng (với hầu hết mọi người).
Hãy sử dụng thời gian đó cho những suy nghĩ khó khăn.
Để dành những công việc dễ hơn, mang tính xã hội hơn cho lúc não bạn mụ mị hơn.
Định Chủ Đề Theo Giờ (Gom Nhóm Tối Thiểu Khả Thi)
Ngay cả khi bạn không thể kiểm soát các khối thời gian lớn hơn, hãy gom nhóm ở cấp độ giờ:
9-10 giờ sáng:Xử lý email và Slack.
Xử lý mọi thứ một lần, trả lời hiệu quả, đóng lại.
10-12 giờ trưa:Công việc tính năng.
Điện thoại ở chế độ máy bay.
Slack ở chế độ không làm phiền.
Tập trung tuyệt đối.
12-1 giờ chiều:Ăn trưa và xem xét mã.
Gom tất cả các PR đang chờ.
Giải quyết chúng cùng nhau.
1-2 giờ chiều:Các cuộc họp (nếu không thể tránh).
2-4 giờ chiều:Công việc tính năng, hiệp hai.
4-5 giờ chiều:Kết thúc.
Cập nhật ticket.
Viết ghi chú hàng ngày.
Lập kế hoạch cho ngày mai.
Các nhiệm vụ nhỏ và công việc dọn dẹp.
Phép Màu Của Việc Gom Nhóm Các Nhiệm Vụ Tương Tự
Xem xét mã:Đừng xem xét một PR mỗi hai giờ suốt cả ngày.
Hãy chặn 30-60 phút và xem xét tất cả các PR đang chờ cùng một lúc.
Bạn duy trì ở “chế độ xem xét”
– suy nghĩ phê phán, tìm kiếm mẫu hình, kiểm tra các trường hợp biên.
Mỗi lần xem xét sẽ nhanh hơn và tốt hơn vì bạn không phải chuyển đổi bánh răng tinh thần.
Các cuộc họp:Hãy cố gắng nhóm chúng lại.
Các cuộc họp liên tiếp có thể rất mệt mỏi, nhưng chúng ít phá hoại hơn so với các cuộc họp rải rác trong ngày của bạn.
Một khối họp 3 giờ bảo toàn được 5 giờ làm việc không bị gián đoạn.
Sáu cuộc họp 30 phút rải rác trong ngày sẽ phá hủy toàn bộ năng suất của ngày hôm đó.
Giao tiếp:Đặt thời gian cụ thể để kiểm tra Slack và email.
Có thể là 9 giờ sáng, buổi trưa và 4 giờ chiều.
Ngoài những khung giờ đó, hãy đóng các ứng dụng.
Bạn sẽ không bỏ lỡ những trường hợp khẩn cấp thực sự (mọi người sẽ tìm đến bạn), nhưng bạn sẽ tránh được những gián đoạn liên tục làm phân mảnh sự tập trung của mình.
Các nhiệm vụ nhỏ:Hãy giữ một danh sách các nhiệm vụ nhanh (cập nhật các phụ thuộc, sửa lỗi chính tả, tái cấu trúc nhỏ).
Hãy xử lý chúng theo lô.
Dành 30 phút một hoặc hai lần một tuần để dọn sạch danh sách thay vì để chúng làm gián đoạn dòng làm việc của bạn trong suốt tuần.
Học tập:Đừng rải rác việc học trong suốt tuần.
Hãy dành riêng một khoảng thời gian
– có thể là chiều thứ Sáu hoặc sáng thứ Ba
– khi bạn chủ động khám phá các công cụ mới, đọc tài liệu, xem hướng dẫn hoặc thử nghiệm các kỹ thuật mới.
Cách Bảo Vệ Thời Gian Làm Việc Theo Lô Của Bạn
1. Thiết lập ranh giới một cách rõ ràng:Cập nhật trạng thái Slack của bạn.
“🧠 Làm việc sâu cho đến trưa.” Chặn lịch của bạn.
Huấn luyện nhóm của bạn rằng một số thời điểm nhất định được bảo vệ.
2. Tạo sự cản trở cho các gián đoạn:Đóng Slack.
Tắt thông báo.
Để điện thoại của bạn ở phòng khác.
Sử dụng các công cụ chặn trang web nếu bạn cần.
Làm cho việc tự làm mình phân tâm trở nên khó khăn hơn.
3. Giao tiếp chủ động:Nói với nhóm của bạn về hệ thống làm việc theo lô của bạn.
“Tôi xem xét code lúc 1 giờ chiều và 4 giờ chiều.
Nếu việc đó khẩn cấp, hãy nhắn tin trực tiếp cho tôi.
Nếu không, tôi sẽ xử lý nó vào lô tiếp theo.” Hầu hết mọi người tôn trọng những kỳ vọng rõ ràng.
4. Theo dõi và điều chỉnh:Hãy để ý xem khi nào bạn làm việc hiệu quả nhất.
Bạn là người làm việc buổi sáng hay buổi chiều?
Khi nào các cuộc họp làm bạn kiệt sức nhất?
Khi nào bạn làm việc sâu tốt nhất?
Hãy thiết kế việc làm việc theo lô xung quanh nhịp điệu tự nhiên của bạn, chứ không phải một lịch trình lý tưởng nào đó mà bạn nghĩ mình nên có.
Hiệu Ứng Tích Lũy
Làm việc theo lô không phải là nhồi nhét nhiều công việc hơn vào ít thời gian hơn.
Mà là làm công việc chất lượng cao hơn với ít sự kiệt sức về tinh thần hơn.
Khi bạn viết code trong 3 giờ liên tục không bị gián đoạn, bạn đạt được một mức độ tập trung sâu và trạng thái “flow” mà không thể có được trong sáu phiên 30 phút.
Bạn giữ được nhiều ngữ cảnh hơn trong đầu.
Bạn nhìn thấy các kết nối và mẫu mà bạn sẽ bỏ lỡ nếu không làm vậy.
Bạn viết code tốt hơn.
Khi bạn xem xét code theo lô, bạn bắt đầu nhận thấy các mẫu xuyên suốt các PR.
“Ồ, ba người đã mắc cùng một lỗi xử lý lỗi
– chúng ta nên cập nhật tài liệu của mình.” Cái nhìn sâu sắc đó chỉ xuất hiện khi bạn xem nhiều PR liên tiếp nhau.
Bắt Đầu Từ Những Việc Nhỏ
Bạn không cần phải cấu trúc lại toàn bộ tuần của mình vào ngày mai.
Hãy chọn một chiến lược làm việc theo lô:
- Gom tất cả việc xem xét code vào hai khung giờ cố định mỗi ngày
- Bảo vệ hai giờ đầu tiên trong ngày cho công việc sâu
- Chỉ kiểm tra Slack vào những thời điểm đã lên lịch
- Dành chiều thứ Sáu cho việc học tập/dọn dẹp
Hãy thử nó trong hai tuần.
Hãy để ý sự khác biệt.
Sau đó thêm một chiến lược làm việc theo lô khác.
Sự Cho Phép Bạn Cần
Bạn không cần sự chấp thuận của quản lý để làm việc theo lô.
Bạn không phải là người không phản hồi hay khó tính.
Bạn đang chiến lược về cách sử dụng sự chú ý của mình
– nguồn lực có giá trị nhất và hữu hạn nhất của bạn.
Những nhà phát triển giỏi nhất không phải lúc nào cũng sẵn sàng 24/7.
Họ có chủ đích về thời điểm họ sẵn sàng và cho việc gì.
Họ bảo vệ sự tập trung của mình như một mặt hàng khan hiếm.
Làm việc theo lô là cách họ thực hiện điều đó.
10. Tận Dụng Các Công Cụ AI, Nhưng Đừng Để Chúng Suy Nghĩ Thay Bạn
Chúng ta cần nói về “con voi trong phòng”:
các trợ lý lập trình AI đã thay đổi cơ bản việc phát triển phần mềm.
GitHub Copilot, ChatGPT, Claude (xin chào!), Cursor và hàng chục công cụ khác giờ đây có thể viết những đoạn code đáng kể.
Bỏ qua chúng, và bạn đang tự làm mình yếu thế.
Phụ thuộc quá nhiều vào chúng, và bạn sẽ làm mai một những kỹ năng bạn cần.
Điểm ngọt ngào về năng suất:
Sử dụng các công cụ AI như một hệ số nhân lực, không phải là sự thay thế.
Các Công Cụ AI Thực Sự Giỏi Ở Điều Gì
Loại bỏ mã mẫu:Cần một endpoint API REST với các thao tác CRUD tiêu chuẩn?
Cần một component React với các mẫu phổ biến?
Cần mã mẫu cho kiểm thử?
Các công cụ AI xuất sắc ở đây.
Chúng tạo ra khung sườn ngay lập tức, và bạn tùy chỉnh các phần quan trọng.
Ví dụ:
- Bạn:
“Tạo một component React cho thẻ hồ sơ người dùng với ảnh đại diện, tên, email và nút chỉnh sửa” - AI:
Tạo ra cấu trúc component hoàn chỉnh với props, các hook tạo kiểu, mọi thứ - Bạn:
Tùy chỉnh kiểu dáng, thêm logic nghiệp vụ cụ thể, tích hợp với hệ thống quản lý trạng thái của bạn
Thời gian tiết kiệm:
10-15 phút cho cấu trúc.
Thời gian bỏ ra:
5 phút để tùy chỉnh.
Lợi ích ròng:
đáng kể.
Giải thích và tài liệu hóa:Gặp phải code không quen thuộc?
Đang xử lý một thuật toán phức tạp?
Các công cụ AI có thể giải thích điều gì đang xảy ra bằng ngôn ngữ đơn giản.
Chúng giống như có một nhà phát triển cấp cao sẵn sàng 24/7 cho các câu hỏi “tại sao cái này hoạt động?”.
Hỗ trợ gỡ lỗi:Bị kẹt với một lỗi?
Dán nó vào một công cụ AI cùng với ngữ cảnh liên quan.
Thường thì chúng sẽ phát hiện vấn đề ngay lập tức hoặc đề xuất các chiến lược gỡ lỗi mà bạn chưa nghĩ tới.
Nó giống như gỡ lỗi với vịt cao su nhưng con vịt biết nói lại.
Chuyển đổi code:Cần chuyển đổi một component dạng class sang hooks?
Tái cấu trúc callbacks thành async/await?
Dịch TypeScript sang JavaScript?
Các công cụ AI xử lý những chuyển đổi mang tính cơ học này ngay lập tức và thường là chính xác.
Gia tốc học tập:Muốn hiểu một framework mới?
Các công cụ AI có thể tạo ra code ví dụ, giải thích các khái niệm và trả lời các câu hỏi tiếp theo.
Đó là tài liệu tương tác thích ứng với phong cách học của bạn.
Các Công Cụ AI Nguy Hiểm Ở Điều Gì
Quyết định kiến trúc:Các công cụ AI đề xuất các mẫu, nhưng chúng không hiểu các ràng buộc của hệ thống của bạn, quy ước của nhóm bạn hoặc nhu cầu bảo trì lâu dài của bạn.
Chúng cho bạn “một giải pháp”, không nhất thiết là “giải pháp của bạn”.
Code quan trọng về bảo mật:Code xác thực, ủy quyền, mã hóa hoặc xác thực dữ liệu do AI tạo ra cần được xem xét cực kỳ kỹ lưỡng.
Những công cụ này có thể tạo ra code trông có vẻ hợp lý nhưng chứa các lỗ hổng bảo mật tinh vi.
Logic đặc thù miền:Quy tắc nghiệp vụ của bạn, mô hình dữ liệu của bạn, các trường hợp biên độc đáo của bạn
– các công cụ AI không biết những điều này.
Chúng sẽ đưa ra các giải pháp chung chung có thể hoàn toàn sai trong ngữ cảnh của bạn.
Quản lý trạng thái phức tạp:Các công cụ AI gặp khó khăn với các tương tác trạng thái phức tạp, điều kiện chạy đua và các luồng bất đồng bộ phức tạp.
Chúng sẽ tạo ra code hoạt động trong trường hợp bình thường nhưng thất bại trong các trường hợp biên.
Code quan trọng về hiệu suất:Code do AI tạo ra ưu tiên tính đúng đắn và rõ ràng hơn hiệu suất.
Nếu bạn đang tối ưu hóa các đường dẫn nóng hoặc xử lý tập dữ liệu lớn, bạn cần sự phán đoán của con người về độ phức tạp thuật toán và các chiến lược tối ưu hóa.
Cách Sử Dụng Các Công Cụ AI Hiệu Quả (Khung Làm Việc)
1. Bắt đầu với AI, kết thúc bằng suy nghĩ:
Hãy để AI tạo bản nháp đầu tiên.
Sau đó đọc từng dòng.
Hiểu từng phần.
Tái cấu trúc những gì không phù hợp với mẫu của bạn.
Thêm xử lý lỗi mà nó đã bỏ sót.
Xem xét các trường hợp biên mà nó không nghĩ tới.
Đừng bao giờ chấp nhận mã được tạo ra một cách mù quáng.Hãy coi nó như đánh giá mã:
đầu vào có giá trị nhưng vẫn cần sự phán đoán của bạn.
2. Sử dụng AI để tăng tốc, không phải để thay thế:
❌ “Viết cho tôi một tính năng hoàn chỉnh để xác thực người dùng”
✅ “Tạo mã mẫu cho một hàm middleware JWT”
Cách đầu tiên từ bỏ tư duy.
Cách thứ hai tiết kiệm thời gian cho công việc mang tính cơ học trong khi vẫn giữ quyền kiểm soát kiến trúc của bạn.
3. Cung cấp ngữ cảnh, nhận kết quả tốt hơn:
Đừng chỉ dán mã và yêu cầu trợ giúp.
Hãy giải thích:
- Bạn đang cố gắng đạt được điều gì
- Bạn đã thử những gì
- Bạn đang làm việc dưới những ràng buộc nào
- Mã nguồn của bạn sử dụng những mẫu nào
Đầu vào tốt hơn → Đầu ra tốt hơn.
4. Xác minh mọi thứ:
Chạy mã.
Kiểm tra nó.
Đọc nó.
Hiểu nó.
Đừng triển khai mã do AI tạo ra mà bạn không hoàn toàn hiểu.
Đó là một lỗi (hoặc lỗ hổng bảo mật) tiềm ẩn trong tương lai.
5. Sử dụng AI để học, không phải để bỏ qua việc học:
Khi AI tạo ra mã bạn không hiểu, hãy yêu cầu nó giải thích.
Sử dụng nó như một công cụ giảng dạy.
Đừng để nó tạo ra khoảng trống kiến thức.
Tích hợp trong Thế giới Thực
Tình huống 1:
Triển khai tính năng mới
- Sử dụng AI để tạo cấu trúc ban đầu và mã mẫu
- Tự viết các bài kiểm tra (điều này buộc bạn phải suy nghĩ kỹ về yêu cầu)
- Tự triển khai logic nghiệp vụ cốt lõi
- Sử dụng AI để giúp xử lý lỗi, xác thực, các trường hợp biên
- Xem xét mọi thứ một cách chỉ trích trước khi commit
Tình huống 2:
Gỡ lỗi
- Cố gắng tự giải quyết trong 15 phút (sự vật lộn xây dựng sự hiểu biết)
- Nếu bị kẹt, giải thích vấn đề cho một công cụ AI với ngữ cảnh
- Đánh giá các đề xuất của nó một cách chỉ trích
- Tự triển khai giải pháp
- Hiểu tại sao nó hoạt động
Tình huống 3:
Đánh giá mã
- Tự đánh giá PR trước
- Sử dụng AI để phát hiện những điều bạn có thể đã bỏ sót (vấn đề bảo mật, trường hợp biên, vấn đề hiệu suất)
- Kết hợp thông tin chi tiết của con người và AI trong phản hồi của bạn
- Không bao giờ ủy thác phán đoán của bạn cho AI
Sự Cân bằng Xây dựng Kỹ năng
Đây là nghịch lý:
Các công cụ AI có thể khiến bạn trở nên tốt hơn và tệ hơn với tư cách là một nhà phát triển, tùy thuộc vào cách bạn sử dụng chúng.
Sử dụng AI tốt:Bạn học nhanh hơn, thấy nhiều mẫu hơn, khám phá nhiều giải pháp hơn và tập trung thời gian vào tư duy cấp cao hơn.
Sử dụng AI kém:Bạn trở nên phụ thuộc, mất các kỹ năng cơ bản, không hiểu mã của chính mình và không thể hoạt động nếu không có công cụ.
Bài kiểm tra:Bạn có thể giải quyết vấn đề mà không có AI không?
Nếu không, bạn đang quá phụ thuộc.
Hãy sử dụng AI ít hơn cho các vấn đề tương tự cho đến khi bạn nội tâm hóa mẫu đó.
Quy tắc Cá nhân của Tôi
-
AI tạo ra, tôi xác minh và tùy chỉnh:Không bao giờ triển khai mã được tạo ra mà không hiểu và sửa đổi nó.
-
Tôi viết các bài kiểm tra:Kiểm tra buộc phải hiểu.
Nếu AI viết các bài kiểm tra, có lẽ tôi đang tránh suy nghĩ kỹ về yêu cầu. -
Tôi đưa ra tất cả các quyết định kiến trúc:AI có thể đề xuất, nhưng tôi quyết định dựa trên kiến thức hệ thống mà nó không có.
-
Tôi gỡ lỗi trước:Tự cho mình 15-30 phút trước khi hỏi AI.
Sự vật lộn là nơi việc học diễn ra. -
Tôi nghi ngờ mọi thứ:AI tự tin ngay cả khi sai.
Tin tưởng, nhưng hãy xác minh.
Công cụ Đáng Thử
- GitHub Copilot:Hoàn thành mã nội tuyến.
Tuyệt vời cho mã mẫu và mẫu. - Cursor:IDE tích hợp AI.
Tốt cho các đề xuất nhận thức mã nguồn. - ChatGPT/Claude:Trợ giúp hội thoại để giải thích và gỡ lỗi.
- Tabnine:Lựa chọn thay thế cho Copilot, tập trung vào quyền riêng tư.
Chọn một.
Làm chủ nó.
Hiểu điểm mạnh và điểm yếu của nó.
Đừng thu thập sáu công cụ AI và không sử dụng tốt cái nào.
Cách tiếp cận Bảo đảm Tương lai
Các công cụ AI sẽ trở nên tốt hơn.
Chúng sẽ viết nhiều mã hơn.
Nhưng chúng sẽ không thay thế phần tư duy của phát triển phần mềm—hiểu yêu cầu, đánh đổi, thiết kế hệ thống, xem xét khả năng bảo trì và áp dụng phán đoán.
Tập trung xây dựng các kỹ năng không thể thay thế:
- Tư duy thiết kế hệ thống
- Phương pháp gỡ lỗi
- Phán đoán đánh giá mã
- Ra quyết định kiến trúc
- Kiến thức miền
- Giao tiếp và hợp tác
Đây là những kỹ năng mà công cụ AI nâng cao nhưng không thể thay thế.
Các nhà phát triển phát triển mạnh sẽ không phải là những người có thể nhắc AI tốt nhất—họ sẽ là những người sử dụng AI để di chuyển nhanh hơn trong các nhiệm vụ cơ học trong khi giữ cho phán đoán của họ sắc bén trong các nhiệm vụ chiến lược.
Sử dụng công cụ AI.
Chấp nhận chúng.
Nhưng đừng bao giờ ngừng suy nghĩ.
Sự tăng cường năng suất đến từ sự hợp tác giữa trí tuệ con người và tốc độ máy móc, không phải từ việc từ bỏ trách nhiệm cho máy móc.
Tổng hợp Tất cả Lại
Đây là điều không ai nói với bạn về năng suất:Nó không phải là làm nhiều hơn.
Mà là làm những điều đúng đắn với ít ma sát hơn.
Mọi mẹo trong bài viết này thực sự là về việc loại bỏ ma sát:
- Quy tắc Hai Terminal loại bỏ ma sát điều hướng
- Timeboxing loại bỏ ma sát quyết định
- Quy tắc 15 Phút loại bỏ ma sát bắt đầu
- Tài liệu-Trước loại bỏ ma sát thiết kế
- Quy tắc 2 Phút loại bỏ ma sát đánh giá
- Tự động hóa loại bỏ ma sát lặp lại
- Họp đứng hàng ngày loại bỏ ma sát rõ ràng
- Làm chủ IDE loại bỏ ma sát công cụ
- Xử lý theo lô loại bỏ ma sát chuyển đổi ngữ cảnh
- Công cụ AI loại bỏ ma sát mã mẫu
Năng suất không phải là làm việc chăm chỉ hơn hoặc nhanh hơn.
Mà là về việckiến trúc môi trường làm việc của bạn để những điều đúng đắn trở nên dễ dàng và những điều sai trái trở nên khó khăn.
Hãy chú ý mẫu trong tất cả các mẹo này:
Chúng không phải về kỷ luật thô hoặc ý chí.
Chúng là hệ thống.
Chúng là cấu trúc.
Chúng biến ý định tốt thành hành vi tự động.
Bạn không cần áp dụng tất cả mười mẹo vào ngày mai.
Đó là công thức cho sự choáng ngợp và từ bỏ.
Hãy chọn hai.
Những cái gây được tiếng vang nhất.
Những cái giải quyết các điểm đau lớn nhất của bạn ngay bây giờ.
Triển khai chúng.
Cho chúng hai tuần để trở thành thói quen.
Hãy chú ý điều gì thay đổi—không chỉ trong đầu ra của bạn, mà còn trong cảm giác của bạn vào cuối ngày.
Bạn có ít kiệt sức hơn?
Hài lòng hơn?
Triển khai nhất quán hơn?
Sau đó quay lại và thêm một mẹo khác.
Trong sáu tháng, bạn sẽ xây dựng được một hệ thống năng suất cá nhân có tính chất cộng dồn.
Mỗi cải tiến làm cho cái tiếp theo dễ dàng hơn.
Ma sát giảm.
Dòng chảy tăng lên.
Công việc trở nên bền vững hơn.
Đây là thách thức của tôi dành cho bạn:
Sáng mai, trước khi bạn viết một dòng mã nào:
- Viết ghi chú họp đứng hàng ngày của bạn (3 gạch đầu dòng, 5 phút)
- Thiết lập hai cửa sổ terminal nếu bạn chưa có sẵn
- Thêm một phím tắt vào trí nhớ cơ bắp của bạn
- Đặt hẹn giờ 15 phút trước khi lao vào nhiệm vụ mà bạn đang trì hoãn
Bốn hành động nhỏ.
Tổng cộng ba mươi phút.
Nhưng bạn vừa nâng cấp toàn bộ ngày làm việc của mình.
Những nhà phát triển giỏi nhất không phải là phép màu.
Họ không được ban cho khả năng tập trung siêu phàm hay gen quản lý thời gian hoàn hảo.
Họ chỉ đơn giản là đã loại bỏ một cách có hệ thống sự ma sát giữa ý định và hành động của họ.
Bạn cũng có thể làm được.
Bây giờ hãy đóng tab này, mở trình soạn thảo của bạn lên, và đi xây dựng điều gì đó tuyệt vời.
Bạn đã có những công cụ tốt hơn rồi.
Code sẽ không tự viết ra đâu—nhưng với những mẹo này, bạn sẽ ngạc nhiên về việc viết code dễ dàng hơn bao nhiêu.
Chúc bạn viết code vui vẻ.
🚀
