Tag Archives: chất lượng

Th1 24 2017

Lầm tưởng về hiệu suất khi làm nhiều dự án cùng một lúc

Bài viết được dịch từ blog Coding Horror

Trong cuốn sách Quality Software Management: Systems Thinking, tác giả Gerald Weinberg đề xuất một quy tắc để tính toán sự lãng phí do phải chuyển đổi dự án:

Theo tính toán của Weinberg, ngay cả khi chỉ bổ sung thêm một dự án vào khối lượng công việc của bạn thì nó cũng gây ra ảnh hưởng hết sức sâu sắc. Bạn sẽ mất đi 20% thời gian của mình. Khi bạn thêm một dự án thứ 3 vào, thì gần một nửa thời gian của bạn sẽ bị lãng phí trong việc chuyển đổi qua lại giữa các dự án.

Năng suất lập trình viên giảm khi phải tham gia nhiều dự án cùng một lúc.Năng suất lập trình viên giảm khi phải tham gia nhiều dự án cùng một lúc.

Đọc tiếp >>

Th6 1 2015

Chúng ta làm ra phần mềm dở ẹc.. với rất nhiều Bug!

Bài viết được dịch từ blog Coding Horror

Tôi thấy điều này thực sự buồn cười, dù nó hơi cũ một chút, đó là một bài viết trên blog của Scoble và nó đã khiến tôi không thể nhịn được:

Một câu slogan cũ tại công ty phần mềm Living Videotext: “Chúng tôi làm ra phần mềm dở ẹc… với rất nhiều Bug!” Nó khiến tôi phì cười! Chúng tôi chẳng bao giờ cho đăng câu khẩu hiệu này trên một quảng cáo cả. Mọi người sẽ không hiểu. Nhưng đó là sự thật. Chúng tôi làm ra phần mềm dở ẹc. Và bạn cũng vậy!

Tất cả chúng ta đều làm ra những phần mềm dở ẹc!Tất cả chúng ta đều làm ra những phần mềm dở ẹc!

Đọc tiếp >>

Th1 28 2015

FizzBuzz: nấc thang lên thiên đường của lập trình viên

Bài viết được dịch từ blog Coding Horror

Lời bàn của Vinacode:

Sau khi Jeff Atwood viết bài “Tại sao nhiều lập trình viên lại không biết… code” thì đã tạo ra một “làn sóng” tranh luận tại chính blog Coding Horror và trên các mạng xã hội như Digg, và Reddit. Đã có hàng ngàn giải pháp được viết ra cho bài toán FizzBuzz, trong đó có rất nhiều phần code được viết rất vội vàng nhằm chứng tỏ khả năng của mình. Còn quan điểm của Jeff thì sao? Bạn hãy đọc tiếp bài viết ở dưới đây nhé!

Rõ ràng việc viết về vấn đề FizzBuzz trên một blog lập trình đã tạo ra kết quả là những thôi thúc khó lòng cưỡng lại để người ta viết code giải pháp cho nó. Những bình luận tại blog này, trên các mạng xã hội Digg, và Reddit – tổng cộng có khoảng gần cả ngàn giải pháp – tràn ngập cùng với những giải pháp được viết code một cách vội vàng cho vấn đề FizzBuzz. Các lập trình viên thường chẳng làm gì nếu không có những ép buộc họ trở thành những người giải quyết vấn đề.

Đó chắc chắn không phải là chủ đích của tôi, nhưng một phần lớn độc giả đã hiểu theo cách rằng vấn đề FizzBuzz là một thách thức. Tôi cho rằng nó thì cũng giống như việc bạn bước chân vào một trung tâm chuyên bán đàn Guitar (Guitar Center) và hét toáng lên rằng ‘hầu hết các tay guitar không thể chơi bản Stairway to Heaven!’ Bạn có thể sẽ tạo ra một cuộc tranh luận rằng Stairway to Heaven là một cách để đo lường mức độ tối thiểu của năng lực chơi đàn guitar.

Bài toán FizzBuzz là mức tối thiểu nhất trong lập trình, giống như các tay guitar đều biết chơi bản Stairway to Heaven vậy.Bài toán FizzBuzz là mức tối thiểu nhất trong lập trình, giống như các tay guitar đều biết chơi bản Stairway to Heaven vậy.

Đọc tiếp >>

Th1 9 2015

Khi bạn đọc hiểu code chính là lúc bạn đang rewriting code

Bài viết được dịch từ blog Coding Horror

Nếu bạn hỏi một nhà phát triển phần mềm rằng họ dành thời gian để làm công việc gì nhiều nhất, thì họ sẽ nói với bạn rằng họ dành phần lớn thời gian để viết code.

Tuy nhiên, nếu bạn thực sự quan sát công việc mà các nhà phát triển phần mềm dành thời gian của họ để làm, thì bạn sẽ nhận ra rằng họ dành phần lớn thời gian của họ để cố gắng hiểu code:

Phần lớn thời gian làm việc của một lập trình viên là dùng để đọc hiểu code.Phần lớn thời gian làm việc của một lập trình viên là dùng để đọc hiểu code.

Đọc tiếp >>

Th12 5 2014

Kỹ nghệ phần mềm: Đã chết?

Bài viết được dịch từ blog Coding Horror

Tôi đã hoàn toàn rối trí khi đọc được bài viết mới IEEE này của tác giả Tom DeMarco (pdf). Hãy xem liệu bạn có thể giải thích lý do tại sao.

Cuốn sách trước đây của tôi là, Controlling Software Projects: Management, Measurement, and Estimates [1986] (Kiểm Soát Các Dự Án Phần Mềm: Quản Lý, Đo Lường, và Ước Lượng), đã đóng một vai trò quan trọng trong cách hướng dẫn nhiều kỹ sư phần mềm mới vào nghề có thể tính toán khối lượng công việc và lên kế hoạch cho các dự án của họ. Trong tâm trạng suy nghĩ của mình, tôi đang tự hỏi, liệu lời khuyên từ cuốn sách đó thì có đúng thời điểm hay không, liệu nó vẫn còn thích hợp, và liệu tôi vẫn còn tin rằng những phép đo lường đó là bắt buộc cho bất kỳ nỗ lực phát triển phần mềm thành công nào? Câu trả lời của tôi là không, không, và không.

Tôi dần dần đi đến một kết luận rằng kỹ nghệ phần mềm là một ý tưởng của ai đó mà theo thời gian đã đến và đã đi.

Phát triển phần mềm luôn là một cái gì đó cần phải thí nghiệm. Thực ra việc xây dựng phần mềm thì không cần phải thí nghiệm, nhưng các khái niệm của nó thì cần. Và đây chính là nơi mà chúng ta nên tập trung vào đó.

Liệu có phải kỹ nghệ phần mềm đã chết?Liệu có phải kỹ nghệ phần mềm đã chết?

Đọc tiếp >>