Danh ngôn hay của các lập trình viên

Bài đăng này đã không được cập nhật trong 5 năm

Geek - thuật ngữ chỉ những người "nghiện" máy tính từ những lập trình viên cho tới những người mê những thiết bị số hay những tỷ phú cỡ Bill Gates hay Steve Jobs. Geek là những người mê những thứ gì đó hơn người khác và họ có cách nhìn về cuộc sống rất hài hước và rất "geek". Họ luôn có những câu nói khiến người khác phải gật gù đồng ý mà không phải dân ngoại đạo nào cũng hiểu.

Và các bạn có thể thoải mái share mấy câu danh ngôn này để thể hiện mình “so deep”, hoặc ghi nhớ để lòe mấy đứa cùng lớp/cùng team khi nói chuyện.

Danh ngôn nổi tiếng

Những chia sẻ của lập trình viên Henrik Warne

Nguyên tắc phát triển sản phẩm

Đi từng bước nhỏ, rồi phát triển dần lên.

Tôi thường không lên kế hoạch tỉ mỉ cho tất cả mọi thứ ngay từ bước ban đầu. Trái lại, tôi sẽ vừa làm vừa quan sát và rút kinh nghiệm.

Mỗi lần chỉ thay đổi một thứ

Nếu bạn phải refactor code trước khi gắn tính năng mới vào sản phẩm, thì hãy commit phần code đã được refactor trước. Sau đó, (trong một commit mới) hãy gắn cái tính năng mới vào.

Sớm thêm phần logging và xử lý lỗi Khi phát triển một hệ thống, một trong những việc đầu tiên tôi làm là thêm vào phần logging và xử lý lỗi. Bởi vì chúng rất hữu ích, ngay cả ở giai đoạn đầu.

Với mọi hệ thống lớn hơn vài dòng code, lập trình viên đều cần phải chuẩn bị sẵn phương án để biết được chuyện gì đang diễn ra trong chương trình. Lúc bình thường, điều này có vẻ không cần thiết. Song, chỉ cần chương trình chạy “trật đường rày” chút xíu là bạn sẽ thấy rõ ngay tầm quan trọng của logging.

Cũng tương tự với xử lý lỗi.

Lỗi và các ngoại lệ (exceptions) cũng thường xuất hiện ngay từ đầu. Do đó, bạn cần có cách để xử lý chúng một cách hệ thống càng sớm càng tốt.

Test từng phần trước khi test toàn bộ Test kĩ từng phần sẽ giúp lập trình viên tiết kiệm được rất nhiều thời gian. Bởi vì, thông thường vấn đề phát sinh khi tích hợp các phần khác nhau lại.

Ví như interface của các modules không thống nhất/bị hiểu lầm. Nếu bạn có thể yên tâm rằng từng phần nhỏ đều hoạt động đúng như ý muốn, thì khi tích hợp hệ thống sẽ dễ tìm lỗi hơn nhiều.

Hãy đọc và chạy thử code May thay, có hai phương pháp bổ trợ lẫn nhau cực kì hiệu quả để hiểu code: đọc code và chạy thử code.

Chạy thử code là cách rất hữu ích để hiểu được code đó là để làm gì. Hãy chắc chắn rằng bạn dùng cả hai phương pháp này.

Nguyên tắc tìm và sửa bug

Sẽ luôn có bug Tôi không thích cách tiếp cận việc phát triển phần mềm theo kiểu “phải đúng ngay từ bước đầu tiên”. Nói thật, dù lập trình viên có đổ bao nhiêu công sức ra đi chăng nữa, thì vẫn sẽ luôn luôn có bugs. (Định nghĩa bugs: những vấn đề xảy ra ngoài dự liệu). Thế nên, theo tôi, tốt hơn hết, hãy:

Chấp nhận sự thật đắng cay đó.
Chuẩn bị sẵn một hệ thống, để giúp bạn nhanh chóng tìm, sửa lỗi, và triển khai phần đã sửa.

Hãy giải quyết các báo cáo bug Mọi lập trình viên đều nên dành một phần thời gian để xem báo cáo bugs của khách hàng, và để sửa lỗi. Việc này sẽ giúp bạn hiểu rõ hơn:

Những gì khách hàng đang cố gắng thực hiện.
Hệ thống được dùng như thế nào.
Khả năng phát hiện vấn đề khó/dễ ra sao.
Hệ thống được thiết kế tốt đến đâu. Đây cũng là cách tuyệt vời để chịu trách nhiệm cho những gì bạn phát triển. Đừng dại dột bỏ lỡ những lợi ích này.

Tái hiện lại bug Để fix bug thì bước đầu tiên là phải tái hiện lại được bug. Nhờ đó, lập trình viên có thể yên tâm rằng, một khi bug đã được fix thì vấn đề cũng sẽ thực sự được giải quyết. Nguyên tắc cơ bản này giúp bảo đảm rằng:

Bạn không đoán mò, đoán nhầm một vấn đề nào đó là bug, trong khi thực ra không phải thế.
Giải pháp thực sự hiệu quả như bạn nghĩ.

Sửa những bug đã biết trước, rồi hãy xem những phần còn lại. Đôi khi, có hàng loạt vấn đề xuất hiện ngoài dự đoán. Những bug khó nhằn có thể “cấu kết” với nhau và gây nên nhiều chuyện kì quái.

Trong tình huống này, thay vì cứ cố tìm hiểu tường tận tất cả mọi chuyện cùng một lúc, thì bạn nên fix những bug đã biết, giải quyết những vấn đề “lộ thiên” trước đã.
Rồi hãy từ từ kiểm tra xem những phần còn lại như thế nào.

Đừng tin vào trùng hợp ngẫu nhiên. Khi test và tìm lỗi, đừng bao giờ tin vào trùng hợp ngẫu nhiên.

Bạn thay một giá trị trong bộ định thời (timer value), và giờ hệ thống cứ tự khởi động lại thường xuyên hơn? Chẳng ngẫu nhiên tí nào.
Một tính năng mới được thêm vào, và một tính năng khác (vốn chẳng liên quan gì) tự dưng chạy chậm hơn? Không ngẫu nhiên đâu. Trái lại, rất đáng ngờ.