Khi nào thì developer gõ code

Dưới góc nhìn của mình, developer là nhà văn đầy logic viết nên con chữ qua những đoạn mã, hay một danh hoạ đầy lí trí vẽ nên bức tranh bằng những dòng code…

Ở bài viết này, mình muốn chia sẻ một số điều đã học hỏi từ các anh chị em trong ngành cho một câu hỏi bất hủ – khi nào developer mới gõ code?


Bạn đã thấy bức tranh lớn chưa

Nếu bạn là công thần lập quốc, bạn không cần quan tâm phần này, nhưng nếu bạn là một người vừa tham gia dự án, chắc chắn sẽ luôn có một buổi giới thiệu về sứ mệnh cũng như sản phẩm mà công ty (hay chí ít là team bạn) đang thực hiện, đó chính là big picture mà bất kì developer nào cũng nên biết vào ngày đầu tiên.

Lẽ dĩ nhiên, từ bức tranh lớn đó, sẽ phân ra những mảng nhỏ hơn mà từng team hay từng member đang đảm nhận, từ đó hình thành nên các yêu cầu nghiệp vụ (business requirements) tương ứng, cuối cùng, để hiện thực hoá chúng – những dòng code bắt đầu ra đời.

Nắm được toàn cảnh và ý nghĩa của sản phẩm đang xây dựng, cũng như vai trò mà team bạn đang nắm giữ trong bức tranh lớn, là vô cùng quan trọng giúp bạn hiểu được kiến trúc và ý nghĩa những dòng code trong dự án, cũng như tham gia đóng góp thêm mà không bị trật nhịp.

Cũng không cần nhìn quá nhiều như này đâu nhé

Thực chất cũng tương tự khi các bạn đi học ở trường qua rất nhiều môn học: việc quan trọng nhất vẫn là đọc hiểu đề, phân tích yêu cầu, phác thảo cách giảo quyết, thiết kế (giao diện, luồng thực thi, kiến trúc code…), và sau đó – mới là code.

Việc lao đầu vào code ngay khi chưa nắm rõ yêu cầu, ý nghĩa của những gì mình đang làm hay hướng đi cụ thể, có thể dẫn đến nhiều hậu quả như code xấu, không cover đủ các trường hợp, logic bug, tệ hơn là có thể crash app hay làm sai lệch lượng lớn dữ liệu… dễ thấy những hậu quả này, không chỉ ảnh hưởng đến mỗi một mình bạn.

Coding giống với tìm đường ở một điểm: đừng đâm đầu đi đại.


Đừng chế tạo lại cái bánh xe

Bạn có một vấn đề cần giải quyết, bạn tìm tòi một lúc, bạn thấy có một số hàm team đã build sẵn hay một thư viện, một đoạn code đã giải quyết chính xác vấn đề gặp phải và được nhiều người sử dụng – vậy thì hãy đọc qua và ứng dụng nó hay chỉnh sửa lại một chút cho phù hợp là được.

Thói quen phải hiểu tất cả mọi thứ và phải tự tay dựng nên mọi thứ là không hề xấu trong lập trình, nhưng bạn cũng phải suy xét rằng vấn đề bạn đang gặp phải có phổ biến hay không, nếu có – tức là cũng đã có nhiều người đã giải quyết vấn đề đó và xây dựng nên các solution, thư viện hay framework rất chỉnh chu và luôn cải tiến, hãy ứng dụng chúng để tiết kiệm thời gian và công sức của bạn.

Copy code không tệ đến thế nếu bạn biết mình nên làm gì

Chỉ chế tạo cái bánh xe khi bạn biết không có cái bánh xe nào ngoài kia phù hợp cho chiếc xe của bạn, hoặc đôi khi bạn chỉ cần cải tiến lại một cái bánh xe gần đảm bảo yêu cầu là được.


Điều bất biến là mọi thứ đều khả biến

Mình cũng đã nói nhiều về phần này ở các bài viết trước – yêu cầu nghiệp vụ luôn có thể thay đổi, trước khi bạn code, khi bạn đang code hay sau khi bạn code, bạn không biết vũ trụ sẽ gửi thông điệp gì cho khách hàng hay cho team bạn để thay đổi vận mệnh của những thứ bạn đã, đang và sẽ gõ trên IDE hay code editor được.

Và chúng tôi gọi đó là cột sống

Vì vậy, hãy đảm bảo các đoạn mã, các thiết kế có thể sử dụng được lâu dài, scale up cũng như backward compatible tốt, có hai cách để thực hiện:

  • Code thật nhanh một đoạn code “đủ giải quyết vấn đề”, sau đó cân nhắc chia nhỏ, phân bố lại thành các hàm con, chia ra thêm file hay module nếu cần, hay thậm chí là refactor…
  • Phác thảo chi tiết những step cần thực hiện để giải quyết vấn đề, suy xét một chút xem có thể tối ưu hơn không về mặt code, kiến trúc, xử lí và khả năng tái sử dụng… và sau đó là code (nếu may mắn, bạn có thể làm luôn cả cách 1 =P).

Cách tiếp cận nào cũng có những ưu và nhược riêng, tuy nhiên hãy luôn đảm bảo được tinh thần rằng code của bạn có thể thích nghi và mở rộng được càng nhiều thay đổi về yêu cầu nghiệp vụ theo thời gian càng tốt.


Thứ có thể làm, không có nghĩa là nên làm

Đôi khi thứ mà khách hàng cần là một tool đã có sẵn thay vì muốn bạn tạo thêm một chức năng (trừ khi họ nói rõ là họ muốn bạn code).

Đôi khi những tính năng vốn đã và đang vận hành tốt thì dù biết có thể cải thiện, hãy thật cẩn thận, nên hỏi thử đồng nghiệp là tại sao chỗ code này bá dơ vậy mà chưa ai sửa nữa nhé.

Đôi khi code dễ đọc dễ hiểu hiểu quan trọng hơn việc áp dụng thuật toán nếu performance không quá chênh lệch.

Cái gì quá cũng không tốt

Bạn hát hay nhảy đẹp, không có nghĩa là bạn nên thể hiện nó ở đám tang.

Bạn biết nhiều bài bolero hay, không có nghĩa là bạn phải mở nó trong bar.

Bạn lập trình tốt, không có nghĩa là vấn đề nào bạn cũng xử lí bằng code.


Mình thích thì mình cứ code thôi

Bạn vừa tìm hiểu một công nghê, ngôn ngữ nào đó mới và hay ho, có thể ứng dụng trong tương lai hay trong project, và luôn có tiếng gọi thôi thúc bạn phải dùng thử, đây chính là lúc bạn nên gõ code và chiêm nghiệm.

Những lúc cần ứng dụng thư viện, công nghệ mới vào dự án, hãy đảm bảo bạn thật thận trọng trong việc sử dụng chúng, tốt nhất hãy code trên project cá nhân, chia sẻ cách ứng dụng, thuyết phục mọi người về hiệu quả của nó, và sau đó là áp dụng vào dự án.

Pet project hay open source – hai miền đất hứa thoã mãn đam mê coding của bạn

Hoặc đôi khi bạn muốn thử tìm luồng gió mới cho các pet project hay muốn đóng góp vào các open source, hãy thoải mái code và đóng góp các thử nghiệm nhé.


Developer không chỉ là gõ code

Không một nhà văn nào dành hết cả ngày chỉ viết.

Không một hoạ sĩ nào dành hết cả ngày để vẽ.

Không một developer nào dành hết cả ngày để code.

Cả ba đều cần tìm chất liệu cho mình, riêng phần developer, các chất liệu đó có thể đến từ việc học hỏi từ rất nhiều nguồn: một ngôn ngữ, một công nghệ, một ý tưởng, một vấn đề, một thuật toán, một yêu cầu nghiệp vụ, một code review comment…

Khi đó, developer không chỉ còn gõ code, họ còn lắng nghe, giao tiếp, nhìn vấn đề theo nhiều chiều, thiết kế, ghi chép, sáng tạo và luôn đi tìm nguồn cảm hứng nữa.

Suy cho cùng, code chỉ là cách mà họ trình bày cách giải cho một bài toán mà thôi, các developer luôn thích giải toán để tìm ra các cách giải thật hay và sáng tạo mà đúng không =)

Vì developer không phải là coder :>

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s