12/08/2018, 13:56

The Learn

Mọi người vẫn thường hay nói, một nhà phát triển phần mềm chuyên nghiệp thường không bao giờ ngừng học hỏi. Cuốn sách Pragmatic Programmer có nói về việc này bằng những cách khác nhau như sau: Mỗi năm nên tìm hiểu ít nhất một ngôn ngữ mới. Mỗi quý nên đọc một cuốn sách về kĩ thuật. Mỗi quý ...

Mọi người vẫn thường hay nói, một nhà phát triển phần mềm chuyên nghiệp thường không bao giờ ngừng học hỏi.

Cuốn sách Pragmatic Programmer có nói về việc này bằng những cách khác nhau như sau:

  • Mỗi năm nên tìm hiểu ít nhất một ngôn ngữ mới.
  • Mỗi quý nên đọc một cuốn sách về kĩ thuật.
  • Mỗi quý cũng nên đọc một cuốn sách không phải về kĩ thuật.
  • Tham gia vào các khóa học.
  • Tham gia vào các local groups.
  • Thử nghiệm với các môi trường khác nhau.
  • Ở hiện tại.
  • Kết nỗi tới các nguồn khác nhau (như blogs, Hack News,...)

Tất cả các ý tưởng đó đều tốt. Nhưng, chúng ta có nhất thiết phải học một ngôn ngữ mới mỗi năm, nếu không có gì đạt được?

Vâng, tất nhiên. Bạn nên học ít nhất một ngôn ngữ mới mỗi năm. Và nếu như bạn làm vậy, bạn sẽ dần dân nhận ra rằng ngôn ngữ bắt đầu trở nên lặp đi lặp lại. Ví dụ nếu như bạn học Lua, bạn sẽ nhận ra thực sự nó cũng như Javascript (hoặc ngược lại). Bạn học Ruby và bạn nhận ra rằng nó thực sự chỉ là Python trong vỏ bọc khác. Bạn học Swift và nhận ra rằng nó chỉ là một rehash của Java với ngụ ý mạnh mẽ của Pascal với một số bang(!) được ném vào. Bạn sẽ học GO và nhận ra rằng nó là một hỗn hợp của C, Java, và Erlang.

Bạn sẽ bắt đầu thấy các mô hình đằng sau tất cả các thứ tiếng, và nhận ra rằng những mô hình tương đối ít về số lượng. Và rất khó để có thể tái tổ hợp chúng. Chính vì vậy, tìm hiểu ít nhất một ngôn ngữ mới mỗi năm bạn có thể đến với sự hiểu biết rằng chúng ta đã khám phá khá tốt về miền ngôn ngữ.

Điều này cũng đúng đối với frameworks. Tìm hiểu một cái mới mỗi năm hoặc lâu hơn. Và khi bạn làm, bạn sẽ đến với nhận thức rằng không ai trong số các frameworks mới thực sự là mới trong bất kì ý nghĩa nào. Nó hoàn toàn giống như việc học một ngôn ngữ mới vậy.

Đây có phải là một quan điểm buồn? Nó không nên là vậy. Thực tế chúng tôi đã khám phá ra một khía cạnh nhỏ không có nghĩa là không có những thứ khác để khám phá và học hỏi. Danh sách những thứ cần học hỏi và cải tiến là rất lớn.

Ví dụ, chúng ta hãy nói về concurrency (đồng thời). Đây là một cái gì đó mà chúng ta bị hút lại. Nó không giống như chúng ta học một ngôn ngữ mới, nhưng nó đi sâu hơn được hiểu như là nền tảng xử lý ứng dụng của chúng ta như là multi-processor platforms, configurations, và deployments.

Đây, tôi sẽ kiểm tra kiến thức của bạn một chút:

  • Bạn có biết vấn đề của Dining Philosopher's (bài toán năm triết gia) và nó dạy bạn những gì?
  • Bạn có thể định nghĩa một deadlock và mô tả làm sao để tránh nó?
  • Bạn có quen thuộc với việc từ lúc chạy cho đến lúc hoàn thành threads?
  • Bạn có bao giờ viết một bộ đệm tròn để giao tiếp giữa interrupt head và background app?
  • Bạn biết những gì về semaphore, ai là người phát minh ra nó và tại sao?
  • Bạn có biết lý do đằng sau việc double-checked locking?

Nếu bạn không thể trả lời các câu hỏi kia một cách thành thạo (sau khi bạn đã googling) thì bạn đã có thêm những kinh nghiệm về việc khai thác thông tin bổ ích phía trước, hãy tận dụng những ưu điểm của chúng.

Hoặc là các protocols giao tiếp với nhau như thế nào? Bạn có đang có đủ thông tin về lĩnh vực này? Bạn có biết đến domain?

  • Bạn có hiểu thế nào là kết nối không đáng tin cậy để truyền những thông điệp tin cậy?
  • Bạn có biết thế nào là một giao thức cửa sổ trượt (sliding window protocol)?
  • Một CRC nó như thế nào?
  • Tại sao collision detection (phát hiện va chạm) lại quan trọng với Ethernet?
  • Exponential backoff là gì?
  • Mô hình OSI có 7 tầng, chúng là gì và tại sao lại quan trọng?
  • Sự khác biệt giưã BPS và BAUD?

Hay là một số chủ đề kinh điển trong ngày công nghệ bạn đã đọc và hiểu (một vài trong số đó);

  • The Art of Computer Programming: Knuth
  • Computer Networks: Tanenbaum
  • The Structure and Interpretation of Computer Programs: Abelson and Sussman
  • Structured Analysis and System Specification: DeMarco
  • Design Patterns: Gamma, Helm, Johnson, Vlissides
  • Analysis Patterns: Fowler
  • Structured Programming: Dijkstra, Dahl, Hoare
  • Object Oriented Software Construction: Meyer

Bạn có hiểu sự khác nhau giữa discrete event simulation (mô phỏng sự kiện rời rạc) và continuous simulation (mô phỏng liên tục). Khi nào bạn sẽ sử dụng chúng?

Bạn có sử dụng thành thạo các thuật toán đồ thị? Làm thế nào để bạn có thể tìm được con đường ngắn nhất giữa 2 thị trấn?

Định lý DeMorgan's là gì, và tại sao nó lại hữu ích cho bạn?

Sự khác nhau giữa một máy Mealy và một máy Moore?

Bạn đã từng viết một thuật toán di truyền? Bạn đã từng làm việc với một mạng lưới thần kinh? Bạn biết gì về Big Data. Bạn đã từng viết về một trình điều khiển IO? Bạn đã từng viết một hệ thống tập tin? Bạn đã từng viết về một trình biên dịch?

Sau tất cả chúng đều được định nghĩa dưới dạng một ngôn ngữ. Bạn đã học một trong số những thứ quan trọng đó? Bạn đã học Fortran, Cobol, Snobol, Forth, Libs hay Prolog hoặc C?

Vì vậy câu trả lời cuối cùng là nên học một ngôn ngữ mới mỗi năm. Và có lẽ nó là mới đối với bạn nhưng mà là cũ đối với profession của chúng ta, trong khi bạn học ngôn ngữ mới bạn có thể áp dụng học một số chủ để đã được liệt kê ở bên trên nó rất hữu ích cho các bạn có thể hiểu được ngôn ngữ hơn và áp dụng được sâu bên trong mỗi ngôn ngữ mà bạn theo học.

0