Điều gì làm cho một dự án lớn? [đóng cửa]

Vì tò mò, sự khác biệt giữa một dự án quy mô nhỏ, vừa và lớn là gì? Được đo bằng dòng mã hay độ phức tạp hay sao?

Tôi đang xây dựng một hệ thống trao đổi và cho đến nay có khoảng 1000 dòng mã để đăng nhập / đăng ký. Mặc dù có rất nhiều LỘC, tôi sẽ không coi đó là một dự án lớn vì nó không phức tạp mặc dù đây là dự án đầu tiên của tôi nên tôi không chắc chắn. Nó được đo như thế nào?

Phức tạp.

Càng phức tạp, càng khó học mọi thứ trong dự án.

Gần như làm thế nào tôi đồng ý mọi thứ - hãy nhớ rằng điều này ít nhiều tùy tiện. "Kích cỡ" của dự án trong tổng hợp các yếu tố khác như độ phức tạp, dòng mã nguồn, số tính năng / giá trị doanh nghiệp, v.v ... Một sản phẩm rất nhỏ có thể mang lại một lượng giá trị lớn, v.v.

• 2m + sloc là một dự án lớn đến rất lớn. Chúng thường phức tạp đến mức ít người biết "thông thạo" trong toàn bộ hệ thống; thay vì trách nhiệm có xu hướng được mô đun hóa dọc theo cấu trúc của mã. Những dự án này thường mang lại giá trị kinh doanh to lớn và có thể là nhiệm vụ quan trọng. Họ đôi khi cũng chịu một loạt các khoản nợ kỹ thuật nặng nề và các mối quan tâm di sản khác.

• 100k - 2m sloc là một dự án cỡ trung bình. Đây là nền tảng trung gian của tôi: dự án đủ phức tạp để đòi hỏi một số kiến ​​thức chuyên môn và có khả năng tích lũy một số mức độ nợ kỹ thuật; nó cũng có khả năng cung cấp một số mức độ của giá trị kinh doanh.

• 10k - 100k là một dự án nhỏ, nhưng không quá nhỏ để có đủ độ phức tạp mà bạn sẽ muốn các chuyên gia xem xét; nếu bạn là nguồn mở, hãy xem xét nhận những người bạn tin tưởng để xem xét các cam kết của bạn.

• Bất cứ điều gì ít hơn 10k sloc là rất nhỏ, thực sự. Điều đó không có nghĩa là nó không thể cung cấp bất kỳ giá trị nào cả, và nhiều dự án rất thú vị có dấu ấn rất nhỏ (ví dụ: Cắm trại, có nguồn là ~ 2 kb (!)). Những người không phải là chuyên gia thường có thể gây ra những lo ngại về giá trị - sửa lỗi và thêm tính năng - mà không cần phải biết quá nhiều về tên miền.

Kích thước của dự án được đo bằng mức độ không thể nhầm lẫn.

Sự phức tạp có thể được ước tính theo một số cách:

1. Ngân sách. Một dự án có ngân sách 10.000.000 đô la + có lẽ khá khác biệt so với dự án dưới 10.000 đô la chẳng hạn. Điều này có thể bao gồm lao động, phần mềm, phần cứng và các chi phí khác phát sinh khi thực hiện một dự án.
2. Người giờ làm việc để hoàn thành dự án. Nó sẽ mất một triệu giờ hoặc cái gì khác? Đây cũng có thể được coi là một yếu tố dòng thời gian trong đó một số dự án có thể mất nhiều năm mà tôi nói là lớn so với các dự án khác có thể mất ít hơn một tuần. Lưu ý rằng số giờ của người đó có thể gây hiểu lầm vì ai đó có thể nghĩ bằng cách nhân đôi số nhân viên để có gấp đôi số người làm việc trong dự án sau đó lịch trình có thể bị cắt làm đôi mà hiếm khi làm việc trong tâm trí tôi.
3. Số lượng phần cứng, hệ thống khác và mọi người sử dụng những gì dự án đang xây dựng. Nếu một cái gì đó được buộc vào 101 hệ thống thì có thể phức tạp hơn nếu nó đứng một mình và không liên kết với bất kỳ thứ gì khác.

Mặc dù các yêu cầu nghe có vẻ giống như một cách hay để đo lường điều này, nhưng thường có nhiều yêu cầu sẽ được tìm thấy khi một dự án được thực hiện với giả định là một phương pháp phi Thác nước mà tôi tin.

Một kích thước dự án có thể được đo lường tốt nhất bằng số lượng yêu cầu mà hệ thống có, trong đó các yêu cầu không thể giảm xuống hơn nữa.

Tất nhiên, nhiều yêu cầu hơn chủ yếu có nghĩa là phức tạp hơn, nhưng không phải lúc nào cũng như vậy.

Tôi đo kích thước của một dự án bằng cách khó xem toàn bộ dự án như một bức tranh lớn. Ví dụ: tôi có một cơ sở mã khám phá / tạo mẫu cho một vấn đề máy học tôi đang làm việc. Nó chỉ có 5k dòng mã, nhưng cảm giác như một dự án lớn. Có hàng tấn tùy chọn cấu hình tương tác theo những cách không thể đoán trước. Bạn có thể tìm thấy mọi mẫu thiết kế mà con người biết ở đâu đó trong cơ sở mã để quản lý tất cả sự phức tạp đó. Thiết kế thường không tối ưu vì sự phát triển rất nhiều do quá trình tiến hóa và không được tái cấu trúc thường xuyên như vậy. Tôi là người duy nhất hoạt động trên cơ sở mã này, nhưng tôi thường ngạc nhiên về cách mọi thứ tương tác.

Mặt khác, một trong những dự án sở thích của tôi có mã khoảng 3-4 lần, nhưng nó cảm thấy nhỏ hơn rất nhiều vì về cơ bản nó là một thư viện các hàm toán học chủ yếu là trực giao với nhau. Mọi thứ không tương tác theo những cách phức tạp và thật tuyệt khi hiểu từng chức năng một cách cô lập. Thật dễ dàng để nhìn thấy bức tranh lớn đến mức có một, bởi vì không có nhiều thứ để xem.

Câu trả lời tùy tiện: Dự án lớn đến mức nào bạn muốn bạn đã thực hiện nó với nguồn cung cấp sự kiện và SOA ngay từ đầu. Hoặc là các tác giả của hệ thống đã đọc cuốn sách "DDD: Xử lý sự phức tạp trong trái tim của phần mềm" của Evan;)

Tương đương & Phạm vi

Độ phức tạp và phạm vi Tôi tin là những gì quyết định một dự án thực sự lớn như thế nào. Tuy nhiên, có một số tài sản vô hình cũng có thể ảnh hưởng đến quy mô của một dự án.

Yêu cầu

Sự sụp đổ lớn nhất mà tôi phải đối mặt là thiếu các yêu cầu. Trong tình huống cụ thể của tôi, người quản lý bán hàng đã xác định các yêu cầu. Trọng tâm của anh là bán hàng ... phải bán. Trong tâm trí của anh ấy những gì khách hàng yêu cầu dường như không quá phức tạp bởi vì chúng tôi đã xây dựng một cái gì đó tương tự. Yêu cầu mơ hồ dẫn đến việc làm được định giá thấp và vượt quá mong đợi.

Thiếu CCMU

CCMU là cái mà tôi gọi là " Coo Ca Moo " (Xóa hoàn toàn sự hiểu biết lẫn nhau). Bạn cần phải có CCMU với khách hàng của mình.

Nếu bạn có một dự án nhỏ với CCMU kém thì bạn có thể thực hiện dự án 2,3,4 lần trở lên. Do đó, một công việc 20 giờ đơn giản biến thành một dự án 60 giờ với một nhân viên căng thẳng và một khách hàng rất không hài lòng.

Creep phạm vi

Điều này xảy ra thường xuyên hơn bạn nghĩ. Khách hàng quyết định rằng vì bạn đã làm A, B & C nên không khó để thêm D hoặc thậm chí F. Nếu hành vi này không được kiểm tra, nó cũng có thể biến một dự án nhỏ thành dự án cỡ trung bình. Và tùy thuộc vào cách người quản lý bán hàng bán công việc, những kỳ vọng này có thể "MIỄN PHÍ" đối với khách hàng.

Thật kỳ lạ, đọc rất nhiều câu trả lời này tôi thấy tôi thấy quy mô của một dự án rất khác nhau. Có lẽ đó là công việc của tôi trong một tập đoàn lớn nhưng tôi có xu hướng xem quy mô của dự án như là một quy mô về khả năng hiển thị / mong muốn của nó đối với khách hàng của nó (tùy thuộc vào lĩnh vực công việc của bạn, đây có thể là đồng nghiệp hoặc khách hàng trả tiền thực tế).

Sự phức tạp là câu trả lời đúng, nhưng làm thế nào để ước tính nó?

Các yếu tố là:

1. Số điểm gia hạn
2. Số lượng mô-đun đếm (chức năng, lớp, hệ thống lớp, thư viện, thư viện dùng chung, ứng dụng, ứng dụng mạng, v.v.)
3. Số lượng phụ thuộc (bao gồm các nền tảng)
4. Tính năng phụ thuộc lẫn nhau.
5. Các tài nguyên không phải là mã cần thiết (bao gồm đồ họa / nghệ thuật, tập lệnh lái xe - như tập lệnh thiết kế mức - và các tài nguyên khác cần thiết để hoàn thành phiên bản của ứng dụng).

Bạn càng có nhiều trong số đó, dự án càng phức tạp.

LỘC là nổi tiếng là không chính xác đối với nhiều phép đo, nhưng tôi nghĩ rằng bạn đang cố gắng để đo lường cái gì đó có thực sự không phải là một cách chính xác để đo lường. Có lẽ một sự thay thế có thể là phức tạp chu kỳ .

Cuối cùng, tôi nghĩ rằng "bigness" của một dự án là khó định lượng. Nó gần giống như hỏi làm thế nào bạn xác định xem một con chó có lớn hay không. Không chỉ có nhiều cách để đo lường nó (khối lượng, khối lượng, v.v.), mà cá nhân tôi không thấy nó rất hữu ích. Thực tế là tiêu chí của tôi có lẽ sẽ là một cái gì đó như "Tôi có khả năng chạy khỏi con chó này như thế nào nếu tôi nhìn thấy nó trong một con hẻm tối?"

Và đối với hồ sơ, tôi thường không coi các dòng mã 1k là nhiều. Nó sẽ là một đoạn khá lớn mã, nhưng nó sẽ không có nhiều trong các chương trình lớn của sự vật. Tất nhiên, tôi cho rằng nó phụ thuộc vào ngôn ngữ. Ví dụ, 1k dòng mã là nhiều ít mã trong một ngôn ngữ như C hơn là trong một ngôn ngữ như Pyhon.