thảo luận Thoát kiếm thợ gõ v2

Asher123

Senior Member
Đào lại vì đang gặp hoàn cảnh tương tự, tay ngang đi học làm lập trình, làm cũng được gần 2 năm rồi mà cảm thấy bản thân không khác thợ gõ.
Vấn đề là nếu bắt đầu dự án từ đầu(không có gì hết) thì em lại không biết bắt đầu từ đâu. Vd: trước giờ chỉ biết copy cách thức bố trí như vậy chứ chẳng hiểu nguyên lý gì đằng sau là gì, mỗi thứ nếu hỏi đến kiểu yes no hay nên chọn này hay kia thì mình trả lời được, còn đưa ra những phương án nào thì không biết làm

Hiện tại em em gặp vấn đề sau, các bác chỉ giúp em với, tài liệu học và thực hành chỗ nào cũng được
  • Nguyên lý nào để quyết định cấu trúc ban đầu của một dự án ?
  • Dựa vào đâu để xây dựng tiêu chí cho solution
  • Nguyên lý nào để mình quyết định code nên mix lại hay phân ra ?

Vậy giờ làm gì tiếp hở các bác ? tiếp tục cầy giải toán leetcode hay sao bác ? nhưng giải leetcode thì đâu giúp em giải quyết được những câu hỏi trên ?
 
mới 2 năm mà đã đòi lên lv đó hả bạn, cứ làm đi tầm chục năm nữa thì hiểu được
chục năng nữa hiểu nhưng chưa chắc nó cho đụng vào mấy system củ :> , khiểu cái gì nó ổn định thì kệ cmn, nhiều chú backend vô là đòi đập đi xây lại rồi xây ko xong lại ra 1 đóng shit rồi nghĩ cty. Cái hiện tượng này dạo này thấy cũng đông :>
 
Đào lại vì đang gặp hoàn cảnh tương tự, tay ngang đi học làm lập trình, làm cũng được gần 2 năm rồi mà cảm thấy bản thân không khác thợ gõ.
Vấn đề là nếu bắt đầu dự án từ đầu(không có gì hết) thì em lại không biết bắt đầu từ đâu. Vd: trước giờ chỉ biết copy cách thức bố trí như vậy chứ chẳng hiểu nguyên lý gì đằng sau là gì, mỗi thứ nếu hỏi đến kiểu yes no hay nên chọn này hay kia thì mình trả lời được, còn đưa ra những phương án nào thì không biết làm

Hiện tại em em gặp vấn đề sau, các bác chỉ giúp em với, tài liệu học và thực hành chỗ nào cũng được
  • Nguyên lý nào để quyết định cấu trúc ban đầu của một dự án ?
  • Dựa vào đâu để xây dựng tiêu chí cho solution
  • Nguyên lý nào để mình quyết định code nên mix lại hay phân ra ?

Vậy giờ làm gì tiếp hở các bác ? tiếp tục cầy giải toán leetcode hay sao bác ? nhưng giải leetcode thì đâu giúp em giải quyết được những câu hỏi trên ?
Leetcode chủ yếu để rèn cho bạn khả năng tư duy thuật toán, các cấu trúc dữ liệu, cách code cơ bản thôi
Còn muốn học những cái trên thì phải tìm hiểu thêm về System Design, Design Pattern. Cái này bên Mẽo bọn nó tìm hiểu từ khi học ĐH rồi chứ không cần phải đi làm 10 năm mới phải biết.
Những tài liệu về System Design nên tham khảo
  • Designing Data-Intensive Applications - Martin Kleppman (Kinh thánh về System Design - Must Read)
  • System Design Interview - Alex Xu (Volume 1 + Volume 2)
  • Khoá Grokking the System Design Interview của Educative
  • Engineering blog của các công ty product lớn
Một số repo trên github về System Design
Tài liệu về Design Pattern
Có thể tham khảo thêm quyển High Performance MySQL về SQL Database

Với những kiến thức này, bạn có thể đưa ra được solution cho những bài toán cơ bản, ví dụ
  • Nên chọn REST hay gRPC ?
  • Nên chọn thuật toán Load Balancing nào ?
  • Nên chọn SQL hay NoSQL ?
  • Thiết kế DB như nào. Khi nào cần Normalization và khi nào thì nên Denormalization ?
  • Nên index như nào cho table ?
  • Nên thiết kế caching và Message Queue như nào ?
  • Nên cấu trúc code như nào, khi nào thì cần dùng Decorator, Observer, Factory,... Pattern?
....

Sau đó thì tiếp tục học tập và làm việc lấy kinh nghiệm để có thể giải quyết được những bài toán phức tạp hơn.
 
Leetcode chủ yếu để rèn cho bạn khả năng tư duy thuật toán, các cấu trúc dữ liệu, cách code cơ bản thôi
Còn muốn học những cái trên thì phải tìm hiểu thêm về System Design, Design Pattern. Cái này bên Mẽo bọn nó tìm hiểu từ khi học ĐH rồi chứ không cần phải đi làm 10 năm mới phải biết.
Những tài liệu về System Design nên tham khảo
  • Designing Data-Intensive Applications - Martin Kleppman (Kinh thánh về System Design - Must Read)
  • System Design Interview - Alex Xu (Volume 1 + Volume 2)
  • Khoá Grokking the System Design Interview của Educative
  • Engineering blog của các công ty product lớn
Một số repo trên github về System Design
Tài liệu về Design Pattern
Có thể tham khảo thêm quyển High Performance MySQL về SQL Database

Với những kiến thức này, bạn có thể đưa ra được solution cho những bài toán cơ bản, ví dụ
  • Nên chọn REST hay gRPC ?
  • Nên chọn thuật toán Load Balancing nào ?
  • Nên chọn SQL hay NoSQL ?
  • Thiết kế DB như nào. Khi nào cần Normalization và khi nào thì nên Denormalization ?
  • Nên index như nào cho table ?
  • Nên thiết kế caching và Message Queue như nào ?
  • Nên cấu trúc code như nào, khi nào thì cần dùng Decorator, Observer, Factory,... Pattern?
....

Sau đó thì tiếp tục học tập và làm việc lấy kinh nghiệm để có thể giải quyết được những bài toán phức tạp hơn.
Cảm ơn bác nhiều, mà mấy cái này chỉ đọc thì liệu có nắm đc ko bác ?
 
Hiện tại em em gặp vấn đề sau, các bác chỉ giúp em với, tài liệu học và thực hành chỗ nào cũng được
  • Nguyên lý nào để quyết định cấu trúc ban đầu của một dự án ?
  • Dựa vào đâu để xây dựng tiêu chí cho solution
  • Nguyên lý nào để mình quyết định code nên mix lại hay phân ra ?

Leetcode chỉ cày để đi phỏng vấn thôi, kiểu như ôn thi đại học, còn thực tế không dùng nhiều lắm đâu (mặc dù sau khi ôn leetcode mình thấy nó giúp dễ nhìn ra corner cases khi code hơn).

Mấy cái bạn nói nó liên quan đến kiến trúc phần mềm. Mục tiêu của mọi quyết định trong thiết kế phần mềm là để thỏa mãn functional requirements và non functional requirements (maintainability, security, durability, testability...). Từ những yêu cầu đó người ta phát hiện ra có một số nguyên lý thiết kế (principles) hữu ích trong phát triển phần mềm (KISS; high cohesion, low coupling, dependency inversions, abstractions...) và từ những principles đó họ phát hiện ra một số patterns để giải quyết các yêu cầu trên.

Tóm lại là từ yêu cầu -> principles -> patterns. Để hiểu được quy trình và kiến thức cơ bản trong kiến trúc phần mềm bạn có thể đọc cuốn Clean Architecture của Uncle Bob, Fundamentals of Software Architecture: An Engineering Approach của Mark Richards et al. Nếu bạn làm backend có thể đọc thêm cuốn Patterns of Enterprise Applications của Martin Fowler để biết mấy patterns như DAO, repository, active record, controller, ORM, layers pattern nó xuất hiện từ đâu ra.
 
Leetcode chỉ cày để đi phỏng vấn thôi, kiểu như ôn thi đại học, còn thực tế không dùng nhiều lắm đâu (mặc dù sau khi ôn leetcode mình thấy nó giúp dễ nhìn ra corner cases khi code hơn).

Mấy cái bạn nói nó liên quan đến kiến trúc phần mềm. Mục tiêu của mọi quyết định trong thiết kế phần mềm là để thỏa mãn functional requirements và non functional requirements (maintainability, security, durability, testability...). Từ những yêu cầu đó người ta phát hiện ra có một số nguyên lý thiết kế (principles) hữu ích trong phát triển phần mềm (KISS; high cohesion, low coupling, dependency inversions, abstractions...) và từ những principles đó họ phát hiện ra một số patterns để giải quyết các yêu cầu trên.

Tóm lại là từ yêu cầu -> principles -> patterns. Để hiểu được quy trình và kiến thức cơ bản trong kiến trúc phần mềm bạn có thể đọc cuốn Clean Architecture của Uncle Bob, Fundamentals of Software Architecture: An Engineering Approach của Mark Richards et al. Nếu bạn làm backend có thể đọc thêm cuốn Patterns of Enterprise Applications của Martin Fowler để biết mấy patterns như DAO, repository, active record, controller, ORM, layers pattern nó xuất hiện từ đâu ra.
Bác chẩn chắc đúng bệnh của em nầy, mà cứ đọc vậy thôi hở bác ?
 
Leetcode chủ yếu để rèn cho bạn khả năng tư duy thuật toán, các cấu trúc dữ liệu, cách code cơ bản thôi
Còn muốn học những cái trên thì phải tìm hiểu thêm về System Design, Design Pattern. Cái này bên Mẽo bọn nó tìm hiểu từ khi học ĐH rồi chứ không cần phải đi làm 10 năm mới phải biết.
Những tài liệu về System Design nên tham khảo
  • Designing Data-Intensive Applications - Martin Kleppman (Kinh thánh về System Design - Must Read)
  • System Design Interview - Alex Xu (Volume 1 + Volume 2)
  • Khoá Grokking the System Design Interview của Educative
  • Engineering blog của các công ty product lớn
Một số repo trên github về System Design
Tài liệu về Design Pattern
Có thể tham khảo thêm quyển High Performance MySQL về SQL Database

Với những kiến thức này, bạn có thể đưa ra được solution cho những bài toán cơ bản, ví dụ
  • Nên chọn REST hay gRPC ?
  • Nên chọn thuật toán Load Balancing nào ?
  • Nên chọn SQL hay NoSQL ?
  • Thiết kế DB như nào. Khi nào cần Normalization và khi nào thì nên Denormalization ?
  • Nên index như nào cho table ?
  • Nên thiết kế caching và Message Queue như nào ?
  • Nên cấu trúc code như nào, khi nào thì cần dùng Decorator, Observer, Factory,... Pattern?
....

Sau đó thì tiếp tục học tập và làm việc lấy kinh nghiệm để có thể giải quyết được những bài toán phức tạp hơn.
học theo fen này nè. Mà cho hỏi fen bn năm kinh nghiệm rồi ha, list được như này thì cứng phết đấy
 
Bác chẩn chắc đúng bệnh của em nầy, mà cứ đọc vậy thôi hở bác ?
Nếu được thì bác đọc code/documents của framework bác đang dùng để thấy cách họ áp dụng mấy mẫu thiết kế. Bác đang làm backend hay frontend?
 
Thường mình thấy developers dễ bị dính vào chỉ học mấy cái patterns/practices mà không hiểu principles với tư duy, mục tiêu thiết kế, dễ dẫn tới over engineering :nosebleed:.
Không hiểu Principles thì làm sao mà trả lời được những câu hỏi như mình đề cập :big_smile:

Thường khi gặp 1 bài toán mình sẽ đặt ra câu hỏi là có những cách tiếp cận nào, pros và cons, tradeoffs của từng solution.
Sẽ không bao giờ có one-fit-all solution mà sẽ phải tuỳ phải tuỳ vào từng bài toán cụ thể để đưa ra solution cho phù hợp.
 
Last edited:
Cảm ơn bác nhiều, mà mấy cái này chỉ đọc thì liệu có nắm đc ko bác ?
Có kiến thức về những cái này chỉ là bước khởi đầu để fence chuyển từ thợ code sang Software Engineer thôi. Dù là bước khởi đầu nhưng nếu ko có nó thì có đi code 10 năm nữa fence cũng vẫn chỉ là thợ code thôi :big_smile:

Nếu hiện tại fence đang làm nhưng không hiểu vì sao họ lại thiết kế như thế, dựa vào đâu để xây dựng solution,... thì giống như kiểu fence chỉ là thợ xây, KTS bảo gì thì mình làm nấy mà ko hiểu vì sao nó lại làm thế.

Còn nếu có kiến thức về principles, system design, design pattern,... thì giống như kiểu fence biết cách đọc bản vẽ thiết kế một cách tổng quan. Khi được giao cho một hệ thống mới trước hết fence tìm đọc thiết kế của nó và có thể hiểu được ngay hệ thống có những thành phần như nào, liên kết với nhau ra sao,... Dần dần lên level cao hơn fence có thể học được cách chỉnh sửa một vài thành phần trong hệ thống để tăng performance, tối ưu tài nguyên,.... Lên level cao hơn nữa thì fence sẽ biết được cách thiết kế cả một hệ thống hoàn chỉnh. Cái này người ta gọi là Solution Architect :big_smile:
 
Leetcode chủ yếu để rèn cho bạn khả năng tư duy thuật toán, các cấu trúc dữ liệu, cách code cơ bản thôi
Còn muốn học những cái trên thì phải tìm hiểu thêm về System Design, Design Pattern. Cái này bên Mẽo bọn nó tìm hiểu từ khi học ĐH rồi chứ không cần phải đi làm 10 năm mới phải biết.
Những tài liệu về System Design nên tham khảo
  • Designing Data-Intensive Applications - Martin Kleppman (Kinh thánh về System Design - Must Read)
  • System Design Interview - Alex Xu (Volume 1 + Volume 2)
  • Khoá Grokking the System Design Interview của Educative
  • Engineering blog của các công ty product lớn
Một số repo trên github về System Design
Tài liệu về Design Pattern
Có thể tham khảo thêm quyển High Performance MySQL về SQL Database

Với những kiến thức này, bạn có thể đưa ra được solution cho những bài toán cơ bản, ví dụ
  • Nên chọn REST hay gRPC ?
  • Nên chọn thuật toán Load Balancing nào ?
  • Nên chọn SQL hay NoSQL ?
  • Thiết kế DB như nào. Khi nào cần Normalization và khi nào thì nên Denormalization ?
  • Nên index như nào cho table ?
  • Nên thiết kế caching và Message Queue như nào ?
  • Nên cấu trúc code như nào, khi nào thì cần dùng Decorator, Observer, Factory,... Pattern?
....

Sau đó thì tiếp tục học tập và làm việc lấy kinh nghiệm để có thể giải quyết được những bài toán phức tạp hơn.
Comment hay quá.
mà học lý thuyết chừng này sao nhớ đc bác.
nó sẻ nhanh quên lắm.
 
E nghĩ bác nên trau dồi kiến thức, sếp thấy ổn thì cho lên vị trí cao hơn, được học nhiều thứ hơn. Chứ code chưa xong đã làm engineer thì hơi khó đấy.
 
Back
Top