Lập trình viên Ferengi

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

Có một chút ồn ào gần đây về một số bình luận của Joel Spolsky trên podcast của chúng tôi:

Tuần trước, tôi có nghe một podcast trên trang web Hanselminutes, trong đó Robert Martin nói về các nguyên tắc SOLID trong phát triển phần mềm. (Nó là một thuật ngữ rất dễ tìm kiếm trên Google!) Đó là về thiết kế hướng đối tượng và họ gọi là thiết kế agile, nhưng thực ra không phải là như vậy. Đó là các nguyên tắc để làm thế nào thiết kế các class của bạn, và các class đó sẽ làm việc như thế nào. Khi tôi lắng nghe họ, thẳng thắn mà nói, tôi có cảm giác rằng tất cả họ đều có vẻ như có lối suy nghĩ về lập trình cực kỳ quan liêu xuất phát từ tâm trí của những người chưa từng viết thật nhiều code.

Bạn có phải là một lập trình viên Ferengi?Bạn có phải là một lập trình viên Ferengi?


Nếu chỉ xem xét qua về chúng thì không có gì thực sự đáng bị phản đối về các nguyên tắc thiết kế hướng đối tượng của Bob cả. (Bạn có thể tìm hiểu từng nguyên tắc trong các đường link ở dưới đây, ở định dạng PDF).

The Single Responsibility Principle A class should have one, and only one, reason to change.
The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
The Dependency Inversion Principle Depend on abstractions, not on concretions.
The Interface Segregation Principle Make fine grained interfaces that are client specific.
The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
The Common Closure Principle Classes that change together are packaged together.
The Common Reuse Principle Classes that are used together are packaged together.
The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
The Stable Dependencies Principle Depend in the direction of stability.
The Stable Abstractions Principle Abstractness increases with stability.

Trong khi tôi tin rằng mọi nhóm phát triển phần mềm nên cố gắng làm theo các hướng dẫn ở trên thùng sơn, nhưng sẽ có một giới hạn cho những gì bạn có thể làm theo khi sử dụng một thùng sơn. Hướng dẫn nên bao gồm những thông tin cơ bản nhất, quan trọng nhất mà bạn cần phải tiến hành và không trở thành một mớ bòng bong trong quá trình thực hiện nó. Một tóm tắt của các chỉ dẫn trên một thùng sơn, có thể đại diện cho giới hạn của những gì mà hầu hết mọi người trên thực tế sẽ đọc, hiểu, và thu được lợi ích ngay lập tức từ đó.

Việc mở rộng từ một vài hướng dẫn trên một thùng sơn thành một cuốn sổ tay hướng dẫn chi tiết công việc sơn mang lại khá nhiều rủi ro. Bộ quy tắc mà bạn gặp phải càng lớn hơn và hoành tráng hơn thì càng nguy hiểm hơn. Một vài hướng dẫn thêm trên một thùng sơn có thể sinh ra ba mươi quy tắc, và sẽ sinh ra một trăm nguyên tắc chi tiết cho việc sơn đó.

Không lâu sau bạn sẽ thấy bản thân mình tin rằng mọi tình huống trong phát triển phần mềm đều có thể được quy định, nếu bạn là người duy nhất có thể đưa ra một bộ đầy đủ các quy tắc chi tiết! Và tất nhiên, có một số lượng lớn các lập trình viên đủ kiên nhẫn để đọc bộ quy tắc toàn tập Volumes I – XV nói trên. Bạn cũng sẽ muốn thiết lập một vài nơi để cho các lập trình viên này tranh luận bất tận với nhau về ý nghĩa và cách giải thích các quy tắc đó.

Điều này làm tôi liên tưởng một chút, nó trông giống như kiểu lập trình Ferengi vậy.

Lập trình viên Ferengi là gì?Ferengi là một phần của thế giới Star Trek, chủ yếu là trong Deep Space Nine. Họ là một chủng tộc người đặc biệt, những người thực hiện mọi giao dịch kinh doanh đều được quy định chỉ trong 285 quy tắc Rules of Acquisition. Mỗi tình huống kinh doanh có thể xảy ra đều có một quy tắc dành cho nó – và, chắc chắn, một sự giải thích những quy tắc đó cho phép các Ferengi có thể ăn gian, đánh cắp, và bẻ cong sự thật để phù hợp với nhu cầu của họ.

Tại thời điểm nào để bạn ngừng việc có một bộ hướng dẫn lập trình cơ bản, hợp lý – và bắt đầu trở thành một lập trình viên viên Ferengi, hay chính là một biểu hiện không hoàn hảo của bộ quy tắc đó?

Giống như James Bach, tôi nhận thấy rất ít khi phải sử dụng các quy tắc trong nghề nghiệp của mình. Không phải vì tôi là một thiên tài tự chơi với các quy tắc do tôi đặt ra, mà vì tôi đánh giá cao những kỹ năng, kinh nghiệm và phán đoán của các đồng nghiệp trong nhóm của mình nhiều hơn so với bất kỳ quy tắc nào.

Khi Ron nói rằng có một “bộ quy tắc tối thiểu” phải được thực thi để cho một dự án agile có thể thành công, tôi muốn trả lời là tôi tin rằng có một bộ quy tắc tối thiểu cần thiết để có một quan điểm đúng đắn về những điều cần thiết — và rằng trong bài viết của mình, anh ta không đạt được những yêu cầu tối thiểu đó. Tôi nghĩ rằng phần tối thiểu đó là phải hiểu được những từ như “practice” và “agile” và “thành công” có nghĩa là gì (nhận ra rằng chúng là những ý tưởng rất dễ bị uốn cong). Một phần của nó là nhận ra rằng mọi người có thể và đã hành xử theo những cách agile mà không cần bất kỳ khái niệm nào về agile hoặc có thể giải thích chúng để làm gì.

Phong cách của tôi trong việc phát triển và kiểm thử phần mềm là đề cao agile. Tôi áp dụng agile trong việc chuẩn bị để đặt câu hỏi và suy nghĩ lại về bất cứ điều gì. Tôi thay đổi và phát triển các phương pháp của mình. Tôi có thể học hỏi từ những ý tưởng đã được đóng gói như Extreme Programming, nhưng tôi chẳng bao giờ làm theo chúng. Việc làm theo là dành cho những tay lập trình viên mới vào nghề, những người đang chịu sự giám sát về công việc của họ. Thay vào đó, tôi phác thảo ra các phương pháp trên từng dự án, và tôi khuyến khích mọi người nên làm điều đó, vì nó rất tốt. Tôi chịu trách nhiệm cho sự lựa chọn của mình. Đó là kỹ thuật dành cho những người lớn như chúng ta.

Các hướng dẫn, đặc biệt là trong những trường hợp vắng mặt các chuyên gia và cố vấn, thì rất hữu ích. Nhưng cũng có một mối nguy hiểm rất thực tế của việc quá mù quáng để đâm đầu tuân theo các bộ quy tắc. Các lập trình viên đã khá có hệ thống bằng các kế hoạch, vì vậy ý tưởng về việc bạn có thể đến với một bộ các quy tắc, quy tắc con, và quy tắc cháu đủ chi tiết, mà bạn có thể lập trình cho mình để thành công với một “hệ thống” đủ tinh tế – điều này, thật không may, là điều tự nhiên đối với hầu hết các nhà phát triển phần mềm. Nếu bạn không cẩn thận, bạn thậm chí có thể sẽ trượt chân và ngã vào một Methodology. Sau đó, bạn sẽ gặp phải rắc rối thực sự.

Đừng trở thành một lập trình viên Ferengi. Các quy tắc, hướng dẫn, và nguyên tắc là những viên ngọc quý của kinh nghiệm đã được chưng cất cần được nghiên cứu và tôn trọng. Nhưng chúng không bao giờ có thể thay thế cho suy nghĩ phản biện về công việc của bạn.

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Advertisements

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s