Lập trình + SRS

Vấn đề 1: Chúng ta quên quá nhanh

Bạn đã bao giờ dành cả tuần để học cho một kỳ thi, nhưng lại quên mất 90% những gì bạn đã học trong vòng 2 tháng và quên sạch mọi thứ trong vòng một năm chưa?

Quên làm cản trở việc học các kỹ năng đòi hỏi nhiều kiến thức như lập trình. Bạn cần ghi nhớ nhiều ngôn ngữ, giải pháp, thư viện và những "cái bẫy" nếu muốn xây dựng các ứng dụng lớn. Vì tài liệu kỹ thuật có thể quá trừu tượng và khô khan, bạn sẽ quên đặc biệt nhanh.

Quy tắc đầu tiên của Janki giúp tăng cường trí nhớ của bạn: "Mỗi khi bạn học được điều gì đó mới, hãy tạo một thẻ ghi nhớ câu hỏi và câu trả lời, và thêm thẻ này vào Anki."

Bắt đầu bằng cách tạo một bộ thẻ ghi nhớ, ví dụ như "khoa học máy tính". Một bộ thẻ chứa nhiều thẻ, và mỗi thẻ bao gồm một câu hỏi và một câu trả lời. Bạn gắn thẻ cho những thẻ này bằng các danh mục mô tả nội dung của chúng. Ví dụ, một thẻ có thể được gắn thẻ "Rails" và thẻ khác là "SQL". Mỗi thẻ có thể có nhiều thẻ, điều này hữu ích vì các công nghệ thường chồng chéo nhau.

Theo thời gian, bạn sẽ xây dựng một kho kiến thức về lập trình, được phân loại rõ ràng, dễ tìm kiếm và được sao lưu thường xuyên trên đám mây. Việc giữ một kho như thế này rất hữu ích, nhưng nó không giúp bạn giữ kiến thức trong đầu. Điều quan trọng là phải làm "Anki" của bạn.

Mỗi buổi sáng, Anki tính toán những thẻ mà bạn có nguy cơ quên và sau đó nhắc bạn xem lại những thẻ này. Việc làm "Anki" chỉ mất vài phút mỗi ngày, vì bạn chỉ cần xem lại một phần bộ thẻ của mình vào bất kỳ ngày nào.

Đối với mỗi thẻ bạn xem lại, Anki hiển thị cho bạn mặt câu hỏi, mặt câu trả lời ban đầu bị che đi. Nhiệm vụ của bạn là trả lời câu hỏi trong đầu, sau đó tiết lộ câu trả lời và kiểm tra xem bạn có trả lời đúng không. Sau khi bạn trả lời, bốn nút xuất hiện ở cuối màn hình: "lại", "tốt", "dễ" và "rất dễ". Đánh giá mức độ dễ dàng bạn có thể nhớ lại thẻ đó và sau đó nhấn nút thích hợp. Dựa trên nút bạn nhấn, Anki xác định thời điểm hiển thị thẻ đó cho bạn lần tiếp theo, vì vậy việc trả lời trung thực là rất quan trọng nếu bạn muốn thuật toán hoạt động.

Làm điều này mỗi ngày và bạn sẽ không quên.

Vấn đề 2: Chúng ta bỏ cuộc quá sớm

Hầu hết mọi người không học được lập trình vì lý do tương tự như việc họ không chơi guitar giỏi: họ bỏ cuộc quá sớm. Mặc dù họ luyện tập chăm chỉ trong vài tuần đầu tiên, nhưng họ nhanh chóng mất động lực và bỏ cuộc trước khi đạt được kết quả.

Cố gắng học theo nhịp độ hoạt động cường độ cao trong thời gian ngắn, sau đó là những khoảng dừng dài là một vấn đề. Tâm trí của bạn cần thời gian để hấp thụ những gì nó học được, vì vậy các kỹ năng học tập không thể được cô đọng vào một ngày cuối tuần. Bằng cách chấp nhận thực tế này và sử dụng phương pháp học tập nhấn mạnh nỗ lực gia tăng hàng ngày, bạn sẽ ít có khả năng bị kiệt sức và có nhiều khả năng thành công hơn.

Quy tắc thứ hai của Janki khuyến khích cam kết học tập hàng ngày:

"Bạn phải sử dụng Anki mỗi ngày - bao gồm cả ngày cuối tuần và ngày lễ - và cam kết làm như vậy vô thời hạn."

Việc làm "Anki" của bạn phải có cùng sức mạnh của thói quen như đánh răng, và bạn nên cảm thấy "hư" nếu bỏ lỡ "Anki" của mình.

Quy tắc 2 không đòi hỏi khắt khe như thoạt nhìn. Sau vài tháng luyện tập, bạn sẽ có thể làm "Anki" trong 5-8 phút. Tìm thời gian đó cũng không phải là vấn đề, vì Anki có sẵn trên điện thoại thông minh, nghĩa là bạn có thể xem lại khi đi bộ đến nơi làm việc, ngồi trên xe buýt hoặc có một phút rảnh rỗi tại văn phòng. Anki thậm chí còn đồng bộ hóa trạng thái bộ thẻ của bạn trên tất cả các thiết bị, vì vậy các thay đổi đối với bộ thẻ trên máy tính để bàn của bạn sẽ được phản ánh trên tất cả các thiết bị của bạn.

Vấn đề 3: Chúng ta học ngoài ngữ cảnh

Học ngoài ngữ cảnh là lãng phí. Đọc một cuốn sách giáo khoa từ đầu đến cuối có thể thú vị, nhưng nếu những khái niệm đó không liên quan đến các vấn đề kỹ thuật mà bạn hiện đang gặp phải, thì bạn sẽ thiếu ngữ cảnh tinh thần cần thiết để đồng hóa kiến thức đó một cách hiệu quả. Sự hiểu biết không đầy đủ và nỗ lực lãng phí sẽ xảy ra.

Quy tắc thứ ba của Janki giúp bạn tập trung vào những gì quan trọng vào thời điểm đó: "Học trong ngữ cảnh. Chọn một dự án và chỉ học những gì bạn cần để hoàn thành nó."

Khi tôi viết bài đăng trên blog này, tôi không biết cách thêm hình ảnh trong ngôn ngữ Textile.

Bước 1: Tôi đã tìm kiếm trên Google.

Bước 2: Tôi đã thử mã bằng cách thêm hình ảnh vào bài đăng.

Bước 3: Sau khi kiểm tra xem nó có hoạt động không, tôi đã thêm kỹ thuật mới của mình vào Bộ thẻ Anki.

Vấn đề 4: Chúng ta nghĩ rằng có thể học mà không thực hành

"Tôi học về tình dục theo cách khó khăn - từ một cuốn sách." Eddie Izzard

Giống như tình dục, lập trình được nắm vững tốt hơn và thú vị hơn thông qua thực hành. Học mà không thực hành cô lập bạn khỏi thực tế.

Khi bạn đọc về lập trình mà không thử mã, bạn sẽ hình thành một biểu diễn nội bộ không đầy đủ, hiểu biết kém và khó áp dụng thực tế.

Bạn sẽ không nhận thấy các chi tiết quan trọng. Nhiều điều có vẻ tầm thường khi bạn lần đầu tiên đọc về chúng trong sách giáo khoa. Có thể đó là việc đặt dấu ngoặc kép xung quanh một tham số cho một hàm, hoặc các quy tắc về vị trí cho phép khoảng trắng. Những điểm bị bỏ qua này thường có thể rất quan trọng trong thực tế, và bất kỳ điều gì ít hơn sự hiểu biết đầy đủ sẽ làm tê liệt năng suất của bạn. Chỉ bằng cách thử mã, bạn mới nhận thấy được sự khác biệt tinh tế của những quy tắc này và thực sự hiểu được ngôn ngữ, kỹ thuật và lệnh được đề cập.

Quy tắc thứ tư của Janki đặt nền tảng kiến thức vào thực tế: "Chỉ thêm thẻ vào bộ thẻ của bạn sau khi đã cố gắng sử dụng mục kiến thức trong đó."

Giả sử bạn đang làm việc trên một ứng dụng được cung cấp bởi cơ sở dữ liệu SQL. Để xây dựng nó, bạn sẽ cần tham khảo tài liệu về thiết kế cơ sở dữ liệu và SQL (một ngôn ngữ truy vấn để chọn bản ghi từ bảng cơ sở dữ liệu). Khi bạn làm việc trên ứng dụng, bạn sẽ tiếp xúc với các khái niệm mới. Hãy thử từng mẩu kiến thức mới trước khi thêm nó vào bộ thẻ Anki của bạn. Ví dụ, nếu bạn đọc về cách xóa một hàng trong bảng cơ sở dữ liệu, thì bạn nên thử xóa một hàng thực tế trong cơ sở dữ liệu của mình trước khi tạo thẻ Anki chi tiết truy vấn SQL đó.

Vấn đề 5: Chúng ta mắc nhiều sai lầm hơn mức cần thiết

Những sai lầm trong quá khứ của chúng ta đóng vai trò là công cụ hỗ trợ trí nhớ tuyệt vời. Đây là lý do chính khiến chúng ta học bằng cách làm. Điều đó nói rằng, không phải tất cả những sai lầm trong quá khứ đều có hiệu quả như nhau trong việc dạy chúng ta bài học; có một mối tương quan giữa tác động cảm xúc của một lỗi và khoảng thời gian bài học đó sẽ còn lại trong trí nhớ.

Giả sử bạn mắc một sai lầm lớn. Bạn vô tình đẩy mã chưa hoàn chỉnh lên máy chủ trực tiếp, làm ứng dụng của bạn ngừng hoạt động trong 12 giờ. Bạn hoảng loạn để sửa nó và khi những lời phàn nàn của khách hàng tràn ngập, bạn cảm thấy ngu ngốc và xấu hổ. Sự trừng phạt cảm xúc này đóng vai trò như một lời nhắc nhở mạnh mẽ về lỗi của bạn và bạn sẽ cẩn thận hơn khi đẩy mã lên máy chủ trong tương lai.

Rất may, những lỗi có tác động cảm xúc rất hiếm và bạn không có khả năng cần Phương pháp Janki để học hỏi từ những lỗi này. Nhưng còn những sai lầm còn lại mà chúng ta mắc phải thì sao, nơi yếu tố cảm xúc bị giảm bớt hoặc thậm chí không có? Chúng ta có thể cần phải mắc những sai lầm này nhiều lần trước khi cuối cùng học được bài học của mình.

Sự lặp lại sai lầm là số lần bạn cần mắc một sai lầm cụ thể trong suốt cuộc đời trước khi học được một bài học vĩnh viễn. Vì những sai lầm rất tốn kém, xấu hổ và có khả năng đe dọa sự nghiệp, nên việc giảm thiểu chúng là điều hợp lý. Sếp, khách hàng và đồng nghiệp hiểu được sai lầm lần đầu và tất cả trừ những người vô lý nhất sẽ tha thứ cho bạn. Tuy nhiên, họ sẽ không cảm thấy dễ tha thứ như vậy vào lần thứ hai hoặc thứ ba bạn mắc sai lầm tương tự.

Quy tắc thứ năm của phương pháp Janki giảm thiểu sự lặp lại sai lầm. "Mỗi khi bạn mắc sai lầm, hãy thực hiện phân tích sau sự kiện và cố gắng tìm ra những bài học từ trải nghiệm đó. Hãy suy nghĩ về những gì bạn cần biết để ngăn chặn sai lầm đó xảy ra lần nữa và biến hiểu biết sâu sắc này thành những thẻ ghi nhớ mới."

Bằng cách áp dụng quy tắc này, bạn sẽ thay thế những sai lầm trong thế giới thực bằng các lần xem lại Janki và do đó, bạn sẽ học hỏi từ những sai lầm của mình nhanh hơn và ít xấu hổ và lỗi thực tế hơn.

Việc "Anki hóa" những thất bại trong quá khứ của bạn không chỉ ngăn chặn sự lặp lại của chúng. Nó còn giúp bạn hiểu được lĩnh vực của mình, vì hành động thực hiện phân tích sau sự kiện và xem xét các nguyên nhân cơ bản của lỗi sẽ khuyến khích tư duy sâu sắc. Thay vì chỉ tạo những thẻ bạn cần để ngăn chặn lỗi cụ thể đó, bạn có thể tự miễn nhiễm với toàn bộ loại lỗi đó.

Mỗi sai lầm đều trở thành một kinh nghiệm học tập. Mắc sai lầm vẫn tệ, nhưng bạn cảm thấy một chút chiến thắng khi biết rằng bạn vừa tìm ra cách để cải thiện và bạn sẽ cảm thấy yên tâm khi chắc chắn rằng bạn sẽ không bao giờ mắc lại sai lầm đó nữa.

Vấn đề 6: Chúng ta không suy ngẫm về bức tranh toàn cảnh

Bằng cách tuân theo năm quy tắc ban đầu của Phương pháp Janki, bạn sẽ nhanh chóng thành thạo các chi tiết cấp thấp của lập trình: tên và trường hợp sử dụng của các hàm và lệnh, đầu vào và đầu ra dự kiến của chúng, giải pháp cho các lỗi phổ biến và kỹ thuật để giữ cho mã của bạn được tổ chức.

Khi kinh nghiệm của bạn tăng lên, bạn sẽ phải đối mặt với những câu hỏi lớn hơn, chẳng hạn như quyết định cấu trúc về ứng dụng của bạn, kỹ thuật để giảm thiểu độ phức tạp, quy trình làm việc để quản lý các phiên bản đồng thời của mã của bạn và sự đánh đổi giữa hiệu suất và tính thanh lịch của mã. Việc trả lời những câu hỏi này đòi hỏi kiến thức sâu sắc và kinh nghiệm đáng kể và vì lý do này, bạn không bao giờ được bỏ lỡ cơ hội để phát triển kiến thức của mình về những vấn đề bao trùm này.

Quy tắc thứ sáu của phương pháp Janki khuyến khích sự suy ngẫm quan trọng thường xuyên: "Vào cuối mỗi dự án, hãy tự hỏi bản thân những bài học bạn đã học được và những gì bạn sẽ làm khác đi nếu bạn lặp lại dự án với lợi ích của sự sáng suốt sau này."

Sau một dự án lớn, chẳng hạn như hoàn thành một ứng dụng mới, hãy dành thời gian để suy ngẫm. Hãy tự hỏi bản thân những câu hỏi lớn, chẳng hạn như:

• Tôi có lãng phí thời gian đi vào ngõ cụt nào không? Có điều gì tôi có thể làm trong tương lai để giúp tôi thấy trước những điều này và ngăn chúng xảy ra lần nữa không?
• Tôi có chọn đúng công nghệ không? Tôi có thể đưa ra một sơ đồ để giúp tôi đưa ra lựa chọn đúng đắn vào lần tới không?
• Tôi có ước tính chính xác thời gian cần thiết không?
• Tôi có thể xây dựng kiến trúc đơn giản hơn không? Tôi có thể tìm ra điều này sớm hơn không?
• Tôi có thể tạo một danh sách kiểm tra để giảm bớt việc phát triển loại tính năng đó trong tương lai không?

Một số câu hỏi này sẽ khó trả lời vì bạn phải chạy qua các phương án thay thế trong đầu, suy nghĩ về lợi ích và sự đánh đổi của từng phương án. Nỗ lực này rất đáng giá vì những quyết định kiến trúc hợp lý sẽ ngăn chặn nỗ lực lãng phí. Nếu không có sự suy ngẫm tích cực, bạn sẽ ít có khả năng nhận thấy những mô hình cấp dự án này và do đó, sự khôn ngoan của bạn sẽ phát triển chậm hơn so với lẽ ra.

Vấn đề 7: Chúng ta để biểu diễn kiến thức của mình trở nên lộn xộn

Giống như một bãi cỏ phía trước bị bỏ hoang, bộ thẻ Anki của bạn có thể trở nên xấu xí. Có lẽ một trong những ngôn ngữ lập trình bạn đã học trước đây đã thay đổi đáng kể trong phiên bản 2.0 và bây giờ một tỷ lệ phần trăm thẻ của bạn không hợp lệ. Có lẽ một số thẻ của bạn không còn xứng đáng được xem xét định kỳ nữa - tính hữu ích của chúng không biện minh cho thời gian sửa đổi tích lũy cần thiết.

Khi bạn học, bạn sẽ khám phá ra những cách đơn giản hơn để hiểu các khái niệm; nếu không cập nhật thẻ của bạn để phản ánh những mô hình được cải thiện này, bạn có nguy cơ mất những hiểu biết sâu sắc này mãi mãi. Thông thường, một nhóm thẻ có thể được thay thế bằng một thẻ duy nhất về một khái niệm bậc cao hơn.

Đôi khi, bạn sẽ thấy các liên kết giữa các thẻ trong bộ thẻ của mình. Nếu bạn ghi chú mối liên hệ giữa các thẻ này, bạn sẽ tạo nhiều đường dẫn thần kinh đến cùng một mục kiến thức. Nếu một đường dẫn bị lỗi, bạn vẫn có thể đến và kích hoạt kiến thức đó từ một tuyến đường khác. Khả năng giúp bạn ghi nhớ của bản đồ tư duy hoạt động bằng một ý tưởng tương tự. Bằng cách tìm kiếm và ghi chú những kết nối này trong bộ thẻ của bạn, bạn sẽ thêm một lớp dự phòng vào biểu diễn kiến thức của mình, giúp đảm bảo hơn nữa chống lại việc quên lãng trong tương lai.

Quy tắc thứ bảy của Janki giữ cho bộ thẻ của bạn luôn trong tình trạng tốt.

"Xóa hoặc sửa đổi bất kỳ thẻ nào không chính xác, lỗi thời, khó nhớ, không đầy đủ hoặc không cần thiết. Cập nhật các thẻ hiện có khi sự hiểu biết được cải thiện xuất hiện."

Phần sau đây cho thấy sự hiểu biết kém về Git, sau đó được cập nhật với sự hiểu biết tinh tế hơn.

Vấn đề 8: Chúng ta không tham khảo nguồn chính

Các nhà thiết kế đồ họa, nghệ sĩ, kiến trúc sư và những người sáng tạo khác giữ sổ lưu niệm các thiết kế họ thích. Sau đó, khi làm việc trên một dự án, họ lấy cảm hứng từ những sổ lưu niệm tương tự này.

Là một lập trình viên, nguồn cảm hứng chính của bạn sẽ là mã của người khác. Tải xuống các dự án mã nguồn mở (ví dụ: trên Github) và đọc mã. Tra cứu những phần bạn không hiểu và tạo thẻ mới khi cần thiết. Lấy bút và giấy và phác thảo các đường dẫn thông qua chương trình. Đầu vào là gì và đầu ra dự kiến là gì? Điều gì xảy ra với dữ liệu khi nó di chuyển qua chương trình? Tại sao nó được thiết kế theo cách này? Những kỹ thuật nào đã được sử dụng?

Bằng cách đọc mã, bạn sẽ tiếp xúc với nhiều phong cách lập trình và giải pháp cho các vấn đề lập trình. Bạn sẽ thấy những điều bạn thích và rất nhiều điều bạn không thích. Theo thời gian, bạn sẽ tìm thấy phong cách của riêng mình.

Quy tắc thứ tám của Janki khuyến khích bạn sử dụng việc đọc mã của người khác làm nguồn học tập: "Đọc mã thường xuyên. Nếu bạn gặp điều gì đó thú vị - có thể là thuật toán, một mẹo hoặc một quyết định kiến trúc - hãy tạo một thẻ chi tiết kỹ thuật và hiển thị mã."

Mục tiêu ban đầu của tôi khi sử dụng Anki để học là ngăn bản thân khỏi quên và Anki đã thực hiện lời hứa này. Điều tôi không ngờ là những lợi thế thứ yếu xuất hiện thông qua việc sử dụng hàng ngày lâu dài.

Lợi thế 1: Lập trình nhanh hơn

Biết hàng nghìn lệnh giúp tiết kiệm thời gian nếu không sẽ phải tra cứu tài liệu tham khảo. Bạn ngay lập tức nhớ lại các giải pháp trước đó khi đối mặt với một vấn đề và hàng tá khả năng nảy ra trong đầu khi thiết kế một hệ thống. Bạn sẽ đọc mã của người khác nhanh chóng, tự tin vào sự hiểu biết của mình. Sự tương đồng gần nhất là sự thông thạo một ngôn ngữ tự nhiên. Bạn sẽ nói mã.

Hầu hết thời gian tôi dành cho lập trình là gỡ lỗi, tức là sửa lỗi trong mã của bạn hoặc trong mã của các lập trình viên khác. Đây là nơi kiến thức sâu sắc về nền tảng sẽ tăng tốc cho bạn nhiều nhất. Gỡ lỗi chủ yếu bao gồm thu thập thông tin. Hệ thống được cho là làm gì? Dữ liệu nào trong hệ thống khi chúng ta thấy lỗi? Điều gì có thể đã sai? Thông thường, một dòng mã vi phạm duy nhất có thể gây ra lỗi làm sập toàn bộ trang web. Phần khó là tìm ra dòng logic nào trong số hàng nghìn dòng đã gây ra sự cố.

Hãy lấy một ví dụ. Giả sử chương trình của bạn sử dụng 100 hàm và 70 trong số đó được tích hợp sẵn trong ngôn ngữ. Điều đó có nghĩa là có 30 hàm được định nghĩa tùy chỉnh. Nếu bạn biết chắc chắn đầu vào và đầu ra của 70 hàm tích hợp sẵn, thì việc gỡ lỗi sẽ được đơn giản hóa, vì bạn sẽ chỉ cần tìm ra cách 30 hàm tùy chỉnh còn lại hoạt động. Xem xét rằng bản thân các hàm tùy chỉnh được định nghĩa theo các hàm tích hợp sẵn, nhiệm vụ này cũng không mất nhiều thời gian. Sự chắc chắn tuyệt đối về cú pháp, đầu vào, đầu ra và cách sử dụng của các hàm tích hợp sẵn cho phép bạn nhanh chóng cô lập những điều chưa biết và đưa lỗi ra bề mặt.

Khả năng động não được cải thiện thông qua Phương pháp Janki. Kiến thức sâu sắc trong tâm trí có nghĩa là bạn có thể thử các phương án thay thế trên giấy một cách nhanh chóng và do đó tăng cơ hội tìm ra một giải pháp không rõ ràng táo bạo cho vấn đề của bạn.

Bạn có thể lập luận rằng bạn sẽ nhận được sự tăng tốc tương tự với kiến thức thu được thông qua kinh nghiệm. Điều đó đúng, nhưng lập luận này bỏ qua điểm chính. Janki cho phép bạn đạt được kiến thức tương tự đó nhanh hơn và giữ lại nó lâu hơn. Nếu bạn đã từng quên cách làm điều gì đó sau khi bỏ nó sang một bên trong vài tháng, thì Anki là dành cho bạn.

Lợi thế 2: Phân nhóm

Kỹ năng trong một lĩnh vực kỹ thuật là sản phẩm của trí thông minh và kiến thức của bạn. Điểm yếu ở một bên có thể bị lu mờ bởi sức mạnh ở bên kia. Người thông minh nhưng thiếu kinh nghiệm có thể hoạt động ngang bằng với người cùn nhưng có kinh nghiệm.

Điểm này được minh họa tốt nhất bằng ví dụ. Hãy nhân 130 với 30 bằng hai phương pháp.

Phương pháp 1: Bạn biết rằng phép nhân là phép cộng lặp lại và do đó, vấn đề trở thành 130 + 130 + 130... và cứ thế tiếp tục. Áp dụng các quy tắc cộng, cuối cùng bạn sẽ đến được 3900. Hãy gọi trí thông minh là khả năng thực hiện các phép tính riêng lẻ này một cách nhanh chóng.

Phương pháp 2: Có lẽ bạn nhớ từ bảng cửu chương ở trường rằng 13 X 3 là 39. Bạn cũng có thể nhớ rằng các tính chất giao hoán và kết hợp của phép nhân cho phép bạn đơn giản hóa 130 X 30 thành 10 X 13 X 3 X 10 và cuối cùng thành 39 X 100, có thể được tính toán dễ dàng là 3900. Trí thông minh hoặc tốc độ cộng của bạn ở đây là không liên quan vì kiến thức miền cho phép bạn đơn giản hóa vấn đề một cách đáng kể.

Trong phương pháp 1, vấn đề tốn nhiều công sức vì bạn không sử dụng kiến thức để giảm bớt tính toán của mình. Điều này không xảy ra trong phương pháp 2, nơi bạn lý luận bằng cách sử dụng các khối kiến thức bậc cao hơn, do đó giải quyết một vấn đề nếu không sẽ dài dòng một cách dễ dàng. Việc áp dụng các khối kiến thức được ghi nhớ cho các vấn đề hiện tại được gọi là phân nhóm.

Nếu bạn nhớ câu trả lời cho một câu hỏi, bạn không cần phải suy luận nó vào lúc đó và do đó, tâm trí của bạn được tự do suy luận các khái niệm trừu tượng hơn. Đây là giá trị của phân nhóm.

Phương pháp Janki khuyến khích phân nhóm. Đây là một lợi ích bất ngờ, nhưng cuối cùng lại hữu ích nhất đối với tôi. Sau sáu tháng áp dụng hàng ngày, bạn sẽ lý luận về các khái niệm lập trình bằng cách sử dụng các phím tắt tinh thần tương đương với những phím tắt được sử dụng để đơn giản hóa vấn đề nhân trong phương pháp 2. Tối đa hóa phân nhóm bằng cách thêm các quy tắc và khái niệm ngày càng trừu tượng vào bộ thẻ của bạn và nỗ lực sử dụng những ý tưởng này khi giải quyết vấn đề.

Lợi thế 3: Kho lưu trữ có thể tìm kiếm của tất cả kiến thức lập trình của bạn

Máy tính của bạn đã bao giờ phun ra thông báo lỗi và mặc dù bạn nhớ đã thấy nó trước đây, nhưng bạn không nhớ cách khắc phục nó chưa? Trước khi tôi bắt đầu Phương pháp Janki, điều này sẽ xảy ra với tôi rất nhiều.

Lần đầu tiên tôi thấy vấn đề này, tôi sẽ dành nửa ngày để giải quyết vấn đề. Sáu tháng sau, vấn đề sẽ xảy ra lần nữa, có lẽ ở một dạng hơi khác. Mặc dù tôi mơ hồ nhận thức được đã thấy nó trước đây, nhưng tôi đã quên cách khắc phục nó.

Điều này cảm thấy lãng phí và tôi không thích nó. Tôi không thích phải giải quyết cùng một vấn đề hai lần. Phương pháp Janki giúp ngăn chặn điều này xảy ra.

Anki có tính năng tìm kiếm tìm tất cả các thẻ phù hợp trong bộ thẻ của bạn. Bạn thậm chí có thể lọc theo ngày hoặc thẻ. Ví dụ: bạn có thể tìm kiếm các thẻ chứa từ "ssh" được tạo cách đây hơn 6 tháng và được gắn thẻ "triển khai".

Sau khi giải quyết một lỗi, bạn nên luôn thêm một số thẻ vào bộ thẻ của mình chứa kiến thức cần thiết để ngăn chặn lỗi đó xảy ra lần nữa. Tốt hơn nữa, hãy trừu tượng hóa một cấp độ và thêm các thẻ chứa kiến thức cần thiết để ngăn chặn loại lỗi đó. Bây giờ, bất cứ khi nào bạn phải đối mặt với một lỗi lần thứ hai, tất cả những gì bạn cần làm là tìm kiếm kho lưu trữ của mình.

Lợi thế 4: Không phát minh lại bánh xe

Các ngôn ngữ lập trình hiện đại có nhiều thuật toán được tích hợp sẵn hoặc dễ dàng được bao gồm như một phần của thư viện lõi có sẵn. Điều này đặc biệt đúng với các ngôn ngữ cấp cao như Ruby và Python. Bạn muốn sắp xếp một mảng? Array#sort thực hiện thủ thuật.

Nếu bạn không biết thuật toán sắp xếp được tích hợp trong ngôn ngữ, thì bạn có thể tự viết thuật toán đó thay thế. Khi bạn làm như vậy, bạn có nguy cơ mắc sai lầm và bỏ lỡ các tối ưu hóa cấp thấp. Hơn nữa, bạn làm xa lánh người dùng tương lai của mã của mình, những người có thể nghĩ rằng có một lý do khác ngoài sự thiếu hiểu biết tại sao bạn viết một thuật toán sắp xếp tùy chỉnh thay vì sử dụng thuật toán được tích hợp trong ngôn ngữ.

Bằng cách điền vào bộ thẻ của bạn các hàm tích hợp từ các ngôn ngữ bạn đã chọn, bạn sẽ ít có khả năng vô tình triển khai các tính năng hiện có theo cách khó hiểu, nửa vời và dễ bị lỗi.

Tôi có nên tải xuống bộ thẻ của người khác không?

Anki có cơ sở dữ liệu trực tuyến có thể tìm kiếm các bộ thẻ được chia sẻ của người khác. Mặc dù không có nhiều bộ thẻ cho khoa học máy tính, nhưng bạn có thể tìm thấy một số bộ thẻ và ghép chúng lại với nhau làm cơ sở cho bộ thẻ của bạn.

Hãy cẩn thận với điều này. Bạn có thể thêm các sự kiện vào bộ thẻ của mình mà không có ích gì cho bạn và bạn có thể xem lại các sự kiện mà bạn không hiểu đầy đủ, do đó xây dựng một nền tảng kém cho kiến thức trong tương lai.

Lý tưởng nhất là bạn nên xây dựng bộ thẻ của riêng mình từ đầu, rút ra từ kinh nghiệm lập trình của bạn; việc bạn đọc mã, sách giáo khoa của người khác; xem các đoạn phim giáo dục; và xem xét các sai lầm trong quá khứ và các dự án trước đó. Bằng cách tạo bộ thẻ của bạn theo cách này, bạn giữ cho chúng chứa đầy kiến thức theo ngữ cảnh trong thế giới thực được hiểu rõ, được diễn đạt và phân loại theo cách có ý nghĩa đối với bạn.

Nếu bạn định sử dụng bộ thẻ của người khác, hãy đảm bảo bạn hiểu mọi thẻ bạn học. Hãy chắc chắn thử mã khi bạn lần đầu tiên nhìn thấy nó; điều này đòi hỏi kỷ luật nhiều hơn bạn nghĩ. Hãy chắc chắn rằng bạn tin tưởng tác giả của bộ thẻ - bạn không muốn học kiến thức không chính xác hoặc lỗi thời và đáng buồn là hầu hết các bộ thẻ có sẵn miễn phí đều rất tệ.

Một sự thay thế tốt, mà tôi muốn giới thiệu, là Execute Program của Gary Berndhart — anh ấy đã sắp xếp một cách tỉ mỉ một giáo trình SRS cho một quá trình học tập tuyệt vời.

Kiến thức nào thuộc về bộ thẻ của tôi và kiến thức nào không?

Khi tôi mới bắt đầu Phương pháp Janki, tôi đã quá nhiệt tình trong việc thêm các sự kiện vào bộ thẻ của mình. Đặc biệt, tôi đã thêm các chồng thẻ cho các thư viện mã của bên thứ ba. Điều này hóa ra là lãng phí, vì tôi hiếm khi sử dụng kiến thức này. Công nghệ phát triển nhanh chóng và các thư viện thời thượng ngày nay trở thành hành lý từ quá khứ vào ngày mai. Cuối cùng tôi đã xóa nhiều thẻ trong số này sau khi lãng phí chúng vào bộ nhớ dài hạn.

Không phải lúc nào cũng dễ dàng phân biệt giữa kiến thức đáng giữ lâu dài và kiến thức chỉ cần ngắn hạn. Để giúp tôi đưa ra quyết định, tôi đã đưa ra lược đồ này:

Chỉ nhập thẻ vào bộ thẻ của bạn nếu một trong các điều kiện sau được đáp ứng:

• a) Sự thật chứa đựng sự khôn ngoan chung về khoa học máy tính (tái cấu trúc, biểu thức chính quy, lập trình hướng đối tượng, vấn đề về bộ nhớ, v.v.).

• b) Sự thật liên quan đến một công nghệ chính đã tồn tại lâu đời và có lẽ sẽ tồn tại (Linux, Ruby, Javascript, VIM, git, HTML, CSS, SQL)

• c) Sự thật, mặc dù là một phần của thư viện có khả năng thay đổi, là thứ tôi sử dụng hàng ngày và là thứ tôi thấy trước sẽ sử dụng trong một thời gian. Điểm thưởng nếu công nghệ có nhu cầu cao, vì điều này tương đương với tỷ lệ tư vấn cao hơn. (Rails, jQuery).

13 quy tắc tạo thẻ

Tôi đã cô đọng nội dung này thành dạng gạch đầu dòng để tiết kiệm thời gian cho cả hai chúng ta. Mỗi phần nhỏ đại diện cho một nguyên tắc mà tôi đã áp dụng trong chiến lược học tập của mình, với mục tiêu tổng quát là học được càng nhiều tài liệu càng tốt trong thời gian ngắn nhất.

1. Thẻ Ảnh Chụp Màn Hình > Thẻ Văn Bản Thuần Túy.

Trong phương pháp ban đầu của mình, tôi dán các đoạn mã văn bản thuần túy vào bộ thẻ của mình. Bây giờ tôi chụp ảnh màn hình (sử dụng phím tắt) của các ví dụ mã từ các chương trình tôi mở trong trình soạn thảo văn bản, từ sách lập trình và từ các trang web như Stack Overflow. Tôi tiết kiệm thời gian, không cần phải gõ lại mã vào Anki. Tôi cũng nhận được tô sáng cú pháp miễn phí, điều này cho phép tôi đọc thẻ nhanh hơn và tăng tốc độ ôn tập.

Cho phép tôi thêm một chút trực giác khoa học không nghiêm ngặt theo phong cách Tim Ferris: Tôi tin rằng ảnh chụp nguồn gốc của dữ kiện trên thẻ ghi nhớ hỗ trợ trí nhớ trên cơ sở i) trí nhớ dựa trên vị trí mạnh hơn những loại khác; và ii) màu sắc, phông chữ và URL trang web tạo ra một ký ức phong phú hơn, độc đáo hơn so với một thẻ văn bản thông thường và do đó dễ dàng đi vào trí nhớ hơn một chút.

2. Tập Trung Vào Chức Năng Hiện Có Hơn Thông Tin Chi Tiết

Ban đầu, tôi đưa thông tin chi tiết về mọi hàm vào bộ thẻ của mình, bao gồm tên lớp, giá trị trả về và kiểu của chúng, danh sách đối số, thứ tự của chúng. Qua nhiều năm, tôi thấy rằng thông tin này trở nên khó nhớ khi bạn thêm các ngôn ngữ lập trình khác vào hỗn hợp, đặc biệt là những ngôn ngữ có tên hàm tương tự (ví dụ: each()) nhưng cách sử dụng hơi khác nhau. Việc chuyển đổi giữa các ngôn ngữ khiến tôi nhận ra rằng thông tin chi tiết như vậy mang lại lợi thế tốc độ trong ngắn hạn nhưng nhanh chóng trở nên lỗi thời. Tuy nhiên, tôi rất vui vì mình có một ngôn ngữ "mẹ đẻ" (Ruby đối với tôi) ở mức độ quen thuộc này, bởi vì điều đó có nghĩa là tôi có thể phác thảo nhanh chóng phần mềm, tập lệnh và các thủ thuật tiện ích cá nhân.

Điều quan trọng hơn cần ghi nhớ là nhận thức về những hàm dựng sẵn nào tồn tại trong một ngôn ngữ và những dịch vụ nào tồn tại trong một hệ điều hành hoặc giao thức. Tôi tạo thẻ cho các lệnh Linux khác nhau hoặc các thuộc tính window dựng sẵn hữu ích của Javascript.

Đôi khi tôi tạo ra những gì tôi gọi là "thẻ lai" kết hợp tóm tắt về chức năng của một lệnh với các chi tiết về hoạt động của nó. Để làm điều này, tôi theo sau câu trả lời cơ bản "nó là gì" bằng mô tả chuyên sâu hoặc ảnh chụp màn hình mã đang sử dụng (với các đối số và đầu ra thực tế), tương tự như cách người học ngôn ngữ cung cấp từ vựng mới bằng các câu ví dụ. Khi tôi ôn tập các thẻ, tôi tùy chọn liếc nhìn ví dụ về hàm đang sử dụng, nhưng tôi không cố gắng học thuộc lòng ví dụ này. Nếu vào một ngày sau đó, tôi tình cờ cần tính năng cụ thể đó cho một dự án, tôi có thể tách các thẻ đó ra (sử dụng chức năng "drill" của Anki) và học thông tin chi tiết hơn.

3. Thẻ Sổ Lưu Niệm

Các nhà thiết kế đồ họa giữ sổ lưu niệm các tác phẩm nghệ thuật và thiết kế mà họ ngưỡng mộ, sau đó tham khảo sổ lưu niệm của họ khi tìm kiếm cảm hứng trong các dự án tương lai. Lập trình viên cũng có thể làm điều này. Bất cứ khi nào bạn thấy một đoạn mã đặc biệt thanh lịch, hiệu quả hoặc thông minh trong một thư viện, bài đăng trên blog hoặc ghi lại một ghi chú hoặc chụp nhanh bằng ảnh chụp màn hình, sau đó đặt nó vào bộ thẻ của bạn.

Để biến ảnh chụp ví dụ mã thành cặp câu hỏi/trả lời thân thiện với Anki, tôi tạo một thẻ với một câu hỏi trước ảnh chụp màn hình, đại loại như: "Điều gì tuyệt vời về đoạn mã này?". Trong phần trả lời, tôi xác định bằng các dấu gạch đầu dòng điểm mạnh của kỹ thuật, buộc bản thân phải xác định và diễn đạt thành lời những điều tôi học được, thay vì để nó thành sự đánh giá mơ hồ không lời.

Đôi khi tôi đảo ngược quy trình này và phân tích mã tệ, tạo thẻ "Có gì sai với đoạn mã này?", một lần nữa xây dựng các quy tắc hoặc chỉ dẫn chống lại những gì là xấu. Mục tiêu cuối cùng của cả hai quy trình này là nhận thức nhanh chóng về chất lượng trong lập trình của riêng tôi.

4. Thông Tin Có Thứ Tự Không Phù Hợp Để "Ankify" Tốt

Ban đầu, tôi nghĩ rằng mọi kiến thức kỹ thuật đều có thể "ankify" tốt. Kể từ đó, tôi đã giảm bớt sự nhiệt tình và nhận thấy một ngoại lệ lớn: thông tin mà thứ tự/cấu trúc là yếu tố cần thiết. Ví dụ, tôi đã tạo rất nhiều thẻ về cách thiết lập khóa SSH trên máy chủ, một điệu nhảy phức tạp, nhiều bước giữa máy tính xách tay của bạn và máy chủ từ xa của bạn. Mặc dù tôi đã ôn tập bằng Anki, nhưng tôi không bao giờ nhớ được toàn bộ quy trình có thứ tự trong thực tế và luôn phải dùng đến hướng dẫn trực tuyến. Thời gian tôi "ankify" và ôn tập các quy tắc SSH đã bị lãng phí.

Tôi không chắc chắn về nguyên nhân chính xác của sự thất bại này. Có lẽ tôi đã tạo thẻ ghi nhớ không đúng cách cho loại thông tin này và tôi có thể đã khắc phục bằng các thẻ ghi nhớ SSH bổ sung đặt câu hỏi rõ ràng về hành động nào diễn ra trước hay sau hành động nào khác. Nhưng trực giác của tôi là việc tạo ra quá nhiều thẻ bổ sung là một sự lãng phí thời gian và tôi thà giữ và sử dụng danh sách kiểm tra hoặc sơ đồ được cập nhật về quy trình có thứ tự.

5. Đình Chỉ Công Nghệ Tạm Thời. "Drill" Khi Cần Thiết.

Tôi quyết định rằng các công nghệ ngoại vi (ngôn ngữ, thư viện, bộ tính năng và khái niệm hiếm khi được sử dụng trong công việc của tôi) không sử dụng tốt thời gian ôn tập hạn chế của tôi và sau khi tôi "ankify" tài liệu này trong bối cảnh một dự án sử dụng chúng (ví dụ: sử dụng Backbone cho một ứng dụng web năm ngoái), tôi đình chỉ việc ôn tập các thẻ đó. Nếu một dự án khác sử dụng công nghệ đó xuất hiện, tôi sử dụng chức năng "drill" của Anki để nhanh chóng ôn lại công nghệ trước khi bắt đầu. Nếu một dự án như vậy không bao giờ thành hiện thực, tôi để các thẻ bị đình chỉ vô thời hạn, có lẽ không bao giờ được sử dụng lại.

Bạn có thể chỉ ra rằng việc tạo thẻ Anki cho công nghệ ngoại vi ngay từ đầu là lãng phí, có thể đúng với bạn nhưng i) tôi thấy khó xác định công nghệ nào sẽ là ngoại vi so với công nghệ cốt lõi khi mới bắt đầu và, hơn nữa, ii) tôi thấy kỷ luật chủ động biến tài liệu kỹ thuật thành câu hỏi và câu trả lời tập trung vào việc đọc của tôi và giúp tôi thẩm vấn văn bản để tìm thông tin hữu ích nhanh hơn.

6. Giảm Cường Độ

Lý thuyết sử dụng SRS tiêu chuẩn (như P. Wozniak đề xuất) yêu cầu chúng ta ôn tập tất cả các thẻ trong bộ thẻ của mình đến hạn vào bất kỳ ngày cụ thể nào để ghi nhớ kiến thức vào trí nhớ dài hạn với hiệu quả cao nhất có thể. Tôi đã thử điều này trong khoảng hai năm nhưng cuối cùng tôi thấy gánh nặng ôn tập quá lớn. Để chống lại điều này, tôi giới hạn số lượng ôn tập tối đa trong bộ thẻ lập trình của mình xuống 40 thẻ mỗi ngày và sửa đổi cài đặt bộ thẻ trong Anki để tăng "easy bonus" (thêm thời gian giữa các thẻ bạn đánh dấu là dễ) và "interval modifier" (thời gian giữa các lần ôn tập bất kỳ thẻ nào). Hiệu ứng của tùy chọn "ease-spacing" là hiển thị các thẻ dễ ít thường xuyên hơn (chúng không đặt ra thách thức liên tục cho tôi, thường là nền tảng trong các khái niệm nâng cao hơn trong bộ thẻ của tôi, vì vậy sự đánh đổi là hợp lý), trong khi "interval modifier" điều chỉnh thuật toán để giãn cách tất cả các thẻ xa nhau hơn bất kể độ khó, có nghĩa là nhiều ngày hơn giữa mỗi lần ôn tập và do đó ít ôn tập hơn vào bất kỳ buổi sáng cụ thể nào.

Cái giá tôi phải trả cho thời gian ôn tập giảm đi này là tôi có thể không ôn tập theo "đường cong quên lãng", có nghĩa là một chiến lược học tập không hiệu quả trên toàn cầu. Tôi ổn với điều này vì tôi nhận ra rằng các ngôn ngữ lập trình đến rồi đi và tôi nhận ra rằng tôi có thể không còn lập trình trong 10 năm nữa, mục tiêu chính của tôi là lập trình nhanh nhất có thể ngay hôm nay như tôi có thể tự đào tạo bản thân. Bên cạnh đó, giảm hiệu quả là một cái giá hợp lý phải trả nếu nó đảm bảo bạn gắn bó với thói quen ôn tập, thực hiện một chức năng tương tự như những ngày "cheat day" trong chế độ ăn kiêng giảm cân khó khăn.

7. Đánh Số Khi Đọc

Bất cứ khi nào tôi đọc một cuốn sách giáo khoa lập trình in, tôi đặt một số (1, 2, 3...) vào lề bên cạnh bất kỳ điểm nào tôi muốn ghi nhớ vào Anki sau này, cùng với một lời nhắc ngắn gọn, ví dụ: "hiệu quả hệ thống tệp". Sau khi đọc xong cuốn sách, tôi quét qua lại nó, thêm một thẻ vào Anki cho mỗi điểm được đánh số mà tôi tiếp tục nhận thấy là đáng nhớ.

Lý do tôi làm điều này là i) không làm gián đoạn dòng chảy đọc bằng cách cúi xuống máy tính xách tay của mình và "ankify" từng điểm tôi gặp phải, do đó tiết kiệm thời gian bằng cách thực hiện theo lô và ii) để giải thích cách các tác giả sách giáo khoa đôi khi giải thích một điểm rõ ràng hơn trong các chương sau và chỉ sử dụng cách giải thích tốt nhất trong bộ thẻ ghi nhớ của tôi.

8. Nhấn Mạnh Các "Meme" Bất Biến Ngôn Ngữ

Khi tôi học các ngôn ngữ và thư viện lập trình, tôi nhận ra rằng một phần giá trị của việc áp dụng phương pháp Janki trong ngôn ngữ lập trình đầu tiên của tôi, Ruby, là học được các "meme" lặp lại trong các ngôn ngữ khác. Ví dụ: các phương thức "functional" trong module Enumerable của Ruby, chẳng hạn như each(), map(), select(), reject() và zip() lặp lại dưới tên tương tự hoặc tương tự trong Javascript, Lisp, Python và các thư viện khác nhau (chẳng hạn như thư viện Underscore của Javascript). Việc biết ý nghĩa của các hàm này và cách sử dụng chúng, giúp giảm thời gian cần thiết để học một môi trường mới. Tương tự, việc học chi tiết về cách Linux tương tác với các tệp đã làm sáng tỏ các phương thức tương tác File/IO trong Ruby, C và Python.

Tôi không có cách nào hoàn hảo để phân biệt các "meme" bất biến ngôn ngữ với các ý tưởng "chỉ ngôn ngữ này", ngoại trừ một vài quy tắc ngón tay cái sơ bộ. Các ví dụ về mã thanh lịch hoặc mã xấu (chẳng hạn như magic number) thường có điểm tương đồng trong các môi trường khác (hoặc, nếu chưa tương đồng, thì thực hành có thể được thụ phấn chéo một cách hiệu quả); các hàm tương tác với Hệ điều hành cơ bản (luồng, IO), miễn là chúng vẫn chưa được trừu tượng hóa, sẽ sử dụng lại các khái niệm tương tự như các ngôn ngữ khác chạy trên các hệ thống tương tự (Linux, Android, iOS, Windows); nhiều ngôn ngữ chia sẻ các ý tưởng regex giống nhau (mặc dù đáng tiếc là tồn tại nhiều cú pháp); các khái niệm như toán học nhị phân, mã hóa chuỗi, tối ưu hóa hiệu suất, gỡ lỗi và lập trình hướng đối tượng vẫn mạnh mẽ vượt qua các rào cản ngôn ngữ.

9. Thực Thi Mã Cho Bản Thân Sau Khi Thất Bại Lặp Lại

Khi tôi nhận thấy rằng mình đã thất bại một thẻ nhiều lần, tôi kiểm tra mã đó trong bảng điều khiển hoặc thực hiện tương đương của nó (ví dụ: đối với các lệnh Vim, tôi nhấn phím tắt vào Vim). Tôi làm điều này ít nhất hai lần liên tiếp. Điều này giúp ngón tay của tôi học lệnh, chứng minh cho tôi thấy rằng mã hoạt động và mang lại cho tôi sự hiểu biết theo ngữ cảnh, hiệu quả của tất cả những điều này là tôi có nhiều khả năng nhớ nó hơn vào lần tới.

10. Động Não Các Cách Sử Dụng Thẻ. Hoặc Xóa Nó.

Khi tôi ôn tập các thẻ về các tính năng lập trình mà tôi chưa bao giờ sử dụng, tôi tự hỏi: Tính năng này có khả năng ứng dụng thực tế kém hay lỗi là do tôi không nỗ lực đủ để tìm ra các trường hợp sử dụng? Để trả lời, tôi động não các cách sử dụng tính năng này trong các dự án hiện tại của mình, ngay cả khi đó là một cách sử dụng lố bịch. Thực hành này rèn luyện cho tôi việc áp dụng kiến thức của mình và, trong những trường hợp tôi không thể nghĩ ra bất kỳ cách sử dụng tốt nào, tôi thừa nhận thất bại và cắt tỉa bộ thẻ của mình bằng cách xóa thẻ.

11. In Đậm Điểm Chính

Bạn sẽ luôn muốn thực hiện các biện pháp để giảm thời gian bạn dành cho việc ôn tập bộ thẻ của mình. Một giải pháp đơn giản, hiệu quả là in đậm từ khóa hoặc điểm chính trong câu hỏi hoặc câu trả lời hoặc cả hai. Kỹ thuật này đặc biệt hữu ích khi bạn có một số thẻ ghi nhớ đề cập đến các điểm tương tự, ví dụ: giải thích các ngoại lệ khác nhau trong một không gian tên hoặc lớp duy nhất. Do nhiều năm quét văn bản trực tuyến, đôi mắt của bạn đã thích nghi cao độ với việc nhìn thấy văn bản in đậm một cách rõ ràng và tôi đã phát hiện ra rằng chỉ cần nhìn thấy phông chữ in đậm trong thẻ Anki của bạn là đủ để kích thích trí nhớ của bạn và đưa ra câu trả lời cần thiết, giúp bạn tiết kiệm thời gian mà bạn cần để đọc toàn bộ thẻ. Kích hoạt trí nhớ càng nhanh càng tốt trong các lần ôn tập của bạn sau đó tiếp tục.

12. Thẻ "Best Practice" (Thực Hành Tốt Nhất)

Bất cứ khi nào tôi học được về một "best practice", cho dù đó là thông qua việc làm việc cặp đôi với một lập trình viên giỏi hơn, xem một video Play-by-Play hay đọc một bình luận trên Github, tôi đều biến ý tưởng đó thành một thẻ. Không có gì đáng ngạc nhiên cho đến nay. Khi tôi ôn tập các thẻ "best practice" của mình, tôi áp dụng một cách tiếp cận khác với các thẻ thông tin thông thường ở chỗ tôi "thất bại" thẻ nếu gần đây tôi chưa triển khai thực hành đó trong quy trình làm việc của mình. Không giống như trong các thẻ thông tin thuần túy, việc tôi nhớ sự tồn tại của "best practice" là không liên quan; mục tiêu của thẻ "best practice" là để tôi áp dụng thực hành đó, và cảm giác tội lỗi khi liên tục thất bại sẽ thúc đẩy tôi đi đúng hướng.

13. Thẻ Câu Đố và Giải Thích

Đôi khi bạn không chỉ muốn học các sự kiện mà bạn cần học một kỹ thuật, phương pháp luận hoặc thuật toán tinh thần thay thế. Vì những mục đích này (ví dụ: học phép nhân toán học nhị phân), tôi đã tạo các thẻ có câu đố trong câu hỏi và giải pháp của nó trong câu trả lời. Bất cứ khi nào tôi ôn tập các thẻ này, tôi cố gắng giải câu đố ngay tại chỗ và đánh dấu thẻ là "thất bại" nếu tôi nhận được giải pháp sai. Tôi thấy cần thiết phải bao gồm một lời giải thích về cách tôi tìm ra giải pháp (tức là phương pháp luận) trong thẻ trả lời, để tôi có thể tự nhắc nhở mình cách thực hiện nếu tôi đưa ra giải pháp sai.

Một biến thể liên quan là nơi tôi tạo thẻ với câu trả lời cho các lỗi/lệnh chỉ xảy ra một lần nhưng có giải thích chuyên sâu về lệnh được đề cập.