Proxy là một Internet server làm nhiệm vụ chuyển tiếp thông tin và kiểm soát tạo sự an toàn cho việc truy cập Internet của các máy khách, còn gọi là khách hàng sử dụng dịch vụ Internet. Trạm cài đặt proxy gọi là proxy server. Proxy hay trạm cài đặt proxy có địa chỉ IP và một cổng truy cập cố định. Ví dụ: 123.234.111.222:80. Địa chỉ IP của proxy trong ví dụ là 123.234.111.222 và cổng truy cập là 80.
Note lại cấu hình virtual host cho khỏi quên :D!
Hãy xem 1 cấu trúc dữ liệu được sử dụng trong code production thực tế: một “minute/hour counter”. Chúng tôi sẽ đưa ra cho bạn quá trình tự suy nghĩ tự nhiên của 1 kĩ sư có thể trải qua, đầu tiên thử giải quyết vấn đề và sao đó cải thiện hiệu năng của nó và thêm các chức năng. Quan trọng nhất, chúng ta sẽ cố gắng để code dễ đọc , sử dụng các nguyên tắc trong cuốn sách này. Chúng tôi có thể có một số lượt sai trên đường đi hoặc phạm sai lầm khác. Hãy xem nếu bạn có thể làm theo và bắt được chúng.
Trong chương này, chúng tôi sẽ chỉ cho bạn một số kĩ thuật đơn giản để viết các test sạch sẽ và hiệu quả.
Testing định nghĩa khác nhau với những người khác nhau. Trong chương này, chúng tôi sử dụng “test” có nghĩa là một vài code mà mục đích duy nhất của nó là kiểm tra hành vi của 1 phần (“real”) của code khác. Chúng tôi sẽ tập trung vào việc khía cạnh khả năng đọc của test và không nói sâu bạn nên viết test code trước khi viết code thực sự (“test-driven development”) hoặc khái cạnh về sự phát triển của test.
Trong 3 phần trước, chúng ta đã thảo luận về các phần rộng về các kĩ thuật làm cho code dễ hiểu. Trong phần này, chúng ta sẽ áp dụng các kĩ thuật đó vào 1 chủ đề được chọn.
Đầu tiên, chúng ta sẽ thảo luận về testing - làm sao viết test hiệu quả và có thể đọc được cùng 1 lúc.
Sau đó chúng ta sẽ đi quan tâm việc thiết kế và thực thi của cấu trúc dữ liệu mục đích đặc biệt (a “minute/hour counter”) để xem 1 ví dụ về hiệu năng, thiết kế tốt và tương tác với khả năng đọc code.
Biết khi nào không viết code có khả năng là kĩ năng quan trọng nhất 1 lập trình viên có thể học. Mỗi dòng code bạn viết là 1 dòng cần phải kiểm thử và bảo trì. Bằng cách sử dụng lại các thư viện hoặc loại bỏ các tính năng, bạn có thể tiết kiện thời gian và giữ codebase của bạn mỏng và có ý nghĩa.
KEY IDEA
The most readable code is no code at all.
You do not really understand something unless you can explain it to your grandmother.
— Albert Einstein
Code làm rất nhiều thứ 1 lúc rất khó hiểu. Một khối đơn của code có thể khởi tạo đối tượng mới, làm sạch dữ liệu, phân tích inputs và áp dụng logic, tất cả cùng 1 lúc. Nếu tất cả code đan xem với nhau, nó sẽ khó để hiểu hơn là mỗi “task” được bắt đầu và tự hoàn thành.
K E Y I D E A
Code should be organized so that it’s doing only one task at a time.
Nói cách khác, chương này đề cập đến vấn đề “phân mảnh” code của bạn. Theo dõi biểu đồ bên dưới để minh họa quá trình này: biểu đồ bên trái chỉ ra các đoạn mã khác nhau mà 1 phần của code đang làm và đoạn mã bên phải chỉ ra các đoạn code giống nhau sau khi nó được tổ chức làm 1 task 1 lúc.
Kĩ thuật là tất cả về việc chia nhỏ vấn đề lớn thành những vấn đề nhỏ hơn và đưa ra các giải pháp cho vấn đề đó lại với nhau. Áp dụng nguyên tắc này làm code dễ dàng đọc hơn.
Lời khuyên của chương này là chủ động xác định và trích xuất các bài toán con không liên quan. Điều đó có nghĩa:
Trong phần 2, chúng ta đã thảo luận làm sao để thay đổi “vòng lặp và logic” trong chương trình của bạn để làm code có thể đọc. Chúng ta mô tả 1 vài kỹ thuật yêu cầu thay đổi cấu trúc của chương trình theo những cách nhỏ.
Trong phần này, chúng ta sẽ bàn luận về những thay đổi lớn hay bạn có thể làm với code ở mức function. Cụ thể, chúng ta sẽ khám phá các cách tổ chức lại code của bạn:
Cuối cùng, chúng ta sẽ thảo luận cách giải quyết bạn có thể xóa hoàn toàn code và tránh viết nó trong lần đầu tiên - cách tốt nhất để làm cho code dễ hiểu.
Trong chương này, bạn sẽ thấy sẽ cẩu thả sử dụng biến trong lập trình làm khó hiểu hơn. Cụ thể, có 3 vấn đề cần tranh luận:
Một con mực khổng lồ là loài động vật tuyệt vời và thông minh nhưng thiết kế body của nó gần hoàn hảo có 1 lổ hổng chết người: nó có 1 cái não mềm dẻo (donut-shaped brain) bọc trong thực quản. Do đó nếu nó nuốt quá nhiều thức ăn trong 1 lần, não của nó sẽ hư hại.
Điều này làm chúng ta phải làm gì với code? Well, code đến từ các “chunks” cái mà quá lớn, có thể có cùng hiệu ứng. Các nghiên cứu gần đây gợi ý rằng đa số chúng ta chỉ có thể nghĩ về 3 hoặc 4 “thứ” trong cùng 1 lúc. (Ref: Cowan, N. (2001). Con số kỳ diệu 4 trong trí nhớ ngắn hạn: Xem xét lại khả năng lưu trữ của não bộ. Behavioral and Brain Sciences, 24, 97–185.). Chỉ cần đặt đơn giản, 1 biểu thức lớn hơn trong code, đã rất khó hơn để hiểu.
K E Y I D E A
Break down your giant expressions into more digestible pieces.Chia nhỏ những biểu thức khổng lồ của bạn thành những phần dễ hiểu hơn.
Nếu code của bạn không có điều kiện, vòng lặp hay một vài câu lệnh phân chia luồng (control flow statements), nó sẽ rất dễ để đọc. Những lần nhảy code, chia nhánh làm code nhanh chóng trở nên khó đọc. Trong chương này, chúng ta sẽ tìm cách để viết các đoạn mã chia luồng dễ đọc hơn
K E Y I D E A
Make all your conditionals, loops, and other changes to control flow as “natural” as possible—written in a way that doesn’t make the reader stop and reread your code.
Part II: Simplifying Loops and Logic
Trong chương 1, chúng ta đã khám phá cải thiện về mặt bề mặt (nhìn bằng mắt) - surface level - cách đơn giản để cải thiện code của bạn có thể dễ đọc hơn mà không có quá nhiều rủi ro hay nỗ lực.
Trong chương tiếp theo, chúng ta sẽ xem xét sâu hơn, thảo luận về “vòng lặp và logic” trong code của bạn: kiểm soát luồng, biểu thức logic và biến để làm code của bạn hoạt động. Như mọi khi, mục đích của chúng ta là làm cho các phần này trong code của chúng ta dễ hiểu hơn.
Chúng ta sẽ làm điều này bằng cách cố gắng tối thiểu “mental baggage” (hành vi về tinh thần) trong code của bạn. Mỗi khi bạn nhìn thấy 1 vòng lặp phức tạp, 1 biểu thức khổng lồ hoặc 1 số lượng lớn các biến, điều này thêm vào hành lý tinh thần trong đầu của bạn. (kiểu sợ luôn rồi ý =))). Nó yêu cầu bạn nghĩ nhiều hơn và nhớ nhiều hơn. Điều này thì hoàn toàn ngược lại “dễ dàng để hiểu”. Khi code của bạn có quá nhiều hành vi ảnh hưởng tinh thần, bug có nhiều khả năng không được tìm ra, code trở nên khó có thể thay đổi và chúng ta sẽ không mấy vui vẻ khi làm việc cùng nó.
Trong chương trước, chúng ta có nói về cái mà chúng ta nên comment (what). Trong chương này, sẽ nói về cách viết comment rõ ràng và gọn nhẹ
Mục đích của chương này là giúp bạn nhận ra những gì bạn nên comment. Bạn nên nghĩ mục đích của comment là “giải thích cái mà code đang thực hiện” nhưng đó chỉ là 1 phần nhỏ của nó.
Hãy nghĩ 1 chút về layouts (bố cục) của 1 tờ tạp chí - độ dài đoạn văn, chiều rộng của các cột, thứ tự của bài viết và bìa. A good magazine makes it easy to skip around from page to page, but also easy to read straight through..
Trong chương trước, chúng ta đã khám phá việc làm sao để đóng gói các thông tin vào tên của bạn. Trong chương này, chúng ta sẽ tập trung vào 1 chủ đề khác: coi chừng những cái tên có thể bị hiểu nhầm
KEY IDEAD
Chủ động xem xét các tên của bạn bằng cách hỏi chính mình “liệu có nghĩa khác có thể làm cho ai đó giải thích từ tên này”
Bất cứ khi nào bạn đang đặt tên cho 1 biến, 1 hàm hoặc 1 lớp, có rất nhiều nguyên lý giống nhau được áp dụng. Chúng tôi thích nghĩ về tên như 1 comment nhỏ. Thậm chí nó không xuất hiện ở nhiều chỗ, bạn có thể truyền tải nhiều thông tin bằng cách chọn 1 cái tên tốt.
Chúng ta sẽ nói đến vấn đề đầu tiên là cải thiện surface: chọn một cái tên tốt, viết comment tốt và format code gọn gàng. Cách thay đổi này dễ áp dụng. Bạn có thể làm nó “in place” (tại chỗ) mà không phải cấu trúc lại code hoặc thay đổi cách chương trình chạy. Nó cũng có thể cải thiện nó rất nhanh mà không cần mất nhiều thời gian :D
Chủ đề này là rất quan trọng vì chúng ảnh hưởng tới mỗi dòng code trong codebase của bạn. Mặc dù mỗi thay đổi dường như là nhỏ, tổng hợp lại, chúng sẽ tạo ra một sự cải thiện lớn vào codebase. Nếu code của bạn có 1 cái tên tốt, well-written comments và xóa được các khoảng trắng, code của bạn sẽ rất dễ để đọc.
Tất nhiên, có rất nhiều thứ hơn nữa ở dưới surface level ảnh hưởng đến khả năng đọc (và chúng tôi sẽ khám phá nó trong phần sau của cuốn sách). Nhưng những tài liệu trong phần này được áp dụng rộng rãi, không tốn nhiều công, đó là thứ đâu tiên chúng tôi muốn khám phá.
Mục lục của chương bao gồm các chủ đề:
Khoảng 5 năm trước, chúng tôi đã thu thập hàng nghìn các ví dụ về “bad code” (phần lớn là của chúng tôi) và phân tích xem cái gì đã làm nó tệ và các kĩ thuật/nguyên tắc được sử dụng để làm code tốt hơn. Cái mà chúng tôi nhận được là tất cả các nguyên tắc xuất phát từ 1 chủ đề duy nhất.
KEY IDEA
Code should be easy to understand.
Để trở nên hiệu quả trong công việc, kĩ sư phần mềm cần phải rèn giũa các kĩ năng giải quyết vấn đề của bản thân và thành thạo các ngón nghề phức tạp, yêu cầu hàng năng trời học hỏi và luyện tập. Mặc cho những người mới gia nhập nghĩ gì, thì thực tế là việc hiểu một ngôn ngữ lập trình, một framework hoặc kể cả là các giải thuật KHÔNG phải là phần khó trong việc xây dựng phầm mềm.
Chúng ta cùng xem các tham số cấu hình trong docker compose nhé.
Nhật ký cho quá trình tự xây dựng docker-compose.yml cho dự án “Hello World” Laravel.
Một vài package hữu ích được tổng hợp từ: https://codewithdre.com/useful-laravel-packages