Nhái Cốm Blog

I love you just the way you are


Leave a comment

5 phương pháp giúp lập trình viên ước lượng tốt hơn

Author: jsonmez
Original Post in English: 5 Ways Software Developers Can Become Better at Estimation

(lược dịch)

Phương pháp 1: Chia nhỏ vấn đề

Tôi đã từng đề cập (chưa đọc nên chả rõ anh ý đề cập lúc nào và ở đâu 😀) đến vấn đề tạo ra thời hạn quá xa làm việc ước lượng trở nên khó khăn và thiếu chính xác như thế nào; không may điều đó lại thường thấy trong bất kì dự án phát triển phần mềm nào.

Nếu bạn được yêu cầu ước lượng và bạn cho rằng công việc này sẽ tốn 5 phút để hoàn thành, kết quả ước lượng đó sẽ chính xác hơn nhiều so với việc ước lượng một công việc bạn cho rằng cần 5 tháng để hoàn thành.

Vậy thì làm thế nào để giải quyết vấn đề này?

Thật sự thì cách giải quyết tương đối đơn giản: Chia nhỏ công việc ra thành nhiều phần nhỏ và ước lượng cho những phần việc nhỏ đó.

Tôi biết điều này nghe có vẻ đơn giản và dễ thực hiện. Tôi cũng biết sẽ có những hoài nghi với cách tiếp cận này. Bạn sẽ có hàng tá lý do để bào chữa cho việc tại sao mình không chia nhỏ công việc ra. Nhưng sự thật là phần lớn công việc đều có thể chia nhỏ nếu bạn thực sự muốn làm.

Tuy nhiên, tôi đang bàn về việc tại sao việc chia nhỏ công việc ra lại tốt hơn và làm thế nào để chia nhỏ công việc tồn đọng từ trước tới giờ. Vì vậy, tôi sẽ không lan man thêm vào những chi tiết vụn vặt trong bài viết này.

Chìa khóa cho vấn đề ở đây là bạn không bao giờ đưa ra được một ước lượng chính xác với những công việc lớn. Tôi xin phép nhắc lại một lần nữa: Cách duy nhất bạn có thể ước lượng chính xác những công việc lớn là học cách chia nhỏ chúng thành những phần việc nhỏ hơn.

Nếu bạn thực sự cần ước lượng chính xác một việc nào đó, việc dành thời gian và công sức chia nhỏ việc đó thành những phần việc nhỏ sẽ thực sự đáng giá.

Ví dụ, giả sử tôi phải ước lượng khoảng thời gian cần thiết để hoàn thành một bài viết. Đó không phải là một công việc quá lớn, nhưng nó đủ lớn để gây ra sai lệch trong việc ước lượng.

Nếu tôi muốn kết quả chính xác hơn, tôi có thể chia nhỏ công việc của mình thành những việc nhỏ hơn.

Bạn có thể so sánh sự khác nhau giữa việc cố gắng phải ước lượng:

  • Viết và đăng lên một bài viết

So với việc ước lượng:

  • Nghiên cứu và đưa ra những vấn đề sẽ đề cập đến trong bài viết
  • Định hình bài viết
  • Viết một bản nháp
  • Thêm ảnh và liên kết
  • Lên kế hoạch đăng bài viết

Bằng cách phân chia ra, tôi có thể ước lượng chính xác hơn những công việc nhỏ này. Trên thực tế, khi vấn đề được chia nhỏ, tôi có thể giới hạn thời gian cho từng tiến trình một. Điều này đặc biệt hữu ích giúp kết quả ước lượng của tôi chính xác (để tránh đi quá xa, tôi sẽ đề cập đến vấn đề này sau).

Lần tới, khi được yêu cầu ước lượng một vài tính năng nào đó, thay về ước lượng xem bạn cần bao lâu để hoàn thành toàn bộ công việc, hãy cố gắng chia nhỏ tính năng và ước lượng xem bạn cần bao lâu để hoàn thành từng phần việc nhỏ một. Lúc nào bạn cũng có thể thêm vào những ước lượng, đánh giá mới để đưa ra kết quả chung chính xác hơn.

Đợi một chút! Tôi biết chính xác điểm sai bạn sẽ đề cập đến với kiểu ước lượng này. Hiển nhiên việc ước lượng các phần việc nhỏ sẽ chính xác hơn; nhưng khi bạn kết hợp chúng lại với nhau, tính chung lại bạn sẽ nhận được sai số tương đương với việc bạn ước lượng một công việc lớn.

Tất cả những gì tôi có thể trả lời với thắc mắc này là “hãy thử xem”. Ở một góc độ nào đó bạn có thể đúng. Nhiều sai số nhỏ gộp lại sẽ tạo thành một sai số lớn. Nhưng những sai số nhỏ này cũng có xu hướng bù trừ lẫn nhau. Một số công việc cần nhiều thời gian hơn những một số khác lại cần ít hơn. Điều này có nghĩa gộp chung lại, bạn sẽ có kết quả ước lượng chính xác hơn nhiều so với việc ước lượng một công việc lớn.

Phương pháp 2: Dành thời gian nghiên cứu

Tại sao bạn lại tệ trong việc ước lượng?

Lý do là bạn chưa hiểu đầy đủ về công việc bạn đang ước lượng.

Tôi từng đề cập đến việc không nắm được những điều mình không hiểu (đây là hiểm họa với rất nhiều dự án phát triển phần mềm) gây khó cho việc ước lượng như thế nào. Tuy nhiên, tôi chưa giải thích làm thế nào để giải quyết vấn đề chúng ta không nắm được những điều chúng ta không hiểu.

Thêm một lần nữa, câu trả lời cũng rất đơn giản: Nghiên cứu.

Cách tốt nhất để tránh việc không nắm được những điều mình không hiểu là biết rõ về nó.

Mỗi khi bạn được giao nhiệm vụ ước lượng, điều đầu tiên bạn nên nghĩ đến là nghiên cứu, cố gắng khám phá ra những gì mình chưa biết.

Thật không may là phần lớn lập trình viên không nghĩ đến việc nghiên cứu ngay khi họ ước lượng một công việc. Thay vì vậy, họ chủ yếu dựa vào kinh nghiệm trong quá khứ của mình. Nếu họ đã hoàn thành một việc tương tự trước đây, học sẽ tự tin ước lượng công việc mới mà bỏ qua tất cả những gì mình chưa nắm rõ. Nếu họ chưa bao giờ thực hiện một công việc tương tự, họ sẽ cho rằng có rất nhiều vấn đề cần phải làm và đưa ra kết quả ước lượng vống lên so với thực tế.

Cả hai cách làm trên không có cách nào tốt. Thay vì vậy, bạn nên tìm hiểu, đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu về công việc trước ước lượng thời gian cần để thực hiện công việc đó. Bạn sẽ nhận ra rằng phần lớn lập trình viên ước lượng khá tốt thời gian họ cần để nghiên cứu; cho dù họ có thể rất tệ trong việc ước lượng thời gian cần để hoàn thành công việc đó.

Khi bạn đã hoàn thành việc nghiên cứu, bạn sẽ ít phải đối mặt với những vấn đề bạn không biết là mình không hiểu hơn. Tất nhiên, sẽ có những vấn đề bạn chưa hiểu nhưng ít nhất bạn cũng biết về điều đó.

Việc nghiên cứu trên thực tế là như thế nào?

Làm cách nào bạn nghiên cứu những công việc bạn sẽ phải ước lượng?

Đôi khi nó liên quan đến việc lên kế hoạch ra xa hơn một chút so với thời hạn. Tôi sẽ đưa ra một ví dụ về cách thực hiện trong một nhóm sử dụng Scrum hay Agile.

Giả sử bạn muốn cải thiện khả năng ước lượng của mình bằng việc thực hiện nghiên cứu trước khi tiến hành ước lượng công việc. Vấn đề ở đây là khi bạn làm việc trong một dự án sử dụng mô hình Agile, bạn luôn luôn phải ước lượng các công việc thực hiện trong một chu trình phát triển và không thật sự có thời gian để nghiên cứu từng công việc trước khi ước lượng công việc đó, đặc biệt là với những công việc lớn.

Tôi thấy rằng cách tốt nhất có thể làm trong hoàn cảnh này là chuyển công việc đó sang chu trình tiếp theo thay vì ước lượng nó ngay lập tức. Công việc bạn sẽ làm ở chu trình hiện tại là đánh giá xem mình cần bao nhiêu thời gian để nghiên cứu công việc đó.

Bạn có thể có rất nhiều việc nhỏ trong chu trình phát triển hiện tại với mục đích cung cấp đầy đủ thông tin giúp ước lượng chính xác hơn những công việc lớn ở chu trình phát triển tiếp theo. Trong quá trình thực hiện những công việc nhỏ này, bạn cũng có thể chia nhỏ những việc lớn thành những việc nhỏ hơn khi bạn hiểu rõ hơn.

Đợt chút! Tôi biết bạn đang nghĩ gì. Tôi không thể chỉ đơn giản là đẩy công việc sang chu trình phát triển tiếp theo. Sếp tôi và những người làm kinh doanh không thích điều đó. Họ muốn công việc được hoàn hiện ở chu trình phát triển hiện tại.

Tất nhiên là bạn đúng. Vậy làm thế nào bạn giải quyết vấn đề này?

Điều này cũng rất đơn giản. Bạn chỉ cần lên kế hoạch những công việc lớn cần hoàn thiện vào thời gian nào. Nếu bạn làm việc trong nhóm sử dụng mô hình Agile, bạn nên nhắm đến việc nghiên cứu những công việc lớn, những công việc sẽ phải thực hiện ở các chu trình phát triển sau.

Bằng cách luôn tìm tòi, nghiên cứu trước khi ước lượng bất kì việc gì, bạn sẽ tạo tạo dựng cho mình thói quen đưa ra những ước lượng chính xác hơn nhiều.

Cách làm này cũng có thể áp dụng với các công việc nhỏ, bằng cách dành ra khoảng 5 đến 10 phút để tìm hiểu về công việc đó trước khi đưa ra ước lượng.

Lần kế, khi bạn ước lượng một công việc, hãy dành ra một chút thời gian để nghiên cứu. Bạn sẽ ngạc nhiên khi nhận ra rằng kết quả ước lượng của mình trở nên chính xác hơn nhiều như thế nào.

Phương pháp 3: Theo dõi thời gian

Một trong những vấn đề lớn chúng ta gặp phải trong việc ước lượng là cảm giác chính xác thời gian. Việc nhớ lại thời gian thực hiện các dự án trong quá khứ của tôi thường bị sai lệch ít nhiều tùy theo mức độ yêu thích của tôi với dự án cũng như việc tôi đã đói đến như thế nào.

Sự sai lệch thời gian này có thể dẫn đến kết quả ước lượng cực kỳ sai lầm.

Vì lý do này, việc theo dõi thời gian bạn thực sự dùng cho công việc là rất quan trọng.

Tạo cho mình thói quen theo dõi thời gian của bất kì công việc nào bạn làm là một ý tưởng tuyệt vời. Hiện tại, trong khi đang viết bài này, đồng hồ của tôi vẫn đang chạy để theo dõi thời gian tôi bỏ ra. Vì thế, tôi có thể biết được việc viết các bài viết cần bao nhiêu thời gian. Tôi cũng có thể biết được liệu tôi có tiêu tốn quá nhiều thời gian vào một giai đoạn nào đó hay không.

Khi bạn tạo được cho mình thói quen theo dõi thời gian, bạn sẽ mường tượng tốt hơn khoảng thời gian cũng như địa điểm sử dụng cho một công việc nào đó.

Sẽ là điên rồi nếu cho rằng bạn có thể ước lượng tốt những công việc chưa làm trong khi bạn thậm chí không thể nói chính xác thời gian bạn đã làm một việc trước đây.

Bạn nên nghiêm túc suy nghĩ về vấn đề này trong một phút. Đừng cười, tôi nói thật đấy! Theo tôi bạn nên nghĩ về việc sẽ vô lý đến như thế nào nếu tin rằng mình có thể ước lượng tốt bất kỳ công việc gì trong khi bạn không thể nhớ lại được mình đã làm một công việc nào đó trước đây trong bao lâu.

Nhiều người phàn nàn rằng việc phát triển phần mềm không giống như những công việc khác, và rằng công việc này không thể ước lượng chính xác. Tôi đồng ý rằng việc phát triển phần mềm khó ước lượng hơn việc trải thảm hay lợp lại mái nhà. Nhưng tôi nghĩ rằng nhiều lập trình viên không làm tốt trong việc ước lượng là do họ không có ý tưởng gì về khoảng thời gian dành cho những công việc đó.

Hãy tự giúp bản thân mình và bắt đầu theo dõi thời gian. Có rất nhiều công cụ tốt giúp bạn thực hiện việc này:

Nhân tiện, làm theo cách này đã giúp tôi tốt hơn rất nhiều trong việc ước lượng. Tôi luôn có thể ước lượng chính xác toàn bộ công việc trong tuần trong 1 đến 2 giờ. Và tất nhiên, tôi biết được thời gian mình cần để ước lượng bởi vì tôi đã theo dõi thời gian cho việc đó.

Phương pháp 4: Giới hạn thời gian cho công việc

Tôi đã nói rằng tôi sẽ quay lại vấn đề này. Và đây chính là thời điểm đề cập đến.

Một bí mật lớn để trở thành một lập trình viên, người có thể ước lượng tốt công việc, là giới hạn thời gian cho từng công việc một. Điều này gần giống như là gian lận.

Khi bạn giới hạn thời gian cho công việc, bạn đảm bảo nó tiêu tốn đúng khoảng thời gian mà bạn đã lên kế hoạch.

Có lẽ bạn đang nghĩ rằng phần lớn công việc phát triển phần mềm không thể giới hạn thời gian; bạn đã sai. Tôi sử dụng công cụ này thường xuyên và tôi phát hiện ra rằng nhiều công việc chúng ta làm có xu hướng không cố định thời gian phải dành cho chúng.

Tôi cũng phát hiện ra rằng nếu bạn sử dụng một khoảng thời gian cố định (và chỉ dùng đúng khoảng thời gian đó) cho một việc, bạn có thể làm việc theo hướng đảm bảo công việc được hoàn thanh đúng hạn.

Hay xem một ví dụ về việc viết mã kiểm thử đơn vị (Unit test):

Với phần lớn lập trình viên, viết mã kiểm thử đơn vị (Unit test) là một công việc có tính chủ quan. Trừ khi bạn hướng tới mục đích kiểm tra toàn bộ mã, bạn luôn chỉ viết mã kiểm thử đơn vị (Unit test) khi bạn cảm thấy bạn phải kiểm tra đầy đủ đoạn mã. (Nếu bạn đang phát triển phần mềm theo hướng kiểm thử, Test Driven Development – TDD, điều này có lẽ không còn chính xác).

Nếu bạn giới hạn một khoảng thời gian dành cho việc viết mã kiểm thử đơn vị (Unit test), bạn có thể ép mình làm việc với những khối mã quan trọng trước và thực hiện theo nguyên tắc 80/20 để đảm bảo rằng bạn sẽ thu lợi lớn nhất trong giới hạn cho phép.

Đối với nhiều công việc, bạn có thể kết thúc với việc tiêu tốn thêm nhiều giờ cho những chi tiết vụn vặt mà chẳng tạo nên nhiều khác biệt. Giới hạn thời gian ép buộc bạn làm việc với những việc quan trọng trước, tránh thực hiện những công việc như tối ưu hóa ngay trong giai đoạn đầu hay bị ám ảnh về việc đặt tên làm sao cho đúng.

Hiển nhiên rằng sẽ có lúc bạn sử dụng vượt quá thời gian mình thiết lập ra. Nhưng trong nhiều lần khác, bạn sẽ thấy rằng mình thực sự có thể hoàn thành công việc cần thiết; sau đó, bạn luôn có thể quay lại sửa cho nó tốt hơn khi có thời gian.

Tôi xin nhắc lại một lần nữa: bạn hãy yêu thích việc theo dõi thời gian; nó là một thói quen bạn phải gây dựng. Đến khi bạn đã quen với nó, bạn sẽ có khả năng sử dụng nó như một mánh lới giúp các ước lượng của mình trở nên chính xác hơn bất kì thứ gì bạn có thể tưởng tượng.

Phương pháp 5: Kiểm tra lại ước lượng của bạn

Đây là một bí mật nhỏ: Bạn không phải ước lượng chính xác ngay lần đầu tiên. Thay vì thế, bạn có thể xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi biết sếp bạn muốn bạn đưa ra một ước lượng chính xác ngay từ đầu chứ không phải lúc bạn gần hoàn thành công việc đó. Nhưng bạn luôn được phép đưa ra ước lượng chính xác nhất có thể và xem lại ước lượng của mình như một tiến trình trong công việc.

Tôi không thể nghĩ ra bất kỳ tình huống nào trong đó việc cập nhập thêm thông tin lại không được hoan nghênh.

Hãy sử dụng bốn phương pháp trên để đảm bảo rằng ước lượng ban đầu của bạn sẽ chính xác hết mức có thể. Nhưng bạn nên định kỳ dành ra một chút thời gian để đánh giá lại tình trạng thực tế của ước lượng đó.

Hãy nghĩ theo hướng nay: Bạn biết thời điểm bạn tải về một tệp tin và máy tính thông báo với bạn cần bao lâu để hoàn tất công việc đó. Liệu bạn có nghĩ rằng nó tính toán quãng thời gian này ngay từ đầu và không bao giờ cập nhập lại? Tất nhiên là không. Thay vì vậy, phần lớn các chương trình quản lý đều định kỳ cập nhập khoảng thời gian ước tính còn lại.

Nói chung, tiến hành phương pháp này có thể giúp bạn ước lượng tốt hơn. Khi bạn định kỳ xem lại và cập nhập ước lượng của mình, bạn sẽ nhận ra lý do tại sao ước lượng ban đầu của mình lại chưa chính xác.


Leave a comment

11 nguyên tắc lập trình viên nên tuân theo

Author: jsonmez
Original Post in English: 11 Rules All Programmers Should Live By

(lược dịch)

Cá nhân tôi là một người sống có nguyên tắc.

Phải thừa nhận rằng những nguyên tắc dưới đây tôi tự đặt ra cho chình mình, nhưng dẫu sao chúng vẫn là những nguyên tắc.

Tôi nhận ra rằng việc tạo những nguyên tắc cho bản thân giúp tôi làm việc hiệu quả hơn. Tôi có thể quyết định sớm nhiều vấn đề thay vì phải đối mặt với những quyết định một cách thụ động.

Liệu tôi có nên đi tập thể hình sáng hôm nay không?

Tôi có một nguyên tắc là sang thứ 4 tôi sẽ đi tập thể hình và hôm nay chính là thứ 4. Vì vậy tôi sẽ đi, việc đó đã được quyết định.

Tuần này, trong lúc nhớ lại những nguyên tắc tôi áp đặt cho chính mình, tôi đã nghĩ rằng sẽ rất tốt nếu tôi tổng hợp chúng lại thành một bộ nguyên tắc; bộ nguyên tắc bất kì lập trình viên nào cũng nên tuân theo.

Tôi cũng phải thừa nhận rằng phần lớn những nguyên tắc dưới đây tương tự như là những lời chỉ dẫn. Dù sao đi nữa, đây là những nguyên tắc mà tôi đề cập:

1. Công nghệ là cách bạn tìm ra giải pháp, bản thân công nghệ không phải là giải pháp

Chúng ta có thể sử dụng bộ khung ứng dụng Javascript (Javascript framework), Angular chẳng hạn , ngôn ngữ lập trình hay thậm chí là hệ điều hành mới nhất; nhưng bản thân chúng không phải là những giải pháp thực sự cho những vấn đề mà chúng ta, với tư cách những lập trình viên, phải giải quyết. Chúng chỉ đơn giản là những công cụ giúp chúng ta giải quyết vấn đề.

Chúng ta phải thật cẩn thận để không quá cuồng tín vào một công nghệ nào đó mà chúng ta thích hoặc được sử dụng rộng rãi. Đừng giết gà bằng dao mổ trâu!

2. Thông minh là kẻ thù của sự rõ ràng

Khi viết mã, bạn nên hướng đến việc viết sao cho rõ ràng và dễ hiểu.

Những dòng mã có khả năng liên hệ với mục đích thực hiện một cách rõ ràng có giá trị hơn nhiều so với những dòng mã khó hiểu, bất kể chúng tuyệt vời đến thế nào đi nữa.

Không hẳn luôn đúng nhưng nói chung, thông minh là kẻ thù của sự rõ ràng.

Khi ta viết mã “thông minh”, mã đó thường là không rõ ràng.

Mỗi khi bạn định làm gì đó “một cách thông minh”, bạn thực sự cần nhớ đến nguyên tắc này.

Thi thoảng chúng ta viết code “thông minh” nhưng vẫn sáng sủa nhưng đó không phải là vấn đề tôi đề cập đến.

3. Chỉ viết mã khi bạn buộc phải viết

Nguyên tắc này có vẻ hơi mâu thuẫn. Dù sao đi nữa, chẳng phải công việc của một lập trình viên là viết mã sao?

Câu trả lời là nó vừa đúng, vừa sai.

Công việc của chúng ta liên quan đến việc viết mã, nhưng chúng ta nên hướng đến việc viết sao cho ít nhất có thể mà vẫn giải quyết được vấn đề.

Điều này không có nghĩa chúng ta nên thu gọn mã của mình nhiều nhất có thể hay đặt tên biến chỉ bằng 1, 2 kí tự. Nó có nghĩa là chúng ta nên cố gắng chỉ viết mã cần thiết phục vụ cho tính năng được yêu cầu.

Thông thường, bạn sẽ bị cám dỗ bởi việc thêm vào thật nhiều tính năng hấp dẫn hay viết mã thật tổng quát và linh hoạt, sao cho nó có thể bao quát tất cả những tình huống khác nhau có thể xảy ra. Nhưng điều thường diễn ra là mỗi khi chúng ta cố gắng đoán xem tính năng nào là hữu ích hay vấn đề nào có thể xảy ra sau này, chúng ta thường đưa ra câu trả lời sai.

Những đoạn mã thêm thắt này không mang lại giá trị gì cả, trái lại nó ẩn chứa rất nhiều nguy cơ tiềm tàng. Càng nhiều mã, càng nhiều cơ hội xuất hiện lỗi cũng nhưng chúng ta phải tốn nhiều công sức hơn nhằm bảo trì phần mềm.

Một kĩ sư phần mềm tốt không viết mã trừ khi nó thật sự cần thiết.

Một kĩ sư phần mềm tuyệt vời sẽ xóa bớt đi nhiều mã nhất có thể.

4. Chú thích đa phần là không tốt

Tôi không ủng hộ cho việc viết chú thích kèm với mã và hoàn toàn đồng ý với Bob Martin khi anh ấy phát biểu rằng:

“Mỗi lần bạn viết một câu chú thích, bạn nên cau có và cảm thấy bực mình vì sự thất bại trong việc diễn tả của mình.” — Clean Code: A Handbook of Agile Software Craftmanship

Điều này khôgn có nghĩa bạn không nên viết bất kì lời chú thích nào; nhưng trong phần lớn trường hợp, bạn nên tập trung vào việc đặt tên cho dễ hiểu thay vì viết những câu chú thích.

Những câu chú thích chỉ nên được sử dụng khi không có cách nào xây dựng mối liên hệ rõ ràng giữa tên biến, tên hàm với mục đích của chúng. Chú thích được sử dụng để mô tả cho mục đích thực sự khi bạn không thể dễ dàng diễn đạt bằng mã.

Chẳng hạn một câu chú thích nói rằng một thứ tự bất bình thường xảy ra khi thực thi một đoạn mã không phải do lỗi mà là kết quả được biết trước, gây ra bởi một lỗi của hệ thống bên dưới.

Nói chung, những câu chú thích không chỉ không tốt vì sự không cần thiết trong phần lớn trường hợp mà còn bởi vì chúng không diễn đạt chính xác vấn đề.

Lập trình viên có xu hướng không cập nhập lại những câu chú thích cùng với mã, điều này dẫn đến việc những câu chú thích trở nên nguy hiểm bởi vì chúng có thể lái bạn sang một hướng đi hoàn toàn sai lầm.

Bạn có đối chiếu từng câu chú thích với mã tương ứng để đảm bảo rằng mã đang thực hiện chính xác điều mà câu chú thích đang diễn đạt? Trong trường hợp bạn làm như vậy, mục đích của việc sử dụng chú thích ở đây là gì? Trong trường hợp bạn không làm, liệu bạn có thể tin tưởng nội dung mà câu chú thích thể hiện hay không?

Đây là một tình huống cực kì khó xử, vì vậy tốt hơn hết là tránh nó càng xa càng tốt.

5. Luôn chắc chắn điều đoạn mã sẽ thực hiện trước khi viết

Điều này có vẻ hiển nhiên nhưng thực sự không phải như vậy.

Bao nhiêu lần bạn ngồi xuống, bắt đầu viết mã mà không hiểu cặn kẽ đoạn mã bạn sẽ viết sẽ làm những gì?

Tôi không thể nhớ nổi đã bao nhiêu lần mình làm như vậy. Vì thế đây là nguyên tắc tôi cần phải đọc thường xuyên.

Việc thực hành phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có thể giúp bạn trong vấn đề này bởi vì rõ ràng là bạn phải biết đoạn mã thực hiện cái gì trước khi bạn viết nó. Nhưng nó sẽ không giúp bạn ngăn việc tạo ra những đoạn mã sai. Vì vậy, việc đảm bảo bạn hiểu chính xác và đầy đủ yêu cầu của tính năng mình đang xây dựng trước khi bạn thực hiện là cực kì quan trọng.

6. Kiểm tra mã trước khi chuyển đi

Đừng ném mã bạn viết qua và bắt đội ngũ kiểm thử chịu gánh nặng kiểm tra; bạn đang tiêu tốn thời gian của tất cả mọi người chỉ để có những báo cáo và giải pháp sửa lỗi không cần thiết.

Thay vì đó, hãy dành một chút thời gian kiểm tra toàn bộ các tình huống trước khi bạn thông báo mình đã hoàn thành việc thực thi mã.

Chắc chắn rằng bạn sẽ không thể tìm ra mọi lỗi trước khi bạn chuyển phần mềm đến đội ngũ kiểm thử. Nhưng ít nhất bạn sẽ tìm ra trước những lỗi ngớ ngẩn, những lỗi chúng ta vẫn thường mắc phải hết lần này đến lần khác.

Rất nhiều lập trình viên nghĩ rằng chỉ có đội ngũ kiểm thử mới thực hiện việc kiểm tra. Điều này đơn giản là không đúng. Chất lượng sản phẩm là trách nhiệm của tất cả mọi người.

7. Học kiến thức mới hàng ngày

Nếu bạn không cập nhập kiến thức mới hàng ngày, bạn sẽ ngày càng thụt lùi bởi vì tôi cá rằng bạn sẽ quên một cái gì đó.

Sẽ không quá tốn thời gian để học một cái gì đó mới hàng ngày.

Bạn chỉ phải dành khoảng 15 phút để đọc một cuốn sách. Tôi đã đọc trọn vẹn rất nhiều sách trong năm vừa qua chỉ với 45 phút mỗi ngày.

Những tiến bộ nhỏ bạn có được hàng ngày sẽ được tích lũy qua thời gian và trở nên to lớn trong tương lai. Nhưng bạn phải bắt đầu ngay bây giờ nếu bạn muốn giành được phần thưởng đó.

Bên cạnh đó, công nghệ đang thay đổi rất nhanh chóng.Nếu bạn không liên tục nâng cao các kĩ năng của mình và học những kĩ năng mới, bạn sẽ rất nhanh chóng bị bỏ rơi lại phía sau.

8. Lập trình là niềm vui

Thật vậy! Tôi nghĩ có lẽ bạn không chọn nghề này chỉ vì thu nhập cao.

Ý tôi là không có gì sai khi chọn một nghề có thu nhập tốt, nhưng bác sĩ hay luật sư có lẽ là một lựa chọn tốt hơn nhiều.

Lý do lớn nhất bạn trở thành một lập trình viên là bởi vì bạn yêu thích lập trình. Vì vậy, đừng quên rằng bạn đang làm điều mình yêu thích.

Lập trình mang lại rất nhiều niềm vui. Tôi ước rằng tôi có thể viết ra nhiều mã hơn nữa.

Trong thời gian này, tôi luôn quá bận với công việc của mình để dành nhiều thời gian cho việc lập trình. Đó là một trong những lý do tại sao tôi có thể hình dung rõ ràng niềm vui mà việc lập trình mang lại.

Có lẽ bạn đã quên đi niềm vui trong việc lập trình. Đây là lúc nhớ lại bạn đã từng vui vẻ thế nào với việc bắt đầu một dự án hoặc đơn giản là thay đổi cách nghĩ và nhận ra rằng bạn được lập trình và được trả tiền cho công việc đó.

9. Bạn không thể biết tất cả

Càng học nhiều bạn càng nhận ra rằng có quá nhiều điều bạn chưa biết.

Nhận ra điều này rất quan trọng bởi nếu không, bạn sẽ tự huyễn hoặc với suy nghĩ mình biết mọi thứ.

Sẽ chẳng có gì to tát nếu bạn không biết mọi câu trả lời.

Sẽ là bình thường nếu bạn phải nhờ ai đó trợ giúp hoặc giảng giải khi bạn không hiểu vấn đề.

Trong nhiều trường hợp, bạn có thể học điều mình cần biết ngay khi bạn phải biết. Bạn có thể tin tôi về vấn đề này vì nó diễn ra với tôi rất nhiều lần.

Ý tôi là đừng ép mình học tất cả mọi thứ bởi vì đó là nhiệm vụ bất khả thi. Thay vì vậy, bạn nên tập trung học những gì bạn cần biết và xây dựng cho mình các kĩ năng giúp bạn học hỏi nhanh hơn.

10. Phương pháp thực hiện tốt nhất tùy thuộc vào từng tình huống

Liệu phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có phải là phương pháp tốt nhất?

Liệu chúng ta nên luôn luôn áp dụng lập trình theo cặp (pair program).

Bạn sẽ chẳng là gì nếu bạn không sử dụng IoC?

Câu trả lời cho tất cả những câu hỏi trên là “Nó phụ thuộc”.

Nó phụ thuộc vào từng tình huống.

Mọi người luôn cố gắng đưa ra cách làm tốt nhất. Họ sẽ nói với bạn rằng họ luôn làm vậy và bạn cũng nên làm theo. Nhưng điều đó đơn giản là không đúng.

Tôi làm theo rất nhiều phương pháp khi tôi lập trình, nhưng tôi cũng không làm theo vô điều kiện.

Các nguyên tắc là bất di bất dịch nhưng phương pháp thực hiện luôn thay đổi tùy theo tình huống.

11. Luôn hướng đến sự đơn giản

Tất cả các vấn đề đều có thể được chia nhỏ.

Giải pháp hiệu quả nhất thường lại là giải pháp đơn giản nhất.

Nhưng sự đơn giản không phải dễ dàng mà có. Bạn phải lao động để có được nó.

Mục đích của blog này nhằm đề cập đến sự phức tạp trong phát triển phần mềm, cũng như cuộc sống nói chung, và làm cho chúng trở nên dơn giản hơn.

Có lẽ bạn cũng như tôi đều thấy rằng đó không phải là một nhiệm vụ dễ dàng.

Bất kì gã ngốc nào đều có thẻ tạo ra một giải pháp phức tạp cho một vấn đề. Sẽ tốn nhiều công sức và thời gian để thay đổi một giải pháp nhằm giúp nó trở nên đơn giản hơn mà vẫn chính xác.

Hãy dành thời gian. Hãy nỗ lực hết mức. Và hướng đến sự đơn giản.

Những nguyên tắc của bạn là gì?

Trên đây là những nguyên tắc của tôi. Thế còn bạn thì sao?

Những nguyên tắc của cá nhân bạn là gì?

Bạn nghĩ cái gì là quan trọng, đáng để ghi nhớ hàng ngày?


Leave a comment

5 cách để triệt tiêu năng suất lao động

Author: jsonmez
Original Post in English: 5 Ways to Destroy Your Productivity

(lược dịch)

Bạn đang tìm cách triệt tiêu hoàn toàn năng suất lao động của mình?

Bạn tìm đúng chỗ rồi đấy!

Việc đạt năng suất lao động đang được đánh giá quá mức.

Ý tôi là nó có mang lại gì tốt đẹp cho bạn không?

Bạn càng hoàn thành nhiều việc, bạn càng bị yêu cầu làm nhiều việc hơn nữa.

Vì thế, đây là vài lời khuyên giúp bạn giúp bạn dậm chân tại đúng vị trí hiện tại trong sự nghiệp mà không phải hoàn thành bất kỳ công việc nào.

Lời khuyên 1: Cho phép mình phân tâm

Ngay tại thời điểm tôi viết bài này, tôi đang kiểm tra Facebook, đăng vài lời nhắn trên Twitter, âu yếm chú chó của tôi và tập chạy.

Chắc chắn tôi không ngồi đây, tập trung vào máy tính, cố gắng ngăn chặn mọi thứ khác trong khi viết. Làm như vậy sẽ quá hiệu quả. Tôi sẽ gặp rủi ro là hoàn thành bài viết này trong khoảng thời gian hợp lý để rồi bị cám dỗ vào việc viết một bài khác.

Nếu bạn thật sự muốn mình lánh xa nhiệm vụ càng lâu càng tốt, bạn nên mở tất cả các cửa sổ trình duyệt.

Tôi nói điều này hoàn toàn nghiêm túc. Bạn thử nghĩ xem tại sao họ lại phát minh ra các tab?

Tất cả các trình duyệt hiện tại đều hỗ trợ tab là có lý do của nó. Bạn được mong đợi kiểm tra thường xuyên để xem liệu có ai đăng phim đời tư trên Facebook hay trả lời những tin nhắn quái gở mà bạn đăng lên vài phút trước.

Và đừng quên để tiếng và chế độ rung chiếc điện thoại của bạn ở mức cao nhất. Nếu ai đó gọi hay nhắn tin cho bạn, đó sẽ là một lý do tuyệt vời để nghỉ ngơi 2 phút. Bạn đã làm việc rất chăm chỉ và bạn xứng đáng với 2 phút đó.

IM (Instant Messenger) cũng rất cần thiết. Hãy cố gắng đăng nhập nhiều dịch vụ nhất có thể. Một vài lời khuyên dành cho bạn là Skype, Google Hangouts, Facebook Messaging và thậm chí là ICQ.

Địa điểm cũng cự kỳ quan trọng. Đừng bao giờ giấu mình trong phòng riêng hay văn phòng. Bạn nên ra ngoài tận hưởng sự tự do vì chẳng ai lại thích một kẻ ẩn dật cả. Hãy cố gắng tìm một chỗ càng đông người càng tốt và đừng bao giờ nghĩ đến việc lấy tai nghe ra để nghe nhạc cổ điển.

Bạn phải là người đàn ông của hiện tại.

Hãy hòa nhập với vũ trụ. Cảm nhận nhịp sống hối hả đang cuồn cuộn trôi.

Bạn phải sớm nắm bắt mọi thứ trước khi nó trôi ra khỏi tầm tay của bạn.

Lời khuyên 2: Cố gắng làm nhiều việc cùng lúc

Làm nhiều việc cùng lúc cực kỳ tuyệt vời. Tôi nói nghiêm túc đấy.

Bạn có thể giả vờ như bạn đang đang hoàn thành rất nhiều công việc mặc dù bạn chẳng hoàn thành bất kỳ công việc nào cả.

Chẳng có cách nào tốt hơn để thu thập thông tin theo tốc độ của con ốc sên là làm nhiều việc cùng lúc như một ông sếp.

Vừa lập trình vừa xem tivi? Siêu sao!

Vừa viết thư điện tử vừa trò chuyện với đồng nghiệp? Siêu ninja!

Bạn thậm chí có thể làm nhiều việc cùng lúc mặc dù trông bạn rất tập trung.

Bạn có thể thực hiện công việc này hiệu quả hơn bằng cách sử dụng tổ hợp phím tắt “Alt+Tab” (hay “Command+Tab trên Mac)

Với tổ hợp phím đơn giản này, bạn có thể chuyển qua lại giữa bảng tính, môi trường phát triển tích hợp, các cửa sổ trình duyệt và bất kì chương trình nào bạn thích bằng một tốc độ cực nhanh.

Khi bạn thực hiện tốt, bạn có thể hình thành thói quen không bao giờ tập trung vào một công việc đủ lâu để hoàn thành nó. Bạn chỉ việc chuyển đối qua lại giữa các cửa sổ cả ngày. Chẳng phải công nghệ mang lại hạnh phúc cho chúng ta sao?

Nghĩ về việc viết một dòng mã… Alt+Tab

Kiểm tra thư điện tử… Alt+Tab

Nghĩ lại về việc viết một dòng mã… Alt+Tab

Ôi nhìn kìa! Có thư mới…

Lời khuyên 3: Ưu tiên làm những việc vô thưởng vô phạt

Bạn có biết điều gì xảy ra nếu bạn ngồi xuống và làm công việc quan trọng đầu tiên không?

Bạn biết không nào?

OK, để tôi nói cho bạn điều gì sẽ diễn ra.

Bạn sẽ trở thành một kẻ nhàm chán chỉ biết làm theo ý người khác, năng suất công việc cao nhưng buồn tẻ và hèn nhát.

Bạn có muốn là một kẻ hèn nhát?

Bạn có muốn được đề bạt và phải làm nhiều việc quan trọng khác nữa?

Chắc là không rồi!

Vậy câu hỏi tiếp theo là tại sao bạn lại làm những thứ quan trọng thay vì ngay lập tức kiểm tra thư điện tử và Facebook trước tiên vào buổi sáng?

Năng suất công việc chỉ là hoàn thành công việc theo thứ tự ưu tiên.

Nếu bạn sống như vậy, bạn sẽ trở nên vô cùng buồn tẻ.

Công việc quan trọng có thể chờ. Bạn còn có rất nhiều việc vụn vặt, không quan trọng cần làm mà chúng lại thú vị hơn nhiều.

Bạn có biết nhiều người trên mạng có những sai lầm?

Tôi nghiêm túc đấy. Họ đã sai và họa đang gửi cho bạn những thông tin sai lạc.

Bạn sẽ bỏ qua và mặc kệ họ sai lầm? Tất nhiên bạn không nên làm vậy.

Bạn phải để lại nhận xét của mình về bài viết của họ. Bạn phải nói với họ rằng họ đã sai. Bạn thậm chí phải chia sẻ cả những thước phim vui vẻ về những con mèo.

Những chuyện thú vị như vậy sẽ bị bỏ lỡ nếu bạn tập trung vào những công việc quan trọng đầu tiên.

Bạn cũng không bao giờ biết những chuyện thú vị này nếu bạn quá bận rộn cho việc hoàn thành công việc quan trọng.

Và trong lúc hấp hối, bạn có nghĩ rằng mình sẽ nói: “Ước gì tôi có thể làm việc chăm chỉ và sống một cuộc sống ý nghĩa hơn!”.

Không thể nào! Bạn sẽ nói “Ước gì tôi có thể chia sẻ nhiều phim trên YouTube hơn, nhận xét nhiều bài viết chính trị trên Facebook hơn và trả lời tất cả những thư vô bổ”. Đó mới chính là cuộc sống; là những điều có ý nghĩa.

Khi bạn nhìn lại cuộc đời mình, về cơ bản nó được định nghĩa bởi số cuộc tranh cãi bạn thắng trên mạng – hãy tin tôi về điểm này.

Hãy làm những việc vô bổ và những việc dễ trước, việc giải quyết công việc quan trọng hãy để sau.

Ngoài ra, thỉnh thoảng công việc tự dưng hoàn thành như có phép màu dù bạn bỏ qua không làm.

Khi tôi bỏ lại bát đĩa trên bàn và quần áo trên sàn, bạn có nghĩ rằng chúng cứ ở yên đó không?

Tất nhiên là không. Một bà tiên nào đó đã dọn dẹp chúng trong khi tôi ngủ.

Các vấn đề thường có thể được giải quyết ổn thỏa chỉ bằng cách bỏ qua chúng.

Lời khuyên 4: Trì hoãn công việc một cách chuyên nghiệp

Programmer. Pro-grammer. (chơi chữ: Lập trình viên – Người giỏi ngữ pháp)

Bạn có giỏi ngữ pháp không?

Tất nhiên tôi thì không rồi.

Thế bạn có biết tôi giỏi trong lĩnh vực nào không?

Để đến mai.

Đúng là vậy đấy. Và bạn cũng có thể tốt như tôi trong việc này. Việc này không quá khó, thậm chí là một trong những việc tốt nhất bạn có thể làm để ngay lập tức giảm năng suất công việc. Bạn có thể là một Chuck Norris trong việc trì hoãn.

Tôi sẽ nói cho bạn nghe một câu nói bí mật được lưu truyền trong nhiều thế hệ những người chây ì, từ giáo sư cho đến sinh viên. (Có một thời kì câu nói này đã biến mất hoàn toàn khi những giáo sư trong việc chây ì trì hoãn và chết trước khi truyền đạt lại nó cho sinh viên; nhưng hiện giờ câu nói này đã lại được khám phá ra.)

Câu nói đó là “Tí nữa tôi sẽ làm”.

Hãy coi đó là kim chỉ nam của bạn.

Sống với nó. Hít thở cùng nó.

Khi bạn ngồi xuống làm việc, hãy hít một hơi dài, mở IDE (Intergrated Development Evironment – Môi trường phát triển tích hợp) hay tài liệu ra rồi đứng dậy tuyên bố hùng hồn: “Tí nữa tôi sẽ làm.”

Đoán thử xem điều gì sẽ xảy ra nếu bạn hoàn thành việc gì đó trước thời hạn?

Bạn sẽ phải tiếp tục làm việc với nó, làm cho nó trở nên tốt hơn.

Bạn có muốn làm thêm nhiều hơn không? Tôi thì không. Tôi thà đợi cho đến phút cuối, làm một phần công việc tẻ nhạt và tuyên bố rằng không phải lỗi của tôi vì tôi không có đủ thời gian.

Và như bạn thấy, đó là lý do tại sao họ gọi tôi là người trì hoãn công việc chuyên nghiệp chứ không phải tay mơ.

Nó cũng không quá khó như bạn nghĩ. Thực tế là khi bạn thích việc trì hoãn, bạn sẽ thấy việc này ngày càng trở nên dễ dàng hơn.

Sau một thời gian, cách xử lý công việc mặc nhiên của bạn sẽ là để mọi thứ lại đó cho đến những phút cuối.

Bạn sẽ không bao giờ phải làm việc thực sự trừ khi bạn bị ép buộc, và thậm chí khi bị ép buộc, nếu bạn đủ thông minh và trung thành với cách làm này, bạn sẽ tìm ra cách để không phải làm việc đó.

Tôi phải cảnh báo bạn rằng rất nhiều người tập tành trì hoãn công việc đã thất bại trong việc đạt đến trình độ cao và trở thành người chây ì thật sự. Đó là vì họ đã bỏ qua một vài điểm quan trọng.

Tôi sẽ liệt kê những điểm đó ở đây để bạn có thể tránh lặp lại những sai lầm tương tự:

  • Không bao giờ bắt đầu công việc sớm. Luôn luôn đợi đến phút cuối mới bắt đầu.
  • Khi bạn ngồi xuống làm việc, đừng thực sự làm mà hãy làm một việc gì đó khác. Luôn luôn có một việc hay một thứ gì đó mang lại nhiều niềm vui hơn là công việc bạn phải làm. Hãy tin vảo bản năng và bạn sẽ tìm ra niềm vui đó.
  • Công việc càng khó khăn phức tạp bao nhiêu bạn càng có cơ hội trì hoãn thành công bấy nhiêu. Hãy cố gắng tạo ra một núi công việc phức tạp đến hết mức có thể. Nếu bạn chia nhỏ chúng, nó sẽ dễ dàng được hoàn thành hơn và giấc mơ trì hoãn công việc của bạn sẽ sớm trở thành cơn ác mộng.

Hãy nhớ nằm lòng bài học này, bạn sẽ tìm ra “cách làm riêng” của mình.

Lời khuyên 5: Yêu cầu mọi thứ bạn làm phải hoàn hảo

Một số người coi sự hoàn hảo là một yếu điểm, tôi không nghĩ vậy.

Nếu bạn muốn giảm năng suất công việc và đảm bảo rằng bạn rất, rất hiếm khi phải hoàn thành một việc nào đó, bạn phải luôn luôn tâm niệm rằng: tôi sẽ không làm trừ phi nó được thực hiện hoàn hảo.

Thực tế việc nghĩ đến mức độ hoàn hảo của một việc cần được thực hiện là một rào cản lớn trong việc thực hiện nó. Nếu bạn có cách để không phải làm gì, năng suất lao động cũng sẽ biết mất và nhiệm vụ coi như đã hòan thành.

Trong khi mọi người thực hiện những công việc vụn vặt và hoàn thành rất nhiều, nếu bạn cố gắng cầu toàn, có thể bạn sẽ không đạt được kết quả nào. Nhưng ít nhất bạn hoàn toàn đảm bảo về bất kỳ thứ gì mình tạo ra.

Trái ngược với suy nghĩ thông thường, bạn xứng đáng được nhận huy chương vì đã tiêu tốn nhiều giờ mày mò với một giải thuật, khi mà nó đã giải quyết được vấn đề bạn cố gắng giải quyết, nhằm tăng một chút hiệu năng hay đơn giản chỉ là đặt lại tên các biến cho đúng.

Tối ưu hóa ngay trong giai đoạn đầu không chỉ là một người bạn bình thường mà còn là người đồng hành tri kỉ của bạn, nếu bạn muốn hướng đến những thứ hoàn hảo.

Bạn sẽ thường xuyên cảm thấy buồn chán với việc làm cho mọi thứ trở nên hoàn hảo vì nó tiêu tốn một khoảng thời gian đáng kể. Vì vậy sẽ không ai trách móc gì nếu bạn chuyển sang việc tiếp theo mà không bao giờ kết thúc công việc trước đó. Tất nhiên, bạn sẽ làm nó sau 🙂

Mã nguồn được viết hoàn hảo tất nhiên tốt hơn cả trăm lầm mã nguồn chỉ đơn giản là làm được việc. Một số lập trình viên có tiêu chuẩn rất thấp nhưng bạn không nằm trong số họ.

Khi đối mặt với việc chọn lựa sẽ bàn giao sản phẩm không hoàn hảo 100% hoặc bàn giao sản phẩm trễ hạn, luôn luôn chọn cái sau.

Bàn càng trễ hạn nhiều dự án, mức độ nghiêm trọng của việc đó với bạn càng giảm đi. Và khi bạn trở nên vô cảm với việc trễ hạn, thời điểm bàn giao cũng giống như việc bạn tìm đến điểm đầu của một vòng tròn và buông xuôi với năng suất lao động của mình.

Triệt tiêu năng suất lao động thật dễ

Tôi biết 5 lời khuyên trên là hơi nhiều nhưng đừng quá lo lắng về chúng.

Khi bạn bắt đầu thực hiện theo, chúng sẽ tự động đến với bạn một cách tự nhiên.

Thực tế bạn có lẽ đã thực hiện nhiều những việc như trên mà không hay biết gì về chúng. Nhưng cũng đừng lo lắng về điều đó, bạn luôn luôn có cơ hội khám phá ra chúng vào ngày hôm sau.


Leave a comment

The Last Goodbye – Billy Boyd (The Hobbit: The Battle Of The Five Armies)

I saw the light fade from the sky
On the wind I heard a sigh
As the snowflakes cover my fallen brothers
I will say this last goodbye

Lược dịch

Nhìn ánh sáng nhạt nhòa nơi cuối chân trời
Thoảng trong gió tiếng thở dài ai oán
Khi những bông tuyết phủ lên thân thể các anh em đã ngã xuống
Là lúc tôi cất lên lời từ biệt cuối cùng


Leave a comment

Tháng tư về

Tháng tư về.

Dạo một vòng trên mạng, nhà nhà chào đón tháng tư, người người đăng ảnh, chào đón hoa loa kèn (tên đúng nó là lan huệ hay huệ tây, ai xem bức “thiếu nữ bên hoa huệ” của Tô Ngọc Vân thì biết) – loài hoa được coi như sứ giả tháng tư Hà Nội. Giật mình nhớ ra đã vào mùa hoa loa kèn.

Nếu ở gần, bạn có thể ra cuối đường Nguyễn Chí Thanh; hầu như lúc nào cũng có thể bắt gặp những chiếc xe đạp (giờ có cả xe máy nữa) chở hoa loa kèn bán dạo. Loài hoa này đã từ lâu ăn sâu vào tiềm thức nhiều người. Chỉ cần nhắc đến tên thôi cũng đủ gợi lên trong lòng những cảm xúc nhớ nhung khó tả. Cùng với nắng chiều, hoa loa kèn len lỏi khắp phố phường Hà Nội, nhẹ nhàng điểm tô lên thành phố ồn ã bằng màu trắng tinh khôi, nhẹ nhàng và trầm lắng của mình.

 

Người ta mua hoa về, nửa muốn níu kéo mùa xuân với mưa phùn và những con gió lạnh se se, nửa muốn dang tay chào đón nắng hè ấm áp. Lặng lẽ ngắm từng cánh hoa trắng trong, tách mình ra khỏi dòng đời xô bồ và đắm chìm trong kí ức của chính mình; để rồi khi bừng tỉnh, ngơ ngác mùa hoa loa kèn đã qua và ta vẫn ở đó, giữa ngã ba cuộc đời.


3 Comments

7 lý do tại sao các nền tảng trở thành những ngôn ngữ lập trình mới

Author: Peter Wayner
Original post: 7 reasons why frameworks are the new programming languages

(Lược dịch)

Nhờ những công cụ mạnh mẽ, nhu cầu về tốc độ và sự chuyển đổi tự nhiên của việc lập trình, cuộc chiến tiếp theo của bạn sẽ diễn ra trên các nền tảng giao diện lập trình ứng dụng (gọi tắt là nền tảng API) chứ không phải cú pháp.

Trong thập niên 80, cách đơn giản nhất để khơi mào một cuộc chiến là tuyên bố rằng ngôn ngữ lập trình bạn sử dụng là tốt nhất. C, Pascal, Lisp, Fortran? Các lập trình viên dành nhiều giờ để giải thích tường tận tại sao cấu trúc if-then-else (nếu-thì-ngược lại) trong ngôn ngữ của họ lại là tốt nhất dành cho bạn.

Đó là chuyện của quá khứ. Ngày nay, những cuộc chiến liên quan đến cấu trúc và cú pháp phần lớn đã chấm dứt nhờ sự hội tụ lại dựa trên vài tiêu chuẩn đơn giản. Sự khác biệt giữa dấu chấm phẩy, ngoặc nhọn và những thứ khác trong C, Java, Javascript là rất nhỏ. Sự hào hứng cho việc tham gia tranh luận về cách gõ và khối lệnh vẫn tồn tại nhưng phần lớn chỉ còn là tranh luận thông thường do khả năng tự động đang thu nhỏ dần sự khác biệt. Nếu bạn không thích chỉ ra kiểu dữ liệu, máy tính rất có khả năng đưa ra chính xác kiểu bạn cần. Nếu sếp bạn thích Javascript nhưng bạn thích Java, một trình biên dịch đa ngôn ngữ sẽ chuyển đổi các kiểu trong Java thành Javascript để sẵn sàng chạy trong trình duyệt. Tại sao lại phải tranh cãi khi chúng ta đã có công nghệ hỗ trợ?

Đến nay, sự quan tâm chuyển hướng sang các bộ khung ứng dụng (framework). Khi tôi ngồi với các giảng viên ở đại học Johns Hopkins để bàn về khóa học mới, các bộ khung ứng dụng là chủ đề chi phối cuộc thảo luận. Liệu Angular có tốt hơn Ember? Liệu Node.js có tốt hơn cả hai?

Chúng tôi thiết kế một chương trình khảo sát nhằm khám phá kiến trúc những gói phần mềm quan trọng nhất tạo dựng nên Internet. Đây là tâm điểm của công việc; giá trị của cuộc khảo sát sẽ giúp khám phá những nút thắt của các gói phần mềm hiện đang tồn tại trên Internet.

Theo cách hiểu này, các nền tảng là những ngôn ngữ lập trình mới. Chúng là nơi những ý tưởng, triết lý và các vấn đề thực tiễn mới nhất được tìm thấy trong việc lập trình thời hiện đại. Một số thoái lui nhưng có rất nhiều người đang góp phần xây dựng như một khối nhỏ trong việc lập trình. Dưới đây là bảy khía cạnh thúc đẩy xu hướng xây dựng các bộ khung ứng dụng, giúp chúng trở thành mảnh đất màu mỡ mới cho những cuộc chiến 🙂

1. Việc lập trình chủ yếu là nối các API lại với nhau

(API – Application Programming Interface)

Đã có thời gian viết phần mềm đồng nghĩa với việc bạn phải sử dụng toàn bộ kiến thức về ngôn ngữ lập trình để đưa ra các đoạn mã. Khả năng làm chủ sự phức tạp của con trỏ, hàm và phạm vi mã lệnh là thực sự cần thiết; chất lượng mã nguồn phụ thuộc vào cách sử dụng đúng đắn của bạn. Ngày nay, máy tính giúp bạn tự động rất nhiều trong quá trình lập trình. Nếu bạn có một vài đoạn mã vô nghĩa thì cũng đừng quá lo lắng. Trình biên dịch sẽ loại bỏ những đoạn mã không sử dụng đến. Nếu bạn quên không giải phóng bộ nhớ, bộ dọn rác (Garbage Collector) có thể sẽ tìm ra giúp bạn.

Thêm vào đó, cách thức lập trình cũng trở nên khác trước. Phần lớn mã nguồn hiện nay là những dòng lệnh dài gọi đến các API. Việc chuyển đổi định dạng dữ liệu diễn ra thường xuyên xen giữa những lời gọi đến API, nhưng thậm chí công việc này thông thường cũng được thực hiện bởi các API. Một số ít người may mắn làm việc tạo ra những đoạn mã thông min, làm việc với bit hay con trỏ trực tiếp với máy tính; nhưng phần lớn chúng ta làm việc với những lớp cao hơn. Chúng ta chỉ đơn giản kết nối các API lại với nhau.

Do đó, việc hiểu cách thức hoạt động và kết quả của API quan trọng hơn nhiều. Những loại cấu trúc dữ liệu nào nó chấp nhận? Thuật toán bên trong xử lý thế nào khi dữ liệu được mở rộng? Ngày nay, những câu hỏi như thế này thường gặp hơn trong lập trình so với những câu hỏi về cú pháp hay ngôn ngữ. Hiện nay có một số công cụ giúp đơn giản hóa việc gọi một hàm trong ngữ bạn sử dụng từ một ngôn ngữ khác. Ví dụ bạn có thể dễ dàng liên kết các thư viện C từ ngôn ngữ Java. Cái cần thiết là phải hiểu về các API.

2. Nên đứng trên vai những người khổng lồ

Hãy hình dung việc bạn trở thành một tín đồ của Erlang hay một ngôn ngữ mới nào đó. Bạn cho rằng nó cung cấp nền tảng tốt nhất để tạo ra một ứng dụng ổn định và không có lỗi. Điều này thật tuyệt vời nhưng bạn có thể mất nhiều năm để viết lại toàn bộ mã nguồn Java hay PHP hiện tại sang ngôn ngữ mới. Chắc chắn rằng mã nguồn mới của bạn sẽ tốt hơn rất nhiều nhưng liệu nó có đáng giá so với thời gian bạn phải bỏ ra?

Các bộ khung ứng dụng cho phép chúng ta tận dụng thành quả những công việc khó khăn của những người đi trước. Chúng ta có thể không thích kiến trúc mà họ chọn cũng như có thể tranh cãi về chi tiết thực thi; nhưng sẽ hiệu quả hơn nhiều nếu chúng ta gác lại những lời phàn nàn và tìm cách chung sống với những sự khác biệt. Việc thừa kế tất cả những điểm tốt và xấu của một bộ mã nguồn sẽ dễ dàng hơn nhiều nếu sử dụng một bộ khung ứng dụng (framework). Đi theo con đường tự mình viết lại mọi thứ (trong ngôn ngữ mới yêu thích của bạn) thay vì sử dụng một bộ khung ứng dụng phổ biến, bạn sẽ không thể nhanh chóng tận hưởng thành quả từ lựa chọn mới so với việc tận dụng lại những bộ khung ứng dụng (framework) và các API của nó.

3. Hiểu biết kiến trúc chứ không phải cú pháp mới là điều thực sự quan trọng

Khi công việc lập trình phần lớn là xâu chuỗi các lời gọi đến API, sẽ không có quá nhiều lợi thế trong việc học các đặc tính riêng biệt của ngôn ngữ. Chắc chắn rằng bạn có thể trở thành một chuyên gia về ngôn ngữ Java, biết cách Java khởi tạo các trường tĩnh (static field) trong đối tượng; nhưng sẽ tốt hơn nếu bạn tìm ra cách tận dụng sức mạnh của Lucene, JavaDB hay nhưng mã nguồn tương tự. Bạn có thể tốn hàng tháng để tối ưu hóa các hàm trong trình biên dịch Objective-C nhưng học các thư viện mới nhất của Apple sẽ thực sự giúp mã nguồn của bạn gây chú ý. Bạn sẽ nhận được nhiều hơn với việc học chi tiết về bộ khung ứng dụng thay vì cú pháp của ngôn ngữ mà bộ khung ứng dụng được xây dựng nên.

Phần lớn mã nguồn của chúng tiêu tốn thời gian thực thi bên trong các bộ thư viện. Nắm bắt các chi tiết của ngôn ngữ có thể giúp bạn nhưng hiểu biết điều gì đang diễn ra bên trong các bộ thư viện mang lại cho bạn kết quả đáng giá hơn nhiều.

4. Sự thống trị của các thuật toán

Học một ngôn ngữ lập trình giúp bạn sắp xếp dữ liệu được lưu bên trong các biến, nhưng nó chỉ giúp bạn được đến vậy. Rào cản thực sự là sử dụng các thuật toán chính xác và thông thường nó được định nghĩa và thực hiện bên trong các bộ khung ứng dụng (framework).

Rất nhiều lập trình viên hiểu rằng việc thực hiện lại các thuật toán và cấu trúc dữ liệu chuẩn là rất nguy hiểm và lãng phí thời gian. Bạn có thể muốn thay đổi nó một chút phục vụ cho nhu cầu riêng của bạn nhưng bạn đang đánh đổi bằng nguy cơ xảy ra các lỗi nguy hiểm. Các bộ khung ứng dụng (framework) đã được kiểm nghiệm rộng rãi trong nhiều năm. Chúng chính là thành quả đầu tư và hạ tần cơ sở phần mềm. Sẽ không có nhiều ví dụ minh chứng ý nghĩa của việc tách khỏi cộng đồng, quẳng đi những công việc khó khăn người khác đã làm để tự mình xây dựng lại một lô các thuật toán khác nhau.

Cách tiếp cận đúng đắn là học hỏi về các bộ khung ứng dụng (framework) và học cách sử dụng làm sao đạt hiệu quả cao nhất. Nếu bạn chọn sai cấu trúc dữ liệu, bạn có thể biến một công việc thông thường thành một công việc sử dụng thời gian nhiều hơn gấp bội. Sẽ có rắc rối lớn khi mà bạn không có định hướng đúng đắn.

5. Trình biên dịch và Môi trường phát triển tích hợp (IDE) có thể sửa lỗi cú pháp của bạn

Liệu tôi có phải đặt một dấu chấm phẩy sau câu lệnh cuối cùng? Liệu dấu chấm phẩy là “dấu phân tách” hay là “dấu kết thúc”? Những nhà thiết kế ngôn ngữ đã dành lượng lớn thời gian tạo nên những bộ phân tích cú pháp nhằm chuẩn hóa những quy tắc này. Bạn đoán thử coi? Tôi không quan tâm. Đã có lúc tôi quan tâm đến những vấn đề này nhưng giờ đây, môi trường phát triển tích hợp (IDE) đã thực hiện công việc đó cho tôi. Chúng âm thầm trợ giúp và thông báo khi nào tôi làm sai. Tôi để chúng làm công việc đó cho tôi và dành thời gian cân nhắc cho những câu hỏi lớn về mã nguồn của mình. Môi trường phát triển tích hợp là người trợ lý, giúp bạn xử lý những chi tiết nhỏ nhặt khi lập trình.

Tự động hóa cũng giúp chúng ta thoát khỏi sự nhàm chán của cú pháp lập trình. Tất nhiên, chúng không làm mọi thứ hộ bạn. Chúng ta vẫn phải có một ý tưởng để bắt đầu. Nhưng phần lớn thời gian, các chi tiết về ngôn ngữ không thật sự quan trọng.

Môi trường phát triển tích hợp cũng giúp các bộ khung ứng dụng (framework) ở các chi tiết nhỏ. Nó hiển thị các tham số cần thiết cho một lời gọi hàm; chúng ta thậm chí có thể kiểm tra liệu dữ liệu đưa vào đã đúng kiểu hay chưa. Sau đó, chúng ta phải biết hàm nào sẽ được sử dụng và làm thế nào để gắn chúng lại hoạt động với nhau. Điều chúng ta chú ý tới (khi mà cú pháp không còn quá quan trọng) là các phương thức, các hàm có thể sử dụng cho giải pháp của chúng ta.

6. Cú pháp đang dần biến mất với ngôn ngữ thị giác

Mặc dù điều này đã được tiên đoán từ nhiều năm trước, nó nó vẫn đang diễn ra một cách chậm rãi với một số (chứ không phải tất cả) mã nguồn. Một số chương trình vẫn giữ nguyên nhưng những đoạn văn bản nhưng một số khác được hình ảnh hóa hơn. Điều này đồng nghĩa với việc ngôn ngữ máy tính bên dưới cũng mất dần tầm quan trọng vốn có.

Những bộ xây dựng giao diện đồ họa người dùng (GUI) là điểm dễ nhận ra nhất. Bạn có thể kéo thả giao diện người dùng suốt cả ngày mà không cần lo lắng đến ngôn ngữ C, Java hay bất kì ngôn ngữ nào khác. Chi tiết được mã hóa bên trong các khối hình ảnh.

Các công cụ như AndroidBuilder cho phép kéo thả để tạo ra bố cục; và AndroidBuilder sẽ tạo ra mã XML và Java cần thiết giúp mã nguồn có thể chạy. Rất khó để nói rằng ngôn ngữ thị giác là tương lai, đặc biệt sau những thất bại so với những tiên đoán. Nhưng những công cụ này đang phát triển hết mức, ngay khi có thể. Điều này nghĩa là ngôn ngữ truyền thống cũng giảm dần sức mạnh cũng như tầm quan trọng.

7. Mã nguồn là luật pháp

Các ngôn ngữ máy tính nói chung là không có tri giác. Chúng được thiết kế để mở, chấp nhận và thực hiện liên tục, bất kì điều gì bạn muốn. Đôi khi bạn cần sử dụng một vài tính năng bổ sung do cú pháp nhưng phần lớn chúng chỉ là những tổ hợp phím. Sau đó, đơn giản chỉ là nếu-thì-ngược lại (if-then-else) cùng với một số phần khác. Ngôn ngữ sẽ giúp bạn đạt được điều bạn cần, theo cách bạn muốn. Nếu có giới hạn thì chúng cũng được thiết kế để giữ mã nguồn của bạn ít lỗi nhất có thể chứ không phải để giới hạn điều bạn có thể làm.

Các bộ khung ứng dụng (framework) mới là nơi ẩn giấu sức mạnh. Đây là chỗ các kiến trúc sư quyết định cái gì được phép và cái gì bị cấm. Nếu họ không muốn điều gì đó xảy ra, lời gọi hàm sẽ biến mất khỏi bộ API. Nếu họ thích một ý tưởng nào đó, sẽ có nhiều lời gọi hàm cũng như công cụ hỗ trợ nó. Đây là lý do tại sao Larry Lessig, giáo sư luật ở Harvard, nói, “Mã nguồn là luật pháp.”

Các bộ khung ứng dụng (framework) thiết lập các quy tắc của riêng mình và bạn buộc phải sống với những quy tắc này nếu bạn lựa chọn nó. Một số nền tảng blog khuyến khích liên kết với những người khác thông qua lời gọi AJAX nhưng một số khác lại không hỗ trợ. Đó là lý do tại sao bạn phải nghiên cứu cẩn thận và lựa chọn thật khôn ngoan. Đó cũng là lý do sau cùng tại sao các bộ khung ứng dụng (framework) chi phối mọi thứ trong cuộc đời chúng ta, ngay cả trong những thời điểm hiếm hoi chúng ta không lập trình.