Lộ trình học Toán

Chào mọi người,

Giới thiệu sơ qua về mình. Mình đi làm dev được 4 năm rồi mà cảm thấy kiến thức thuật toán còn mơ hồ, chả là lúc trước mình học Aptech ra thôi nên không học toán cao cấp hay gì hết nên bây giờ thấy kiến thức như vầy thì không đi xa với nghề được. Lúc trước có làm với 1 anh chuyên toán thì thấy code người ta rất hay, chạy nhanh mà còn tối ưu (mình làm bên fintech) nên mình quyết định sẽ học toán lại từ gốc và ôn dần lên.Mong mọi người góp ý về lộ trình hay sách hoặc web nào hay thì cho mình xin nhe. À mà có góp ý gì thì cứ góp ý đừng công kích là được.

Cảm ơn mọi người

học toán 99% chả giúp cái quái gì được đâu. học phí công. cứ lên leetcode, codeforce hay tìm hiểu về competitive programming luyện não nhăn hơn.

4 Likes

Ý bác là học toán bình thường hay toán giải thuật, hình như bác vẫn đang mông lung nhỉ.

Mà bác thử xem qua những thứ em liệt kê để góp phần cho code hay này:

  • Nắm chắc các khái niệm, đặc trưng của ngôn ngữ đó và từ đó sử dụng được hết tinh hoa của ngôn ngữ lập trình đó, vì thấy bác bachjground Aptech, chỗ đó chắc học kiểu vẹt thầy gõ gì trên màn hình thì trò gõ theo thôi nhỉ (nên dạy 1 chỉ biết 1 không đào sâu được)
  • Code sạch, giang hồ hay gọi là clean code đó
  • Áp dụng các kỹ thuật lập trình như Design Patterns, S.O.L.I.D
  • Học thêm các kiểu kiến trúc hệ thống, áp dụng triết lý thiết kế của những cái không liên quan (ví dụ tư tưởng lập trình React áp dụng vào Winform (chia thành component))
  • Học hỏi tư tưởng của các Framework lập trình nổi tiếng.
  • Lập trình thật nhiều thật đa dạng, không kể việc trên công ty.

Không biết là bác đã áp dụng được mấy điều em liệt kê bên trên chưa?

4 Likes

Nếu có thể thì bạn có thể up đề bài câu giải thuật lên đây được không?

Ồ, liệt kê anagram là bài toán sinh hoán vị, độ phức tạp O(n!) lận, không biết bạn loop kiểu gì vậy :crazy_face:

Bạn có thể học các thuật toán cơ bản (toán biết cộng trừ nhân chia, đệ quy, backtracking, sorting, searching) và bắt buộc phải nắm được cách đánh giá độ phức tạp thuật toán. Không cần phải học toán như chuyên Toán đâu bạn.

1 Like

Hình như mình đang không hiểu đề bài và ý tưởng của bạn lắm, bạn có thể viết code ra được không?

Toán có nhiều loại

  • Toán sơ cấp, là toán được dạy từ bậc tiểu học đến phổ thông.
  • Toán cao cấp, là các môn dạy ở Đại học, như Đại số tuyến tính, Vi tích phân, Xác suất thống kê, Phương pháp tính,…
  • Toán hiện đại, là học để tìm hiểu các vấn đề Toán học, như: Giải tích thực, Đại số trừu tượng, Quá trình ngẫu nhiên, Lý thuyết đồ thị, Tối ưu phi tuyến, Phương trình đạo hàm riêng, …

Không biết bạn cần học toán nào?

4 Likes

Lập trình cần toán thì cũng tùy loại lập trình nữa bạn. Mình đưa ra hai ví dụ

  • Mô phỏng vết nứt trên bề mặt vật liệu: bài toán này thuộc lĩnh vực Numerical Analysis và Mathematical Physics. Hai lĩnh vực sẽ tiếp cận bài toán khác nhau. Bên Mathematical Physics sẽ quan tâm việc mô phỏng thành một phương trình đạo hàm riêng, giải nghiệm xấp xỉ bằng máy tính (đây là bước lập trình). Từ giá trị nghiệm rời rạc họ vẽ đồ thị để rút được ý nghĩa từ bài toán. Lĩnh vực Numerical Analysis cũng tìm nghiệm xấp xỉ, nhưng công việc thuần về mặt Toán học hơn, như, chứng minh sự tồn tại nghiệm, sự duy nhất nghiệm, sự ổn định cuẩ nghiệm (nếu nghiệm tồn tại), đánh giá các giải thuật có hội tụ về nghiệm chính xác hay không, nếu có hội tụ vì hội tụ nhanh hay không.

  • Vấn đề tam giác hóa các mặt phẳng trơn (mỗi điểm trên mặt phẳng đều khả vi, và đạo hàm riêng tại điểm đó liên tục), thuộc về lĩnh vực Hình học, cụ thể là Topology, khi các hình được xem xét không quan tâm đến độ dài khoảng cách giữa hai điểm thuộc hình. Cho một mặt phẳng trơn bất kỳ, tìm giải thuật để xấp xỉ mặt phẳng đó bằng hội của những hình tam giác, sao cho hai tam giác bất kỳ trong họ các tam giác, hoặc giao nhau bằng rỗng, hoặc có chung một cạnh, hoặc có chung một đỉnh. Lĩnh vực ứng dụng của bài toán này là trong việc xấp xỉ những vật thể tự nhiên, như hình dáng con người, cây cối, đồi núi, dòng sông,…

Do đó bạn cần biết bạn đang làm gì, và tập trung học chuyên ngành Toán liên quan thôi, còn học cơ bản thì không có thời gian để bạn học đâu.

2 Likes

Như những bạn khác đã comment ở trên, tớ cũng cảm thấy cậu đang bị confuse và nhầm lẫn giữa việc “giỏi toán” thì “viết code hay, chạy nhanh, tối ưu”. Nó giống như việc cậu nghe nói mấy người giàu có, thành công thường ngủ ít, và cậu ngủ ít với hi vọng thành công được như họ.

Tớ có thể thấy cậu là software developer ở lĩnh vực fintech, đang ở mức “senior” (ít nhất về mặt title). Tớ không biết cậu định tiến xa đi đâu nữa, cơ mà tớ khá chắc cậu không cần giỏi toán để có thể làm được ở lĩnh vực này. Như @hungaya đã chỉ ra, trừ khi cậu cần sử dụng toán học vì cậu cần làm những công việc khoa học, hay mô phỏng thực tế…, còn với software developer ở fintech, tớ không thấy lợi ích gì rõ rệt.

Ở buổi phỏng vấn cậu mô tả, cũng như việc mô tả anh bạn “code hay, tối ưu, chạy nhanh”, cho thấy cậu khá kém về giải thuật. Đó là điểm yếu khiến cậu đưa ra các giải pháp cài đặt thiếu hiệu quả hơn, cơ mà nó cũng không quá nghiêm trọng với ngành fintech. Cậu có thể cải thiện nó, cơ mà cá nhân tớ, học giải thuật sẽ chỉ giúp cậu:

  • Train tư duy logic. Toán, chơi cờ vua, giải câu đố… cũng là thứ làm điều tương tự với cậu.
    Nó tương tự như cậu đi nâng tạ - vốn chẳng giải quyết được việc gì - để train cơ bắp của cậu.
  • Đi phỏng vấn. Cậu cần clear vòng coding test ở rất nhiều buổi phỏng vấn.
  • Hiểu rõ hơn bản chất những công nghệ, hệ thống hoạt động ra sao ở mức độ cài đặt, khi cậu cần nghiên cứu sâu cài đặt của nó. Nếu cậu chỉ đơn thuần sử dụng công nghệ và làm trên tầng bề mặt của công nghệ, cậu chắc cũng không cần lắm về giải thuật.

Ở mức senior, tớ nghĩ cậu sẽ có xu hướng viết code ít hơn, design nhiều hơn, thậm chí đôi khi làm công việc tổ chức, lên kế hoạch, mentor và quản lý nhiều hơn. Các vấn đề cậu cần giải quyết sẽ không chỉ ở từng method/variable, hay 1 software cụ thể, mà là vấn đề ở quy mô lớn hơn. Giải thuật chắc chắn không có nhiều ích lợi khi cậu design system hay làm các việc tớ đề cập ở trên, mà những practice @lethienhoang.eth mô tả ở trên mới giúp cậu rõ rệt hơn. Thậm chí, cậu còn cần nhiều hiểu biết hơn về system design ở quy mô kiến trúc lớn hơn, để làm công việc của một senior engineer/developer.

Nếu cậu vẫn muốn bỏ thời gian quý báu của mình để học giải thuật, cậu nên cân nhắc đọc comment của @noname00. Cơ mà bỏ thời gian của cậu để học toán, thì tớ nghĩ nó khá lãng phí với vị trí của cậu (trừ khi cậu muốn đổi lĩnh vực có nhiều yếu tố khoa học, và cần nhiều toán hơn).
Bản thân tớ thấy ngay cả việc ôn giải thuật để chuyển việc đã rất mất thời gian và tương đối vô dụng rồi (đừng hiểu nhầm, tớ có kiến thức tốt về giải thuật, cơ mà để chuyển việc, tớ vẫn cần luyện tập lại trên leetcode để luyện lại khả năng viết code kiểu đó nhanh hơn).

1 Like

Mình thấy rằng bạn vẫn đang bị lệch hướng rất nhiều

  1. Việc áp dụng Design pattern không ảnh hưởng bởi Toán
    => Về các pattern , bạn làm càng nhiều , gặp vấn đề, tìm giải pháp và áp dụng pattern từng chút một, vừa làm vừa học, chứ không thể nào, áp 1 pattern cho tất cả project được.

  2. Việc các test case, edge case, corner case cũng chẳng ảnh hưởng bởi Toán
    => Bạn cũng phải làm nhiều, mường tượng được các hành vi của End user, để có được các dòng code chất lượng. Để giải quyết được các trường hợp khác.

Mình thấy bạn muốn đi xa ? Bạn muốn đạt vị trí nào trong 1-3-5-10 năm nữa? Vị trí đó cần gì ? Tìm hiểu và bạn sẽ có câu trả lời.

Chúc bạn đi xa như bạn mong muốn.

3 Likes

Lúc code logic mình thường nhìn 1, 2 ví dụ rõ ràng rồi code theo chứ chưa có tầm nhìn về tất cả case nên code xong test case mình hay bị fail.

Ý cậu là, cậu cài đặt code xong, viết unit test và thấy unit test fail? Hay cậu viết xong code, chạy unit test suite có sẵn và thấy test fail?
Cậu có thể mô tả rõ hơn được không? Có ví dụ dễ hiểu thì sẽ rất tốt :smile:

Mình không rành về giải thuật nhưng nếu 1 người giải thuật tốt thì lúc code có cái nhìn cao hơn về logic, case test sẽ tổng quát và tối ưu hơn đúng ko ?

Thực ra không phải đâu cậu :smile:
Nếu cậu nghe tới Test driven development (đó là cách lập trình viết test trước khi cài đặt), cậu sẽ thấy không nhất thiết phải có 1 cài đặt hoàn chỉnh ngay từ đầu. Với việc viết test, cài đặt, refactor code và lặp lại chu trình đó cho tới khi cậu cài đặt được toàn bộ logic, cậu sẽ có một cài đặt cuối cùng khó bị lỗi và gọn gàng nhất có thể.

Có rất nhiều logic cậu không thể có ngay phương án cài đặt hoàn chỉnh ngay từ đầu, bởi độ phức tạp của chúng. Thực ra, đa số các logic cậu sẽ rất dễ để cài đặt “happy scenario”, và rất hay miss “exception scenario”.

Về việc “case test tổng quát và tối ưu”, tớ không rõ ý cậu là gì, vì:

  • Logic mà nói, test case là thứ phải chi tiết, và cover hết các nhánh và nhiều code nhất có thể.
  • Lên kế hoạch test là công việc cần sự tổ chức và chi tiết hơn. Nếu cậu hay miss các exceptional scenario, cậu hoàn toàn có thể khắc phục nó bằng kỹ thuật cổ điển, như lập decision test table chẳng hạn.
    Việc cậu giỏi các giải thuật cơ bản chắc chắn không giúp gì nhiều cho cậu ở việc lên kế hoạch test đâu :smile:

Cậu có thể cân nhắc các phương pháp/practice tớ kể ở trên. Quan điểm cá nhân tớ vẫn là, luyện tập các phương pháp ở trên, hoặc dành thời gian phát triển các kỹ năng quan trọng khác sẽ tốt hơn luyện tập giải thuật, hay học toán, vốn không phải là giải pháp cho vấn đề của cậu.

2 Likes

Cho mình hỏi cá nhân bạn tí, nhưng không phải kiểu quy chụp cá nhân đâu.

  • Bạn có học qua bậc Đại học ngành Công nghệ thông tin không?

Tại vì mình thấy nội dung bạn viết nó kì kì. Một người qua đào tạo Đại học thì phải phân biệt đâu là Công nghệ phần mềm, đâu là Phân tích giải thuật.

2 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?