Code có thể thối - Nhưng bạn thì không
code
38
Git
51
oop
15
White

ShinaBR2 viết ngày 23/11/2017

Bàn về code thối

Hãy tự đặt câu hỏi cho bạn, khi bắt đầu lập trình, bạn nghĩ tới điều gì?

Đi phỏng vấn

Điều đầu tiên tôi muốn nói về những câu hỏi khi bạn đi phỏng vấn. Cá nhân tôi cảm thấy không phải ai cũng đủ giỏi để phỏng vấn một ứng viên, hoặc nói thẳng ra từ trước giờ chưa có một ai phỏng vấn mà khiến tôi cảm thấy nể phục. Xét về quan điểm kỹ thuật, cái mà tôi nhấn mạnh nhất nhất và đầu tiên trong lập trình, đó chính là Cấu trúc dữ liệu.
Có thể bạn sẽ thắc mắc hai chữ thuật toán nằm ở đâu rồi? Trong chương trình đại học có một môn học như thế và tôi cũng nhớ nhiều người khi đi làm họ đều nhấn mạnh đây là một trong những thứ quan trọng nhất. Chắc chắn rồi, nhưng với tôi, mọi thứ đơn giản hơn, bởi vì chính cấu trúc dữ liệu sẽ định nghĩa thuật toán và là kiến trúc cho toàn bộ hệ thống.
Quay lại câu chuyện phỏng vấn. Trong một lần gần đây, khi phỏng vấn tôi được hỏi một cách rất rập khuôn và bài bản những câu hỏi nằm trong danh sách "Những câu hay được hỏi khi phỏng vấn", tra google vài phút là có. Tôi ứng tuyển vị trí lập trình frontend, họ hỏi hết sức cơ bản là phân biệt array với linked list. Bạn có nghĩ tôi sẽ trả lời rành rọt như trong tài liệu môn cấu trúc dữ liệu không? Dĩ nhiên là tôi chả nhớ rồi :))
Bạn có thể dừng đọc tại đây khi mà cho rằng một thằng lập trình viên không nắm được cái cơ bản ấy thì làm được trò trống gì. Đúng, và tôi cũng chẳng quan tâm lại về kiến thức đó. Tôi lập trình Javascript là chủ yếu, tôi có array push và cũng có assign object. Khi cần truy xuất theo key, tôi có object, khi cần lặp nhanh, tôi có array, vậy chắc đủ nhỉ.

Bắt đầu một dự án

Bạn đang băn khoăn khi còn chưa biết tôi muốn viết gì? Quay trở lại câu hỏi đầu tiên của tôi, nó liên quan phần trên nữa đấy.
Ngu kiến của tôi cho rằng việc đầu tiên khi bắt đầu xây dựng 1 dự án, dù là làm frontend hay backend, là xây dựng một cấu trúc dữ liệu rõ ràng. Sẽ còn nhiều yếu tố khác, nhưng đầu tiên, hãy làm cho tất cả mọi thứ sáng tỏ đã, kể cả server lẫn client.
Tôi chắc chắn ai đó đã từng nhận một project đã được làm trước đó, sẽ có một khát khao mãnh liệt là đập đi làm lại từ đầu. Và vấn đề không phải là lập trình viên trước đó code dở, xử lý không hay... mà là vấn đề về cấu trúc. Một cấu trúc sai từ đầu, thì càng làm chỉ càng sai. Đơn giản vậy thôi.
Cá nhân tôi là một lập trình viên frontend, tôi luôn đề cao một việc tưởng chừng rất đơn giản, đó là tự định nghĩa cấu trúc dữ liệu ở phía client. Và thật ngạc nhiên, khi tôi nhận ra không phải lập trình viên nào cũng biết điều đó, ngay cả những leader, thậm chí có cả tech lead.
Định nghĩa cấu trúc dữ liệu ở phía client có nghĩa là bạn tự đề ra một cấu trúc dữ liệu cho riêng mình xử lý, và sẽ có một bộ phận làm nhiệm vụ chuyển đổi dữ liệu nhận từ API về sang dữ liệu bạn cần ở client.
Hãy tưởng tượng một cấu trúc đơn giản của một object product trả về từ API có những key là product_id, name, owner... Một lập trình viên lười biếng sẽ dùng chính những key đó để sử dụng ở phía client. Và hãy tưởng tượng chuyện gì xảy ra nếu như API chỉ cần đổi product_id thành p_id hay productId. Mọi chuyện sẽ rất dễ dàng nếu như bạn định nghĩa sẵn cho mình dưới client một object với những key tương ứng là productId, name, owner và dùng một bộ map tương ứng qua. Vì những giá trị đó bạn tự định nghĩa nên với client, nó là thứ không bao giờ thay đổi dù cho API có thay đổi như thế nào.
Tôi luôn làm điều đó để project của mình hoạt động trơn tru và dễ mở rộng bất cứ khi nào tôi cần, và chẳng cần biết linked list với array khác nhau ra sao cả. Thật đấy! Không phải ngẫu nhiên mà các framework bây giờ đều có tên dạng MVC, MVP, MV... đâu. Model MUST be always the first thing you have to think about.

Git

Chắc hẳn bạn sẽ cảm thấy rất đỗi quen thuộc với những bản tin tìm dev yêu cầu sử dụng Git thành thạo. Và tôi đoán cũng không ít lập trình viên sau khoảng 3 tháng sử dụng Git, biết commit, pull và push, lâu lâu resolve conflict dùng tool đã tự tin ghi vào CV dòng tôi in đậm ở trên. Tôi cũng từng như thế :))
Về tác dụng của Git, không cần phải nói nữa, tôi chỉ muốn nói tới tác hại của nó. Là như ở trên, nó quá dễ để tiếp cận, nhưng không phải ai cũng sử dụng thành thạo. Không phải cứ thuộc câu lệnh, gõ như máy vào command line nghĩa là familiar với Git. Mọi thứ trong Git đều được ghi rất rõ ràng trên docs, nhưng chẳng mấy ai đọc, chỉ cần làm qua loa commit, pull, push là tự vỗ ngực rung đùi ta đây nắm được bay rồi. Tuy nhiên sẽ rất là nực cười nếu như bạn không thể nào làm việc được với Git chỉ vì đã quen làm với SourceTree rồi và máy chưa cài phần mềm này.
Có những tip khi làm việc với Git, và tùy vào dự án, bạn hãy lựa chọn câu trả lời phù hợp cho mình.

  • Git flow như thế nào?
  • Nếu dùng nhiều branch, đặt tên branch như thế nào.
  • Format cho commit message, commit message như thế nào là hợp lý.
  • Phân quyền tương ứng để không phải ai cũng được push tùy tiện lên một branch nào đó, thường là master.
  • Hãy thử tìm hiểu và sử dụng git tag.
  • Phân biệt được merge và rebase.
  • Biết cách sử dụng cherry pick.
  • Chú ý Git trên Windows và Linux có những điểm khác nhau (Line ending, chmod mode...)

Tuy nhiên, điều quan trọng nhất, theo tôi đó là hãy cố gắng ghi nhớ trong đầu về khái niệm của commit, đó là một thời điểm mà bất cứ khi nào checkout về, code của bạn phải thực hiện được 1 tính năng nào đó.

IDE hay editor

Cái này có quan trọng không? Theo tôi là có. Sử dụng một trình IDE hay editor, theo tôi nó không cho thấy bạn code hay dở thế nào, mà là cách bạn tổ chức công việc, quản lý code và sử dụng những công cụ để phục vụ cho mục đích code tốt nhất có thể. Tôi không cần thiết, và cũng không muốn phải đợi 30 giây chỉ để cho Jetbrain IDEs khởi động xong, tôi thích dùng Sublime Text hơn. Hoặc notepad++ cũng được, chỉ cần không phải là DreamWeaver hay notepad :))
Tuy nhiên cần chú ý những cái này, theo tôi nó hữu ích:

  • Code folding.
  • BOM.
  • Line ending (LF/CLRF) <== Đừng xem thường cái này
  • code formating tool, ví dụ eslint, jslint, bất cứ cái gì khiến bạn thấy thoải mái.
  • Phím tắt, search sẽ hữu ích khi bạn cực kỳ quen thuộc với 1 IDE/Editor bất kỳ, nhưng đừng để nó cản trở khi bạn phải làm việc với một IDE/Editor tương tự khác.

Comment trong code

Đây thực sự là một chủ đề hay ho, và có thể bạn sẽ gây ra một cuộc chiến giữa hai phe, có hay không nên comment trong code. Theo tôi, hãy comment theo cách của bạn, đã có rất nhiều bài viết về cách comment như thế nào rồi. Bạn thực sự sẽ là một vị thánh nếu như một intern hiểu được thứ bạn đang code chạy như thế nào. Không phải ngẫu nhiên mà tôi tách phần này ra, nó thực sự cho thấy bạn code chuyên nghiệp hay không đấy.

Tools

Tôi xin lướt qua một vài thứ hữu ích cho những bạn newbie frontend developer như tôi. I love Javascript, so please feel relax to this tool list :)))

  • HTML validator, có rất nhiều tool hỗ trợ. HTML luôn là cái đầu tiên bạn nên nghĩ tới, vì nó là cái cấu trúc, sai cấu trúc rồi, thì càng sửa càng sai thôi. Nhắc tới đây tôi càng thấy nực cười khi ở đây phỏng vấn cũng yêu cầu SEO onpage, nhưng khi vào làm chẳng thấy có một chỗ nào mà dev ở đó xài tool để validate HTML :))
  • Less, sass, BEM... đừng ham chạy theo công nghệ, hãy sáng suốt lựa chọn cái nào phù hợp nhất với dự án. CSS mới thực sự là vấn đề đáng lo ngại nhất, hơn hẳn Javascript nhiều đấy.
  • Chrome developer tool hay bất cứ tool debug nào bạn quen thuộc. Khả năng debug thực sự sẽ làm bạn có giá trị và nó thực sự cho thấy khả năng nhìn nhận, giải quyết vấn đề, chứ không phải muốn ghi vào CV là được đâu :)) mà tôi cũng chưa tìm được ai phỏng vấn mà hỏi câu nào khiến tôi trình bày được khả năng giải quyết vấn đề của mình như thế nào.
  • OOP giờ không chỉ còn là khái niệm chỉ dành cho Javascript nữa, hãy áp dụng nó cho cả HTML và CSS.
  • Task runner là một ý kiến hay, nhưng tôi ưa thích webpack hơn.
  • Hãy luôn chắc rằng mọi thứ hoạt động gần như là như nhau trên các trình duyệt phổ biến, cá nhân tôi thì không quan tâm IE, tuy nhiên bạn đừng học theo :))
  • Công cụ quản lý code, quản lý task, công cụ build task, code integration...
  • Còn nhiều lắm

Tips

Khi bạn đã xây dựng được cấu trúc dữ liệu tạm ổn (luôn luôn là cấu trúc dữ liệu đầu tiên), thì bạn đã có thể dễ dàng xử lý mọi thứ like a boss :))

  • Hãy học tập cách cấu trúc thư mục của một dự án. Thư mục dành cho file config, file assets...
  • Hãy tập cách tách riêng nội dung và xử lý logic, một lập trình viên chuyên nghiệp sẽ không bao giờ sẽ phải sửa code mỗi khi một message hay một label nào đó thay đổi. Cái này cũng không phải là gì quá phức tạp, nhưng nó đánh giá được nhiều sự chuyên nghiệp trong cách code của bạn, cũng giống như việc định nghĩa cấu trúc dữ liệu cho riêng mình vậy.
  • Hãy tập suy nghĩ về business của dự án như là product owner, nó sẽ còn có tác dụng giúp bạn nhìn nhận những vấn đề kỹ thuật một cách chính xác và đơn giản hơn.
  • Và cuối cùng, hãy tập cách suy nghĩ kỹ càng. Đối với một lập trình viên frontend, việc xử lý lỗi, xử lý khi loading, xử lý khi chưa có dữ liệu... những thứ tưởng chừng rất đơn giản nhưng đòi hỏi sự tỉ mỉ và kiên nhẫn, đôi khi sẽ định nghĩa giá trị con người bạn. Bạn đã từng nghe qua câu chuyện một button đáng giá triệu đô chưa?

Kết

Bất cứ ai làm dev, cũng đã trải qua thời kỳ mình code, nói thẳng ra là thối không thể chấp nhận được. Tuy nhiên, dev là cả một quá trình dài, hãy luyện tập từng ngày, hi vọng những gì một lập trình viên cùi bắp như tôi kể trên, sẽ giúp ích cho bạn.

ShinaBR2 23-11-2017

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

ShinaBR2

10 bài viết.
86 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
54 16
Đây là một vấn đề kinh điển, và có rất nhiều bài viết về nó, tuy nhiên đa phần là dịch từ bản gốc ra và sao chép lại một vài câu lệnh, và câu hỏi t...
ShinaBR2 viết 7 tháng trước
54 16
White
32 9
Vào một ngày đẹp trời, khi bạn nhận được yêu cầu phải thiết kế database cho một hệ thống, câu hỏi đầu tiên được đặt ra, quy trình làm ra nó sẽ cụ t...
ShinaBR2 viết 7 tháng trước
32 9
White
21 6
Trước khi viết bài này, mình cũng đã chịu khó ngồi search kipalog về từ khóa này, và chưa thấy ai viết về cái này, cá nhân mình nghĩ nó là một tính...
ShinaBR2 viết 7 tháng trước
21 6
Bài viết liên quan
White
49 21
Luận về comment code (Phong cách kiếm hiệp) Comment code luôn là vấn đề gây tranh cãi sứt đầu mẻ trán trong giới võ lâm. Xưa kia, thuở còn mài đít...
Huy Hoàng Phạm viết hơn 2 năm trước
49 21
White
0 0
Clojure là ngôn ngữ functional có hỗ trợ OOP. Về mặt khoa học máy tính, có nhiều cách để thực hiện đa hình. Ở phiên bản trước 1.2, đa hình trong Cl...
Ngoc Dao viết gần 2 năm trước
0 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
86 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!