Để viết hoặc không viết: Các khung [đã đóng]


8

Hôm nay một số bạn bè và tôi bắt đầu thảo luận về khung ..

Một số người trong chúng ta tin tưởng mạnh mẽ rằng trong 99,9% trường hợp, viết một khung mới là một ý tưởng tồi. Chúng tôi tin rằng có lẽ một số trong số hàng triệu khung công tác ngoài kia sẽ phù hợp với vấn đề của chúng tôi và nếu không, một số hack, API hoặc cấu hình là đủ. Nếu không, chúng tôi nghĩ rằng việc đóng góp vào một số khuôn khổ, đề xuất các tính năng hoặc một cái gì đó tương tự sẽ là giải pháp tốt nhất. 0,1% là khi không có khung nào phù hợp với trường hợp của chúng tôi.

Nhưng, một số người trong chúng tôi nói rằng tốt hơn là nên có "khung công ty nội bộ" (ví dụ), vì việc khắc phục sự cố nhanh hơn, tạo ra sự phù hợp 100% với ứng dụng, vì yếu tố "học hỏi" (khi bạn cải thiện kỹ năng của bạn xây dựng một khung), v.v.

Tôi nghĩ rằng đi ra ngoài các khung mã hóa như không có ngày mai không phải là cách đúng đắn. Tôi đã thấy rất nhiều nhóm nhỏ xây dựng khung riêng của họ chỉ để truyền bá: "chúng tôi xây dựng khung riêng của chúng tôi, chúng tôi cai trị, người anh em". Nói chung, khung là tào lao, không có bất kỳ tài liệu nào và chỉ hoạt động cho các ứng dụng của riêng họ.

Ý kiến ​​là ý kiến, nhà phát triển là nhà phát triển, không có ý định bắt đầu bất kỳ loại chiến tranh ngọn lửa nào, tôi hỏi:

Bạn nghĩ gì về điều này? Những thông số bạn xem xét khi xây dựng một khung? Bạn nghĩ gì về tất cả những điều này?



1
Bạn có biết những nỗ lực cần thiết để viết một Framework không? Nó sẽ hoạt động trong 2 năm? Có bao nhiêu người sẽ chịu trách nhiệm duy trì nó? Làm thế nào về kiểm tra khả năng tương thích ngược? Bạn sẽ dành thời gian để làm tài liệu? Bạn sẽ có các khóa đào tạo cho nó?
NoChance

@EmmadKareem: Nếu câu trả lời là thì sao? Điều đó có nghĩa là họ nên làm điều đó sau đó?
Omega

1
@Omega, Cá nhân tôi sẽ không bao giờ làm điều này trừ khi tôi có các kỹ năng và tài nguyên cũng như lý do chính đáng tại sao mọi thứ khác ngoài đó không hoạt động với tôi. Đó là nghiên cứu nhiều hơn phát triển với tôi. Ngoài ra, tôi không chắc chắn doanh nghiệp sẽ đợi mẫu hàng tháng cho đến khi việc này kết thúc trước khi xây dựng các ứng dụng của họ.
NoChance

Câu trả lời:


10

Tôi ở phía đối diện của quang phổ từ GrandmasterB. Đối với tôi, đây là một câu hỏi mua so với xây dựng.

Từ quan điểm của tôi, thời gian và nỗ lực của tôi có thể được thể hiện bằng một chi phí. Câu hỏi sau đó trở thành, khi nó có đủ lợi tức đầu tư để xây dựng một khuôn khổ? (Nếu tôi đang làm việc cho một khách hàng, tôi nghĩ về những câu hỏi này từ quan điểm của khách hàng.)

Dưới đây là những câu hỏi tôi tự hỏi:

  • Liệu khuôn khổ đã tồn tại?
  • Nếu tôi xây dựng khung này, đây có phải là thứ tôi muốn được biết đến không? Nói cách khác, khung này có phải là điểm khác biệt đối với tôi không?

Thông thường, tôi thấy câu trả lời cho câu hỏi thứ hai là không. Tôi đang làm việc cho một công ty chăm sóc sức khỏe. Họ không muốn được biết đến như là nhà phát triển của một công cụ lập lịch trình tốt nhất. Tôi nên thuê ngoài việc phát triển và bảo trì khung đó.

Tuy nhiên, nếu chúng ta đang nói về một công cụ định giá, đó là bánh mì và bơ của công ty, vì vậy tôi chắc chắn nên tập trung năng lượng của mình để tạo ra một công cụ tuyệt vời.


6

Nguyên tắc chung của tôi là, nếu đó là một sản phẩm, hoặc một phần quan trọng của sản phẩm, hãy biến nó thành nơi có thể. Nếu chức năng không phải là cốt lõi của nó, hoặc đang hoạt động để hỗ trợ một doanh nghiệp (thứ gì đó chỉ được sử dụng trong kênh), hãy thực hiện với các khung.

Nhiều ứng dụng tôi thực hiện là các khoản đầu tư dài hạn - có thể hơn 10 năm - và chúng là các sản phẩm được bán cho khách hàng (do đó là trách nhiệm của tôi). Vì vậy, việc có thể 'nhanh chóng' sử dụng khung bên thứ 3 không phù hợp với tôi vì nó sẽ giúp một ai đó tạo ra hàng tá ứng dụng mỗi năm. Vì vậy, tôi thường không phản đối việc lặn xuống đất sét và làm cho riêng mình. Trong suốt thời gian sử dụng của sản phẩm, một vài tuần nữa để có được khung / thành phần tùy chỉnh sẽ không còn quan trọng nữa. Nhưng nó có thể có nghĩa là ít đau đầu hơn và ít tường gạch hơn vì nó được thiết kế dành riêng cho ứng dụng.


1
Nhưng, bạn xây dựng một khuôn khổ cho một ứng dụng mới trước khi bắt đầu xây dựng ứng dụng? Tóm lại: Bạn có xây dựng Foundation hoặc Harvested Frameworks không?
caarlos0

1
Nói chung khi tôi xây dựng ứng dụng, khung phát triển cùng với nó.
GrandmasterB

4

Dường như với tôi rằng một khung là một tập hợp các thư viện. Khi bạn có một loạt chúng và bạn chắc chắn rằng chúng có các API nhất quán và chơi tốt với nhau, bạn kết hợp chúng và gọi nó là một khung. Nhưng bạn nên đảm bảo rằng tất cả các thư viện của công ty bạn đều có API phù hợp dù bạn có sử dụng từ F hay không.

Các khung có xu hướng được viết 'vô tình' khi ai đó nhìn vào tất cả những gì họ có và nói 'hmmm, bó công cụ này có thể hữu ích cho người khác'. Đó là trừ khi bạn là một công ty vận chuyển nguồn hoặc bạn rõ ràng được yêu cầu viết một khung. Làm công cụ vì mục đích làm công cụ luôn là một ý tưởng tồi trong lập trình.

Dù bạn làm gì, hãy chắc chắn rằng bạn không phát minh lại bánh xe, đặc biệt là hình vuông.


2

Nếu bạn giống tôi, công việc của bạn là cung cấp giá trị kinh doanh hiệu quả nhất có thể, không phải để gỡ lỗi và điều chỉnh các dự án thú cưng. Nếu có một khung được sử dụng rộng rãi làm những gì bạn cần, đừng lãng phí thời gian của bạn để phát minh lại bánh xe, vì khung được chấp nhận rộng rãi có thể làm điều đó tốt hơn bạn có thể. Họ đã có nhiều thời gian, kinh nghiệm và nguồn lực để phát triển nó.

Trong 6 tháng qua, công ty của tôi gần đây đã cho tôi viết 2 ứng dụng khác nhau làm rất nhiều việc tương tự. Gần đây tôi đã được yêu cầu viết một ứng dụng tương tự thứ 3 và có rất nhiều chỗ cho các ứng dụng tương tự trong tương lai. Vì không ai phát triển một khuôn khổ cho công nghệ độc quyền mà tôi đang làm việc cùng, tôi không thấy lựa chọn nào khác ngoài việc phát triển khuôn khổ của riêng mình. Nếu tôi không phát triển khuôn khổ của riêng mình, tôi sẽ dành nhiều thời gian để lặp lại chính mình, và điều đó sẽ lãng phí thời gian và tiền bạc.

Tôi nghĩ rằng đây là chìa khóa để xem nó có đáng để xây dựng của riêng bạn hay sử dụng của người khác hay không. Nếu bạn phải lãng phí một tấn tiền mặt trong vài năm tới, hoặc xây dựng một khung, thì hãy xây dựng khung.

Rất khó để dự đoán chính xác một khung lý tưởng sẽ trông như thế nào nếu không xây dựng một cái gì đó đầu tiên. Các giải pháp thu hoạch thường tốt hơn các giải pháp nền tảng (cảm ơn vì các liên kết caarlos0 ), bởi vì mã của bạn không được xây dựng dựa trên dự đoán về những gì lập trình viên khách muốn, nhưng trải nghiệm thực tế. Đọc: Thiết kế mới nổi .

Điều đó nói rằng, chỉ có một lý do trong tâm trí của tôi để xây dựng khuôn khổ của riêng bạn: nếu bạn đã thực hiện cùng một công việc hai lần và có thể sẽ thực hiện nó nhiều lần nữa, và không ai đã làm việc đó cho bạn.


2

Tôi cố gắng để có được những dặm nhất từ ​​các khung có sẵn và các công cụ trên bất kỳ dự án mới. Sau khi dự án đã phát triển, có thể bị đốt cháy trong một hoặc hai năm, sau đó thay thế các phần của khung gây đau đớn nhất là một lựa chọn hợp lý. Trừ khi kế hoạch kinh doanh của bạn tập trung vào việc tạo ra một khung mới, tôi sẽ không có kế hoạch viết riêng của bạn.

Khi một phần công nghệ thực sự thất bại, tôi giữ một danh sách các khiếu nại và ý tưởng cụ thể về cách nó được thiết kế lại để hoạt động tốt hơn. Trong ngắn hạn, "tuyên ngôn" này mang đến cho tôi một lối thoát cho sự thất vọng của tôi trong khi vẫn sử dụng khuôn khổ hiện có . Trong trung hạn, nó giúp tôi xác định các điểm đau tồi tệ nhất để tôi không lãng phí năng lượng để khắc phục các vấn đề nhỏ. Về lâu dài, bản tuyên ngôn có thể trở thành một thiết kế để thay thế một phần hoặc toàn bộ hoặc một danh sách tính năng để chọn một khung mới.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.