Làm khuôn khổ đặt quá nhiều trừu tượng? [đóng cửa]

Tôi đã lập trình được ít hơn một năm và có một số kinh nghiệm viết các ứng dụng hệ thống, ứng dụng web và tập lệnh cho các doanh nghiệp / tổ chức. Tuy nhiên, một điều tôi chưa bao giờ thực sự làm là làm việc với một khung như Django, Rails hoặc Zend.

Nhìn qua khung Django, tôi hơi thất vọng với bao nhiêu được trừu tượng hóa trong các khung. Tôi hiểu các mục tiêu cốt lõi của DRY và mã tối thiểu, nhưng một số trong số này phụ thuộc quá nhiều vào các mô-đun khác nhau và sự trừu tượng hóa nặng nề của các chức năng cốt lõi có cảm giác như sau:

1. Làm cho các chương trình được hẹn hò thực sự nhanh chóng vì tính chất luôn thay đổi của các mô-đun / khung,

2. Làm cho mã khó hiểu vì rất nhiều khung và mô-đun có sẵn và tất cả các đặc điểm riêng của chúng,

3. Làm cho mã ít logic hơn trừ khi bạn đọc tất cả các tài liệu; tức là, tôi có thể đọc qua một số cách hiểu danh sách và logic điều kiện và tìm hiểu xem chương trình đang làm gì, nhưng khi bạn thấy các hàm yêu cầu chuyển các chuỗi và từ điển tùy ý, mọi thứ sẽ hơi khó hiểu trừ khi bạn đã là một bậc thầy trong một mô-đun nhất định; và:

4. Làm cho nó khó khăn và tẻ nhạt để chuyển đổi giữa các khung. Chuyển đổi giữa các ngôn ngữ đã là một thách thức, nhưng nó có thể quản lý được nếu bạn có đủ hiểu biết về chức năng / triết lý cốt lõi của chúng. Chuyển đổi giữa các khung dường như là vấn đề ghi nhớ vẹt, trong một số trường hợp dường như khuyến khích sự không hiệu quả mà các khung này được thiết kế để loại bỏ.

Chúng ta có thực sự cần đặt 50 lớp trừu tượng lên trên một thứ đơn giản như truy vấn MySQL không? Tại sao không sử dụng một cái gì đó như giao diện PDO của PHP, trong đó các câu lệnh chuẩn bị / kiểm tra đầu vào được xử lý nhưng truy vấn SQL dễ hiểu vẫn là một phần của hàm?

Là những trừu tượng thực sự hữu ích? Không phải tính năng phình to làm cho chúng trở nên vô dụng, làm cho các ứng dụng trở nên khó khăn hơn so với các ứng dụng tương tự được viết mà không sử dụng khung?

Các khung có thể là khó khăn thực sự. Các vấn đề có thể dễ dàng phát sinh khi một khung quá "quan điểm", tức là khi nó thực sự thích một phong cách ứng dụng cụ thể và tất cả các phần đều hướng đến việc hỗ trợ phong cách đặc biệt này.

Chẳng hạn, nếu khung hoàn toàn trừu tượng hóa quá trình xác thực của người dùng bằng cách cho phép bạn chỉ cần thêm một thành phần, thêm mẫu đăng nhập ở đâu đó và voila, bạn sẽ được xác thực người dùng miễn phí. Điều này giúp bạn tiết kiệm rất nhiều công việc lặp đi lặp lại trong việc lo lắng về cookie, lưu trữ phiên, băm mật khẩu và không có gì.

Các vấn đề bắt đầu khi bạn nhận ra rằng hành vi mặc định của mã xác thực của khung không phải là thứ bạn cần. Có lẽ nó không tuân theo các thực tiễn bảo mật tốt nhất mới nhất. Có thể bạn cần một cái móc tùy chỉnh trong quá trình để kích hoạt một số hành động, nhưng khung không cung cấp một hành động. Có thể bạn cần thay đổi các chi tiết của cookie đang được đặt, nhưng khung cung cấp không có cách nào để tùy chỉnh điều này.

Sự trừu tượng được cung cấp bởi khung cho phép bạn thêm một tính năng quan trọng vào trang web của bạn trong vài phút thay vì ngày ban đầu, nhưng cuối cùng bạn có thể phải chiến đấu chống lại khung để làm cho nó làm những gì bạn cần, hoặc bạn sẽ dù sao cũng phải phát minh lại chức năng từ đầu để phù hợp với nhu cầu của bạn.

Điều này không có nghĩa là trừu tượng khung là xấu, nhớ bạn. Có thể nói đây luôn là một khả năng bạn cần ghi nhớ. Một số khung công tác rõ ràng hướng đến điều này, chúng cung cấp một cách để có được thứ gì đó rất nhanh như một nguyên mẫu hoặc thậm chí là khung sản xuất cho một loại ứng dụng hạn chế, rất cụ thể. Các khung khác giống như các bộ sưu tập các thành phần lỏng lẻo mà bạn có thể sử dụng, nhưng vẫn cho phép bạn linh hoạt thay đổi nó sau này.

Khi sử dụng một bản tóm tắt, bạn phải luôn hiểu ít nhất là những gì nó trừu tượng hóa. Nếu bạn không hiểu cookie và hệ thống xác thực, bắt đầu từ một sự trừu tượng hóa không phải là một ý tưởng tốt. Nếu bạn hiểu những gì bạn đang cố gắng làm và chỉ cần mã đã làm điều đó thay vì phải tự viết một cách tẻ nhạt, thì trừu tượng là một trình tiết kiệm thời gian tuyệt vời. Tóm tắt bằng văn bản kém có thể khiến bạn gặp rắc rối sau đó, vì vậy nó là một con dao hai lưỡi.

Bạn cũng nên phân biệt giữa trừu tượng kỹ thuật và trừu tượng "quy tắc kinh doanh" . Lập trình bằng ngôn ngữ cấp cao hơn là một sự trừu tượng mà bạn có thể không muốn bỏ lỡ (Python, PHP, C # so với C so với Trình biên dịch; Ít so với CSS), trong khi "trừu tượng hóa quy tắc kinh doanh" có thể khó khăn nếu họ không đáp ứng chính xác nhu cầu của bạn (xác thực một lần nhấp so với cookie mã hóa bằng tay).

Đó là bởi vì sự trừu tượng kỹ thuật hiếm khi "rò rỉ", tức là bạn sẽ khó phải gỡ lỗi mã máy khi viết các ứng dụng bằng Python. Tóm tắt quy tắc kinh doanh hoạt động trên cùng một cấp độ kỹ thuật và thực sự chỉ là "gói mã". Bạn có thể sẽ cần gỡ lỗi cookie đã được đặt hoặc hàm băm mật khẩu được tạo tại một số điểm, điều đó có nghĩa là bạn sẽ lặn qua rất nhiều mã của bên thứ 3.

Dường như với tôi rằng bạn hiểu sai về trừu tượng và tái sử dụng mã.

Toàn bộ ngành công nghiệp phát triển phần mềm được xây dựng dựa trên sự trừu tượng. Chỉ vì không sử dụng chúng, tức là tránh sử dụng các khung, thư viện và mã chung không được viết trong nhà, sẽ làm tăng chi phí bạn cần để sản xuất một phần mềm lên hàng trăm, hàng nghìn, thậm chí có thể hơn.

Giống như bạn không tạo ra một máy bay phản lực khổng lồ từ đầu, mà không sử dụng bất kỳ kiến ​​thức kỹ thuật nào được phát triển trong nhiều năm khi chế tạo máy bay khác, bạn không viết phần mềm kinh doanh từ đầu.

Bạn có được điều đó bằng cách sử dụng PHP hoặc Ruby ở nơi đầu tiên, bạn đã có một số lượng trừu tượng rất lớn, phải không? Những cái rõ ràng nhất:

1. Hệ điều hành, ngôn ngữ lập trình và trình biên dịch cung cấp một sự trừu tượng hóa lớn đối với Trình biên dịch và phần cứng,

2. Máy chủ web cung cấp một bản tóm tắt về socket, failover, giao thức HTTP, v.v.

3. SQL cung cấp một sự trừu tượng về cách dữ liệu được lưu trữ trên một hỗ trợ lưu trữ vĩnh viễn và được lưu trong bộ nhớ để truy cập nhanh hơn, đảm bảo ACID, phản chiếu, v.v.

Bạn luôn có thể cố gắng tạo một ứng dụng web mà không cần sử dụng hệ điều hành cũng như máy chủ web, cơ sở dữ liệu hoặc ngôn ngữ lập trình cấp cao. Bạn sẽ nhanh chóng thấy rằng bạn dành nhiều năm reinventing the wheel, tức là tái tạo của bạn ngôn ngữ lập trình, bạn máy chủ web và bạn sở dữ liệu, cho rằng chất lượng của họ sẽ xa chất lượng sản phẩm, chúng tôi thực sự sử dụng.

Các khung không khác nhau từ đó. Bạn có thể làm những gì họ làm. Chỉ là bạn sẽ lãng phí thời gian để làm lại chức năng tương tự, với sự khác biệt là các khung đó sẽ làm điều đó tốt hơn và thường thì mã của chúng sẽ được kiểm tra và ghi lại tốt hơn so với của bạn.

Lấy ví dụ về một giỏ hàng cho một trang web thương mại điện tử. Bạn có thể tự phát minh và dành vài tuần để phát triển nó, hoặc bạn có thể lấy cái được phát triển trong nhiều năm bởi một nhóm người trong khuôn khổ. Chúng được dự kiến ​​sẽ được thử nghiệm, không kể thực tế là trong một vài năm, những nhà phát triển đó đã phát hiện và vá một loạt lỗi mà bạn không thể tưởng tượng được khi phát triển giỏ hàng của riêng mình.

Bạn có thể trả lời rằng họ phức tạp hơn vì nó có nhiều trường hợp người dùng hơn. Ví dụ: họ nên đối phó với giảm giá, trong khi bạn không có giảm giá trên trang web của bạn và không cần tính năng này trong giỏ hàng. Chà, bạn không bị buộc phải sử dụng tính năng này và nó không giống như nó sẽ phạt hiệu suất của ứng dụng web của bạn.

Bạn có thể có một kịch bản rất cơ bản khi thực sự dễ dàng hơn để phát triển giỏ hàng của riêng bạn thay vì sử dụng kịch bản hiện có. Theo cùng một cách, nếu điều duy nhất mà ứng dụng của bạn cần là lưu trữ một danh sách các số, không có gì nữa, bạn không cần một cơ sở dữ liệu: một văn bản điền đơn giản là đủ. Trong những trường hợp đó, đừng thiết kế quá mức ứng dụng của bạn: các tình huống đơn giản yêu cầu các giải pháp đơn giản.

Một yếu tố khác là khả năng đọc mã của bạn. Hãy tưởng tượng bạn đã tạo một trang web thương mại điện tử. Sau đó, bạn rời khỏi dự án và một nhà phát triển khác nên duy trì nó.

• Nếu bạn đã sử dụng một giỏ hàng được cung cấp bởi một khung, đồng nghiệp của bạn sẽ cảm thấy nhẹ nhõm: anh ta phải duy trì một đoạn mã nhỏ dựa trên một khung đáng tin cậy, được ghi chép nhiều. Thậm chí tốt hơn: nhà phát triển này có thể đã được sử dụng để làm việc với khung này và quen thuộc với nó. Nếu không, anh ta có thể đặt câu hỏi về Stack Overflow: chắc chắn, ai đó đã sử dụng khung.

• Nếu bạn có giỏ hàng của riêng mình, thì đồng nghiệp của bạn sẽ phải duy trì một số mã tùy chỉnh, thậm chí có thể không được ghi lại, mà không thể có được sự giúp đỡ ở bất cứ đâu.

Bằng cách sử dụng một khung công tác, bạn dựa vào một mã:

• Được viết bởi các nhà phát triển có kinh nghiệm,

• Thường được đánh giá theo cặp,

• Đơn vị thử nghiệm,

• Tài liệu rộng rãi,

• Được sử dụng trong nhiều năm bởi hàng ngàn nhà phát triển,

• Thường được hỗ trợ, vì vậy bạn có thể báo cáo lỗi và xem nó thực sự đã được sửa,

• Được biết đến bởi nhiều nhà phát triển, những người biết các vấn đề và sự cố có thể xảy ra và có thể giúp đỡ trên các trang web như Stack Overflow.

• Có sẵn cho bạn ngay bây giờ, miễn phí.

Tôi đồng ý - hầu hết các khuôn khổ trở thành những kẻ độc tài cồng kềnh. Họ hứa tự do nhưng cuối cùng bạn lại được phục vụ. vì vậy hãy nhìn vào một khuôn khổ giống như một công cụ - công cụ tốt nhất là công cụ tránh xa bạn. Nếu trong PHP tôi sẽ đề nghị kiểm tra khung Codeigniter, bởi vì nó là sự cân bằng thanh lịch giữa các quy ước và tự do và có một cộng đồng tuyệt vời. Và với người đăng sử dụng ví dụ về giỏ hàng thương mại điện tử - tôi rất mong tôi có thể đồng ý với bạn. nhưng đã xem xét mã cho nhiều giải pháp thương mại điện tử - và đã thiết kế một vài - tôi sẽ không đồng ý với ví dụ của bạn.

Hmmm Một khía cạnh của LedgerSMB mà chúng tôi đã làm việc rất nhiều là cách tiếp cận khung của chúng tôi. Có hai vấn đề cơ bản đi kèm với loại trừu tượng này. Đó là:

1. Sự bùng nổ phụ thuộc, và

2. Trừu tượng sai

Đầu tiên là thực sự tốt hơn so với thay thế đó là phát minh lại bánh xe. Thứ hai là một chút khó khăn để dán nhãn bởi vì nó có thể đến từ một trường hợp vấn đề được xác định kém hoặc, thường xuyên hơn, từ những người sử dụng một cái gì đó bên ngoài mục đích sử dụng của nó.

Hãy xem xét các ORM chẳng hạn. Tôi tránh sử dụng ORM vì rất thường xảy ra trường hợp db được thiết kế theo mô hình đối tượng của ứng dụng vì tốt nhất là chúng là các lớp trừu tượng bị rò rỉ. Đây không hẳn là trường hợp. Tôi đã gặp các nhà phát triển quản lý để duy trì thiết kế DB tốt và ứng dụng tốt trong khi sử dụng ORM nhưng họ sử dụng rất nhiều điều mà orm hype nói không nên yêu cầu, như đóng gói API quan hệ của db phía sau các chế độ xem có thể cập nhật.

Tất nhiên, một vấn đề lớn là mã càng tự động hóa cao, đặc biệt khi nó cũng mờ đục, càng khó nhìn thấy những gì đang xảy ra. Đây là một điểm về ORM mà @jhewlett đưa ra ở trên (xem /software//a/190807/63722 ).

Một song song tốt có thể là hệ thống điện tử hàng không tiên tiến như một khuôn khổ để điều khiển một chiếc máy bay. Những thứ này đã được thiết kế rất cao cho độ tin cậy và là một yếu tố làm tăng sự an toàn của chuyến bay. Tuy nhiên, như nhiều bài viết trong Phổ Spectrum chỉ ra điều này có chi phí phục hồi từ các lỗi bên ngoài giới hạn của những gì được coi là chấp nhận được từ góc độ tự động hóa. Cùng gỡ lỗi. Đó là một điều để gỡ lỗi mã SQL trong chương trình của bạn. Đó là một điều rất khác để gỡ lỗi một phần chương trình viết mã SQL cho chương trình của bạn sử dụng.

Chúng tôi đã viết khung LedgerSMB từ đầu bởi vì tại thời điểm chúng tôi bắt đầu, không có khung thực sự tốt nào làm được điều chúng tôi muốn. Đó thực sự là một điều tôi khá hài lòng, và theo một nhà phát triển mới hơn trong dự án, nó làm cho việc tùy biến ứng dụng trở nên khá dễ dàng. (Chúng tôi thực sự giữ việc tạo mã SQL ở mức tối thiểu và thay vào đó tập trung vào các hàm do người dùng viết tay, có nghĩa là các phần viết sql được dán rất mỏng). Vâng, nó cung cấp rất nhiều sự trừu tượng ở một số nơi, hơn một số lập trình viên cảm thấy thoải mái với (đặc biệt là "các thuộc tính đối tượng ánh xạ tới các đối số trong thủ tục được lưu trữ" thỉnh thoảng khiến chúng ta bị đẩy lùi). Tuy nhiên, chúng tôi cố gắng giữ mọi thứ đơn giản và nhất quán để dễ dàng xác định điều gì đã xảy ra. Điều này hoạt động khá tốt.

Cuối cùng "quá nhiều" là một chút chủ quan, nhưng ở mức độ khách quan, nó cũng phụ thuộc vào những gì bạn đang làm. Nếu bạn đang làm chính xác những gì khung được thiết kế để làm, một khung được thiết kế tốt sẽ cung cấp một lượng trừu tượng hoàn hảo. Nếu bạn đang làm một cái gì đó ít phù hợp hơn một chút, sự trừu tượng sẽ trở nên quá nhiều và quá rò rỉ.

Vâng, chúng rất hữu ích. Chúng cung cấp cho bạn lợi ích của rất nhiều nhà phát triển có kinh nghiệm khác đang làm việc để giải quyết vấn đề bạn cần giải quyết, với các lợi ích bổ sung khi đã thử nghiệm nó, sửa rất nhiều lỗi và cung cấp giải pháp cho các vấn đề khó khăn mà bạn không phải lo lắng chính mình bằng cách sử dụng khuôn khổ.

Họ có thể bị cồng kềnh quá mức? Chắc chắn rồi. Tất cả điều này phụ thuộc vào những gì bạn cần, và những gì khuôn khổ mang đến cho bảng. Nếu bạn có một ứng dụng web đơn giản, có thể Rails quá mức cần thiết cho bạn và bạn nên xem một cái gì đó đơn giản hơn như Sinatra như một giải pháp.

Chắc chắn có một đường cong học tập cho tất cả các khung, và nó dốc hơn với nhiều công việc hơn mà nó tiết kiệm cho bạn. Tuy nhiên, học khung có nghĩa là bạn đã tiết kiệm thời gian và có thể tận dụng tất cả kiến ​​thức đó trong dự án tiếp theo, thay vì viết lại ứng dụng của bạn từ đầu, lần thứ hai.

Nhưng, bạn nói, tôi sẽ chỉ sao chép mã của mình từ dự án cũ và tôi có thể sử dụng nó làm điểm khởi đầu cho dự án mới của mình! Tôi sẽ chỉ thay đổi những gì khác biệt và có thể làm cho một số đối tượng / chức năng của tôi trở nên tổng quát hơn và nghĩ ra một cách tốt hơn để giải quyết đoạn mã khó hiểu đó! Xin chúc mừng, bạn vừa tạo một khung. Làm điều này một vài nghìn lần nữa, và bạn có một cái gì đó như Django, Rails hoặc Zend.

Các khung thường dẫn đến năng suất cao hơn (có lẽ sau một thời gian học tập nhẹ), nhưng thường có sự đánh đổi liên quan. Trong một số trường hợp, ví dụ, bạn có được năng suất lập trình viên với chi phí giảm hiệu năng.

Hãy xem xét các Mappers quan hệ đối tượng (ORM). Họ rất tuyệt ở chỗ họ chăm sóc rất nhiều mã bản đồ tẻ nhạt cho bạn. Họ thậm chí có thể tạo đối tượng của bạn cho bạn. Tuy nhiên, trong việc trừu tượng hóa SQL, việc lập luận về hiệu năng và tối ưu hóa các tắc nghẽn của bạn khó hơn nhiều.

Nếu bạn đang xây dựng một ứng dụng sẽ không có nhiều dữ liệu hoặc truy vấn phức tạp, hiệu suất có thể không phải là vấn đề đối với bạn. Thật vậy, thời gian lập trình viên là nút cổ chai cho rất nhiều dự án, và các khung, thư viện và ngôn ngữ cấp cao giúp giảm bớt điều đó.

Tôi đồng ý rằng "Bạn sử dụng thư viện, nhưng khung sử dụng bạn". Đó là một cách rất gọn gàng để đặt nó. Tôi không đồng ý rằng ngay khi bạn bắt đầu sử dụng lại mã, bạn sẽ bắt đầu xây dựng một khung, vì bạn thường không cần phải làm nhiều hơn một bản sao nhanh và dán để sử dụng lại mã của mình - đó là một thư viện bạn đang xây dựng; không cần phải kỳ lạ về cách bạn mang mã vào trang web hoặc ứng dụng của bạn.

Đối với tôi, điểm cốt yếu là tôi phải khai thác được nhiều tài nguyên hơn là nó đòi hỏi tôi phải đầu tư. Hoặc, từ một góc độ khác, tôi sẽ nói rằng ngay khi nhu cầu của một khung lớn hơn phần thưởng có sẵn, tất cả lợi thế đều không có. Vì vậy, đó là 'Có! Làm ơn! Và cảm ơn!' cho tất cả những người tạo ra các tài sản sẽ giảm thẳng và hoạt động khi cần trong html / CSS / PHP và SQL của riêng tôi.

Một điều tôi thấy không thể hiểu được là các khung được cho là để bảo trì dễ dàng hơn? Nếu mạng lưới phức tạp của các bộ phận tương tác không hoạt động như dự định, bạn nên biết rõ hơn mọi thứ cần biết về khung được đề cập. Hoặc sẵn sàng cho một đầu vào lớn của cú pháp mới.

Một số người nói rằng đây là Nguyên tắc khuôn khổ của Hollywood : "Đừng gọi cho chúng tôi, chúng tôi sẽ gọi cho bạn". Ngược lại, bất cứ khi nào bạn sử dụng thư viện, mã của bạn sẽ gọi thư viện chứ không phải ngược lại.

Như bạn có thể thấy, điểm quan trọng là ai là người kiểm soát - cụ thể là kiểm soát dòng kiểm soát. Ai quyết định câu lệnh nào được chạy sau câu lệnh nào?

Có những tranh luận ủng hộ và phản đối, và bất cứ khi nào tôi thấy những cuộc thảo luận bất tận như vậy, tôi có xu hướng nghĩ rằng đây phải là một vấn đề của hương vị, chứ không phải là một câu hỏi có thể quyết định khách quan. Nếu không, nó đã được quyết định rồi.

Theo quan điểm của tôi, việc bạn thích sử dụng các khung công tác hay thư viện sẽ nói lên điều gì đó về loại nhà phát triển của bạn, và không phải liệu một trong hai cách tiếp cận có tốt hơn hay không và cuối cùng sẽ thắng thế.

Nếu bạn thích các khung công tác, bạn thích trao đổi tự do để bảo mật: bạn có thể thực dụng hơn và bạn có xu hướng tin tưởng người khác thực hiện công việc của họ đúng cách. Nếu bạn thích thư viện, bạn thích trao đổi bảo mật để có tự do: bạn có thể là người theo chủ nghĩa duy tâm hơn và bạn đặt câu hỏi về ý tưởng và yêu cầu của người khác.

Tôi không nghĩ sẽ là khôn ngoan khi quyết định tốt hơn là giống như trước hay sau.

Trả lời câu hỏi của bạn: Các khung công tác có quá nhiều trừu tượng không? Nó phụ thuộc vào bạn là ai, và cụ thể là khoảng cách từ các nguyên tắc đầu tiên mà bạn cảm thấy thoải mái.

...

Và đặc biệt hơn nữa, nếu bạn không thích các khung như Django, hãy tìm kiếm "microframeworks" như Flask :)