Các cơ sở mã lớn hoặc cũ nên được điều hướng dễ dàng?


8

Tôi là một sinh viên khoa học máy tính đại học hiện đang trong một năm sắp xếp tại một công ty sản xuất và hỗ trợ một ứng dụng web doanh nghiệp lớn. Tôi yêu trải nghiệm khi thấy phần mềm được sản xuất trong thế giới thực và cảm thấy rất may mắn khi tìm thấy một công ty mang đến cơ hội không chỉ duy trì và mở rộng chức năng hiện có mà còn phát triển các tính năng hoàn toàn mới cho sản phẩm.

Mặc dù vậy, tất cả những gì đã nói, tôi rất ý thức rằng điều này rất, rất khó có thể là một ví dụ hoàn hảo về cách phát triển chính xác. Xa từ nó, trong thực tại. Tôi cảm thấy mình đang học được một lượng lớn từ kinh nghiệm của mình ở đây và tôi không muốn học những điều sai trái hoặc từ bỏ những thói quen xấu từ những đồng nghiệp khó có thể rũ bỏ xuống đường. Hầu như thật dễ dàng để nói điều gì tốt và điều gì không - ví dụ, phạm vi kiểm tra Đơn vị ở đây thực tế không tồn tại vì nhiều lý do (chủ yếu là những lý do kém cỏi trộn lẫn với một hoặc hai điểm hợp lệ). Gần đây, mặc dù, tôi đã nhận thấy một sự xuất hiện thường xuyên mà tôi chỉ không chắc chắn về.

Bất cứ khi nào chúng tôi bắt đầu một dự án mới, tự nhiên chúng tôi cần tìm bất kỳ mã nào có liên quan cần được mở rộng, thay đổi hoặc xóa. Dường như với tôi rằng, phần lớn thời gian, bất cứ điều gì không nằm trong các phần được sử dụng phổ biến nhất của ứng dụng đều khiến mọi người mất một tuổi để tìm thấy trong cơ sở mã. Có một hoặc hai nhà lãnh đạo công nghệ biết rõ phần mã của họ, nhưng thậm chí đôi khi họ bị vấp ngã và phải mất một thời gian dài để tìm kiếm những gì họ yêu cầu, hoặc chuyển sang một người đã chỉnh sửa phần mã đó gần đây ( nếu có ai) giúp đỡ Khi tôi nói lâu, tôi không có nghĩa là hàng giờ (thông thường) nhưng đối với tôi, một cơ sở mã tốt sẽ có thể điều hướng đến bất kỳ điểm nào trong vòng vài phút tồi tệ nhất, với bất kỳ ai thậm chí mơ hồ với hệ thống.

Vì vậy, câu hỏi của tôi. Là vấn đề trên do mã cấu trúc kém? Ngoài ra, có phải các nhà phát triển không có đủ kiến ​​thức về cơ sở mã? Hoặc đơn giản là không thể tránh khỏi trong các ứng dụng lớn, bất kể có bao nhiêu công việc đi vào để giữ cấu trúc tệp rõ ràng?

Hoặc, thực sự ... tôi chỉ lãng phí thời gian của mình vào một chủ đề thực sự không quan trọng?


5
Sự phức tạp khó quản lý ... cơ sở mã càng lớn thì vấn đề này càng trở nên tồi tệ hơn.
Oded

Nếu bạn "không muốn học những điều sai trái hoặc từ bỏ thói quen xấu từ đồng nghiệp", hãy xem câu hỏi này và chọn một vài cuốn sách để đọc
Dylan Yaga


Cả hai đều là về các cơ sở mã lớn không làm cho nó trở thành một bản sao. Hỏi tại sao các cơ sở mã lớn khó điều hướng là một câu hỏi rất khác với cách điều hướng một.
Karl Bielefeldt

Câu trả lời:


19

Cơ sở mã lớn không được thiết kế, chúng phát triển. Rất nhiều điều không có ý nghĩa khi nhìn vào ảnh chụp nhanh hiện tại, có ý nghĩa hoàn hảo khi bạn tính đến lịch sử. Và tôi không chỉ có nghĩa là lịch sử cá nhân của cơ sở mã, tôi cũng có nghĩa là lịch sử thực hành kỹ thuật phần mềm nói chung.

Kiểm thử đơn vị gần như luôn tồn tại ở một mức độ nào đó, nhưng không thực sự được sử dụng rộng rãi cho đến khi phát triển theo hướng lập trình và kiểm thử cực đoan được "phát minh" vào khoảng năm 1999 đến 2003. Rất nhiều cơ sở mã có trước đó, và do đó không được thiết kế theo cách làm cho thử nghiệm đơn vị dễ dàng.

Có lịch sử tương tự đằng sau các thực hành kỹ thuật phần mềm khác. Ví dụ, cuộc cách mạng DVCS năm 2005 đã thay đổi cách mọi người nghĩ về quy trình công việc và mô hình phân nhánh, ngay cả với kiểm soát phiên bản không phân tán. Đối với một ví dụ khác, mặc dù nó đã tồn tại, hầu như không ai nghe nói về mẫu thiết kế MVC cho đến khi Microsoft tạo ra một khung với tên đó, và bây giờ việc không tách rời mô hình và khung nhìn bị nản lòng hơn nhiều so với trước đây, ngay cả trong các dự án không sử dụng khung của Microsoft.

Việc tạo và phổ biến các công cụ đánh giá ngang hàng trực tuyến về cơ bản đã chấm dứt việc thực hành đánh giá ngang hàng là một cuộc họp chính thức, và làm cho chúng dễ thực hiện hơn, và do đó phổ biến hơn. Việc phổ biến các ngôn ngữ được thu thập rác đã thúc đẩy các đổi mới quản lý bộ nhớ trong C ++ như con trỏ thông minh và RAII, hiện được coi là thông lệ tiêu chuẩn, nhưng chưa từng thấy khi nhiều cơ sở mã hiện tại được bắt đầu. Tôi có thể đi và về.

Khi các công ty phát triển, họ cố gắng tận dụng việc tái sử dụng mã càng nhiều càng tốt, do đó, một kiến ​​trúc mã lý tưởng cho một sản phẩm có thể bị kéo vào một dự án khác với một chút sửa đổi, mặc dù kiến ​​trúc có thể hơi khó xử trong bối cảnh mới . Khi điều này xảy ra nhiều lần trong nhiều thập kỷ, bức tranh lớn sẽ ngừng có ý nghĩa.

Không phải là các công ty không muốn thay đổi theo thời đại, mà các cơ sở mã giống như tàu biển. Họ mất nhiều thời gian và kế hoạch cẩn thận để quay lại. Do đó, rất khó có thể bạn sẽ tìm thấy một cơ sở mã lớn sẽ không được thiết kế lại theo một cách khác nếu bắt đầu từ đầu ngày hôm nay. Điều quan trọng để tìm kiếm là nếu một công ty đang phấn đấu để đi đúng hướng.


Hãy xem, đây là những gì tôi yêu thích về người của StackExchange. Bạn không chỉ trả lời bằng câu hỏi rõ ràng và nhiều thông tin, bạn còn cung cấp vô số bối cảnh và cùng với đó là một số lịch sử CS liên quan. Cảm ơn bạn. Tôi sẽ để câu hỏi mở trong một ngày hoặc lâu hơn trong trường hợp bất kỳ ai khác có bất cứ điều gì để thêm, nhưng tôi nghĩ rằng điều này sẽ gây ra một số lỗi cho câu trả lời được chấp nhận: P
Hecksa

6
Đừng bỏ qua chi phí sửa chữa nó hầu như luôn vượt quá chi phí sống với nó. Đọc bài viết này - Joel trên phần mềm ( joelonsoftware.com/articles/fog0000000069.html )
mattnz

5

Chắc chắn có một giới hạn cho sự phức tạp mà tâm trí con người có thể nắm bắt. Bạn không thể mong đợi ai đó biết cách của mình xung quanh hàng triệu dòng mã. Đó là lý do tại sao bạn nên cấu trúc và ghi chép nó một cách hợp lý và dễ hiểu. Thông thường, cơ hội để cấu trúc mã bị bỏ qua. Bạn sẽ không tìm thấy một lớp cơ sở dữ liệu trong gói cho giao diện người dùng đồ họa. Nhưng bạn có thể tìm thấy một lớp cơ sở dữ liệu làm một cái gì đó khá khác nhau (ví dụ như báo cáo). Các lớp học và mô-đun có xu hướng phát triển gần như hữu cơ. Tổ chức mã trong nhiều lớp hơn nhưng nhỏ hơn với các trách nhiệm đơn lẻ thì tốt hơn là làm cho mã dễ hiểu hơn. Mã dễ hiểu là chìa khóa để đạt được các mục tiêu của công nghệ phần mềm, ví dụ như phần mềm chính xác, mạnh mẽ, có thể tái sử dụng và có thể mở rộng.


3

Bạn sẽ không tìm thấy bất kỳ nhà phát triển nào muốn viết nhiều mã. Ý tưởng là chỉ viết càng nhiều và viết nó theo cách có thể mở rộng.

Thật không may, các nhà phát triển phải thu thập các yêu cầu s / w từ kinh doanh / bán hàng / tiếp thị và chúng thường không bao giờ cụ thể. Vì vậy, bạn đã sử dụng các trường hợp phải được vá trong một số mã mà không bao giờ có nghĩa là để làm những gì nó đang làm ở nơi đầu tiên.

Không có cách nào để thay đổi tình huống này, trừ khi bạn có cách với tâm trí con người. Những gì có thể giúp bạn tiết kiệm là tài liệu bắt buộc, đơn vị mạnh và khung kiểm tra tích hợp, hệ thống theo dõi lỗi, danh sách gửi thư của nhà phát triển trong công ty có thể lưu trữ thư, đánh giá ngang hàng và học các kỹ thuật lập trình chung.

Ngoài ra, hãy cân nhắc sử dụng càng nhiều càng tốt từ các thành phần nguồn mở vì chúng thường có cơ sở người dùng tốt và mức độ tài liệu vừa phải. Quan trọng hơn, bạn có người đặt câu hỏi nếu lãnh đạo công nghệ của bạn đang đi nghỉ.

Sách quy mô lớn liên quan đến thiết kế phần mềm cũng là một bổ sung đáng hoan nghênh.


1

Khi giải quyết một ứng dụng brownfield, bước đầu tiên lý tưởng là viết các bài kiểm tra đơn vị cho nó.

Điều này thực hiện một số điều:

  1. Nó buộc bạn phải làm việc thông qua mã và hiểu nó
  2. Các thử nghiệm đơn vị đóng vai trò là tài liệu và mã mẫu cho chức năng hiện có và
  3. Các thử nghiệm đơn vị cung cấp một mạng lưới an toàn để tái cấu trúc.

Việc tổ chức có thiên hướng cho phép bạn làm điều này hay không là một vấn đề khác. Họ đã sống mà không có bài kiểm tra đơn vị trong thời gian dài này; khiến họ đồng ý giảm nợ kỹ thuật theo cách này sẽ khó khăn.

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.