Ngôn ngữ máy tính không phải là ngôn ngữ của con người

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

Mặc dù tôi đã trở thành một người không thể hiểu về sự hoàn toàn vô nghĩa trong việc lựa chọn giữa VB.NET và C#, theo quan điểm của tôi thì cú pháp được kế thừa từ ngôn ngữ C là một điểm mà nhiều người thèm muốn. Và không chỉ trong việc phân biệt chữa hoa – chữ thường khi viết code. Daniel Appleman, trong một cuốn sách e-book tuyệt vời của ông, VB.NET hay C#, Nên chọn ngôn ngữ nào?, cũng đồng tình:

Ở đây tôi đang mạo hiểm bước đi trên chỉ vài ngón chân của mình, bởi vì cú pháp ngôn ngữ giống như một vấn đề tôn giáo đối với nhiều lập trình viên. Chắc chắn là tất cả chúng ta có khuynh hướng thích cú pháp ngôn ngữ mà mình đã quen thuộc, các lập trình viên C++ và Java chắc chắn sẽ cảm thấy rất quen thuộc khi làm việc với C#.

Một điểm cũng nên cần làm rõ từ phần này đó là sự khác biệt giữa 2 ngôn ngữ VB.NET và C# là thực sự không đáng kể. Cả hai hầu như đều có cùng chức năng.

Tuy nhiên, về vấn đề cú pháp đối tượng (object), tôi phải trao giải thưởng chiến thắng cho VB.NET. Bạn chỉ cần nhìn vào những khai báo kế thừa sau đây:

public class BClass: AClass, Iint
Public Class BClass
Inherits AClass
Implements Iint

Hãy xem các từ được sử dụng để kiểm soát kế thừa:

abstract, sealed, virtual
MustInherit, NotInheritable, Overridable, Overrides, Shadows

Khi nói đến việc nhìn vào code và hiểu ngay đoạn code đó để làm gì — đặc biệt là sau khi nhà phát triển ban đầu đã nghỉ việc và một số lập trình viên trẻ vừa mới chân ướt chân ráo bước ra khỏi trường đại học phải tìm hiểu phần code đó một cách nhanh chóng để giải quyết một số bug khó hiểu hoặc bổ sung thêm một tính năng mới, thì ngôn ngữ nào sẽ dễ hiểu hơn? Xin thưa, đó là Visual Basic .NET.

Ngôn ngữ lập trình nào là tốt nhất?Ngôn ngữ lập trình nào là tốt nhất?

Đọc tiếp >>

Advertisements

Bạn đang đọc blog lập trình nguy hiểm nhất thế giới

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

Bạn đã bao giờ nhận thấy rằng các blog chứa đầy rẫy những thông tin sai lạc và dối trá? Đặc biệt, tôi đang đề cập đến chính blog này. Cái blog mà bạn đang ngồi đọc vào lúc này đây. Ví dụ, bài viết ngày hôm qua có nội dung cực tồi, và đó chính là bằng chứng thuyết phục nhất cho thấy tôi đã trở thành một gã cực đoan.

Hãy cẩn thận vì bạn đang đọc blog lập trình nguy hiểm nhất thế giới!Hãy cẩn thận vì bạn đang đọc blog lập trình nguy hiểm nhất thế giới!

Đọc tiếp >>

Thất bại là mẹ thành công

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

Tôi tìm thấy đoạn trích này của Will Wright, từ một hội thảo tuần rồi, khá là thú vị:

Will Wright nói rằng anh ta đã học được bài học rằng hầu hết mọi dự án đều dường như có vẻ rất quyến rũ trên giấy tờ, nhưng đều bị thất bại khi ra thị trường. “Tôi thực sự đã hỏi các ứng viên khi tôi tuyển dụng là có bao nhiêu thất bại mà họ đã làm việc trên đó,” anh nói, “và tôi thực sự thích tuyển dụng một ai đó dựa trên số lần thất bại mà họ đã trải qua. Tôi nghĩ rằng đó là một hệ thống học tập tốt nhất.”

Lập trình viên thành công là người phạm sai lầm và rút ra được bài học từ thất bại.Lập trình viên thành công là người phạm sai lầm và rút ra được bài học từ thất bại.

Đọc tiếp >>

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 >>

Lập trình viên đừng ở trong bóng tối

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

Ben Collins-Sussman đã viết về lập trình viên bất an như sau:

Bạn sẽ làm gì khi có một ai đó đưa ra một dự án mã nguồn mở với một số lượng khủng các đặc trưng mới mà phải mất nhiều tháng trời để viết ra? Liệu có ai có đủ thời gian để review lại hàng ngàn dòng code đó? Điều gì sẽ xảy ra nếu có một quyết định thiết kế tồi được thực hiện ngay từ rất sớm trong quá trình đó — liệu còn có ý nghĩa gì không khi chỉ ra sai lầm của nó tại thời điểm này? Việc tung ra cộng đồng hàng tấn code thì hiếm khi là điều tốt cho một dự án: nhóm phát triển hoặc sẽ bắt buộc phải loại bỏ nó hoàn toàn, hoặc chấp nhận nó và phải đối mặt với một hộp đen đồ sộ và khó hiểu, cũng như khó thay đổi và bảo trì. Nó khiến cho dự án đó đi theo một hướng mà không có nhiều sự bàn thảo hoặc đồng lòng.

Và cứ như vậy, tôi đã tập hợp được rất nhiều câu chuyện để chỉ ra một thực tế rằng các lập trình viên không muốn viết code trong một môi trường mở. Các lập trình viên không muốn các đồng nghiệp nhìn thấy những sai lầm hoặc thất bại của họ. Họ muốn làm việc một cách bí mật, ở trong một cái hang, và sau đó tung ra phần code “hoàn hảo” tới cộng đồng của mình, cứ như thể là chưa bao giờ có lỗi nào xảy ra vậy.

Lập trình viên đừng trở thành 'cao thủ' núp trong bóng tối.Lập trình viên đừng trở thành ‘cao thủ’ núp trong bóng tối.

Đọc tiếp >>

Làm theo chỉ dẫn trên thùng sơn

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

Tôi đã nói chuyện qua điện thoại với một người bạn của tôi một vài ngày trước đây, và anh ta đã mô tả một dự án mà anh vừa tiếp nhận gần đây. Nó là sản phẩm của nửa tá lập trình viên khác nhau, mỗi người xây dựng một phần trong cái dự án đó theo một cách hoàn toàn khác nhau, mà có rất ít hoặc không có sự trao đổi nào giữa bất kỳ ai trong số họ cả. Code của dự án đó đã nói lên một câu chuyện rằng: bạn sẽ thấy đó là một đội ngũ nghiệp dư; chả tuân theo một khuôn mẫu nào cả; một đám ô hợp.

Lập trình viên cần tuân theo những chỉ dẫn để dự án có thể thành công.Lập trình viên cần tuân theo những chỉ dẫn để dự án có thể thành công.

Đọc tiếp >>

SEOs: những tay viết nội dung khiêu dâm mới trên Web

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

Có một cái gì đó về ngành công nghiệp Search Engine Optimization (SEO) mà tôi thấy nó thật đáng ghê tởm. Tôi chẳng bao giờ lại đụng tay mình nào nó, cho tới khi tôi đọc bài viết của tác giả Rich Skrenta là: những tay viết truyện khiêu dâm vs. SEOs.

SEOs thì cũng giống như mấy tay chuyên viết nội dung khiêu dâm trên web mà thôi!SEOs thì cũng giống như mấy tay chuyên viết nội dung khiêu dâm trên web mà thôi!

Đọc tiếp >>

Tạm gác lại “cái tôi” trong lập trình: Bạn không phải là công việc của bạn

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

Khái niệm về việc tạm gác lại “cái tôi” trong lập trình, được mô tả bởi Johanna Rothman:

Hai mươi lăm năm về trước, Jerry Weinberg đã xuất bản cuốn sách The Psychology of Computer Programming (Tâm lý học của công việc lập trình máy tính). Tôi đã khám phá ra cuốn sách đó vào năm 1977, và tôi đã quyết định rằng mình muốn làm việc như một kỹ sư phần mềm tạm gác lại “cái tôi”, tất nhiên là không phải giống như một tay DJ (làm việc chỉnh và trộn nhạc) trên radio.

Tạm gác lại “cái tôi” trong lập trình xuất hiện khi một nhóm các đồng nghiệp kỹ thuật sử dụng hình thức review ngang cấp một cách thường xuyên để tìm những khuyết điểm trong phần mềm đang ở giai đoạn phát triển. Mục tiêu ở đây là để mọi người có thể tìm thấy những sai sót, bao gồm cả tác giả, không phải để chứng minh rằng sản phẩm đó là không có sai sót. Mọi người trao đổi các sản phẩm đang trong quá trình phát triển đó để review lẫn nhau, cùng với sự mong đợi rằng các tác giả sẽ tạo ra nhiều lỗi, và những người reviewer sẽ tìm thấy nhiều lỗi. Bất kỳ ai cuối cùng cũng học được từ những sai lầm của bản thân họ và của những người khác. Đó là lý do tại sao nó được gọi là lập trình mà không có “cái tôi”. “Cái tôi” của tôi thì không gắn với cái “hoàn hảo” hoặc “không hoàn hảo” của sản phẩm mà tôi làm ra. “Cái tôi” của tôi thì chỉ gắn với những nỗ lực của tôi để làm công việc theo cách tốt nhất mà tôi biết, và học được từ những sai lầm của chính tôi, chứ không phải là kết quả đầu tiên trong công việc của tôi.

Trong công việc bạn nên gác lại 'cái tôi' để nhắm đến mục tiêu chung của cả nhóm.Trong công việc bạn nên gác lại ‘cái tôi’ để nhắm đến mục tiêu chung của cả nhóm.

Đọc tiếp >>

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 >>

Quy tắc đầu tiên trong lập trình: Nó luôn là lỗi của bạn

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

Bạn đã biết cái cảm giác đó. Nó đã xảy ra với tất cả chúng ta tại một thời điểm nào đó: bạn đã nghiền ngẫm đoạn code đó hàng tá lần và vẫn không thể tìm thấy một vấn đề ở trong nó. Nhưng có một vài bug hoặc lỗi mà bạn dường như không thể tống khứ nó đi được. Có lẽ là có một cái gì đó sai sót với chiếc máy tính mà bạn đang lập trình trên đó, hoặc với hệ điều hành mà bạn đang chạy, hoặc là những công cụ và các thư viện mà bạn đang sử dụng. Nhất định là như vậy rồi!

Các lỗi trong phần mềm thì phần lớn là nguyên nhân do code của bạn!Các lỗi trong phần mềm thì phần lớn là nguyên nhân do code của bạn!

Đọc tiếp >>