Viết code Viết tiểu thuyết

Spread the love

Bài viết được dịch từ : Hackernoon

Nhân vật

Khi bắt đầu viết tiểu thuyết, tác giả cần phải đặt mình vào hoàn cảnh của từng nhân vật. Tác giả phải hiểu rõ từng đặc điểm của nhân vật trong tiểu thuyết của mình, tính cách của họ, cách họ phản ứng, hành động, những thứ họ yêu/ghét, cũng như lối suy nghĩ của nhân vật. Ở đây tôi dùng chữ “làm quen” bởi vì dù nhân vật có được chính nhà văn nhào nặn suy nghĩ đi chăng nữa thì cũng hiếm khi nhà văn hiểu được chính nhân vật họ sáng tạo ra ngay từ đầu câu chuyện; nhân vật sẽ được hoàn thiện và phát triển qua quá trình sáng tạo của nhà văn.

Lập trình viên cũng ở trong một hoàn cảnh tương tự, nhưng thay vì đối diện với những nhân vật của mình, ở đây chúng ta có khách hàng. Cho dù chúng ta nghĩ rằng mình có thể hiểu được yêu cầu của khách hàng ngay tại lần đầu tiên nghe họ trình bày, nó không có nghĩa là lần sau chúng ta có thể hiểu hết được yêu cầu của họ, và yêu cầu ở lần nghe đầu tiên không đổi. Chúng ta có thể làm ra một chương trình quản lý cực kì chi tiết và đầy đủ , nhưng không có nghĩa là người dùng chúng ta sẽ cần những thứ cao siêu đó, có thể họ dùng chương trình chỉ vì nó xuất được một report (vâng chỉ một report trong số hàng trăm report chúng ta tạo ra ) chính xác.

Khi điều này xảy ra, có thể bạn nghĩ “Oh sh!t,” và thấy công sức của mình bị phung phí, tuy nhiên chúng ta không thể nào bắt khách hàng bất biến được. Họ cần một tính năng ở ngày đầu tiên, không có nghĩa là họ cần nó ở ngày thứ 2. Một tính năng họ cho là hữu ích ở ngày đầu tiên có thể trở nên không hữu ích ở ngày tiếp theo và bạn phải thay đổi (cách nghĩ + chương trình ) để có thể hiểu được và đáp ứng nhu cầu của khách hàng

Mọi thứ bắt đầu từ một dòng code

Nhà văn viết, họ viết rất nhiều, họ cho rằng viết càng nhiều càng tốt, bởi đó là cách tốt nhất để biết được chính xác rằng sản phầm họ viết ra sẽ được nhàu nát trong sọt rác hoặc tốn hàng ngày trời để chỉnh sưuar nó. Dẫu biết rằng để bắt đầu viết thứ gì đó sẽ rất khó khăn, nhưng đó là cách duy nhất để họ tiếp cận được với ý tưởng ngay trong đầu họ (mà có lẽ lúc bắt đầu họ còn chưa hiểu được nó ). Thông thường nhà văn sẽ trải qua giai đoạn nháp đầu tiên, thứ 2, thứ 3 , thứ 4 và có khi còn hơn nữa

Điều tương tự cũng xảy ra khi lập trình. Lần thử đầu tiên của lập trình viên chúng ta luôn là viết sao cho đoạn code compile được và chạy được như dự định (có thể ko phải là toàn bộ các trường hợp, chỉ là một hoặc hai trường hợp thông thường ). Sau đó bạn sẽ trở lại, xem lại đoạn code của mình cho đến khi phát hiện vài điểm thừa, trùng lặp, hoặc vấn đề liên quan đến hiệu năng.

Dần dần, khi tích luỹ được nhiều kinh nghiệm hơn, đoạn code đầu tiên bạn viết sẽ trở nên sáng sủa và súc tích hơn. Hãy ghi nhớ rằng chúng ta luôn luôn có thể hoàn thiện code tốt hơn. Và nên nhớ vào cuối ngày “một đoạn code xấu mà chạy được” sẽ ăn đứt một đoạn code “có vẻ hoàn hảo nhưng chưa làm được tích sự gì”. Hãy nhớ điều đó, hãy viết code chạy được trước, sau đó hoàn thiện nó (chỉ là đừng trì hoãn việc hoàn thiện nó quá lâu lúc đó bạn sẽ không nhớ mớ bòng bong mình đã viết đâu 😀 )

Code mỗi ngày

Nhà văn luôn luôn nhấn mạnh rằng họ cần một thứ thói quen , nên họ viết mỗi ngày. (Hơi ngoài lề xíu, nhà văn yêu thích của mình, Haruki Murakami là một nhà văn, có lẽ ông cũng viết mỗi ngày, nhưng ngoài ra ông cũng chạy bộ mỗi ngày ). Không quan trọng là họ viết cái gì , đơn giản là họ viết. Có thể đó là một đoạn bình luận về một quyển sách, làm một bài thơ, phân tích một đoạn văn … bất cứ thể loại nào liên quan đến viết-có-chủ-đích. Tại sao nhà văn lại làm thế ? Họ làm thế vì : nhạc sĩ , vận động viên, diễn viên hài, đầu bếp đều làm thế mỗi ngày. Rèn luyện thường xuyên giúp chúng ta tốt hơn

Là một lập trình viên, chúng ta cũng cần rèn luyện hằng ngày để trở hoàn thiện khả năng hơn. Chúng ta có thể học một ngôn ngữ mới, add thêm tính năng vào ứng dụng hiện hành, hoặc viết lại một đoạn code nào đấy. Hãy tập thể thao cho tư duy của bạn, vì khi bạn đổ mồ hôi suy nghĩ cho một đoạn code hôm nay, thì giọt mồ hôi đó sẽ không đổ cho đoạn code nào đó ở tương lai. Và nếu chúng ta vận động đầu óc thường xuyên, dường như chúng ta sẽ có giải pháp ngắn ngọn, hiệu quả hơn cho mai sau. Và nên nhớ rằng, cho dù có đọc bao nhiêu sách vở, xem bao nhiêu tutorials, tham dự hàng trăm ngàn hội thảo đi chăng nữa, nếu cuối ngày, chúng ta không chịu ngồi lại, vận dụng những kiến thức đấy, suy nghĩ cách áp dụng nó thì sẽ không bao giờ nhớ được chúng (vận dụng được thì chắc còn khó hơn, vì có nhớ đâu mà vận dụng :D)

Tự phản biện hay là đối diện với việc bị ném cà chua thối

Đôi khi một nhà văn mất hàng tháng trời, thậm chí hàng năm để tạo ra tác phẩm của mình, nhưng chỉ mất 1 tuần lễ để nhà xuất bản từ chối xuất bản tác phầm của họ. Có hàng tỉ rào cản trong quá trình sản xuất ra sản phẩm trí truệ, và bị từ chối, chê bai là hoàn toàn có thể xảy ra ngay cả những tác giả có tên tuổi. Khi sáng tác một tác phẩm, nhà văn đã đồng thời gieo hai loại hạt, một mặt họ kì vọng tác phẩm lần này sẽ được công chúng đón nhận , một mặt nỗi sợ hãi bị tẩy chay, hay cho ra đời một tác phẩm không nhiều giá trị cũng ám ảnh họ.

Lập trình viên cũng thế, khi chúng ta viết những dòng code, đều hi vọng code sẽ compile được và chạy ổn định, một mặt chúng ta cũng tiến gần hơn với việc sắp cho ra đời những đoạn code “thối”, code “rối như mì gói” … Tất nhiên nỗi sợ ấy không chỉ ám ảnh các lập trình viên đang code, sau này, nếu code của bạn “thối” thật sự thì nó còn ám ảnh cả những lập trình viên phải maintain đoạn code đó nữa…. Những lúc cảm thấy thật sự rối và sắp cho ra đời những đoạn code “thối”, hãy tự đứng lên , gập laptop lại và hít thở (thật ra lúc code chúng ta cũng hít thở , chỉ là lúc đấy thì nỗi sợ code-thối, code-không-compile-được đã tràn ngập tâm trí)…. để cảm thấy cân bằng lại. Nếu vẫn sợ, hãy mở lại đoạn code cách đây vài năm của chính bạn, lúc đấy khi nhìn vào đám “rừng già nhiệt đới” đó bạn sẽ thêm vững tin rằng đoạn code sắp tới của mình sẽ ăn đứt bạn của vài năm trước. Nên nhớ , hãy tự “phản biện” -“review” lại chính đoạn code của mình để thấy được sai lầm của mình :-).

Kết

Khi đọc đến những dòng này, cũng sắp đến đoạn kết. Có thể bạn là lập trình viên, hoặc đơn giản chỉ ghé ngang trang web này, nhưng cám ơn vì bạn đã đến được đoạn kết 😀 . Chúng ta đều đơn giản là có những lựa chọn cho bản thân mình, từ giây phút chúng ta lựa chọn đó chúng ta đã đối diện với kết quả (ví dụ như bạn đọc đến đây thì chắc cũng đã tốn hết gần cả phút quí giá của cuộc đời bạn 😀 ). Có nhà văn từng nói “Đau đớn là không thể tránh khỏi, đau khổ là tự lựa chọn“, tự bản thân mình cũng cảm thấy điều này là đúng đắn. Khi chúng ta chọn nghề lập trình, có những lúc rất đau đớn khi phải đập đi toàn bộ code sửa lại chỉ vì khách hàng thay đổi yêu cầu, hay những khi vãi mồ hôi fix bug production chỉ vì đoạn code chúng ta viết quá rối …  đau đớn đó là điều không thể tránh khỏi, tuy nhiên ta có thể giảm bớt sự đau đớn bằng cách thực hành các sự đau khổ . Biết đâu nhờ vậy sau này chúng ta còn không cảm thấy đau đớn nữa 😀 (vô cảm luôn :P)

 

Leave a Reply

Your email address will not be published. Required fields are marked *