Làm thế nào để các nhóm phát triển phần mềm chuyên nghiệp đối phó với sự phức tạp trong thiết kế trong các dự án không tầm thường?


9

Đầu tiên, tôi nhận ra câu hỏi này có thể hơi dài và mơ hồ và tôi xin lỗi vì điều này. Đây có lẽ là một vấn đề cơ bản với một tên ngắn cho bất kỳ ai "hiểu", nhưng vì tôi thấy mình thiếu về vấn đề này, xin hãy cùng tôi mô tả vấn đề.

Tôi đã làm lập trình theo cách này hay cách khác từ khi tôi khoảng 11 tuổi. Điều này có nghĩa là tôi đã chủ yếu dạy bản thân mình mọi thứ ngay từ đầu. Tôi đã nhận được một nền giáo dục kỹ thuật, nhưng không nghiêm túc về Khoa học Máy tính (tôi đã tốt nghiệp với bằng Kỹ sư Quang tử). Tất nhiên chúng tôi đã có các khóa học lập trình, nhưng đây chủ yếu là những thứ cơ bản đối với tôi và tôi đã không học được nhiều điều mới. Tôi đã tiếp tục giáo dục bản thân trên đường đi vì niềm vui của nó và luôn biết rằng tôi sẽ theo đuổi sự nghiệp lập trình, nhưng tất cả các dự án của tôi đều khá nhỏ vào thời điểm đó. Tôi không gặp khó khăn gì trong việc giữ chúng trong tâm trí và duy trì chúng.

Bây giờ, tôi thấy mình là người dẫn đầu trong một nhóm, nhưng không phải trong môi trường doanh nghiệp - tôi làm việc cho trường đại học phát triển phần mềm khoa học (trong C ++) cho các ứng dụng kỹ thuật. Đột nhiên dự án đang phát triển (tương đối) lớn và tôi gặp khó khăn trong tâm trí của mình xung quanh nó hầu hết thời gian. Tôi đang mất rất nhiều thời gian và công sức cho hai điều chủ yếu là:

  1. Khi tôi phải quay lại một phần mã mà tôi đã không làm việc trong một thời gian, tôi gặp khó khăn trong việc ghi nhớ cách thức hoạt động của nó. Tôi dành nhiều thời gian để xem xét các tệp tiêu đề cho các lớp có liên quan và đọc các bình luận tôi đặt dọc đường trong các tệp nguồn. Tôi ước có một số dạng "sơ đồ" tôi có thể nhìn thoáng qua và lấy lại hình ảnh dễ dàng hơn;
  2. Khi tôi giới thiệu các thay đổi, đôi khi tôi nhận ra một nửa rằng những gì tôi đang cố gắng sẽ phá vỡ mọi thứ ở một nơi khác (hoặc tệ hơn, nó chỉ xuất hiện trong thời gian chạy như một sự bất ngờ). Tôi hoàn nguyên và bắt đầu làm nó khác đi, chỉ để phát hiện ra tôi đã bỏ qua ảnh hưởng đối với một số thành phần khác. Tôi ước có một "sơ đồ kiến ​​trúc" nơi tôi có thể thấy mọi thứ được thực hiện như thế nào, những gì tôi đang cố gắng sẽ ảnh hưởng đến các thành phần khác và cách để tôi lên kế hoạch chi tiết trước khi tôi bắt đầu thực hiện các thay đổi.

Hầu hết những người tôi làm việc cùng có những câu chuyện tương tự như của riêng tôi - định hướng kỹ thuật mạnh mẽ và đôi khi là những kỹ năng tuyệt vời, nhưng không có cách nào để tổ chức công việc của họ. Tuy nhiên, các dự án của họ thường nhỏ hơn tôi rất nhiều nên họ đối phó bằng cách nào đó. Dù sao, điều đó có nghĩa với tôi là tôi chỉ có một mình và tôi không có ai để học những thực hành tốt từ đó.

Tôi đã tham gia một khóa học sau đại học về quản lý CNTT và trong khi tôi thấy nó khá thỏa mãn, nó chủ yếu nhắm vào những người không lập trình, giảng dạy về phương pháp quản lý dự án, dự toán ngân sách / lịch trình, kiến ​​trúc doanh nghiệp, v.v. - không phải là thiết kế và lập kế hoạch phần mềm. Không sao, tôi cũng đang cố gắng học những thứ đó. Tất nhiên, một số công cụ (như UML) và các loại quy trình phát triển phần mềm (xếp tầng, lặp lại, nhanh nhẹn ...) đã được giới thiệu, nhưng rõ ràng là không chi tiết lắm và tôi rất khó quyết định nên chọn và sử dụng cái gì ( và ở mức độ nào).

Tôi đã đọc nhiều câu hỏi và câu trả lời về thiết kế phần mềm trên SO - có nhiều cách thực hiện bằng cách sử dụng công cụ hoặc phương pháp cụ thể này và nếu tôi tin rằng tài liệu UML sẽ giải quyết vấn đề của mình - tôi sẽ chọn nó và bắt đầu sử dụng nó Nhưng một số người thề với nó, những người khác nói rằng nó vô dụng. Tôi đang tìm kiếm một câu trả lời ở mức độ trừu tượng cao hơn - có cách nào để giải quyết hai vấn đề tôi đang gặp phải không, và cá nhân bạn làm điều đó như thế nào? Tôi nên học gì để có thể làm điều đó, có thể mà không bị ràng buộc với một công cụ cụ thể nào? Đôi khi chúng đến và đi ra khỏi phong cách, và tôi hy vọng khả năng ứng dụng của chúng thay đổi tùy thuộc vào loại dự án.

Cảm ơn rất nhiều vì đã đọc, tôi không thể nói những gì tôi muốn nói ngắn gọn hơn (thiếu kinh nghiệm thiết kế phần mềm và từ vựng).


2
Tôi nghĩ rằng phản ứng chuyên nghiệp phổ biến nhất đối với những khó khăn mà bạn đang nói đến là "Chết tiệt", sau đó là đổ lỗi cho quản lý, sản phẩm hoặc một số SOB ngẫu nhiên khác.
Edward Strange

Câu trả lời:


9

Khi tôi phải quay lại một phần mã mà tôi đã không làm việc trong một thời gian, tôi gặp khó khăn trong việc ghi nhớ cách thức hoạt động của nó. Tôi dành nhiều thời gian để xem xét các tệp tiêu đề cho các lớp có liên quan và đọc các bình luận tôi đặt dọc đường trong các tệp nguồn.

Hãy tưởng tượng anh chàng tội nghiệp đến sau bạn sẽ cảm thấy như thế nào - anh ta thậm chí không có lợi ích gì khi biết mã của bạn hoạt động như thế nào. Thay vì cố gắng giải mã mã của bạn, bạn nên xem lại tài liệu mà bạn đã viết cho mô-đun được đề cập. Tài liệu đó sẽ cung cấp một cái nhìn hợp lý chính xác về những gì mô-đun làm bất kỳ lý do tại sao. Đó không phải là "mô-đun bắt đầu bằng cách khởi tạo ba mảng bằng cách sử dụng vòng lặp ba vòng ...", mà thay vào đó: "mô-đun này lấy dữ liệu được thu thập bởi cảm biến chính của Fabulotron, sắp xếp lại thành định dạng Neopolitan (sô cô la, vani, dâu tây), và đưa nó đến mô-đun Phân tích. "

Trong một thế giới hoàn hảo, bạn sẽ có một tài liệu thiết kế đưa ra các mô-đun khác nhau trong hệ thống và mô tả trách nhiệm tương ứng của chúng và mỗi mô-đun của bạn chỉ có thể tham khảo lại tài liệu đó để giải thích những gì chúng làm: "Mô-đun này cung cấp Dịch vụ thu thập dữ liệu Fabulotron như chi tiết trong phần 4.8 của tài liệu thiết kế: http://fabulotron.org/design/section4-8.html . " Nếu bạn không có cái gì đó tương tự, hãy bắt đầu viết tổng quan về từng mô-đun khi bạn làm việc với nó. Bạn không cần phải viết một cuốn sách - một vài đoạn thường đủ để bạn định hướng.

Khi tôi giới thiệu các thay đổi, đôi khi tôi nhận ra một nửa rằng những gì tôi đang cố gắng sẽ phá vỡ mọi thứ ở một nơi khác (hoặc tệ hơn, nó chỉ xuất hiện trong thời gian chạy như một sự bất ngờ). Tôi hoàn nguyên và bắt đầu làm nó khác đi, chỉ để phát hiện ra tôi đã bỏ qua ảnh hưởng đối với một số thành phần khác.

Đó có thể là một dấu hiệu cho thấy các mô-đun của bạn quá liên kết với nhau. Bạn càng có thể làm cho các mô-đun / lớp / đơn vị của mình càng độc lập thì càng ít khả năng bạn sẽ gặp phải loại vấn đề này. Cố gắng làm cho các giao diện giữa các mô-đun càng rõ ràng càng tốt và cố gắng giới hạn chúng ở những gì cần ở đó. Giao diện là một hợp đồng - nếu bạn biết rằng một số mô-đun thực hiện theo nghĩa vụ của nó như được chỉ định trong giao diện, bạn không cần phải biết bất cứ điều gì khác về nó. Điều đó ngăn những thay đổi trong mô-đun bạn đang làm việc ảnh hưởng đến các mô-đun khác.

Tôi ước có một số "sơ đồ kiến ​​trúc" nơi tôi có thể thấy mọi thứ được thực hiện như thế nào

Sử dụng các bộ phận tiêu chuẩn có thể giúp về mặt này. C ++ cung cấp các phần tiêu chuẩn dưới dạng Thư viện Mẫu Chuẩn và sử dụng các phần đó khi thích hợp cho phép bạn làm việc ở mức độ trừu tượng cao hơn. Nếu bạn đã viết mã của riêng mình để quản lý các cấu trúc dữ liệu như danh sách, bạn và những người theo dõi bạn sẽ liên tục phải đọc nguồn để tìm hiểu điều gì đang xảy ra. Thay vào đó, nếu bạn sử dụng các phần tiêu chuẩn do STL cung cấp, bất kỳ lập trình viên C ++ nào cũng sẽ nhanh chóng có thể biết mã của bạn đang làm gì mà không đào sâu vào các thói quen quản lý dữ liệu của bạn.

Một loại phần tiêu chuẩn khác đến từ các mẫu thiết kế. Chúng là những khái niệm tiêu chuẩn có thể được sử dụng như một cách viết tắt để giải thích mối quan hệ giữa hai đối tượng hoạt động như thế nào.


Cảm ơn câu trả lời. Tất nhiên tôi đã sử dụng STL trong nhiều năm, nhưng trình tự các bước mà chương trình của tôi thực hiện để tính toán một số tính toán đôi khi rất khó để hình dung toàn bộ ngay cả khi sử dụng nó. Các mô-đun cũng vậy. Tôi không có nghĩa là thay đổi một cái khác, nhưng thay đổi một cái gì đó ở đâu đó gây ra sự cố, ví dụ như khi người dùng làm một cái gì đó không chuẩn trong GUI trong đó một chuỗi phức tạp phức tạp hơn theo thứ tự các bước không thể đoán trước mà họ thực hiện để hoàn thành nó.
neuviemeporte

5

Tôi chỉ là một nhà phát triển chuyên nghiệp trong một khoảng thời gian ngắn và phải vật lộn rất nhiều với cách làm điều này khi tôi mới bắt đầu. Tôi chủ yếu tự học, thậm chí thông qua Đại học. May mắn cho tôi, những người tôi làm việc cùng có nhiều kinh nghiệm và có thể hướng dẫn tôi cách quản lý và làm việc trong các dự án lớn.

Một trong những điều đầu tiên tôi phải làm là ngồi xuống và đọc mã sạch . Đó là một cuốn sách tuyệt vời giúp tôi hiểu cách viết mã mà tôi có thể hiểu khi tôi quay lại hoặc người khác có thể hiểu.

Điều thứ hai là viết các bài kiểm tra chất lượng tốt, Đơn vị, Tích hợp, Chấp nhận. Nếu mã của bạn được kiểm tra tốt, bạn sẽ nhanh chóng biết khi nào bạn đã phá vỡ thứ gì đó và nhanh chóng có thể chẩn đoán sự cố. Có rất nhiều tài nguyên thử nghiệm tốt trên mạng và tôi không chắc đâu là tài nguyên tốt nhất để gợi ý cho bạn.

Điểm quan trọng của tôi là Kiểm tra và Mã sạch.


Cảm ơn lời đề nghị, tôi chắc chắn sẽ kiểm tra cuốn sách (mặc dù "nhanh nhẹn" trong phụ đề dường như cho thấy nó hầu như có liên quan đến phương pháp đó). Tôi có các bài kiểm tra và đã đọc nhiều sách về phong cách mã hóa (ví dụ: Lập trình viên thực dụng) Tôi luôn cố gắng tạo ra các giao diện sạch và tách biệt, nhưng đối với một thử nghiệm tự động là khó khăn cho phần GUI của ứng dụng của tôi và tôi vẫn không có cách để thực hiện thiết kế tổng thể tốt ở quy mô lớn hơn, vượt xa việc thực hiện các thực hành "sạch" trên các đoạn mã tương đối nhỏ.
neuviemeporte

2

Dưới đây là một số ý tưởng cấp cao để tổ chức các hệ thống phần mềm lớn. Hầu hết kinh nghiệm của tôi là trong các hệ thống internet, nhưng tôi nghĩ những ý tưởng này áp dụng cho phần mềm kỹ thuật.

  • Chức năng riêng biệt thành các khối mô-đun tương đối cô lập. Ví dụ: bạn có thể có một mô-đun cho từng họ tính toán mà phần mềm của bạn cung cấp.
  • Áp dụng mẫu thiết kế MVC cho giao diện người dùng, nếu có. Giữ giao diện và mô hình tách biệt với các ranh giới được xác định rõ.
  • Xem xét sử dụng các lớp để mô-đun nhóm. Trong một ứng dụng sử dụng các lớp trừu tượng, mỗi lớp chỉ phụ thuộc vào lớp bên dưới nó.
  • Khi viết tài liệu, giả sử bạn sẽ quên tất cả các chi tiết thực hiện. Bạn sẽ viết rất nhiều tài liệu theo giả định này - có thể bằng một nửa mã của bạn sẽ là nhận xét, nhưng bạn sẽ bớt bối rối hơn sau này.
  • Đơn vị tự động, kiểm tra tích hợp và chấp nhận là rất tốt trong một số không gian, nhưng các nhà phát triển C ++ dường như có cảm xúc lẫn lộn về chúng.
  • Vẽ rất nhiều trên các mẫu thiết kế . Bên cạnh việc nói chung là những ý tưởng tốt, các mẫu thiết kế cung cấp một từ vựng phổ biến trong công nghệ phần mềm. Gọi một lớp là WidgetFactory là một cách ngắn gọn để truyền đạt rằng đó là một lớp tồn tại để tạo các widget.

Đã lâu rồi tôi mới làm việc với phần mềm kỹ thuật, vì vậy số dặm của bạn có thể thay đổi theo những gợi ý này. Chúc may mắn!


1

Câu trả lời là kỹ thuật phần mềm.

Đó là đối với các dự án lớn, bạn tuân theo một chuỗi các yêu cầu thu thập, định nghĩa quy trình, đặc tả kỹ thuật, vv trước khi thực hiện bất kỳ mã hóa thực tế nào.

Có nhiều phương pháp khác nhau được sử dụng tùy thuộc vào môi trường và văn hóa. Doanh nghiệp loại hình doanh nghiệp có xu hướng tuân theo " Quy trình hợp nhất hợp lý " hoặc tương tự, các công ty khởi nghiệp công nghệ thường đi theo một số biến thể trên Agile , một số bộ phận chính phủ làm việc quá sức với phương pháp thác nước .

Trong mọi trường hợp, quy trình giúp bạn xác định chính xác những gì bạn đang làm, và, đến cuối dự án cho phép bạn chứng minh rằng bạn đã thực hiện nó.


Giả sử các yêu cầu không thay đổi (một giả định không thực tế trong nhiều trường hợp, tôi biết), có thực sự có thể chỉ định mọi thứ trước khi mã hóa và sau đó tạo phần mềm làm việc từ thông số kỹ thuật mà không cần thay đổi lớn không? Tôi chỉ không thể hình dung nó. Tôi phải bắt đầu viết mã để cảm nhận. chỉnh sửa một chút, chỉnh sửa thêm một số thứ khác ...
neuviemeporte

Điều này có thể làm việc cho các dự án nhỏ, nhưng đối với các dự án lớn, trước tiên bạn cần nắm bắt được các yêu cầu. Ngoài ra, một phần quan trọng của RUP là mô hình hóa hệ thống được đề xuất với sơ đồ UML và Sequence. Nó dễ dàng hơn nhiều để điều chỉnh và cấu trúc lại một mô hình so với mã thực tế.
James Anderson

@neuviemeporte: Nó phụ thuộc. Đôi khi các yêu cầu thay đổi hoặc yêu cầu mới được phát hiện trong quá trình phát triển. Đôi khi các yêu cầu khá rõ ràng ngay từ đầu và chỉ một số chi tiết nhỏ sẽ thay đổi trong quá trình phát triển nhưng kiến ​​trúc tổng thể sẽ giữ nguyên.
Giorgio

1

Tôi thực sự khuyên bạn nên tiếp cận với Kiến trúc sư doanh nghiệp , trong khi không miễn phí, sẽ cung cấp giá cả học thuật. Đây là một công cụ tuyệt vời để lập sơ đồ các dự án ở cả cấp độ vĩ mô và vi mô. Nó cũng có thể đảo ngược các tệp nguồn của bạn thành các sơ đồ lớp, đây có thể là một khởi đầu tốt cho bạn trong việc ghi chép và sắp xếp lại cách ứng dụng của bạn đi cùng nhau.

Tôi cũng muốn đề xuất thứ hai của @ Klee. Đừng bỏ qua các công cụ được cho là "nhanh nhẹn", vì chúng thực sự chỉ là những vật dụng thực hành tốt nhất cũng tiện dụng (nếu không bắt buộc) nếu bạn đang theo một quy trình nhanh. Nhưng tích hợp liên tục (ví dụ) là có giá trị cho dù phương pháp của bạn là gì. Hơn nữa, các bài kiểm tra đơn vị (cppUnit?) Là bạn bè của bạn. Các bài kiểm tra đơn vị sẽ rất khả thi nếu bạn kiểm tra các lớp logic được gọi bởi UI của bạn, thay vì kiểm tra trực tiếp UI. Ngoài ra còn có các công cụ có thể giúp bạn tự động kiểm tra giao diện người dùng, nhưng trước tiên tôi sẽ cố gắng kết nối các công cụ phía sau.

Chúc may mắn!


1

Tôi tin rằng vấn đề của bạn có ba chiều

  1. Định hướng lập trình viên
  2. Định hướng chương trình
  3. Bảo trì chương trình - Định hướng

Về vấn đề đầu tiên, bạn có thể có các lập trình viên không hiểu khái niệm về chương trình làm gì (điều này thường xảy ra trong các thiết lập công ty). Nhưng đi qua câu hỏi của bạn và tên miền bạn đang ở, có vẻ như bạn và nhóm của bạn đang kiểm soát những gì chương trình làm nhưng không thể dịch nó thành một chương trình làm việc trong thời gian nhanh chóng (Để trích dẫn một ví dụ, tôi đã nghe về mọi người có bằng tiến sĩ Vật lý gặp khó khăn trong việc hiểu con trỏ trong lập trình và tôi chắc chắn rằng Vật lý khó hơn nhiều so với C ++). Nếu đó là trường hợp, thì vấn đề của bạn chủ yếu là Chương trình tập trung (Bạn phải cảm thấy đủ may mắn để mọi người xung quanh có thể hiểu chương trình của bạn đang làm gì và có thể đánh giá cao nó).

Trong trường hợp các vấn đề tập trung vào chương trình, một trong những gợi ý thái quá của tôi sẽ là chuyển sang mức độ trừu tượng cao hơn C ++ như học một ngôn ngữ mới như Python hoặc Haskell (Python khá dễ học và nếu bạn có những nhà toán học giỏi, Haskell chỉ là tuyệt vời). Chuyển đến mức độ trừu tượng cao hơn sẽ giữ kích thước mã của bạn xuống, dễ hiểu và duy trì trong thời gian dài và thay đổi hiệu quả nhanh chóng. Vì vậy, bạn có thể có 10 dòng mã thay cho 50 dòng mã ban đầu. Ngoài ra, có một người có chuyên môn về lập trình máy tính chắc chắn sẽ giúp ích. Ở trong một trường đại học, bạn cũng có thể thu hút một vài sinh viên về GUI và giao diện để bạn có thể tập trung hơn vào chức năng. Tôi cũng giới thiệu cuốn sách Thiết kế phần mềm C ++ quy mô lớn của John Lakos(Đây là một cuốn sách khá lớn, bạn có thể trở thành một Lập trình viên Python thành thạo trong thời gian bạn có thể đọc cuốn sách này)

Nếu bạn loại ra khỏi 2 chiều đầu tiên của vấn đề, thì thứ ba sẽ tự động được giải quyết. Vì tôi tin rằng bạn đang làm việc trên một dự án lớn duy nhất, bất kỳ phần mềm quản lý dự án tử tế nào bạn sẽ giúp bạn vượt qua. Kế hoạch trả trước là cần thiết. Nếu bạn bắt đầu viết mã ngay lập tức, bạn có thể tham gia quá nhiều vào chương trình mà bạn sẽ quên đi bức tranh lớn. Giữ mọi thứ trong tâm trí sẽ không làm việc cho một dự án lớn. Đặt mọi thứ vào giấy (hoặc trong máy tính). Sử dụng wiki để chia sẻ thông tin. Về phương pháp luận, tôi thích phương pháp nhanh nhẹn (Đơn giản, nhanh nhẹn là một tên thời trang để phát triển phần mềm gia tăng). Tôi cũng đề nghị thuê một người có chuyên môn trong lĩnh vực này để anh ta quan tâm đến những điều này để bạn có thể tập trung vào chương trình cốt lõi của mình. Điểm mấu chốt ở đây là tất cả các phương pháp quản lý dự án chỉ là một cách để đảm bảo sự thành công của chương trình; vì vậy bạn có thể chọn bất kỳ ai phù hợp với bạn và nhóm của bạn thay vì chọn thứ gì đó mà ai đó đề xuất là tốt nhất. Ngoài ra, phần mềm sau đây cũng có thể giúp bạn

  • Free Mind - Phần mềm bản đồ tư duy
  • Trac - Chương trình lỗi phần mềm nhanh chóng và dễ dàng và wiki
  • MoinMoin - wiki nhanh để cho phép chia sẻ kiến ​​thức về chương trình

Mặc dù những lời khuyên trên sẽ có một số đường cong học tập đáng giá về lâu dài. Và cuối cùng, lập trình dễ hơn Kỹ thuật Photonic (mặc dù không phải Lập trình C ++)


0

Giống như câu hỏi của bạn, bất kỳ câu trả lời nào hữu ích cho bạn sẽ rất dài và mơ hồ - nhưng câu trả lời ngắn gọn là "Kỹ thuật phần mềm"

Tôi đề nghị bạn xóa một chút thời gian rảnh, càng nhiều càng tốt nếu bạn nghiêm túc về sự nghiệp phát triển phần mềm và bắt đầu bằng trang web Steve McConnells hiện tại. Lập trình dễ dàng và có thể được dạy trong một học kỳ, Kỹ thuật phần mềm là một thứ tự phức tạp hơn và cần nhiều thời gian hơn để học.

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.