2010-02-19 32 views
11

nềnLàm thế nào để xây dựng một cái gì đó khi tôi biết tôi sẽ làm cho nó sai?

tôi có một dự án cá nhân mà tôi đã cố gắng để xây dựng cho khoảng 5 năm. Về bản chất nó là một trò chơi trực tuyến - một ứng dụng web. Nó không phải là một "nhà sản xuất tiền", chỉ là một cái gì đó mà tôi thực sự muốn xây dựng, vì vậy việc tìm kiếm tài trợ để thuê một đội ngũ có tay nghề cao là rất khó xảy ra.

Tôi đã xây dựng hai nguyên mẫu đầy đủ chức năng trong nhiều năm, cả hai đều thành công từ quan điểm thử nghiệm khái niệm/người dùng, nhưng cả hai đều thất bại ngoạn mục từ quan điểm kiến ​​trúc; mã là một mớ hỗn độn, không thể được duy trì hoặc phát triển hơn nữa, và phải bị ném ra ngoài.

Mất một vài năm để có được các kỹ năng cần thiết để xây dựng khách hàng - phong phú/nhà nước và khá phức tạp. Tôi đã điều chỉnh sự nghiệp và nghiên cứu của mình về phía bên này của sự phân chia phát triển. Cuối cùng, tôi cũng có thể xây dựng một khách hàng tinh vi, tinh vi, có thể phát triển và không cần phải bỏ ra 6 tháng. Có rất nhiều việc phải làm ở mặt trận đó, nhưng ít nhất tôi biết tôi có thể làm điều đó, và làm điều đó một cách hợp lý. Back-end là một câu chuyện khác.

Cho đến nay tôi đã xây dựng lại back-end ít nhất 11 lần với các kết hợp khác nhau của PHP, SQL, Ruby, CouchDB, MongoDB, FriendlyORM, NodeJS vv ​​v.v. Tôi thường không nhận được rất xa trước khi tôi khám phá một số lỗ hổng lớn với cách tiếp cận của tôi và bắt đầu lại: RPC đến REST, quan hệ với tài liệu được điều khiển. Tôi nhận thức được rằng tối ưu hóa sớm là gốc rễ của tất cả các điều ác, nhưng ứng dụng này phụ thuộc rất nhiều vào việc di chuyển nhanh, dữ liệu động. RESTful API thiết kế, mở rộng quy mô, sharding, caching, auth, replication - Tôi không có nhiều kinh nghiệm với bất kỳ điều này, và tôi không thể mong đợi được từ xa phong nha bất kỳ thời gian sớm. Những điều này đòi hỏi nhiều năm học tập và kinh nghiệm.

Có ý nghĩa hơn khi tìm một chuyên gia trong lĩnh vực này, nhưng không có kinh phí, tôi cảm thấy cần triển khai thành công một nguyên mẫu khác để thu hút đúng người. Vì vậy, tôi sẽ phải xây dựng nó tốt nhất có thể.

Các Câu hỏi

Giả sử rằng tuy nhiên tôi xây dựng nó, kiến ​​trúc back-end sẽ là sai và sẽ cần phải được xây dựng lại, cách tốt nhất để tiến hành xây dựng "vừa đủ" để tiếp tục là những gì phát triển ứng dụng của khách hàng? Ngay cả khi nó khó chịu, có cách nào để "ném cùng" một dịch vụ web JSON không? Ruby với Sinatra và MongoDB? Django? Có một số trình xây dựng webservice out-o-the-box không? Không cần một khung công tác web đầy đủ vì không có lớp trình bày - chỉ là dữ liệu. Mọi lời khuyên sẽ được đánh giá cao.

+0

@ Franky-D: _ "Tôi biết rõ rằng tối ưu hóa là gốc rễ của tất cả các điều ác" _. Tại sao? –

+0

Có thể anh ấy muốn nói * tối ưu * sớm? – FrustratedWithFormsDesigner

+0

@ Franky-D Đó là ** tối ưu hóa ** sớm mà là gốc rễ của tất cả điều ác - xem http://c2.com/cgi/wiki?PrematureOptimization –

Trả lời

2

Ý kiến ​​của tôi: Nhấn mạnh quá nhiều vào công nghệ và không đủ khi ngồi xuống và thực hiện các thiết kế phù hợp.

  1. Bắt đầu với thiết kế cao cấp.
  2. Xác định các phần khác nhau có liên quan. Hãy dành một chút thời gian chất lượng cho bướC# 1 & 2.
  3. Xem những thành phần nào bạn có thể sử dụng để giúp triển khai các phần khác nhau nhanh chóng. Hãy xem xét rằng sau này bạn có thể trích xuất các thành phần này cho một thứ khác (bao gồm cả giải pháp của riêng bạn).
  4. Xem lại # 1 & # 2
  5. Chọn một hoặc hai mảnh và bắt đầu mã hóa nguyên mẫu hoạt động cho các phần liên quan.
  6. Sau khi thực hiện các bước chân, hãy bắt đầu lại từ bướC# 1 và xem điều gì đã thay đổi để bạn có thể bù đắp cho phù hợp.
3

Bạn không cần phải xây dựng bất kỳ loại trang web nào để có thể tiếp tục với việc tạo mẫu ứng dụng khách. Chỉ cần làm cho các ứng dụng máy khách gọi các hàm sơ khai trả về dữ liệu giả.

+0

Điểm lớn hơn mà Earwicker gợi ý là thiết kế kiểu mô-đun. Nếu bạn chia dự án thành các phần được xác định rõ ràng và xác định đầy đủ các giao diện giữa chúng, thì dự án của bạn sẽ trở thành một loạt các "khối xây dựng".Nếu bạn cần cấu trúc lại chương trình phụ trợ của mình, bạn chỉ đang làm lại một "khối" duy nhất và miễn là nó tuân theo cùng một giao diện, các thành phần khác thậm chí sẽ không biết rằng mọi thứ đã thay đổi. Việc làm lại hoặc viết lại mã dễ dàng hơn nhiều đối với các thành phần nhỏ. – bta

7

Làm cho nó hoạt động chậm, trước tiên, với mã mô-đun sạch sẽ.

Nếu là mô-đun, bạn có thể thay thế một hoặc hai lớp mà không phải vứt bỏ toàn bộ.

Trong khi chúng cung cấp mô đun, hãy cẩn thận với các dịch vụ web, ngay cả REST, vì chúng có xu hướng chậm; có rất nhiều chi phí với mỗi kết nối, ví dụ.

+8

+1. Đầu tiên làm cho nó chạy. Sau đó, làm cho nó chính xác. Sau đó, làm cho nó nhanh. * Theo thứ tự đó. * –

+0

Wayne có thể đã nói nó tốt hơn tôi. :-) –

5

Xây dựng một ứng dụng phức tạp, rộng lớn, đặc biệt là một với nhiều phụ thuộc lẫn nhau, điều kiện cụ thể của tiểu bang và các bộ phận máy chủ-khách hàng có thể yêu cầu sử dụng ngôn ngữ không tương thích. Dựa trên kinh nghiệm của tôi với các dự án khác thuộc loại này, bạn sẽ thất bại trong lần thử đầu tiên cho dù bạn có cẩn thận đến thế nào đi chăng nữa. Bí quyết là để nắm lấy thất bại như một bước không thể tránh khỏi trên đường đi đến thành công và không phiền phức về mọi điều nhỏ nhặt khi bạn xây dựng ứng dụng. Nhiệm vụ đầu tiên là làm cho nó "hoạt động" với ít lập trình nhất có thể, để đơn giản có được hiệu ứng bạn đang tìm kiếm, ngay cả khi rất gần, vì vậy bạn có thể thấy tất cả mọi thứ phù hợp với nhau như thế nào. Nếu bạn có thể phá vỡ vấn đề lớn thành một loạt các vấn đề nhỏ hơn để giải quyết, bạn có thể tìm thấy thành công với một yếu tố và có thể có động lực để giải quyết các vấn đề lớn hơn hoặc khác nhau. Một chiến lược hữu ích để sử dụng là để giữ cho các phần tử của ứng dụng được kết hợp lỏng lẻo, để tránh sự phụ thuộc lẫn nhau, ngoại trừ nơi yêu cầu nghiêm ngặt, vì vậy bạn có thể hoán đổi hoặc cải tiến các phần của toàn bộ mà không có sự thay đổi hậu quả. Ví dụ, mã mạng của bạn có thể truyền các thay đổi trạng thái giữa máy khách và máy chủ mà không quan tâm đến bản chất của các trạng thái, nhưng mã quản lý trạng thái của bạn sẽ không phải quan tâm đến việc các trạng thái được truyền đi như thế nào.

Nó cũng hữu ích để có một xử lý trên kiến ​​trúc tổng thể của ứng dụng, do đó bạn không bị lạc trong cỏ dại. Từ góc nhìn cao cấp, bạn có thể muốn làm quen với cơ bản Design Patterns có thể giúp bạn tổ chức một mớ hỗn độn không thể xuyên thủng mã thành một thứ đơn giản, mô-đun và dễ xây dựng.

Về chủ đề của khung công tác và ngôn ngữ, tôi muốn tránh chuyển đổi thường xuyên như vậy. Trong khi đó là giáo dục để khám phá một ngôn ngữ mới để xem những tính năng nào có thể giúp với vấn đề cụ thể của bạn, bạn sẽ có thể làm việc hiệu quả hơn nếu bạn gắn bó với một, thậm chí nếu khó đạt được một số thứ, bởi vì bạn trở nên hiệu quả hơn với nó , cải thiện cách tiếp cận của bạn để phù hợp hơn với ngôn ngữ. Trong khi Haskell có thể phù hợp hơn với một số vấn đề, thậm chí cả PHP cũ đơn giản cũng có thể được huấn luyện để thực hiện chính xác những điều tương tự với quyết tâm đầy đủ.

Có một sự cám dỗ để thử những điều mới, mở rộng phạm vi công việc để làm cho nó "làm đúng", để xây dựng trong chức năng mới như nó xảy ra với bạn, nhưng để giữ cho dự án dưới sự kiểm soát bạn sẽ có để duy trì kỷ luật để tránh các hoạt động tốn kém và mất tập trung thường được thực hiện một cách khách quan, chỉ các chuyến bay ưa thích hoặc quá sớm cho tình trạng chung của dự án.

Để trả lời cụ thể câu hỏi của bạn, hãy xây dựng nó trong khuôn khổ bạn quen thuộc nhất, nơi mà điểm mạnh của bạn và thực hiện theo những gia số nhỏ hơn tạo ra kết quả hữu ích.Có lẽ đó là công cụ hiển thị của khách hàng, hoặc thành phần mạng, hoặc chuyển tiếp trạng thái back-end, nhưng bất kể nó là gì, bạn nên có nó ở trạng thái "đủ tốt" để bắt đầu gắn các thành phần khác vào nó.

Giải quyết mười vấn đề nhỏ có thể tẻ nhạt và tốn thời gian, nhưng sẽ dễ dàng hơn nhiều so với giải quyết một vấn đề khổng lồ.

2

Johnny G khá nhiều đóng góp nó với nhận xét của anh ấy cho câu hỏi ban đầu của bạn. Tình hình bạn mô tả thậm chí xảy ra với tài sản 500 tin hay không. Bạn cần phải thouroughly kế hoạch những gì nó là bạn đang cố gắng để xây dựng/thực hiện với dự án của bạn trước khi lựa chọn và ném ra các công nghệ mới nhất và thú vị nhất mỗi ba tháng.

Tôi nghĩ rằng bài viết này từ dây, "tìm hiểu để cho đi" về sự thất bại của công tước nukem mãi mãi để kết thúc nhận được vận chuyển, sẽ giải thích điều này tốt hơn tôi có thể.

http://www.wired.com/magazine/2009/12/fail_duke_nukem/

(nó cũng là một niềm vui khá/thông tin đọc không phân biệt)

0

Nếu dự án của bạn hút và không ai sử dụng nó, những gì nó sẽ như thế nào vấn đề tối ưu hóa nó là gì? Nhận phiên bản kết thúc để kết thúc, tôi chắc chắn bạn sẽ khám phá ra rất nhiều vấn đề khác mà bạn chưa xem xét, điều này có thể có tầm quan trọng lớn hơn.

0

Tôi thấy chỉ có một cách để hoàn thành dự án cá nhân.

Mã thông minh trước, lập kế hoạch sau. Phát triển nguyên mẫu đó, nhưng thiết kế nó sao cho bất kỳ phần nào có thể được loại bỏ và được thay thế bằng một mảnh khác.

Nếu lựa chọn ngôn ngữ của bạn là ruby, ví dụ: hãy xây dựng các lớp học của bạn để có giao diện được xác định rõ ràng mà bạn sẽ không bao giờ phá vỡ. Lo lắng về mỗi chức năng "làm" điều đúng, không thực sự quan tâm nó như thế nào.

Sau đó, quay lại nguyên mẫu của bạn được xây dựng theo mô đun và sửa từng phần một.

Các vấn đề liên quan