#pragmatic-programmer
47 bài viết về chủ đề này
Pragmatic Programmer – Topic 47: Working Together — Code chung
Topic 47 Pragmatic Programmer: pair programming và mob programming — vì sao code chung lại cho kết quả tốt hơn, và làm sao để pair thật sự hiệu quả.
Pragmatic Programmer – Topic 46: Solving Impossible Puzzles — Phá bẫy
Topic 46 Pragmatic Programmer: bài toán 'bất khả thi' thường chỉ bị giới hạn bởi suy nghĩ của chính mình. Cách nhận diện ràng buộc tự đặt và phá bẫy.
Pragmatic Programmer – Topic 45: The Requirements Pit — Đào bới yêu cầu
Yêu cầu hiếm khi nằm trên bề mặt — Topic 45: đào bới yêu cầu thật, biến requirements thành hội thoại, dùng project glossary.
Pragmatic Programmer – Topic 44: Naming Things — Đặt Tên Cho Đúng
Cái tên quyết định code dễ đọc hay ác mộng. Topic 44 Pragmatic Programmer — đặt tên theo ý định, không theo cách thực hiện.
Pragmatic Programmer – Topic 43: Stay Safe Out There — Bảo Vệ Code Trước Thế Giới Bên Ngoài
Topic 43 — Stay Safe Out There: bảo vệ code của bạn khỏi thế giới bên ngoài với nguyên tắc validate input, least privilege, defense in depth, và encryption.
Pragmatic Programmer – Topic 42: Property-Based Testing — Để Framework Tự Tìm Bug Cho Bạn
Property-based testing giúp phát hiện edge case mà example-based test không bao giờ thấy — trải nghiệm với fast-check, Hypothesis và QuickCheck.
Test to Code — Nếu Không Test, Thì Code Của Bạn Không Hoạt Động (Pragmatic Programmer #41)
Testing không phải là giai đoạn riêng — nó là một phần của coding. Cảm nhận về Topic 41 từ Pragmatic Programmer.
Pragmatic Programmer – Topic 40: Refactoring — Dám đụng vào code cũ
Refactoring trong Pragmatic Programmer — cách tiếp cận code cũ như khu vườn cần chăm sóc, không phải toà nhà chỉ xây một lần
Algorithm Speed — Đừng chỉ code, hãy biết code chạy nhanh thế nào (Pragmatic Programmer #39)
Cảm nhận về Topic 39 'Algorithm Speed' trong sách The Pragmatic Programmer — Big O notation, ước lượng tốc độ thuật toán, và cách áp dụng vào thực tế coding hằng ngày.
Programming by Coincidence — Đừng để may mắn quyết định chất lượng code (Pragmatic Programmer #38)
Topic 38 từ The Pragmatic Programmer: Programming by Coincidence — lập trình dựa vào sự tình cờ, tại sao nó nguy hiểm và làm sao để lập trình một cách có chủ đích.
Listen to Your Lizard Brain — Lắng nghe trực giác khi code (Pragmatic Programmer #37)
Khám phá Topic 37: Listen to Your Lizard Brain từ The Pragmatic Programmer. Học cách lắng nghe trực giác và 'lizard brain' để code hiệu quả hơn.
Blackboards — Khi Code Nói Chuyện Qua Một Cái Bảng Đen (Pragmatic Programmer #36)
Topic 36 'Blackboards' từ 'The Pragmatic Programmer' dạy chúng ta về mô hình blackboard — nơi các module trao đổi dữ liệu ẩn danh và bất đồng bộ, giống như các thám tử cùng phá án trên một cái bảng đen.
Actors và Processes — Khi concurrency không cần shared state (Pragmatic Programmer #35)
Cảm nhận về Topic 35 'Actors and Processes' — cách xây dựng hệ thống concurrent không shared memory, không lock, không deadlock nhờ actor model.
Shared State Is Incorrect State — Trạng thái dùng chung là trạng thái sai (Pragmatic Programmer #34)
Topic 34 từ cuốn The Pragmatic Programmer: Shared State Is Incorrect State — giải thích về race condition, nonatomic updates, semaphore/mutex, và cách tránh shared state trong lập trình đồng thời.
Breaking Temporal Coupling — Phá Vỡ Sự Phụ Thuộc Theo Thời Gian (Pragmatic Programmer #33)
Cảm nhận về Topic 33 trong chương Concurrency của The Pragmatic Programmer: Temporal Coupling là gì, tại sao nó nguy hiểm và cách break nó để code linh hoạt hơn.
Topic 32. Configuration — Đừng Hard-code, Hãy Cấu Hình! (Pragmatic Programmer #32)
Một trong những bài học đắt giá nhất: tách rời code khỏi cấu hình. Học cách viết phần mềm linh hoạt, dễ thay đổi mà không cần sửa code.
Topic 31. Inheritance Tax — Đừng trả 'thuế' kế thừa nữa (Pragmatic Programmer #31)
Inheritance là coupling, và coupling là kẻ thù của sự thay đổi. Tìm hiểu 3 alternatives mạnh mẽ thay thế inheritance từ 'The Pragmatic Programmer'.
Transforming Programming — Biến Đổi Dữ Liệu Trong Code (Pragmatic Programmer #30)
Cảm nhận về Topic 30 trong The Pragmatic Programmer: cách nhìn lập trình như chuỗi transformation dữ liệu giúp code sạch và dễ maintain hơn.
Juggling the Real World — Làm sao để code chạy giữa đời thực? (Pragmatic Programmer #29)
Cảm nhận về Topic 29: Juggling the Real World - Bốn chiến lược xử lý sự kiện trong thế giới thực: Finite State Machines, Observer Pattern, Pub/Sub và Reactive Programming.
Decoupling — Tách Biệt Code Để Dễ Thay Đổi (Pragmatic Programmer #28)
Cảm nhận về Topic 28 Decoupling trong chương Bend or Break của sách The Pragmatic Programmer. Học cách viết code linh hoạt, ít phụ thuộc để dễ maintain và mở rộng.
Đừng Chạy Nhanh Hơn Tầm Nhìn Của Mình! — Don't Outrun Your Headlights (Pragmatic Programmer #27)
Pragmatic Programmer Topic 27 — Don't Outrun Your Headlights: bài học về việc chỉ nên tiến xa trong tầm nhìn của mình, lấy feedback làm tốc độ giới hạn.
Topic 26. How to Balance Resources — Cân Bằng Tài Nguyên (Pragmatic Programmer #26)
Cảm nhận về cách cân bằng tài nguyên trong lập trình từ cuốn The Pragmatic Programmer. Tip thực tế để tránh leak memory, file và các resource khác.
Topic 25. Assertive Programming — Lập trình quyết đoán (Pragmatic Programmer #25)
Assertive Programming dạy chúng ta đừng bao giờ tin vào câu 'chuyện này không bao giờ xảy ra'. Dùng assertion để ngăn chặn những điều tưởng như impossible — Tip 39 của The Pragmatic Programmer.
Dead Programs Tell No Lies — Crash Early, Don’t Trash (Pragmatic Programmer #24)
Topic 24 trong chương Pragmatic Paranoia: Tại sao chương trình chết lại tốt hơn là chương trình 'bị thương' và tiếp tục chạy? Cảm nhận của mình sau khi đọc.
Topic 23. Design by Contract — Hợp đồng trong code (Pragmatic Programmer #23)
Design by Contract (DBC) là một trong những nguyên lý quan trọng nhất của Pragmatic Programmer — giúp phân định trách nhiệm giữa các module bằng hợp đồng rõ ràng. Preconditions, Postconditions và Class Invariants là nền tảng.
Engineering Daybooks — Ghi chép hàng ngày cho lập trình viên (Pragmatic Programmer #22)
Tại sao một cuốn sổ tay và cây bút lại là công cụ mạnh mẽ nhất mà một lập trình viên có thể sở hữu? Bài học từ Topic 22 của The Pragmatic Programmer về engineering daybooks.
Text Manipulation — Đừng Viết Code Khi Có Tool Sẵn (Pragmatic Programmer #21)
Cảm nhận về Topic 21 trong The Pragmatic Programmer. Học cách tận dụng sed, awk, Perl để thao tác văn bản hiệu quả thay vì viết code thủ công.
Debugging — Tâm lý và cách tiếp cận đúng khi fix bug (Pragmatic Programmer #20)
Cảm nhận về Topic 20 Debugging trong The Pragmatic Programmer. Bình tĩnh thu thập dữ liệu, dùng debugger, và coi bug là cơ hội học hỏi.
Version Control — The Basic Tools (Pragmatic Programmer #19)
Cảm nhận về Topic 19 Version Control trong The Pragmatic Programmer. Tại sao version control là công cụ cơ bản quan trọng nhất cho dev.
Power Editing — The Pragmatic Programmer #18
Cảm nhận về Topic 18 Power Editing trong cuốn The Pragmatic Programmer. Học cách dùng editor mạnh mẽ để tăng năng suất lập trình.
🐚 Shell Games — Làm chủ terminal, làm chủ công cụ (Pragmatic Programmer #17)
Shell Games (Topic 17) trong The Pragmatic Programmer so sánh terminal với bàn làm việc của người thợ mộc. Tại sao lập trình viên cần làm chủ command line?
The Power of Plain Text — Sức mạnh của sự đơn giản (Pragmatic Programmer #16)
Topic 16 của The Pragmatic Programmer nói về plain text — thứ tưởng xưa mà hoá ra là vũ khí lợi hại nhất của lập trình viên.
Estimating — Nghệ thuật ước lượng (Pragmatic Programmer #15)
Topic 15 của The Pragmatic Programmer nói về estimating — kỹ năng ước lượng mà dev nào cũng cần rèn. Làm sao để ước lượng trung thực, không biến estimate thành commit.
Domain Languages — Ngôn ngữ của riêng bài toán mình (Pragmatic Programmer #14)
Topic 14 trong series The Pragmatic Programmer: Domain Languages — xây dựng ngôn ngữ nhỏ cho riêng bài toán, giúp code gần gũi với domain hơn và dễ maintain hơn.
Prototypes and Post-it Notes — Học hỏi, không phải để dùng lại (Pragmatic Programmer #13)
Topic 13 trong series The Pragmatic Programmer: Prototypes and Post-it Notes — một trong những topic làm mình suy nghĩ lại rất nhiều về cách mình vẫn thường làm việc. Prototype không chỉ dành cho code, mà còn có thể dùng Post-it Notes để thiết kế UI nữa cơ!
Tracer Bullets — Bắn đạn sáng để tìm đường trong đêm
Topic 12 trong series The Pragmatic Programmer: Tracer Bullets — build end-to-end nhanh, lấy feedback sớm, thay vì thiết kế hoàn hảo rồi mới code.
Reversibility — Không có quyết định nào là vĩnh viễn
Topic 11 trong series The Pragmatic Programmer nói về Reversibility — khả năng đảo ngược quyết định. Một bài học đắt giá cho bất kỳ ai làm software: không có quyết định nào là mãi mãi, hãy xây dựng hệ thống để dễ xoay hướng.
Orthogonality — Khi 'mỗi thứ lo việc của mình' là chìa khóa của code sạch
Tính trực giao (orthogonality) giúp code dễ bảo trì, dễ mở rộng và ít bug hơn. Cùng mình tìm hiểu qua góc nhìn từ cuốn The Pragmatic Programmer.
DRY — The Evils of Duplication: Khi 'đừng lặp code' bị hiểu sai
DRY không phải là đừng copy-paste code, mà là đừng lặp kiến thức. Cùng mình ôn lại một trong những nguyên lý quan trọng nhất của lập trình viên qua góc nhìn từ cuốn The Pragmatic Programmer.
Topic 8: The Essence of Good Design — Thế nào là một thiết kế tốt?
Bản chất của một thiết kế tốt là gì? The Pragmatic Programmer gói gọn trong 3 chữ: ETC — Easier to Change. Đọc xong gật gù suốt!
Communicate! — Giao tiếp cũng quan trọng như code (Pragmatic Programmer #7)
Topic 7 cuối cùng của Chapter 1: Communicate! — giao tiếp trong công việc lập trình viên. 5 nguyên tắc: biết đối tượng, chọn thời điểm, biết mình muốn nói gì, làm đẹp, và lắng nghe.
Your Knowledge Portfolio — Danh mục đầu tư tri thức (Pragmatic Programmer #6)
Tiếp tục series The Pragmatic Programmer với Topic 6: Your Knowledge Portfolio. Khám phá 5 nguyên tắc quản lý kiến thức như một danh mục đầu tư tài chính — đầu tư đều đặn, đa dạng hóa, và luôn đón đầu công nghệ mới.
Tuần 5: Good-Enough Software — Khi nào thì "đủ tốt" là đủ?
Tuần 5: Good-Enough Software — phần mềm 'đủ tốt' là gì? Khi nào thì ship, khi nào thì trau chuốt thêm?
Stone Soup và Boiled Frogs — Chuyện nấu súp với luộc ếch trong Pragmatic Programmer
Topic 4 trong The Pragmatic Programmer kể hai câu chuyện ngụ ngôn: Stone Soup dạy chủ động, Boiled Frogs dạy tỉnh táo.
🧹 Software Entropy — Tại sao "cửa sổ vỡ" lại nguy hiểm?
Cảm nhận về Topic 3: Software Entropy trong The Pragmatic Programmer — tại sao cửa sổ vỡ lại nguy hiểm với codebase của bạn?
The Pragmatic Programmer — Hành trình lập trình viên trách nhiệm
Topic 2: The Cat Ate My Source Code — Nghe cái tên hài hước vậy thôi, nhưng nội dung bên trong lại nói về một trong những phẩm chất quan trọng nhất của một lập trình viên: tinh thần trách nhiệm.
[Cảm nhận sách] The Pragmatic Programmer — Topic 1: It's Your Life
Mình bắt đầu đọc lại cuốn The Pragmatic Programmer và muốn ghi lại cảm nhận từng topic. Bài đầu tiên: It's Your Life — về tinh thần làm chủ sự nghiệp của một lập trình viên.