Tại sao mọi developer đều nên chọn hàng nhỏ thay vì hàng to?

Ly trà sữa siêu to siêu khổng lồ, nồi lẩu thái siêu cay siêu khổng lồ…, mình chẳng biết mấy cái này có còn là trend không nhưng có vẻ như chúng ta đang sống trong thời đại mà mọi người đều thích “to”. Con trai thích to, con gái cũng thích to, nói chung là càng to càng thích. Hay là developer chúng ta cũng nên làm một method siêu to, một module siêu to nhỉ?

Không không, là một developer tầm cỡ, bạn nên yêu thích hàng nhỏ thay vì hàng to. Những function nhỏ, class nhỏ, module nhỏ, task nhỏ, ý tưởng nhỏ… là những thứ bạn nên hướng tới. Các tiền bối đã khuyên như thế, người xưa đã khuyên như thế, tổ nghiệp cũng đã khuyên như thế.

À mà tổ nghiệp không có khuyên như thế nhé, mình chỉ bắt chước thằng bạn thôi, nó nói là developer chúng ta cũng có tổ nghiệp.

Trong bài viết này, chúng ta hãy cùng đi tìm hiểu xem tại sao người xưa lại khuyên chúng ta nên yêu thích hàng nhỏ nhé.
alt text

Nhỏ đồng nghĩa với đơn giản, dễ hiểu

Bạn có còn nhớ những ngày đầu bắt đầu học lập trình, khi mà chúng ta vứt hết đống code vào trong hàm main không? Bạn có biết tại sao các tiền bối lại quyết định tạo ra cái gọi là “function” hay không? Đó chính là bởi họ hiểu ra mọi thứ cần được giữ ở mức nhỏ nhất, từ đó chúng sẽ đơn giản nhất, dễ hiểu nhất.

Mình từng phải làm việc với những function siêu to, có khoảng hơn một nghìn dòng code, mình có thể nói rằng để hiểu được những function như vậy là bất khả thi. Công việc của developer chúng ta là viết code, là code chứ không phải đống rác, code là thứ đơn giản, dễ hiểu, dễ bảo trì, code khiến người đọc mỉm người khi đọc. Để code của bạn có thể khiến người đọc mỉm cười ( thông thường sẽ là: “fuck, thằng *** nào viết cái function này vậy, đm.”) là cả một nghệ thuật, trong đó tư duy “nhỏ” là một trong những khía cạnh quan trọng.

public static String testableHtml(
  PageData pageData,
  boolean includeSuiteSetup
 ) throws Exception {
  WikiPage wikiPage = pageData.getWikiPage();
  StringBuffer buffer = new StringBuffer();
  if (pageData.hasAttribute("Test")) {
   if (includeSuiteSetup) {
    WikiPage suiteSetup =
     PageCrawlerImpl.getInheritedPage(
      SuiteResponder.SUITE_SETUP_NAME, wikiPage
     );
    if (suiteSetup != null) {
     WikiPagePath pagePath =
      suiteSetup.getPageCrawler().getFullPath(suiteSetup);
     String pagePathName = PathParser.render(pagePath);
     buffer.append("!include -setup .")
      .append(pagePathName)
      .append("\n");
    }
   }
   WikiPage setup =
    PageCrawlerImpl.getInheritedPage("SetUp", wikiPage);
   if (setup != null) {
    WikiPagePath setupPath =
     wikiPage.getPageCrawler().getFullPath(setup);
    String setupPathName = PathParser.render(setupPath);
    buffer.append("!include -setup .")
     .append(setupPathName)
     .append("\n");
   }
  }
  buffer.append(pageData.getContent());
  if (pageData.hasAttribute("Test")) {
   WikiPage teardown =
    PageCrawlerImpl.getInheritedPage("TearDown", wikiPage);
   if (teardown != null) {
    WikiPagePath tearDownPath =
     wikiPage.getPageCrawler().getFullPath(teardown);
    String tearDownPathName = PathParser.render(tearDownPath);
    buffer.append("\n")
     .append("!include -teardown .")
     .append(tearDownPathName)
     .append("\n");
   }

Phía trên là một function kha khá to mà mình lấy từ cuốn sách “Clean code”, cả về số lượng dòng code lẫn ý nghĩa của nó. Một function được gọi là to khi nó chứa quá nhiều code và làm quá nhiều điều. Bạn có thể hiểu được function trên trong vài phút không?

public static String renderPageWithSetupsAndTeardowns(
 PageData pageData, boolean isSuite
) throws Exception {
 boolean isTestPage = pageData.hasAttribute("Test");
 if (isTestPage) {
  WikiPage testPage = pageData.getWikiPage();
  StringBuffer newPageContent = new StringBuffer();
  includeSetupPages(testPage, newPageContent, isSuite);
  newPageContent.append(pageData.getContent());
  includeTeardownPages(testPage, newPageContent, isSuite);
  pageData.setContent(newPageContent.toString());
 }
 return pageData.getHtml();
}

Phía trên là function đã được Uncle Bob tối ưu lại, làm nó nhỏ hơn, đơn giản hơn, dễ hiểu hơn. Mình tin là bạn cũng thấy được sự khác biệt.

Không chỉ với code, tư duy “nhỏ” cũng là tôn chỉ cho rất nhiều công việc khác nhau của một developer, những công việc đòi hỏi sự đơn giản, dễ hiểu. Một task quá lớn sẽ làm đồng nghiệp, cấp dưới của bạn gặp khó khăn trong việc đọc hiểu yêu cầu, một tính năng quá lớn sẽ làm cho user của bạn cảm thấy khó chịu khi chờ đợi quá lâu…

Nhỏ đồng nghĩa với cảm hứng

“Chúng ta sẽ xây dựng một nền tảng cạnh tranh trực tiếp với facebook trong năm nay, mọi người cần giữ vững cảm hứng làm việc.”. – CEO nói.
“Nhưng facebook to quá, phức tạp quá, biết bao giờ chúng ta mới đuổi kịp. Haizzz.”. – Ceo lại nói.

“Mình sẽ tập gym để có 6 múi trong vài tháng nữa, mình cảm thấy vô cùng hào hứng.” – Sơn nói.
“Haizz, nhưng tập đến bao giờ cho đủ 6 múi đây, mà gái nó cũng chả thích trai 6 múi đâu, thôi vậy.”

Bạn thấy đấy, những thứ quá to, quá phức tạp sẽ giết chết cảm hứng của bạn. Hầu hết các developer đều muốn tạo ra thứ gì đó lớn lao, thứ gì đó của riêng họ, nhưng rất ít người thực hiện được. Lý do là bởi ngay từ lúc đầu họ đã nghĩ đến những thứ quá lớn, những ý tưởng thay đổi thế giới, cuối cùng họ không bao giờ dám bắt đầu, họ chỉ ngồi đó và nhìn ngắm ý tưởng của bản thân mà thôi.

Quay trở lại với code, nếu chẳng may bạn lôi một class, function quá dài dòng, phức tạp do một gã nào đó viết ra để đọc hiểu vào lúc 9h30 sáng thì mình cam đoan cả ngày hôm đấy bạn sẽ chẳng làm được thứ gì ra hồn. Lý do là gì thì chắc bạn cũng biết. Hoặc sáng sớm bạn vào công ty, mở mail ra thì thấy một task đã được assign cho bạn, kiểu như: “làm ứng dụng tương tự youtube, làm ứng dụng đánh bại google…”, mình hy vọng bạn sẽ không bị rơi vào tình trạng như vậy. Nhưng nếu sau này có thành sếp, leader thì đừng quên rằng không điều gì làm tinh thần nhân viên đi xuống bằng một task quá lớn, quá phức tạp nhé. Thay vì “làm ứng dụng tương tự youtube”, hãy chia nó thành nhiều phần nhỏ như “làm một web có chức năng xem video”, rồi ngày mai lại assign tiếp một task là “thêm một chức năng nhỏ giúp gợi ý video”, hôm sau lại “thêm chức năng hơi hơi nhỏ giúp web chịu được vài triệu lượt truy cập một lúc”… Như vậy cuối cùng bạn vẫn có một nền tảng tương tự youtube, nhưng mấy tên culi dev sẽ vui vẻ, thoải mái, hào hứng hơn nhiều.

Nhỏ đồng nghĩa với dễ dàng quản lý

Một trong những kĩ năng quan trọng của một developer tầm cỡ là kĩ năng “ước lượng thời gian – estimate“. Estimate là công việc bạn cần làm mỗi ngày. Nào là Estimate thời gian code xong một task, estimate thời gian hoàn thành project (nếu bạn làm freelancer, startup), estimate giá trị của project (tiền, công sức…)…. Việc estimate chính xác sẽ giúp bạn dễ dàng lên kế hoạch làm việc, dễ dàng quản lý công việc hơn.

Một trong những yếu tố quan trọng để bạn có thể estimate chính xác đó là phạm vi của vấn đề. Giả sử như bạn có thể dễ dàng estimate thời gian bạn cần để đi bộ ra đầu ngõ, nhưng nếu mình muốn bạn estimate thời gian bạn cần để đi bộ lên trung tâm thành phố thì sao? Rõ ràng là khó khăn hơn nhiều đúng không? Tương tự như vậy, trong công việc của một developer, bạn cần phân tách vấn đề ra thành những vấn đề nhỏ, nhỏ đến mức bạn có thể dễ dàng estimate thời gian để hoàn thành nó. Giả sử như khách hàng của bạn muốn có một website về chứng khoán, vậy làm sao để bạn biết mất bao lâu thì bạn hoàn thành website đó? Cách duy nhất là chia các công việc bạn cần làm ra những công việc nhỏ hơn, estimate công việc nhỏ, từ đó có được tổng thời gian cần để hoàn thành. Đó là lý do tại sao bạn nên yêu thích “hàng nhỏ”.

Cuối cùng

To không phải là không tốt, có những thứ cần phải to để hoàn thành nhiệm vụ của nó. Tuy nhiên, nếu muốn trở thành một developer tầm cỡ, mình nghĩ chúng ta nên tập yêu những thứ nhỏ nhỏ, xinh xinh. Lần tới khi code, bạn thử làm một function siêu nhỏ thử xem? Hoặc là một class siêu nhỏ, class chỉ phục vụ một mục đích duy nhất. Khi muốn code gì đó, hãy thử bắt đầu với một phiên bản đơn giản nhất, rồi từ từ nâng cấp lên sau. Mình tin là bạn sẽ cảm nhận được sự khác biệt.

Xem thêm nhiều bài viết tại:https://thedarkknighttech.com

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

Võ Cao Sơn

15 bài viết.
39 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
29 1
Ngày nay, thời đại của thông tin, của mạng xã hội, chúng ta có xu hướng bị đắm chìm trong những thông tin vô bổ, kém hữu ích. Video game show, thôn...
Võ Cao Sơn viết 4 tháng trước
29 1
White
28 7
Gần đây mình thấy rất nhiều bài viết câu like dạng như: “Chấm để tham gia khóa học lập trình A, B, C miễn phí”, ngạc nhiên là những bài như vậy đượ...
Võ Cao Sơn viết 4 tháng trước
28 7
White
7 1
Nếu bạn đang là một sinh viên, hoặc bạn mới chỉ bắt đầu con đường sự nghiệp của mình thì một công việc thực tập có thể là vị trí lý tưởng để bạn bắ...
Võ Cao Sơn viết 4 tháng trước
7 1
Bài viết liên quan
White
11 0
Review sách: The Passionate Programmer – Những điều giúp developer phát triển sự nghiệp Sau một loạt những bài viết về technical khô khan, hôm nay...
Huy Hoàng Phạm viết gần 4 năm trước
11 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
15 bài viết.
39 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á!