Một câu hỏi về đạo đức lập trình

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

Đây là một số chuẩn mực về đạo đức trong lập trình từ tổ chức uy tín ACM:

Là một thành viên của ACM tôi sẽ

  • Đóng góp cho xã hội và sự hạnh phúc của nhân loại.
  • Tránh làm hại những người khác.
  • Trở nên thành thật và đáng tin cậy.
  • Công bằng và hành động mà không phân biệt đối xử.
  • Tôn trọng quyền sở hữu tài sản bao gồm cả quyền tác giả và bằng sáng chế.
  • Mang lại một sự tín nhiệm thích hợp cho tài sản trí tuệ.
  • Tôn trọng quyền riêng tư của những người khác.
  • Tôn trọng thông tin bí mật.
Lập trình viên nên tuân theo những chuẩn mực đạo đức trong nghề.Lập trình viên nên tuân theo những chuẩn mực đạo đức trong nghề.

Đọc tiếp >>

Advertisements

Lập trình viên nên thuộc lòng triết lý KISS và YAGNI

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

Những quan điểm của kỹ sư Rico (hiện đang làm việc cho Microsoft) về một chủ đề gần như rất thân thuộc đối với tôi:

Tôi không nghĩ rằng có ai đó lại có thể đưa bất kỳ kết luận nào về tốc độ thực thi của phần mềm trong bài viết của tôi trên blog Performance Tidbits. Nếu tôi có thể tóm tắt lại lời khuyên của mình trong bài viết đó trong chỉ một vài từ thì nó sẽ là “đừng sử dụng các đặc trưng OOP mà bạn không cần đến.”

Điều này không phải nói rằng bạn nên tránh xa các hàm ảo, kế thừa, hoặc những đặc trưng khác của các ngôn ngữ lập trình hiện đại. Mà thực ra chúng không những chỉ mang lại sự rõ ràng và khả năng bảo trì mà chúng cũng cải thiện cả về tốc độ thực thi nữa. Nhưng, cũng rất thường xuyên, tôi quan sát thấy rằng người ta viết code của họ theo một cách rối rắm trong khi có một mô hình đơn giản hơn rất nhiều mà vẫn mang lại hiệu quả tương đương và tốc độ thực thi còn nhanh hơn. Dù cho bạn có sùng bái phong cách lập trình nào đi chăng nữa thì tôi nghĩ bạn sẽ đồng ý rằng ngôn ngữ càng trừu tượng và phức tạp thì không giúp ích gì cho thiết kế của bạn – thay vì mỗi đặc trưng phức tạp sẽ tạo ra rất nhiều tiêu cực thì nên bằng một cách nào đó chuyển thành tích cực hơn với những lợi ích như là sự rõ ràng, dễ bảo trì, tốc độ thực thi nhanh, và nhiều vấn đề khác.

Vì vậy khi tôi nói những câu kiểu như “đừng sử dụng một delegate nếu tính đa hình thông thường đã có thể làm được” thì ý tôi không phải là bạn nên tránh xa các delegate, mà ý tôi là bạn nên không sử dụng chúng nếu không thấy cần thiết.

Khi bạn viết code thì hãy viết theo cách đơn giản nhất có thể.Khi bạn viết code thì hãy viết theo cách đơn giản nhất có thể.

Đọc tiếp >>