Học lập trình hiệu quả

Lập trình là một nghề “nóng” vì nó tạo ra nhiều tỷ phú hơn những nghề khác. Công nghệ thông tin bỗng trở thành thời thượng, được thiên hạ đồn “kiếm tiền ngon lắm”. Nhiều người lao đầu vào nó nhưng lại không biết bắt đầu từ đâu, và cũng không biết sẽ đi về đâu. Tệ hơn, nhiều người chạy theo trào lưu công nghệ vô tội vạ, học nhiều thứ cùng lúc với hi vọng tăng thu nhập. Cuối cùng, họ phát hiện ra thu nhập không tỉ lệ thuận với số lượng kiến thức, mà là với chất lượng kiến thức.

Tập trung vào một công nghệ

Lập trình viên mới vào nghề thường nhìn những người có kinh nghiệm lâu năm và cảm thấy khâm phục kiến thức uyên bác, kĩ năng điêu luyện của các bậc thầy. Để đạt tới cảnh giới đó, họ phải khổ công luyện tập. Tuy nhiên, do không kìm được nôn nóng, các “tân binh” lại muốn đi nhanh, về đích sớm. Thế là họ nghĩ đến phương pháp “đi tắt đón đầu”: học nhiều công nghệ cùng lúc để mau chóng bắt kịp tiến độ của đàn anh.

Thật không may, điều này làm hại hơn là giúp họ. Não người chỉ có khả năng tập trung vào một thứ tại một thời điểm. Cách duy nhất để đạt hiệu quả tối đa trong học tập là toàn tâm toàn ý tập trung vào một thứ. Học nhiều công nghệ cùng lúc càng khiến đầu óc rối mù, và càng rối thì càng nản. Dần dần, họ từ bỏ cuộc chơi, bỏ cái giấc mộng “Bill Gates” mà lúc đầu họ vẫn còn hăm hở. Lúc này, họ nhận ra rằng “đi tắt” là “đón đầu lâu”.

Nếu anh thích C#, hãy tập trung vào nó. Nếu anh thích JavaScript, hãy chỉ quan tâm đến JavaScript, ít ra là trong giai đoạn đầu. Tránh trường hợp vừa C#, vừa JavaScript, vừa Java, vừa Ruby, vừa Python, vừa PHP. Não anh sẽ loạn, tâm trí anh sẽ rối bời, và nguy cơ đột quỵ cũng tăng cao.

Học là một quy trình có nhiều giai đoạn. Kiến thức trước sẽ làm nền tảng cho kiến thức sau. Ta không thể chạy khi chưa biết đi, không thể học giải tích khi chưa thông lượng giác và đại số, không thể viết văn khi chưa biết đánh vần. Đó là quy luật tự nhiên, và nếu không theo quy luật này, ta rất dễ bị tẩu hỏa nhập ma.

Cũng có nhiều người, vì nghe lời đồn “kiếm tiền ngon lắm” nên mới lao đầu vào học lập trình. Cuối cùng, họ phát hiện ra sao mà khó quá. Vào lớp mà cứ Facebook với đọc tin lá cải, còn không thì chơi game. Bài tập không làm, dự án cũng không màn tới. Học kỳ này tới học kỳ khác, phiếu điểm chỉ toàn số 0 to tướng. Đến lúc bạn bè đi làm hết rồi, chỉ còn họ ngồi lại học tiếp. Được một thời gian thì nghỉ vì quá nản. Cũng có trường hợp quay lại học từ đầu, rồi cũng thói nào tật nấy.

Có người lại tham lam, học cùng lúc nhiều ngành, nhiều trường. Họ muốn “bắt cá hai tay”. Cuối cùng chẳng cái nào ra hồn cả. Khi đầu óc bị phân tán, nó không tiếp thu kiến thức được. Học mà không tiếp thu thì sẽ nản. Đã nản thì sẽ nghỉ học.

Tự tay viết code

Viết code cũng giống như viết văn. Trước khi viết, ta phải suy tính, lên kế hoạch xem mình viết cái gì và viết như thế nào. Khi viết code, não ta hoạt động mạnh để tìm giải pháp. Nhờ tư duy liên tục, tay nghề viết code sẽ tiến bộ nhanh chóng.

Nhiều người học lập trình mà lười viết code. Họ nghĩ rằng chỉ cần coi code là đủ. Trên đời này không có phương pháp học bằng mắt, mà chỉ có học bằng thực hành. Ta không thể học giỏi toán nếu cứ coi bài giải người khác, và ta cũng không thể lập trình tốt nếu cứ ngó code người khác. Ta phải tự tay viết, mắc lỗi và tự sửa lỗi.

Lướt qua các diễn đàn, nhóm Facebook về lập trình, ta thấy phần lớn nội dung là giải bài tập hộ. Hễ gặp lỗi là cứ chụp màn hình, đăng lên nhờ giúp đỡ, trong khi trình biên dịch thông báo số dòng gây ra lỗi. Tệ hơn, một số người lười đến mức đăng cả đề bài lên nhờ người khác giải. Không tự viết code thì chẳng bao giờ tiến bộ.

Ta nên tránh nhầm lẫn giữa sửa codeviết code. Viết code là tự mình viết chứ không lấy code người khác rồi chỉnh sửa. Khi làm dự án trong lớp, ta phải vắt óc suy nghĩ, chứ không phải lên mạng lấy code của ai đó về biên tập lại. Sửa code không đòi hỏi tư duy nhiều như viết code. Do đó, ta bỏ mất cơ hội để trau dồi trình độ, và chính trình độ sẽ quyết định tiền lương khi đi làm. Nâng cao trình độ chính là nâng cao đồng lương.

Sử dụng thành thạo công cụ

Ta không thể gọi một người là thợ mộc nếu như anh ta không biết dùng cây búa. Ta cũng không thể gọi một người là lập trình viên nếu anh ta không thành thạo các công cụ lập trình, cụ thể là IDE. Ta có thể coi IDE là hộp đồ nghề, bao gồm nhiều công cụ nhỏ bên trong: trình soạn thảo text (text editor), trình biên dịch (compiler), trình gỡ lỗi (debugger) và nhiều đồ chơi thú vị khác. Để viết code hiệu quả, ta phải sử dụng thành thạo IDE.

Phần lớn lập trình viên chỉ dùng 10% các chức năng mà IDE hỗ trợ. Đây là một sự lãng phí lớn. Nếu biết tận dụng tối đa IDE, công việc viết code sẽ nhẹ hơn. Do vậy, ngoài học ngôn ngữ lập trình, ta nên dành chút thì giờ để đọc tài liệu hướng dẫn của IDE. Nhân tiện, ta học luôn vài phím tắt hữu dụng để tăng tốc các thao tác.

Sử dụng đúng công cụ cũng quan trọng không kém. Dùng đúng công cụ, công việc sẽ được giải quyết nhanh gọn mà không tốn nhiều công sức. Ta có thể đóng đinh bằng cây búa hoặc bằng cục đá. Nhưng dùng cây búa dễ hơn, vì nó được thiết kế để đóng đinh. Dùng cục đá cũng được, nhưng khó khăn và rủi ro nhiều hơn.

Tránh chạy theo trào lưu

Cứ mỗi giây trôi qua là có một thư viện JavaScript mới ra đời. Nghe có vẻ cường điệu, nhưng nó nói lên một thực tế là ta không thể bắt kịp công nghệ mới dù cố cách mấy. Cập nhật kiến thức mới rất cần thiết, nhưng ta làm việc này có chọn lọc, không phải vô tội vạ. Nếu anh chuyên về .NET, hãy luôn cập nhật kiến thức mới về .NET, chứ không phải Java hay Python. Người học nhiều công nghệ thường chẳng hiểu sâu về cái nào cả, và những ai chạy theo công nghệ, đặc biệt là các thư viện JavaScript, thì sẽ sớm thất vọng vì nhận ra các thư viện này biến mất cũng nhanh như lúc ra đời. Chỉ rất ít library và framework trụ được lâu dài.

Các công ty lớn thường rất kiêng kị khi dùng code “lạ”, đặc biệt là từ nguồn tác giả vô danh, vì chẳng ai biết liệu mã độc có bị cài cắm trong đó. Công nghệ mới nổi thường rất tệ trong khâu documentation. Điều này tạo ra nhiều khó khăn khi viết code. Khâu hỗ trợ cũng tệ không kém. Khi gặp lỗi, ai sẽ hỗ trợ ta? Liệu tác giả có sẵn lòng? Phải mất một khoảng thời gian để công nghệ mới gầy dựng lòng tin nơi người sử dụng. Đeo đuổi khi chưa biết rõ số phận nó ra sao chỉ phí thời gian vô ích.

Lập trình viên thường cảm thấy ganh tị khi công nghệ của đối thủ được bổ sung tính năng mới hoành tráng, trong khi công nghệ đang dùng lại không có. Họ khó cưỡng lại cái thôi thúc nhảy qua công nghệ “đối lập” để tận hưởng cái tính năng mới sành điệu. Thực ra, họ không cần phải cuống cuồng làm gì, bởi nếu tính năng đó là hữu ích, thì trong nay mai sẽ xuất hiện bản cập nhật bổ sung tính năng đó cho công nghệ họ đang dùng.

Cách đây nhiều năm khi ứng dụng chạy đa nền tảng là một chủ đề nóng, Java là cái tên được nhắc đến nhiều nhất. Vào thời điểm đó, chỉ Java có khả năng ưu việt này. Nhưng bây giờ thì mọi chuyện đã khác, hầu như công nghệ nào cũng có thể chạy đa nền tảng. Ứng dụng .NET giờ có thể chạy ngon lành trên Linux thông qua Mono. Ứng dụng C++ cũng có thể tận hưởng hương vị đa nền nhờ Qt Framework. Thậm chí ứng dụng JavaScript, vốn chỉ dành cho phía client, giờ cũng đã thoát khỏi nhà tù trình duyệt để tung hoành phía server nhờ Node.js.

Khi cái ý tưởng package manager vừa manh nha, người ta đã nhận thấy sức mạnh của nó. Thế là một loạt các công nghệ đều triển khai tính năng này: PHP thì có Composer, .NET thì có Nuget, Node.js thì có npm, Ruby thì có RubyGems, thậm chí Windows cũng có ứng dụng tương tự apt-get hay yum của Linux tên là Chocolatey. Do vậy, ta không cần phải ganh tị làm gì, vì sớm hay muộn, ta cũng sẽ được tận hưởng tính năng mới trên chính công nghệ ta thành thạo.

Học cấu trúc dữ liệu và giải thuật

Cấu trúc dữ liệu và giải thuật (Data Structures and Algorithms) là hai mặt của một đồng xu. Ta không thể nói đến một cái mà không bàn đến cái còn lại. Có những giải thuật chỉ hoạt động khi dùng một cấu trúc dữ liệu cụ thể, và cũng có những cấu trúc dữ liệu chỉ hiệu quả khi được dùng trong một giải thuật phù hợp. Nói đơn giản, giải thuật là tập hợp các bước cần làm để đạt kết quả mong muốn. Còn cấu trúc dữ liệu là cách sắp xếp, tổ chức dữ liệu trong bộ nhớ.

Lập trình viên ít khi tự tạo cấu trúc dữ liệu hay giải thuật từ con số không, vì hầu hết các công nghệ lập trình đều kèm theo một thư viện đồ sộ bao gồm cả cấu trúc dữ liệu và giải thuật. Trong .NET, ta được cung cấp nhiều class chứa cấu trúc dữ liệu (List, Stack, Queue, LinkedList), và khi cần thì ta lấy ra dùng. Giải thuật liên quan cũng được kèm theo, ví dụ để tìm một phần tử trong List thì ta dùng method Find() có sẵn. Nhờ vậy, lập trình viên không cần quan tâm chúng hoạt động ra sao mà vẫn sử dụng được.

Trớ trêu thay, nhà tuyển dụng thường hỏi xoáy vào chủ đề này khi phỏng vấn ứng viên. Dùng đúng cấu trúc dữ liệu và giải thuật góp phần tối ưu hóa code, và công ty nào cũng muốn code họ làm ra càng tối ưu càng tốt. Do đó, hiểu biết sâu về môn này là một lợi thế khi xin việc. Công nghệ, công cụ có thể thay đổi trong nay mai, nhưng kiến thức về cấu trúc dữ liệu và giải thuật không bao giờ thay đổi, và nó có thể được dùng với bất kì ngôn ngữ nào. Đây chính là nền tảng quan trọng mà lập trình viên phải nắm vững.

Học phân tích và thiết kế hướng đối tượng

Phân tích và thiết kế hướng đối tượng (Object-Oriented Analysis and Design) là bước đầu tiên trong quy trình làm phần mềm. Đây chính là khâu quan trọng nhất, vì sai sót ở khâu này sẽ lan truyền sang những khâu sau. Tuy môn này khá quan trọng nhưng lập trình viên thường cảm thấy ngán ngẩm, ngáp dài ngáp ngắn khi nhìn thấy cuốn giáo trình OOAD. Bởi lẽ lập trình viên chỉ thích viết code, còn môn này thì không có một dòng code nào cả. Thay vào đó là những biểu đồ UML (Unified Modeling Language) khô khan, nhàm chán.

Thành thực mà nói, đây quả là một môn khó nuốt. Phân tích và thiết kế sao cho đúng, hợp lý đòi hỏi phải có nhiều kinh nghiệm. Những người đang học môn này thường không có kinh nghiệm, nên khi phân tích sẽ gặp nhiều khó khăn. Điều này giải thích lý do tại sao các công ty khi tuyển dụng vào vị trí phân tích, thiết kế thì đều yêu cầu người xin việc phải có 5 năm kinh nghiệm trở lên. Một người có kinh nghiệm khi nhìn vào bài toán sẽ biết ngay hướng giải quyết như thế nào. Cũng giống như một thợ máy có kinh nghiệm chỉ cần nghe tiếng máy nổ thì biết ngay máy bị gì, hay một bác sĩ có kinh nghiệm chỉ cần nhìn nước da, sắc mặt của bệnh nhân thì biết ngay họ bị bệnh gì. Phân tích phần mềm cũng thế, kinh nghiệm sẽ giúp ta nhận ra ngay hướng đi tối ưu nhất.

Trong quy trình phát triển phần mềm, khâu viết code là khâu dễ nhất và được trả lương bèo nhất. Người viết code giống như thợ hồ cầm cục gạch và cái bay, ngồi dưới trời nắng để xây nhà. Trong khi đó, người kiến trúc sư chỉ cần ngồi trước máy tính thiết kế bản vẽ, và hưởng tiền công gấp chục lần thợ hồ. Rõ ràng, khâu phân tích, thiết kế mang tính sống còn, và người làm được khâu này phải có tay nghề cao. Đây cũng chính là mục tiêu phấn đấu của bất kỳ lập trình viên nào. Khi lên đến ngưỡng này thì lương vài ngàn đô-la một tháng là chuyện hết sức bình thường.

Với môn này, đọc vài cuốn sách hay coi vài video trên mạng là không đủ. Chỉ khi nào ta tham gia vào một dự án, và xem người có kinh nghiệm xuất chiêu, lúc đó ta mới dần dần thấm những lý thuyết đã học trong sách vở.

Lời kết

Muốn thành thạo việc gì thì hãy làm việc đó nhiều lên. Đây chính là công thức của thành công. Hãy chọn một hướng đi công nghệ rồi tập trung vào nó, luyện tập nó mỗi ngày, càng nhiều càng tốt. Đừng để tâm trí bị phân tán bởi những công nghệ khác. Đặc biệt, ta nên tránh học song song nhiều thứ cùng lúc, kẻo ta trở thành Âu Dương Phong lúc nào không hay.