Các phương pháp phát triển có nên đè bẹp chủ nghĩa cá nhân của nhà phát triển?

Tôi đang trong học kỳ cuối đại học và đang tham gia khóa học kỹ thuật phần mềm. Trong lớp, chúng tôi tìm hiểu về các phương pháp phát triển phần mềm khác nhau. Phương pháp chúng tôi tập trung và sử dụng để phát triển dự án của mình là phương pháp thác nước.

Tôi cảm thấy như người hướng dẫn có thể đã thực hiện nó sai. Trong sơ đồ lớp của chúng tôi, chúng tôi đã phải liệt kê TẤT CẢ các thuộc tính và phương thức bao gồm cả các thuộc tính riêng. Tôi đã đọc một vài cuốn sách, cụ thể là Clean Code, nói rằng giữ cho các chức năng càng ngắn và tập trung càng tốt. Có vẻ tẻ nhạt khi liệt kê mọi chức năng nhỏ trong sơ đồ của chúng tôi nếu chúng không giúp các nhà phát triển khác (chúng là riêng tư, không ai khác sẽ sử dụng chúng). Thêm vào đó, tôi có thể không nghĩ về mọi chức năng nhỏ bé khi thiết kế chương trình, chúng có thể xuất hiện khi tái cấu trúc.

Có phải người hướng dẫn đã nói với chúng tôi sai bằng cách yêu cầu chúng tôi liệt kê mọi chức năng? Và, liệu các phương pháp thiết kế này có đè bẹp chủ nghĩa cá nhân của nhà phát triển để viết mã làm thế nào họ có thể hiểu rõ nhất về nó?

Bạn đã hỏi người hướng dẫn tại sao bạn phải liệt kê tất cả các phương pháp?

Có thể, giống như hầu hết những gì được yêu cầu trong môi trường lớp học, ý định không phải là làm cho sơ đồ lớp của bạn hữu ích hơn cho các nhà phát triển mà là giúp bạn và các bạn cùng lớp nghĩ về cách bạn sẽ thiết kế các lớp học. Khi học sinh đang học cách phân tách các vấn đề lớn hơn thành các vấn đề nhỏ hơn, có lẽ sẽ hữu ích cho họ khi nghĩ về những phương pháp riêng tư nào họ có thể cần. Và nó có thể hữu ích cho người hướng dẫn để hiểu rõ hơn về phương pháp mà sinh viên đang nghĩ đến việc thực hiện để can thiệp sớm hơn vào quy trình nếu thiết kế của ai đó được suy nghĩ kém. Tài liệu trong môi trường lớp học thường liên quan nhiều hơn tài liệu trong môi trường thế giới thực bởi vì người hướng dẫn '

Tất nhiên, cũng có thể là người hướng dẫn tin rằng mức tài liệu này là hữu ích trong một dự án thực sự. Nếu đó là trường hợp, người hướng dẫn có thể đã lỗi thời hoặc đến từ một nền tảng cụ thể mà mức độ lập kế hoạch và tài liệu này là phù hợp. Ví dụ, nếu bạn đang xây dựng hệ thống điều hướng cho tàu con thoi hoặc thiết kế các thiết bị y tế, thì việc đầu tư mạnh vào thiết kế trước hơn là tái cấu trúc mã trong quá trình phát triển. Nếu bạn đang phát triển một trang web mạng xã hội, mặt khác, một cách tiếp cận nhanh hơn sẽ phù hợp hơn.

Không, người hướng dẫn đã đúng khi yêu cầu bạn liệt kê tất cả các thuộc tính và phương thức trả trước nếu bạn đang sử dụng phương pháp thác nước. Wikipedia ghi nhận một lời chỉ trích về thác nước:

Nhiều người cho rằng mô hình thác nước là một ý tưởng tồi trong thực tế, tin rằng không thể có bất kỳ dự án không tầm thường nào hoàn thành một giai đoạn trong vòng đời của một sản phẩm phần mềm trước khi chuyển sang các giai đoạn tiếp theo và học hỏi từ chúng. Ví dụ, khách hàng có thể không biết chính xác những yêu cầu họ cần trước khi xem xét một nguyên mẫu hoạt động và nhận xét về nó. Họ có thể thay đổi yêu cầu của họ liên tục. Các nhà thiết kế và lập trình viên có thể có ít quyền kiểm soát về điều này. Nếu khách hàng thay đổi yêu cầu của họ sau khi thiết kế được hoàn thành, thiết kế phải được sửa đổi để phù hợp với yêu cầu mới. Điều này có nghĩa là vô hiệu hóa một lượng lớn thời gian làm việc, có nghĩa là chi phí tăng lên, đặc biệt là nếu một lượng lớn tài nguyên của dự án đã được đầu tư vào Big Design Up Front.

Các phương pháp thiết kế này không đè bẹp người thực hiện chủ nghĩa cá nhân của thiết kế vì vẫn còn những phần cần diễn giải và cách đặt các nét độc đáo của một người lên cấu trúc, ví dụ như hình ảnh được đưa ra một bộ xương và thêm các cơ và các mô khác để tạo ra một con vật tự hỏi bao nhiêu tự do bạn đã phải thiết kế con vật đó?

Bạn đã tìm thấy một thiếu sót của thác có nhưng mọi thứ đều có điểm mạnh và điểm yếu.

Trong lớp, chúng tôi tìm hiểu về các phương pháp phát triển phần mềm khác nhau. Phương pháp chúng tôi tập trung và sử dụng để phát triển dự án của mình là phương pháp thác nước.

Có lẽ bạn đã học mô hình Thác nước cổ điển, mà người được cho là đã giới thiệu nó với thế giới phát triển phần mềm được nêu từ đầu là không phù hợp để phát triển các hệ thống phần mềm quy mô lớn. Có lẽ bạn sẽ thích đọc bài báo của Winston Royce có tiêu đề Quản lý sự phát triển của các hệ thống phần mềm lớn để tìm hiểu thêm về các vấn đề với những gì nhiều người coi là mô hình Thác nước.

Tuy nhiên, mô hình Waterfall phù hợp để dạy vòng đời phát triển phần mềm khi bạn trải qua và có thể dành thời gian tìm hiểu và thực hiện các yêu cầu kỹ thuật, thiết kế kiến ​​trúc, thiết kế chi tiết, thực hiện, thử nghiệm và bảo trì theo các giai đoạn rất rõ ràng, khác biệt.

Trong sơ đồ lớp của chúng tôi, chúng tôi đã phải liệt kê TẤT CẢ các thuộc tính và phương thức bao gồm cả các thuộc tính riêng. Tôi đã đọc một vài cuốn sách, cụ thể là Clean Code, nói rằng giữ cho các chức năng càng ngắn và tập trung càng tốt. Có vẻ tẻ nhạt khi liệt kê mọi chức năng nhỏ trong sơ đồ của chúng tôi nếu chúng không giúp các nhà phát triển khác (chúng là riêng tư, không ai khác sẽ sử dụng chúng). Thêm vào đó, tôi có thể không nghĩ về mọi chức năng nhỏ bé khi thiết kế chương trình, chúng có thể xuất hiện khi tái cấu trúc.

Đây là tất cả các điểm rất hợp lệ.

Liệt kê tất cả các thuộc tính và phương thức trong giai đoạn thiết kế, ngay cả khi sử dụng Waterfall, có thể là quá mức cần thiết. Bạn chắc chắn nên liệt kê mọi thứ công khai, cùng với các thuộc tính cần thiết. Trong thực tế, mọi thứ khác là một chi tiết triển khai mà bạn có thể có được bằng cách đảo ngược việc thực hiện thành sơ đồ.

Lời khuyên của Clean Code (Tôi chưa bao giờ đọc nó - Tôi chỉ thực hiện theo những gì bạn đã đăng) có vẻ công bằng và có thể áp dụng ngay cả khi sử dụng phương pháp Waterfall. Bạn có thể thiết kế các lớp và phương thức của mình theo Nguyên tắc Trách nhiệm duy nhất , phân tách các mối quan tâm và các nguyên tắc khác của RẮN . Thác nước không cho bạn biết cách thiết kế, ngay khi bạn cần làm. Điều đó nói rằng, khó hơn trước khi bạn tìm hiểu và nghĩ ra những cách tốt hơn để làm điều đó trong quá trình thực hiện.

Tôi nghĩ rằng điều này chỉ ra thực tế rằng cần phải có sự lặp lại giữa thiết kế và triển khai rất rõ ràng - một vấn đề mà Waterfall truyền thống không giải quyết được.

Có vẻ tẻ nhạt khi liệt kê mọi chức năng nhỏ trong sơ đồ của chúng tôi nếu chúng không giúp các nhà phát triển khác (chúng là riêng tư, không ai khác sẽ sử dụng chúng).

Nếu bạn nghĩ rằng điều này là tẻ nhạt, hãy đợi cho đến khi bạn có được một chương trình công việc thực sự. Hãy xem xét, trong một lúc, phần mềm đó có thể không phải là một nghề nghiệp khả thi cho bạn.

Thêm vào đó, tôi có thể không nghĩ về mọi chức năng nhỏ bé khi thiết kế chương trình, chúng có thể xuất hiện khi tái cấu trúc.

Vì thế?

người hướng dẫn đã nói với chúng tôi sai bằng cách yêu cầu chúng tôi liệt kê mọi chức năng?

Không. Đó là một yêu cầu chung.

Và, liệu các phương pháp thiết kế này có đè bẹp người thực hiện chủ nghĩa cá nhân của nhà thiết kế (nhà phát triển) để viết mã làm thế nào họ có thể hiểu rõ nhất về nó?

Đúng. Sự nghiền nát linh hồn của các cá nhân là một phần quan trọng của sự phát triển phần mềm. Tất cả các cá nhân sẽ bị đánh bật ra khỏi tất cả các lập trình viên mọi lúc bằng mọi cách có thể. Nó nói rằng một nơi nào đó trong "Quy tắc lập trình của Chúa" được truyền lại từ một ngọn núi cho một nhà tiên tri nào đó.

Không. Bạn chỉ chùn bước ở tedium. Hãy vượt qua nó và trở lại làm việc.

Lập trình là nghệ thuật làm việc trong giới hạn. CPU cung cấp một tập lệnh giới hạn; IO bị hạn chế bởi thiết kế của phần cứng; API hệ điều hành được tạo để khuyến khích một số hành vi nhất định và hạn chế các hành vi khác; ngôn ngữ cấp cao thường được thiết kế để quảng bá một bộ thành ngữ hơn các ngôn ngữ khác ...

Và phương pháp cũng được chế tạo để hạn chế.

Thách thức của bạn, trong tất cả các khía cạnh của quá trình phát triển, là nhận ra tầm nhìn của bạn trong những hạn chế đó. Bạn sẽ đập đầu vào từng bức tường bị ném lên bởi phần cứng, ngôn ngữ, API và phương pháp luận? Hay bạn sẽ tìm cách hài hòa những gì bạn muốn đạt được với những gì được phép và khuyến khích?

Bạn có thực sự nghĩ rằng người hướng dẫn của bạn muốn đọc qua những trang vô tận của minutia? Sau đó kiểm tra lý thuyết đó: phá vỡ một chương trình và ghi lại từng nguyên tử. Khi bàn làm việc của anh ta bị chùng xuống dưới sức nặng, tôi nghi ngờ bạn sẽ thấy rằng ham muốn thực sự của anh ta có phần khác với những gì bạn mong đợi.

Hoặc chuẩn bị các tài liệu khi bạn thấy phù hợp. Làm cho nó rõ ràng, làm cho nó dễ hiểu, làm cho nó đọc như một cuốn tiểu thuyết Dashiell Hammett. Và sau đó ngồi xuống và nói chuyện với anh ta, cho anh ta thấy những gì bạn đã làm, thuyết phục anh ta về công đức của nó.

Tôi nghĩ rằng người hướng dẫn là tuyệt vời để khiến bạn thực hiện dự án này, và do đó dạy cho bạn những ưu và nhược điểm của việc phát triển Thác nước.

Một nguyên tắc đơn giản để đánh giá mức độ phức tạp của phân tích dự án là "Nhà phát triển hoặc công ty mà anh ta làm việc có thể chịu trách nhiệm cho một điều gì đó đủ kịch tính (thường bao gồm cả cái chết hoặc số tiền khổng lồ bị mất) xảy ra với phần mềm được tạo ra không?".

Tôi đã có cùng kinh nghiệm với bạn cho một số khóa học của tôi. Những người có nền tảng trong ngành công nghiệp kỹ thuật sẽ dạy chúng tôi phân tích. Và đó sẽ là phân tích đầy đủ và đầy đủ, lập kế hoạch cho tất cả quá trình của dự án, ngay cả trong những chi tiết nhỏ nhất. Bạn không thể đủ khả năng lặp lại nhiều lần với loại dự án này (cũng có thể phát nổ bom, ok ngân sách không nổ), vì vậy không có chỗ cho sự sáng tạo ở đây, bạn phải đi theo kế hoạch.

Mặt khác, nếu bạn đã đọc một chút, bạn chắc chắn đọc về các phương pháp nhanh. Nhìn chung có ít tài liệu hơn và có nhiều chỗ hơn cho nhà phát triển sử dụng sự sáng tạo của mình trong khi phát triển một giải pháp cho vấn đề mà anh ta gặp phải.

Tóm lại, bạn càng có nhiều kinh nghiệm, càng tốt, và những gì người hướng dẫn của bạn cho thấy bạn áp dụng trong một số phần của ngành. Chỉ cần lưu ý rằng chắc chắn có nhiều cách để quản lý và thiết kế một dự án cũng như có mã để thực hiện chúng. Và bạn sẽ tìm thấy những người bảo vệ và chỉ trích cho tất cả bọn họ. Kiểm tra chúng trong khi bạn đang học và chọn một trong những bạn hài lòng.

Một số lớp kỹ thuật phần mềm, chẳng hạn như lớp tôi đã có, được dạy theo phong cách kỳ lạ, "thất bại là thành công", thành công là một cơ hội lãng phí để học hỏi từ thất bại, và càng ngày càng ít đi. Nếu đây là một trong số đó, thì chỉ cần gắn bó với các bài tập và tận hưởng sự kỳ lạ.

Tôi nghĩ rằng người hướng dẫn của bạn mất liên lạc. Phần mềm thương mại hiếm khi được thiết kế hoặc ghi lại ở mức độ đó. Nó quá đắt, và tài liệu kết quả có thể được duy trì mà không cần thêm chi phí. IMO thực hành như vậy là một di sản từ những ngày mà mã hóa thường được thực hiện bằng ngôn ngữ lắp ráp. Thời gian của bạn sẽ được dành tốt hơn để thử các thực hành nhanh nhẹn hơn: phát triển dựa trên thử nghiệm, lập trình cặp, tái cấu trúc liên tục.

Có phải người hướng dẫn đã "nói với bạn sai"?

Tôi nghĩ vậy.

Phân công công việc nhàm chán cho công nhân sở hữu trí tuệ là lãng phí. Ở trường, công việc nhàm chán có rất ít hoặc không có giá trị sư phạm, ngoại trừ có lẽ để sinh viên làm việc nhàm chán. Những bài tập như vậy có những hậu quả tiêu cực, cho cả sinh viên và ngành công nghiệp. Các sinh viên bị tổn hại vì thời gian của họ bị lãng phí. Ngành công nghiệp bị tổn hại, bởi vì một số sinh viên có thể kết luận rằng tedium như vậy là cần thiết và hữu ích. Nó cũng không. Trong ba mươi năm về phần mềm, công việc duy nhất tôi có thể nghĩ đó là cả nhàm chán và hữu ích là thay đổi băng dự phòng. Có những robot có thể làm điều đó, nhưng chúng rất đắt.