[Bình Dân Học Vụ] - 8 điều cơ bản dành cho ai muốn đổi qua nghề IT

Chào tụi mày,

Nhân đợt ân xá sắp tới 30/4, nhằm để hồi hướng công đức cho thành viên bị án tử, để chánh niệm tỏa ra khắp diễn đàn.
Thanh tịnh hay ô nhiễm đều do tâm bởi tâm làm chủ, tâm tạo tác. Người tạo nghiệp bất thiện phải đoạn trừ tâm ô uế chứ không phải gột rửa ngoài thân. Ví như người luyện sắt phải gạn lọc phần cặn bã để được sắt tinh luyện chứ không thể chỉ đem rửa quặng sắt dưới nước trong mà được.

Cho nên tụi bây phải tập giữ chánh niệm, tụi tao không phải bồ tát mà lúc nào cũng cứu tụi bây được hoài.

Hôm nay tao bèn nghĩ ra một bài viết về CNTT, chuyên ngành của tao là Game Dev(Programmer). Để vừa giúp hồi hướng công đức cho tụi mày.
Mà còn giúp cho tụi mày chút ít phần nào đó kinh nghiệm mà tao đã tích lũy được thông qua hơn 12 năm làm nghề. Những thằng đã trong nghề có thể xem qua, nếu tụi mày có ý kiến nào hay hơn, thì hãy đóng góp hoặc làm bài viết. Còn những thằng có ý định học tập, chuyển nghề để có tương lai tươi sáng. Thì hãy đọc cho kỹ, và áp dụng vào việc học, làm. Để giúp ích cho bản thân tụi mày.
IT là nghề không bao giờ hết hot, chỉ có con người mới không có đủ sự kiên nhẫn mà theo đuổi nghề này mà thôi.

Vì vậy, hôm nay tao sẽ chia sẻ 8 hướng dẫn có thể hoạt động như một sơ đồ để cải thiện kỹ năng lập trình của mày. Những điều tao ghi dưới này được thu thập và tổng hợp từ 35 năm trong ngành công nghiệp máy tính, nhiều người trong số đó đã sử dụng ít nhất là một trong 8 điều bên dưới để ghi nhớ trong sự nghiệp của họ, trong đó có tao.
Nếu học được điều nào đó trong 8 điều này, ít ra tụi mày cũng có ích cho đời lắm. Vô đề thôi.

1. Nhắc nhở bản thân rằng mày phải học bao nhiêu.

Bước đầu tiên khi học một cái gì đó là nhận ra rằng mày không biết nó. Điều đó nghe có vẻ hiển nhiên, nhưng các lập trình viên có kinh nghiệm luôn nhớ rằng tụi nó đã mất bao lâu để vượt qua giả định này. Quá nhiều sinh viên khoa học máy tính tốt nghiệp với một kiểu xạo lồn đó là: “Tao rành cái này lắm, dcm dễ vcl”, một sự chắc chắn rằng tụi nó biết tất cả mọi thứ và tụi nó hay xạo lồn thể hiện điều đó với mọi đồng nghiệp hoặc bạn học của tụi nó. Nói cách khác hơi thực tế là: "Con cặc gì tụi nó cũng biết!" thái độ có thể cản trở việc học của tụi mày ở toàn bộ các lĩnh vực, bất cứ điều gì mới, cũng sẽ khó khăn. Nên hãy ngưng tánh xạo lồn, và giấu dốt, thể hiện. Mày không biết, mày học, không ai chửi mày dốt cả. Nên đừng ngại tỏ ra mình không biết.

2. Ngừng cố gắng chứng minh mày đúng

Để trở nên vĩ đại — không chỉ giỏi — mày phải học hỏi từ kinh nghiệm nữa. Nhưng hãy cẩn thận, kinh nghiệm có thể dạy tụi bây lặp lại hành vi xấu và hình thành thói quen xấu. Để tránh thói quen này, hãy nhìn vào mọi thứ mày làm và tự hỏi bản thân, "Làm thế nào để mày có thể làm cho việc này tốt hơn?"

Các nhà phát triển phần mềm mới bước chân vào nghề (và kể cả người có kinh nghiệm) hay nhìn vào code của tụi nó rồi "thủ dâm", rồi khen đáo để: "dcm đéo thể tin mình đã viết được code thế này, vô địch cmnr." Tụi nó viết các đoạn code test để chứng minh rằng code của tụi nó hoạt động thay vì cố gắng làm cho nó bị lỗi(tức là nó đéo dám đối diện sự thật, và đéo dám làm cho nó hư đi, để tìm ra lỗi và khắc phục). Các lập trình viên thực sự tuyệt vời luôn tích cực tìm kiếm chỗ họ sai — bởi vì tụi nó biết rằng cuối cùng người dùng sẽ tìm thấy những khiếm khuyết mà tụi nó đã bỏ qua.

Nói đơn giản dễ hiểu: "Mày phải tự tìm ra khuyết điểm của mày, chứ đừng chỉ nhìn ra điểm tốt của mày rồi thủ dâm"

3. "Code đã chạy" không phải là mày đã xong việc và dừng lại; đó là nơi mày bắt đầu

Đúng vậy tml, bước đầu tiên của mày luôn là viết phần mềm chất lượng đáp ứng các thông số kỹ thuật. Tụi lập trình viên trung bình, non tay hay bỏ việc tại thời điểm đó và chuyển sang việc tiếp theo.(tức là chạy được là mừng rồi, đéo làm nữa, qua làm cái khác)

Một khi "xong" việc, và dừng lại. Cũng giống như mày chụp một bức ảnh nhanh và mong đợi nó trở thành một tác phẩm nghệ thuật. Các lập trình viên giỏi biết rằng lần chạy đầu tiên chỉ là lần lặp đầu tiên mà thôi. Phần mềm, code đã chạy rồi — xin chúc mừng! —Nhưng mày vẫn chưa làm xong. Bây giờ, hãy làm cho nó tốt hơn .

Một phần của quá trình đó là xác định “cái tốt hơn” nghĩa là gì. Nó có giúp cho phần mềm của mày tối ưu để làm cho nó chạy nhanh hơn? Dễ dàng hơn để lập documents? Có thể tái sử dụng code nhiều hơn? Đáng tin cậy hơn? Câu trả lời thay đổi theo từng ứng dụng, nhưng quy trình thì không.

Chốt: "Mày làm cho nó chạy chưa hẳn là xong chuyện, mày cần phải tối ưu hết mức có thể, theo trình độ của mày".

4. Viết lại cái mày đã viết 3 lần.

Lập trình viên giỏi viết phần mềm hoạt động, chạy được là mừng. Những người tuyệt vời, pro thì viết phần mềm hoạt động cực kỳ tốt. Điều đó hiếm khi xảy ra trong lần thử đầu tiên, chỉ hơn nhau giữa tốt và tạm được thôi. Nhưng phần mềm tốt nhất thường phải được viết ba lần:

Đầu tiên, mày viết phần mềm để chứng minh với bản thân (hoặc khách hàng) rằng giải pháp là khả thi. Những người khác có thể không nhận ra rằng đây chỉ là một bằng chứng về khái niệm, nhưng đối với mày, dĩ nhiên nếu mày là thằng làm có kinh nghiệm, hay không đi nữa, mày cũng thừa biết là cái code của mày chỉ là để demo, chạy thử cho coi thôi. Còn làm lại hoàn thiện hơn phải từ từ, đúng chưa?

Lần thứ hai, mày làm cho nó hoạt động.

Lần thứ ba, mày làm cho nó hoạt động "đúng".

Mức độ công việc này có thể không rõ ràng khi mày nhìn vào công việc của những nhà phát triển giỏi nhất. Mọi thứ tụi nó làm có vẻ rất xuất sắc, nhưng điều mày không thấy là ngay cả những nhà phát triển "thuộc hàng top" , tụi nó cũng có thể bỏ luôn phiên bản 1, và phiên bản 2 trước khi đưa phần mềm của tụi nó cho khách hàng(nó giấu cái xấu, và đưa cái tốt nhất của nó ra). Dẹp bỏ những thứ đã làm và bắt đầu lại từ đầu, có thể là một cách hiệu quả để "làm cho dự án của mày tốt hơn", và đưa nó vào quy trình làm việc cá nhân của mày.

Nói cách khác, "Viết lại phần mềm của mày ba lần" cho mày biết có bao nhiêu cách để tiếp cận một vấn đề. Và nó giúp mày không bị mắc kẹt trong một con đường mòn. OK chưa?

5. Đọc mã. Đọc nhiều mã

Thực sự đây là gợi ý phổ biến nhất và có giá trị nhất để cải thiện kỹ năng lập trình của tụi bây.

Khi mày đọc code của người khác, mày sẽ thấy cách người khác giải quyết vấn đề lập trình. Nhưng đừng coi nó là văn học; coi đó như một bài học và một thách thức. Để trở nên tốt hơn, hãy tự hỏi bản thân:

"Tao đã viết khối mã đó như thế nào? Mày sẽ làm gì khác đi, bây giờ mày đã thấy một giải pháp khác?"

"Tao vừa học cái lồn gì dzậy? Làm thế nào tao có thể áp dụng kỹ thuật đó cho project của tao, cái phần mềm mà tao đã viết trong quá khứ, đưa code đó vô sao ta? (“Tao chưa bao giờ nghĩ đến việc sử dụng phương thức truy xuất đệ quy ở đó, sao thằng ml này nó làm cái này chi vậy ta…”).

Tao sẽ cải thiện đoạn code này như thế nào? Và nếu đó là một dự án mã nguồn mở mà mày tự tin rằng mình có giải pháp tốt hơn, hãy làm điều đó!

Viết code theo phong cách của tác giả . Thực hành điều này giúp mày hiểu được tâm trí của người đã viết phần mềm, điều này có thể cải thiện sự đồng cảm của mày.

Đừng chỉ nghĩ vẩn vơ về các bước này. Viết ra câu trả lời của mày, cho dù trong nhật ký cá nhân, blog, trong quá trình đánh giá mã hoặc diễn đàn cộng đồng với các nhà phát triển khác. Cũng giống như việc giải thích một vấn đề với một người mày có thể giúp mày tìm ra giải pháp, việc viết ra và chia sẻ phân tích của mày có thể giúp mày hiểu lý do tại sao mày phản ứng với đoạn code của người khác theo một cách nhất định. Đó là tất cả một phần của sự xem xét nội tâm mà tao đã đề cập trước đó, giúp mày tự đánh giá điểm mạnh và điểm yếu của mày một cách công tâm.

Cảnh báo: Thật dễ dàng để đọc nhiều code mà không trở thành một lập trình viên giỏi, giống như một nhà văn muốn viết có thể đọc những tác phẩm văn học tuyệt vời mà không cần cải thiện văn xuôi của chính mình. Nhiều nhà phát triển xem xét mã nguồn mở hoặc phần mềm khác để “tìm câu trả lời” và rất có thể là sao chép và dán mã xuất hiện để giải quyết một vấn đề tương tự. Làm điều đó thực sự có thể khiến mày trở thành một lập trình viên tồi tệ hơn, vì mày đang mù quáng chấp nhận sự khôn ngoan của người khác mà không kiểm tra nó. (Vì mày không dành thời gian để hiểu về nó, mày sẽ không bao giờ nhận ra rằng mày vừa nhập một nhà máy sản xuất lỗi).

6. Viết code, và không chỉ là nhiệm vụ

Làm việc trên các dự án lập trình cá nhân có nhiều lợi thế. Đầu tiên, nó cung cấp cho mày một cách để tìm hiểu các công cụ và công nghệ không có sẵn trong công việc hiện tại của mày, nhưng giúp mày có khả năng tiếp cận nhiều hơn cho công việc tiếp theo. Cho dù mày đóng góp cho một dự án mã nguồn mở hay đảm nhận công việc chuyên nghiệp trong một tổ chức, doanh nghiệp nào đó. Tất cả đều đòi hỏi mày phải có kỹ năng công nghệ và sự tự tin. (Ngoài ra, các dự án cá nhân của mày chứng tỏ với các nhà tuyển dụng rằng mày là người tự bắt đầu và không ngừng học hỏi.)

Một ưu điểm khác của việc viết code để giải trí là nó buộc mày phải tự tìm hiểu mọi thứ. Mày không thể giao việc khó cho người khác, vì vậy mày không thể yêu cầu giúp đỡ quá sớm.

Mẹo chuyên nghiệp: Mày đừng chỉ chọn những dự án cá nhân mà mày không bao giờ thất bại. Mày cần phải thất bại! Nhưng có lẽ mày không muốn thất bại trong công việc hoặc khi mày có deadline. Giấu dốt hoặc không chấp nhận rằng mày là 1 thằng thất bại, dễ làm mày ngu lắm.

7. Làm việc riêng với các nhà phát triển khác theo bất kỳ cách nào mày có thể

Nó giúp ích cho việc mày sẽ lắng nghe người khác. Nghĩa là lập trình theo cặp, hoặc tham gia một cuộc thi hackathon, hoặc tham gia một nhóm lập trình, hội nhóm gì đó như facebook hay discord.... Khi mày đóng góp cho một dự án mã nguồn mở, hãy chú ý đến phản hồi mày nhận được từ người dùng và từ các nhà phát triển khác. Mày thấy điểm chung nào trong những lời chỉ trích của tụi nó?

Mày có thể đủ may mắn để tìm được một người cố vấn cá nhân mà mày có thể tin tưởng để hướng dẫn mày mọi thứ từ kỹ thuật viết code, đến các quyết định nghề nghiệp. Đừng lãng phí những cơ hội như vậy.

8. Học kỹ thuật, không phải công cụ

Ngôn ngữ lập trình, công cụ và phương pháp trong nghề này nó cứ đến rồi đi, tức là nó đổi mới liên tục. Đó là lý do tại sao mày phải cần học nhiều ngôn ngữ và frameworks chừng nào thì càng tốt chừng nấy. Tập trung vào các nguyên tắc cơ bản về lập trình, bởi vì các nguyên tắc cơ bản không bao giờ thay đổi; cần quan tâm nhiều hơn đến architecture(kiến trúc) hơn là việc lập trình. Nếu mày cảm thấy chắc chắn rằng chỉ có một cách đúng để làm điều gì đó, có lẽ đã đến lúc kiểm tra thực tế. Giáo điều có thể cản trở khả năng học hỏi những điều mới của mày và khiến mày chậm thích nghi với sự thay đổi.

Nguyên lý quan trọng của việc hoàn thiện bản thân là biết khi nào tụi mày nên dừng lại. Vì tụi mày đéo phải là thánh. Nên biết mày là ai, và ở đâu.
Bài hay, ủng hộ tml. <3
 
Nếu anh làm hệ thống phân tán thì phải có tech stack chứ nhỉ? Có thể chia sẻ thêm không?

1 câu hỏi thôi: "Làm thế nào xử lý 1 triệu requests / 1s ?", cách triển khai của anh như nào ?
Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB.
 
Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB.
Nếu quả thật a trả lời được câu đó thì chúc mừng anh, nó là câu hỏi tuyển người của Binance đó? Nhanh nhanh sang Sing để triple lương lên nào.
 
Tao làm về hệ thống phân tán. 5~7 năm đầu ngồi code là chính. Vài năm nay làm architect do tao từng làm các hệ thống to + với review code và lâu lâu vẫn code không sếp nó ý kiến.

m làm zalo à. Zalo cũng đâu tới mức 1 triệu req/s.

ở VN hiện tại Trừ mấy cái hệ thống stream bóng đá thì t chưa thấy system nào dc như thế.

Cơ mà đi làm cỡ 10 năm mà lên dc lương 10k+ là ghê đấy. Gấp 2 tao rồi.

T vẫn thấy hơi khó tin với mức 10K+ của mày. Vì mức đó là tầm head/CTO các kiểu ở cty bự mới lên dc. Nói chung là đếm trên đầu ngón tay ở mảng này.

T biết 1 ông phD từ US về, lương mới dc cỡ đó, làm head 1 mảng ở VNG, mà ko phải về VN là dc mức đó ngay.

Khó tin thôi chứ ko phải là ko có. Nếu m có thể leak 1 chút về payslip hay gì đó thì tốt quá, coi như cho tao mở mang tầm mắt tí dc ko :)

T biết 1 số thằng có lương cỡ đó, nhưng mà tụi nó kiểu làm ở VN ăn lương nước ngoài nên ko tính.
 
m làm zalo à. Zalo cũng đâu tới mức 1 triệu req/s.

ở VN hiện tại Trừ mấy cái hệ thống stream bóng đá thì t chưa thấy system nào dc như thế.

Cơ mà đi làm cỡ 10 năm mà lên dc lương 10k+ là ghê đấy. Gấp 2 tao rồi.
Stream bóng đá có delay, không phải là real time thật đâu. :vozvn (21):
 
Stream bóng đá có delay, không phải là real time thật đâu. :vozvn (21):

ừa, ngoài delay ra còn CDN các kiểu, nhưng mà nhìn chung thằng nào làm được hệ thống như thế là cũng ghê rồi.
Nên mới nói ở VN tới giờ t vẫn chưa thấy hệ thống nào 1 triệu req/s ở VN :)
Zalo nó cũng có nhiều service, ví dụ message service của nó chắc vài trăm k req/s chứ làm sao 1 triệu nổi được.
 
ừa, ngoài delay ra còn CDN các kiểu, nhưng mà nhìn chung thằng nào làm được hệ thống như thế là cũng ghê rồi.
Nên mới nói ở VN tới giờ t vẫn chưa thấy hệ thống nào 1 triệu req/s ở VN :)
Zalo nó cũng có nhiều service, ví dụ message service của nó chắc vài trăm k req/s chứ làm sao 1 triệu nổi được
Thì câu T post ở trên là câu phỏng vấn của Tech Lead Binance Sing đó :oh:
 
Thì câu T post ở trên là câu phỏng vấn của Tech Lead Binance Sing đó :oh:

thì biết, câu đó thì nhiều nơi hỏi mà, mà ông kia bảo "Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB." ==> tức là ông ấy làm hệ thống như thế.
Mà chắc ko tới triệu, chắc cỡ vài trăm k. Có thể t hiểu sai ý ông ấy, tưởng ý ông ấy là ông ấy làm hệ thống triệu req/s.

Thực ra về cơ bản là cũng ko khó lắm đâu, với các stack và công cụ/kỹ thuật đang có hiện nay, biết sâu 1 chút, chăm đọc và tìm hiểu thì sẽ có phương án để làm.
 
thì biết, câu đó thì nhiều nơi hỏi mà, mà ông kia bảo "Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB." ==> tức là ông ấy làm hệ thống như thế.
Mà chắc ko tới triệu, chắc cỡ vài trăm k. Có thể t hiểu sai ý ông ấy, tưởng ý ông ấy là ông ấy làm hệ thống triệu req/s.

Thực ra về cơ bản là cũng ko khó lắm đâu, với các stack và công cụ/kỹ thuật đang có hiện nay, biết sâu 1 chút, chăm đọc và tìm hiểu thì sẽ có phương án để làm.
Đúng rồi, nhưng mà kinh nghiệm / không kinh nghiệm là sẽ tính đến phương án tối ưu / tiết kiệm chi phí / mà vẫn đảm bảo hệ thống vẫn chạy tốt.

Nãy giờ chém đó, vì mình không phải IT :pudency::pudency::pudency:
 
Đúng rồi, nhưng mà kinh nghiệm / không kinh nghiệm là sẽ tính đến phương án tối ưu / tiết kiệm chi phí / mà vẫn đảm bảo hệ thống vẫn chạy tốt.

Nãy giờ chém đó, vì mình không phải IT :pudency::pudency::pudency:

bạn làm trade coin à
 
IT có cần phải giỏi toán với English ko :vozvn (19):
English trong môi trường làm việc có yêu cầu thì bắt buộc phải biết.
còn làm tự do, thì biết dc bao nhiêu càng tốt. Chứ ko biết thì thua.
sợ tiếng anh thì ko hợp nghề này, vì chuẩn quy tắc lập trình nó cần cơ bản tiếng anh. Để viết cho nó ra dáng theo chuẩn quy ước của quốc tế. Và code để cho người khác đọc nữa, chứ mày làm 1 mình mày, muốn làm sao đó làm, ko ai nói.

tham khảo thêm, bắt buộc thằng nào làm chuyên nghiệp, hay newbie. Cũng cần phải biết cái này:

- về toán thì ko cần, nhưng cái đầu phải có logic một chút. Để nghĩ hướng giải quyết vấn đề. Cơ bản là các vấn đề khó đã có lời giải. Chịu tìm hiểu và biết hướng tìm hiểu thì cái nào cũng giải quyết dc. Toán ko cần, tuy nhiên, sẽ cần khi học sâu, thiêng về architect và giải quyết vấn đề yêu cầu có toán học, vật lý.

- làm công ăn lương, tháng 20, 30tr, thì eng cơ bản sơ sơ. Mua hàng amazon, ebay dc là ok. Và ko cần trình toán học gì cả. Chỉ cần quen tay giải quyết vấn đề. Thì vấn đề 20 30tr là dễ. Còn xa hơn thì như trên.
 
Nếu quả thật a trả lời được câu đó thì chúc mừng anh, nó là câu hỏi tuyển người của Binance đó? Nhanh nhanh sang Sing để triple lương lên nào.
Gần 40 rồi sang Sing gì nữa mày :too_sad:
 
Sửa lần cuối:
m làm zalo à. Zalo cũng đâu tới mức 1 triệu req/s.

ở VN hiện tại Trừ mấy cái hệ thống stream bóng đá thì t chưa thấy system nào dc như thế.

Cơ mà đi làm cỡ 10 năm mà lên dc lương 10k+ là ghê đấy. Gấp 2 tao rồi.

T vẫn thấy hơi khó tin với mức 10K+ của mày. Vì mức đó là tầm head/CTO các kiểu ở cty bự mới lên dc. Nói chung là đếm trên đầu ngón tay ở mảng này.

T biết 1 ông phD từ US về, lương mới dc cỡ đó, làm head 1 mảng ở VNG, mà ko phải về VN là dc mức đó ngay.

Khó tin thôi chứ ko phải là ko có. Nếu m có thể leak 1 chút về payslip hay gì đó thì tốt quá, coi như cho tao mở mang tầm mắt tí dc ko :)

T biết 1 số thằng có lương cỡ đó, nhưng mà tụi nó kiểu làm ở VN ăn lương nước ngoài nên ko tính.

Tao làm manager ở Big MNC. Cty tao cũng cũng đứng top thế giới 1 vài mảng.
Tao từng hỏi dò mấy boss tao (người Việt) thì có người package 3 tỏi / 1 năm (lương cứng) chưa tính bonus / stock.
 
IT có cần phải giỏi toán với English ko :vozvn (19):
IT cần phải mạnh tư duy Tin học. (độ phức tạp, giải thuật)

Nếu giỏi toán -> tư duy tin học cũng mạnh.
Ngược lại nếu ko giỏi toán -> Thì cũng có thể có tư duy tin học mạnh (hoặc hên xui)

English thì muốn giàu thì phải có. Còn ko thì làng nhàng lắm.
 
thì biết, câu đó thì nhiều nơi hỏi mà, mà ông kia bảo "Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB." ==> tức là ông ấy làm hệ thống như thế.
Mà chắc ko tới triệu, chắc cỡ vài trăm k. Có thể t hiểu sai ý ông ấy, tưởng ý ông ấy là ông ấy làm hệ thống triệu req/s.

Thực ra về cơ bản là cũng ko khó lắm đâu, với các stack và công cụ/kỹ thuật đang có hiện nay, biết sâu 1 chút, chăm đọc và tìm hiểu thì sẽ có phương án để làm.
Quan trọng là chịu đọc đó chúng mày. Đa phần dev VN ngồi gõ code. Hoặc giỏi lắm người nào hiểu sâu từng dòng code.

Nhưng ngồi đọc sẽ hiểu idea của những cái tool / platform -> đưa ra idea tương tự cho dự án.

Tao cũng chưa làm dự án qps 1M/s đâu.

Nhưng pv thì mình cứ nói idea đến mức mình biết. Có idea còn tốt hơn ko biết gì.
 
Nếu anh làm hệ thống phân tán thì phải có tech stack chứ nhỉ? Có thể chia sẻ thêm không?

1 câu hỏi thôi: "Làm thế nào xử lý 1 triệu requests / 1s ?", cách triển khai của anh như nào ?
Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB.
thì biết, câu đó thì nhiều nơi hỏi mà, mà ông kia bảo "Chính xác là nó. Nhất nhiều kĩ thuật mình sẽ triển khai. Đồng bộ từ infra, network, app-server, DB." ==> tức là ông ấy làm hệ thống như thế.
Mà chắc ko tới triệu, chắc cỡ vài trăm k. Có thể t hiểu sai ý ông ấy, tưởng ý ông ấy là ông ấy làm hệ thống triệu req/s.

Thực ra về cơ bản là cũng ko khó lắm đâu, với các stack và công cụ/kỹ thuật đang có hiện nay, biết sâu 1 chút, chăm đọc và tìm hiểu thì sẽ có phương án để làm.

Nói thế này thì chung chung quá, kiểu code lởm ko tối ưu nhưng mà add thêm nhiều servers/hardwares vào để bù đắp lại thì cũng có thể xử lý được 1 triệu requests/s. Nhưng mà như thế sẽ tốn quá nhiều tài nguyên như tiền bạc, năng lượng, nhân công để duy trì cái hệ thống hardwares đấy. Cho nên theo kinh nghiệm của tôi thì viết code tối ưu, 100x faster thì tốt hơn là code lởm xong add thêm 100 cái servers để bù vào.

Tôi không làm backend dev nhưng tôi làm game dev. Nói về optimization thì tôi thấy chả có mảng nào optimization mà khoai như mảng game dev, cả về CPU optimization lẫn GPU optimization, đặc biệt là triple A game. Nên tôi cũng có nhiều kinh nghiệm trong việc viết perfomance code.

Để handle được 1 mil requests/s thì cái hệ thống server đấy phải được phát triển theo hướng performance hơn là scalability. Thường thì optimization code rất coupling với nhau, khó scalable. Để phát triển một hệ thống mà ưu tiên scalability thì codebase phải áp dụng nhiều abtractions, design pattern của OOP. Mà abstractions tạo ra rất nhiều overhead cho CPU. Cho nên codebase càng scale thì abstractions càng nhiều và về sau càng khó để có thể optimization mà không cần đến sự hỗ trợ của hardware.

Về kỹ thuật chính của việc viết perfomance code thì chủ yếu là liên quan đến cache friendly, tránh cache missing càng nhiều càng tốt khi xử lý data. Vì CPU fetch data từ caches nhanh hơn rất nhiều so với fetch từ RAM. Cho nên nếu như ông dev nào thiếu kinh nghiệm, cứ áp dụng bừa các thể loại design patterns của OOP để phát triển hệ thống server cần tối ưu, thì khi gặp phải performance bottlenecks chỉ có nước đập đi làm lại nhé.

Trong mảng game dev thì họ ko còn ưa thích OOP nhiều lắm vì nó tạo ra nhiều perfomance bottlenecks cho game. Thay vì đó dân game dev đang ưa chuộng 2 paradigms thay thế cho OOP là Data Oriented Design (DOD) và Entity Component Systems (ECS). Hai mô hình lập trình này ưu tiên việc xử lý data dựa vào cache friendly, do đó hướng perfomance hơn là OOP. Hai paradigms này đều có thể áp dụng cho việc phát triển hệ thống backend.

Data Oriented Design by Mike Acton



Entity Component System (ECS) definition
 
Sửa lần cuối:
Nói thế này thì chung chung quá, kiểu code lởm ko tối ưu nhưng mà add thêm nhiều servers/hardwares vào để bù đắp lại thì cũng có thể xử lý được 1 triệu requests/s. Nhưng mà như thế sẽ tốn quá nhiều tài nguyên như tiền bạc, năng lượng, nhân công để duy trì cái hệ thống hardwares đấy. Cho nên theo kinh nghiệm của tôi thì viết code tối ưu, 100x faster thì tốt hơn là code lởm xong add thêm 100 cái servers để bù vào.

Tôi không làm backend dev nhưng tôi làm game dev. Nói về optimization thì tôi thấy chả có mảng nào optimization mà khoai như mảng game dev, cả về CPU optimization lẫn GPU optimization, đặc biệt là triple A game. Nên tôi cũng có nhiều kinh nghiệm trong việc viết perfomance code.

Để handle được 1 mil requests/s thì cái hệ thống server đấy phải được phát triển theo hướng performance hơn là scalability. Thường thì optimization code rất coupling với nhau, khó scalable. Để phát triển một hệ thống mà ưu tiên scalability thì codebase phải áp dụng nhiều abtractions, design pattern của OOP. Mà abstractions tạo ra rất nhiều overhead cho CPU. Cho nên codebase càng scale thì abstractions càng nhiều và về sau càng khó để có thể optimization mà không cần đến sự hỗ trợ của hardware.

Về kỹ thuật chính của việc viết perfomance code thì chủ yếu là liên quan đến cache friendly, tránh cache missing càng nhiều càng tốt khi xử lý data. Vì CPU fetch data từ caches nhanh hơn rất nhiều so với fetch từ RAM. Cho nên nếu như ông dev nào thiếu kinh nghiệm, cứ áp dụng bừa các thể loại design patterns của OOP để phát triển hệ thống server cần tối ưu, thì khi gặp phải performance bottlenecks chỉ có nước đập đi làm lại nhé.

Trong mảng game dev thì họ ko còn ưa thích OOP nhiều lắm vì nó tạo ra nhiều perfomance bottlenecks cho game. Thay vì đó dân game dev đang ưa chuộng 2 paradigms thay thế cho OOP là Data Oriented Design (DOD) và Entity Component Systems (ECS). Hai mô hình lập trình này ưu tiên việc xử lý data dựa vào cache friendly, do đó hướng perfomance hơn là OOP. Hai paradigms này đều có thể áp dụng cho việc phát triển hệ thống backend.

Data Oriented Design by Mike Acton



Entity Component System (ECS) definition

Có hiểu ý nhưng mờ thiên về DOD và ECS thì chắc lại phải đọc thêm rồi, dù gì background cũng đâu phải IT đâu.:too_sad::too_sad:.

Tất nhiên làm game thì khoai hơn web application rồi.
 
Có hiểu ý nhưng mờ thiên về DOD và ECS thì chắc lại phải đọc thêm rồi, dù gì background cũng đâu phải IT đâu.:too_sad::too_sad:.

Tất nhiên làm game thì khoai hơn web application rồi.
Thấy cũng có biết mà, chắc có dự định làm IT nhể?
 
Chào tụi mày,

Nhân đợt ân xá sắp tới 30/4, nhằm để hồi hướng công đức cho thành viên bị án tử, để chánh niệm tỏa ra khắp diễn đàn.
Thanh tịnh hay ô nhiễm đều do tâm bởi tâm làm chủ, tâm tạo tác. Người tạo nghiệp bất thiện phải đoạn trừ tâm ô uế chứ không phải gột rửa ngoài thân. Ví như người luyện sắt phải gạn lọc phần cặn bã để được sắt tinh luyện chứ không thể chỉ đem rửa quặng sắt dưới nước trong mà được.

Cho nên tụi bây phải tập giữ chánh niệm, tụi tao không phải bồ tát mà lúc nào cũng cứu tụi bây được hoài.

Hôm nay tao bèn nghĩ ra một bài viết về CNTT, chuyên ngành của tao là Game Dev(Programmer). Để vừa giúp hồi hướng công đức cho tụi mày.
Mà còn giúp cho tụi mày chút ít phần nào đó kinh nghiệm mà tao đã tích lũy được thông qua hơn 12 năm làm nghề. Những thằng đã trong nghề có thể xem qua, nếu tụi mày có ý kiến nào hay hơn, thì hãy đóng góp hoặc làm bài viết. Còn những thằng có ý định học tập, chuyển nghề để có tương lai tươi sáng. Thì hãy đọc cho kỹ, và áp dụng vào việc học, làm. Để giúp ích cho bản thân tụi mày.
IT là nghề không bao giờ hết hot, chỉ có con người mới không có đủ sự kiên nhẫn mà theo đuổi nghề này mà thôi.

Vì vậy, hôm nay tao sẽ chia sẻ 8 hướng dẫn có thể hoạt động như một sơ đồ để cải thiện kỹ năng lập trình của mày. Những điều tao ghi dưới này được thu thập và tổng hợp từ 35 năm trong ngành công nghiệp máy tính, nhiều người trong số đó đã sử dụng ít nhất là một trong 8 điều bên dưới để ghi nhớ trong sự nghiệp của họ, trong đó có tao.
Nếu học được điều nào đó trong 8 điều này, ít ra tụi mày cũng có ích cho đời lắm. Vô đề thôi.

1. Nhắc nhở bản thân rằng mày phải học bao nhiêu.

Bước đầu tiên khi học một cái gì đó là nhận ra rằng mày không biết nó. Điều đó nghe có vẻ hiển nhiên, nhưng các lập trình viên có kinh nghiệm luôn nhớ rằng tụi nó đã mất bao lâu để vượt qua giả định này. Quá nhiều sinh viên khoa học máy tính tốt nghiệp với một kiểu xạo lồn đó là: “Tao rành cái này lắm, dcm dễ vcl”, một sự chắc chắn rằng tụi nó biết tất cả mọi thứ và tụi nó hay xạo lồn thể hiện điều đó với mọi đồng nghiệp hoặc bạn học của tụi nó. Nói cách khác hơi thực tế là: "Con cặc gì tụi nó cũng biết!" thái độ có thể cản trở việc học của tụi mày ở toàn bộ các lĩnh vực, bất cứ điều gì mới, cũng sẽ khó khăn. Nên hãy ngưng tánh xạo lồn, và giấu dốt, thể hiện. Mày không biết, mày học, không ai chửi mày dốt cả. Nên đừng ngại tỏ ra mình không biết.

2. Ngừng cố gắng chứng minh mày đúng

Để trở nên vĩ đại — không chỉ giỏi — mày phải học hỏi từ kinh nghiệm nữa. Nhưng hãy cẩn thận, kinh nghiệm có thể dạy tụi bây lặp lại hành vi xấu và hình thành thói quen xấu. Để tránh thói quen này, hãy nhìn vào mọi thứ mày làm và tự hỏi bản thân, "Làm thế nào để mày có thể làm cho việc này tốt hơn?"

Các nhà phát triển phần mềm mới bước chân vào nghề (và kể cả người có kinh nghiệm) hay nhìn vào code của tụi nó rồi "thủ dâm", rồi khen đáo để: "dcm đéo thể tin mình đã viết được code thế này, vô địch cmnr." Tụi nó viết các đoạn code test để chứng minh rằng code của tụi nó hoạt động thay vì cố gắng làm cho nó bị lỗi(tức là nó đéo dám đối diện sự thật, và đéo dám làm cho nó hư đi, để tìm ra lỗi và khắc phục). Các lập trình viên thực sự tuyệt vời luôn tích cực tìm kiếm chỗ họ sai — bởi vì tụi nó biết rằng cuối cùng người dùng sẽ tìm thấy những khiếm khuyết mà tụi nó đã bỏ qua.

Nói đơn giản dễ hiểu: "Mày phải tự tìm ra khuyết điểm của mày, chứ đừng chỉ nhìn ra điểm tốt của mày rồi thủ dâm"

3. "Code đã chạy" không phải là mày đã xong việc và dừng lại; đó là nơi mày bắt đầu

Đúng vậy tml, bước đầu tiên của mày luôn là viết phần mềm chất lượng đáp ứng các thông số kỹ thuật. Tụi lập trình viên trung bình, non tay hay bỏ việc tại thời điểm đó và chuyển sang việc tiếp theo.(tức là chạy được là mừng rồi, đéo làm nữa, qua làm cái khác)

Một khi "xong" việc, và dừng lại. Cũng giống như mày chụp một bức ảnh nhanh và mong đợi nó trở thành một tác phẩm nghệ thuật. Các lập trình viên giỏi biết rằng lần chạy đầu tiên chỉ là lần lặp đầu tiên mà thôi. Phần mềm, code đã chạy rồi — xin chúc mừng! —Nhưng mày vẫn chưa làm xong. Bây giờ, hãy làm cho nó tốt hơn .

Một phần của quá trình đó là xác định “cái tốt hơn” nghĩa là gì. Nó có giúp cho phần mềm của mày tối ưu để làm cho nó chạy nhanh hơn? Dễ dàng hơn để lập documents? Có thể tái sử dụng code nhiều hơn? Đáng tin cậy hơn? Câu trả lời thay đổi theo từng ứng dụng, nhưng quy trình thì không.

Chốt: "Mày làm cho nó chạy chưa hẳn là xong chuyện, mày cần phải tối ưu hết mức có thể, theo trình độ của mày".

4. Viết lại cái mày đã viết 3 lần.

Lập trình viên giỏi viết phần mềm hoạt động, chạy được là mừng. Những người tuyệt vời, pro thì viết phần mềm hoạt động cực kỳ tốt. Điều đó hiếm khi xảy ra trong lần thử đầu tiên, chỉ hơn nhau giữa tốt và tạm được thôi. Nhưng phần mềm tốt nhất thường phải được viết ba lần:

Đầu tiên, mày viết phần mềm để chứng minh với bản thân (hoặc khách hàng) rằng giải pháp là khả thi. Những người khác có thể không nhận ra rằng đây chỉ là một bằng chứng về khái niệm, nhưng đối với mày, dĩ nhiên nếu mày là thằng làm có kinh nghiệm, hay không đi nữa, mày cũng thừa biết là cái code của mày chỉ là để demo, chạy thử cho coi thôi. Còn làm lại hoàn thiện hơn phải từ từ, đúng chưa?

Lần thứ hai, mày làm cho nó hoạt động.

Lần thứ ba, mày làm cho nó hoạt động "đúng".

Mức độ công việc này có thể không rõ ràng khi mày nhìn vào công việc của những nhà phát triển giỏi nhất. Mọi thứ tụi nó làm có vẻ rất xuất sắc, nhưng điều mày không thấy là ngay cả những nhà phát triển "thuộc hàng top" , tụi nó cũng có thể bỏ luôn phiên bản 1, và phiên bản 2 trước khi đưa phần mềm của tụi nó cho khách hàng(nó giấu cái xấu, và đưa cái tốt nhất của nó ra). Dẹp bỏ những thứ đã làm và bắt đầu lại từ đầu, có thể là một cách hiệu quả để "làm cho dự án của mày tốt hơn", và đưa nó vào quy trình làm việc cá nhân của mày.

Nói cách khác, "Viết lại phần mềm của mày ba lần" cho mày biết có bao nhiêu cách để tiếp cận một vấn đề. Và nó giúp mày không bị mắc kẹt trong một con đường mòn. OK chưa?

5. Đọc mã. Đọc nhiều mã

Thực sự đây là gợi ý phổ biến nhất và có giá trị nhất để cải thiện kỹ năng lập trình của tụi bây.

Khi mày đọc code của người khác, mày sẽ thấy cách người khác giải quyết vấn đề lập trình. Nhưng đừng coi nó là văn học; coi đó như một bài học và một thách thức. Để trở nên tốt hơn, hãy tự hỏi bản thân:

"Tao đã viết khối mã đó như thế nào? Mày sẽ làm gì khác đi, bây giờ mày đã thấy một giải pháp khác?"

"Tao vừa học cái lồn gì dzậy? Làm thế nào tao có thể áp dụng kỹ thuật đó cho project của tao, cái phần mềm mà tao đã viết trong quá khứ, đưa code đó vô sao ta? (“Tao chưa bao giờ nghĩ đến việc sử dụng phương thức truy xuất đệ quy ở đó, sao thằng ml này nó làm cái này chi vậy ta…”).

Tao sẽ cải thiện đoạn code này như thế nào? Và nếu đó là một dự án mã nguồn mở mà mày tự tin rằng mình có giải pháp tốt hơn, hãy làm điều đó!

Viết code theo phong cách của tác giả . Thực hành điều này giúp mày hiểu được tâm trí của người đã viết phần mềm, điều này có thể cải thiện sự đồng cảm của mày.

Đừng chỉ nghĩ vẩn vơ về các bước này. Viết ra câu trả lời của mày, cho dù trong nhật ký cá nhân, blog, trong quá trình đánh giá mã hoặc diễn đàn cộng đồng với các nhà phát triển khác. Cũng giống như việc giải thích một vấn đề với một người khác, mà mày có thể giúp nó tìm ra giải pháp, việc viết ra và chia sẻ phân tích của mày có thể giúp mày hiểu lý do tại sao mày phản ứng với đoạn code của người khác theo một cách nhất định. Đó là tất cả một phần của sự xem xét nội tâm mà tao đã đề cập trước đó, giúp mày tự đánh giá điểm mạnh và điểm yếu của mày một cách công tâm.

Cảnh báo: Thật dễ dàng để đọc nhiều code mà không trở thành một lập trình viên giỏi, giống như một nhà văn muốn viết có thể đọc những tác phẩm văn học tuyệt vời mà không cần cải thiện văn xuôi của chính mình. Nhiều nhà phát triển xem xét mã nguồn mở hoặc phần mềm khác để “tìm câu trả lời” và rất có thể là sao chép và dán mã của người ta(copy & paste) để giải quyết một vấn đề tương tự. Làm điều đó thực sự có thể khiến mày trở thành một lập trình viên tồi tệ hơn, vì mày đang mù quáng chấp nhận sự khôn ngoan của người khác mà không kiểm tra nó. (Vì mày không dành thời gian để hiểu về nó, mày sẽ không bao giờ nhận ra rằng mày vừa nhập một nhà máy sản xuất lỗi).

6. Viết code, và không chỉ là nhiệm vụ

Làm việc trên các dự án lập trình cá nhân có nhiều lợi thế. Đầu tiên, nó cung cấp cho mày một cách để tìm hiểu các công cụ và công nghệ không có sẵn trong công việc hiện tại của mày, nhưng giúp mày có khả năng tiếp cận nhiều hơn cho công việc tiếp theo. Cho dù mày đóng góp cho một dự án mã nguồn mở hay đảm nhận công việc chuyên nghiệp trong một tổ chức, doanh nghiệp nào đó. Tất cả đều đòi hỏi mày phải có kỹ năng công nghệ và sự tự tin. (Ngoài ra, các dự án cá nhân của mày chứng tỏ với các nhà tuyển dụng rằng mày là người tự bắt đầu và không ngừng học hỏi.)

Một ưu điểm khác của việc viết code để giải trí là nó buộc mày phải tự tìm hiểu mọi thứ. Mày không thể giao việc khó cho người khác, vì vậy mày không thể yêu cầu giúp đỡ quá sớm.

Mẹo chuyên nghiệp: Mày đừng chỉ chọn những dự án cá nhân mà mày không bao giờ thất bại. Mày cần phải thất bại! Nhưng có lẽ mày không muốn thất bại trong công việc hoặc khi mày có deadline. Giấu dốt hoặc không chấp nhận rằng mày là 1 thằng thất bại, dễ làm mày ngu lắm.

7. Làm việc riêng với các nhà phát triển khác theo bất kỳ cách nào mày có thể

Nó giúp ích cho việc mày sẽ lắng nghe người khác. Nghĩa là lập trình theo cặp, hoặc tham gia một cuộc thi hackathon, hoặc tham gia một nhóm lập trình, hội nhóm gì đó như facebook hay discord.... Khi mày đóng góp cho một dự án mã nguồn mở, hãy chú ý đến phản hồi mày nhận được từ người dùng và từ các nhà phát triển khác. Mày thấy điểm chung nào trong những lời chỉ trích của tụi nó?

Mày có thể đủ may mắn để tìm được một người cố vấn cá nhân mà mày có thể tin tưởng để hướng dẫn mày mọi thứ từ kỹ thuật viết code, đến các quyết định nghề nghiệp. Đừng lãng phí những cơ hội như vậy.

8. Học kỹ thuật, không phải công cụ

Ngôn ngữ lập trình, công cụ và phương pháp trong nghề này nó cứ đến rồi đi, tức là nó đổi mới liên tục. Đó là lý do tại sao mày phải cần học nhiều ngôn ngữ và frameworks chừng nào thì càng tốt chừng nấy. Tập trung vào các nguyên tắc cơ bản về lập trình, bởi vì các nguyên tắc cơ bản không bao giờ thay đổi; cần quan tâm nhiều hơn đến architect(kiến trúc) hơn là việc lập trình. Nếu mày cảm thấy chắc chắn rằng chỉ có một cách đúng để làm điều gì đó, có lẽ đã đến lúc kiểm tra thực tế. Giáo điều có thể cản trở khả năng học hỏi những điều mới của mày và khiến mày chậm thích nghi với sự thay đổi.

Nguyên lý quan trọng của việc hoàn thiện bản thân là biết khi nào tụi mày nên dừng lại. Vì tụi mày đéo phải là thánh. Nên biết mày là ai, và ở đâu.
giờ mới thấy post này, mặc dù đã 30 nhưng năm nay tao tagert tìm một công việc dev để ổn định. Xưa giờ làm MMO nhưng tao bỏ hết để bắt đầu lại từ đầu. Cảm ơn mày !
 

Có thể bạn quan tâm

Top