Tuyệt kỹ lập trình nhanh: Hãy dừng suy nghĩ.

Mối khi nói chuyện với các lập trình viên về sự phức tạp của code, đa số họ thường chỉ muốn viết những dòng code đơn giản nhất. Tuy nhiên, với áp lực của deadline và những vấn đề xung quanh luôn khiến họ không thể dành nhiều thời gian và tâm sức để hoàn thành phần code của mình cho gọn gàng sạch sẽ được.

Thực tế cho thấy, việc đặt áp lực thời gian lên các lập trình viên sẽ khiến họ phải viết những đoạn code phức tạp hơn. Thay vì nói trong đầu “Deadline này sẽ cản trở tôi viết những dòng code sạch đẹp”, họ có thể nói, “Tôi không đủ nhanh để viết nó gọn gàng sạch sẽ”. Vì đơn giản là thế này, skill lập trình của bạn càng tăng thì chuyện deadline ảnh hưởng tới chất lượng code cũng sẽ bớt đi.

Nghe có vẻ rất lý tưởng, nhưng làm sao để một người lập trình viên có thể code nhanh hơn? Liệu đây có phải là một kỹ năng mà chúng được thiên bẩm? Hoàn toàn không? Thật ra đó không phải phép màu hay trời phú hay gì cả. Thực tế chỉ có 1 quy luật rất đơn giản, nếu các lập trình viên tuân theo, vấn đề sẽ được giải quyết triệt để.

Mỗi khi bạn thấy mình đang phải dừng lại để suy nghĩ, thì có thể đã có gì đó không đúng xảy ra.

Có lẽ điều này nghe hơi “kỳ vỹ” nhưng nó lại tỏ ra khá hiệu quả. Hãy nghĩ đến lúc mà bạn ngồi trước mặt editor của mình nhưng bạn lại code không được nhanh lắm, phải chăng do bạn “mổ cò” hơi chậm? Tôi không nghĩ đó là vấn đề. Vấn đề nằm ở chỗ, những khoảng dừng suy nghĩ chính là cản trở chính làm bạn type chậm đi. Và các lập trình viên thường làm gì trong các khoảng dừng đó? Có thể họ đang nghĩ về những vấn đề, những tool cần dùng, email, và rất nhiều thứ linh tinh khác.

Việc suy nghĩ thật ra không phải là một thứ gì đó nghiêm trọng, nhưng đó là dấu hiệu báo rằng đang có một số vấn đề khác đang xảy ra. Đó có thể là một trong những điều sau đây:

Hiểu chưa tường tận!

Một trong những lý do lập trình viên bị lấn cấn chính là vì họ không hoàn toàn hiểu một số từ hoặc ký hiệu trong lập trình.

Điều này cũng vừa mới xảy ra đối với tôi trong thời gian gần đây. Nó khiến tôi phải mất nhiều tiếng đồng hồ trong ngày chỉ “bơi lội” trong những thứ khá đơn giản, đáng lẽ phải xong từ lâu. Tôi phải dừng lại khá nhiều lần để suy nghĩ. Và cuối cùng tôi đã nhận ra rằng mình không hiểu một trong những input variables của tính năng chính. Tôi biết tên của loại này nhưng lại chưa bao giờ đọc về định nghĩa của nó, vì vậy tôi đã không thật sự hiểu về variable đấy. Sau khi lục lọi và tìm tòi lại về những lỗ hổng của mình, mọi thứ đã dần trở nên rõ ràng hơn, tốc độ xử lý của tôi đã tăng lên “lợi hại” hơn gấp nhiều lần.

Điều này có thể xảy ra trong bất cứ tình huống nào. Rất nhiều người đã nhảy vào lập trình mà không thật sự hiểu các ký hiệu (, ), [, ], {, }, +, *, and % thật sự có ý nghĩa gì, chúng hoạt động như thế nào. Khi bạn thật sự hiểu về nó, bạn không cần phải dừng lại để suy nghĩ. Đó là lý do vì sao tôi đã viết quyển “The Singular Secret of the Rockstar Programmer”, nó sẽ giúp bạn có những hiểu biết sâu hơn nhằm tránh những sai lầm thường mắc phải.

Vậy khi bạn thấy mình phải dừng lại để suy nghĩ, đừng cố giải quyết vấn đề bằng cách nhìn vào những thứ mà bạn chưa thật sự hiểu rõ. Hãy đi tìm những kiến thức giúp bản hiểu rõ bản chất của chúng trước. Thậm chí nó còn có thể giúp bạn trả lời những câu hỏi như “Liệu người dùng có đọc những đoạn text này không?”. Tuy bạn không có một đội nghiên cứu về User Experience (trải nghiệm người dùng. Nhưng bạn ít nhất có thể đoán được phần nào câu trả lời. Đừng chỉ ngồi đó và nghĩ, hãy LÀM gì đấy!)

Phác thảo ra vấn đề!

Đôi khi, các lập trình viên phải dừng lại để nghĩ vì họ có quá nhiều khái niệm và kiến thức trong đầu khiến họ không thể liên kết chúng lại một cách mạch lạc được. Trong trường hợp đó, bạn có thể viết hoặc phát thảo những ý tưởng ra như một mindmap hẳn hoi, nói chung là bất cứ thứ gì mà bạn có thể nhìn một cách trực quan. Bạn chỉ có thể hiểu nó một cách tường tận và bao quát nhất bằng cách quan sát nó từ bên ngoài.

Cứ hãy làm đi cái đã!

Thỉnh thoảng, vấn đề lại nằm ở chỗ bạn chẳng biết bắt đầu từ đâu. Giải pháp đơn giản nhất chính là bắt đầu viết bất cứ đoạn code nào mà bạn có thể viết xuống. Sau đó chọn ra một phần của vấn đề mà bạn có thể hiểu rõ nhất. Sau đó viết ra những giải pháp cho nó hoặc bạn có thể viết ra một tính năng hay một class nào đó không quan trọng cũng được.

Đôi khi, phần đơn giản nhất của đoạn code mà bạn có thể bắt đầu chính là “hạt nhân” (core) của ứng dụng. Ví dụ, nếu tôi bắt đầu viết một app cho Youtube, tôi có thể bắt đầu viết một ứng dụng video player chẳng hạn. Hãy nghĩ nó như một bài “khởi động” có thể giúp bạn có thể tiến sâu trong việc viết sản phẩm hơn nữa, và cũng đừng quá quan trọng rằng nó chỉ là một phần nhỏ của sản phầm hay không. Một ứng dụng video player nếu chưa có UI vẫn là một sản phẩm khả dụng (play video chẳng hạn), ngay cả khi nó chưa được hoàn chỉnh.

Nếu bạn không chắc rằng mình có thể bắt đầu viết đoạn code chính (core) như thế nào thì bạn hoàn toàn có thể bắt đầu bằng đoạn code nào mà bạn nắm chắc nhất. Về cơ bản, tôi nghĩ rằng, giải quyết vấn đề theo từng mảng miếng nhỏ sẽ dễ hơn là tìm cách giải quyết toàn bộ đống tơ vò trong cùng một lúc. Thỉnh thoảng, vấn đề sẽ được “vô tình” giải quyết khi bạn đang giải quyết những bước nhỏ kia (one step at a time), và nó sẽ kéo theo nhiều vấn đề khác cũng được tháo gỡ. Nói chung, phần nào không cần phải nghĩ quá nhiều, hãy dứt điểm phần đó trước.

Phi nước đại

Một trong những phương pháp đặc biệt giúp bạn hiểu rõ vấn đề là hãy bỏ qua một vài bước trong việc phát triển sản phẩm (sequence of development). Ví dụ, nếu bạn muốn viết toàn bộ một Object “Xe đạp” chẳng hạn mà không muốn viết “Bánh xe”, “tay lái” hay là “khung sườn” object, bạn sẽ phải nghĩ rất nhiều về những classes chưa tồn tại kia. Mặt khác, nếu bạn viết “Bánh xe” class khi mà không có “Xe đạp” class, bạn sẽ phải nghĩ rất nhiều về việc làm sao để dùng “bánh xe” class cho “Xe đạp” class.

Giải pháp đúng cho vấn đề này là làm đủ để “xe đạp” class có thể đạt đến điểm mà bạn bắt đầu cần “bánh xe”. Và viết đủ để “bánh xe” class có thể thoả mản ngay lập tức nhu cầu của “xe đạp” class. Khi trở về với “xe đạp” class, và làm cho đến khi bạn cần một mảnh ghép khác. Cũng như những gì tôi đã đề cập trước đây, hãy tìm những phần bạn có thể giải quyết mà không cần suy nghĩ trước, và giải quyết nó ngay lập tức. Đừng nhảy qua nhảy lại các bước trong quy trình phát triển hệ thống và mong rằng bạn có thể code hiệu quả được.

Thể trạng cơ thể.

Tôi không hề nói đùa, nếu không ăn đủ tôi sẽ mất tập trung vì bị đói bụng. Những suy nghĩ sẽ tập trung vào cái bao tử hơn là code. Điều này cũng sẽ xảy ra khi bạn thiếu ngủ hay đang bị bệnh. Nói chung là mọi vấn đề về thể chất của cơ thể đều có liên quan.

Sự xao nhãng.

Khi lập trình viên bị phân tâm bởi những yếu tố bên ngoài, như tiếng ồn, người ra người vào, tiếng đóng cửa, tiếng nói chuyện ồn ào,v.v nó có thể là một trong những vấn đề chính làm bạn mất tập trung. Câu trả lời đơn giản chỉ là hãy tạo cho bạn một môi trường mà bạn không bị mất tập trung, ít nhất hãy làm việc với những đồng nghiệp biết giữ im lặng.

Ngờ vực bản thân

Có những lúc lập trình viên hay ngồi nghĩ về những quyết định của họ. Giải pháp cũng y như phần “hiểu tường tận” mà tôi đề cập ở trên, hãy tìm cách hiểu rõ tường tận các vấn đề trước khi lao vào code. Nếu bạn cảm thấy không chắc chắn vào bản thân mình, hãy liệt ra những thứ mà bạn chưa hiểu rồi dần dần nghiên cứu về chúng. Vì trong lập trình, sự học hỏi luôn luôn được tiếp diễn liên tục. Ban đầu tuy có hơi chậm nhưng bạn sẽ dần hiểu rõ hơn về nó và việc code cũng sẽ được cải thiện đáng kể.

Những khái niệm sai lầm

Nhiều người nói rằng, việc suy nghĩ là của những người thông minh, họ thường chậm lại để suy nghĩ kỹ càng và đưa ra quyết định. Đây là một khái niệm sai lầm. Nếu việc suy nghĩ biến bạn thành thiên tài, thì chắc có lẽ tất cả đã là Einstein. Người thật sự thông minh là người biết học, quan sát, quyết định, và hành động. Họ lấy được kiến thức và dùng kiến thức đó để giải quyết những vẫn đề trước mắt. Nếu bạn thật sự thông minh, hãy dùng trí thông minh của mình để hành động, đừng dùng nó chỉ để “suy nghĩ!?”

Caveat

Tất cả những điều đề cập ở trên là những bí mật để trở thành một tay “lập trình thần tốc”. Nếu bạn phải đọc email và họp hành cả ngày, không có công việc lập trình nào được làm thì đó là một vấn đề khác. Một số vấn đề có cùng một góc nhìn, nhưng nó không thật sự giống nhau.

Còn một số giải pháp nữa bạn có thể thử, tin tôi đi… Và có lẽ phía công ty vẫn chưa hiểu hết vai trò của bạn, đó là vì do họ đẩy xuống cho bạn quá nhiều email cũng như các cuộc họp hành không cần thiết. Và cũng có lẽ, bạn cũng chưa thật sự hiểu công ty của mình, chưa biết cách nào để phải họp hành ít hơn, để nhận ít email hơn. Thậm chí, một số khó khăn hoàn toàn có thể giải quyết bằng cách dùng những phương pháp mà tôi đề cập ở đây cho một nhóm người trong công ty hơn là chỉ cho 1 vài người nhất định.

Techtalk via codesimplicity