Đây có phải là điển hình cho các công ty phần mềm lớn không tài liệu hoặc mã tái cấu trúc? [đóng cửa]


8

Tôi đã bắt đầu làm việc tại một công ty phần mềm lớn và được giao cho một dự án có hơn một triệu rưỡi mã. Đó là một phần của bộ chương trình được bán cho khách hàng (không phải là dự án nội bộ) và mã nguồn có thể được mua nếu họ muốn (mặc dù được trả thêm phí liên quan đến nó, điều này có vẻ hiếm). Họ đã làm thiết kế phần mềm trong nhiều năm và các sản phẩm hiện tại của họ dự định sẽ được tiếp tục trong tương lai gần.

Thật ngạc nhiên, hàng triệu rưỡi mã gần như hoàn toàn thiếu tài liệu. Hơn nữa, có một số lĩnh vực mã rất khó theo dõi hoặc có thể sử dụng một số phép tái cấu trúc để trở nên dễ hiểu hơn nhiều (ví dụ, một cải tiến trong ngôn ngữ lập trình đã xuất hiện cách đây 10 năm hoặc lâu hơn sẽ tạo ra nhiều phần mã lớn sạch hơn, chưa kể ít bị lỗi). Dường như không có bất kỳ nỗ lực nào để khắc phục điều này và những đề nghị của tôi để làm như vậy đối với những phần tôi đang làm việc đã gặp phải sự kháng cự, mà tôi chưa bao giờ thực sự nhận được câu trả lời rõ ràng.

Là những thực tiễn phổ biến trong một doanh nghiệp lớn trong ngành công nghiệp phần mềm? Hoặc là công ty của tôi là duy nhất trong việc thiếu tái cấu trúc và tài liệu?

Phụ lục: Dựa trên một số ý kiến, tôi muốn làm rõ những gì tôi đang tìm kiếm. Tôi hiểu rằng công ty của tôi có nợ kỹ thuật và điều này là xấu. Tôi không muốn xác định liệu công ty của mình có tệ hơn hay không vì điều này, tôi chỉ muốn biết liệu việc thiếu tài liệu này và khả năng tái cấu trúc có phải là một thực tế của cuộc sống trong thế giới lập trình mà tôi có không để giải quyết nếu tôi tiếp tục làm việc trong đó.


4
Đóng. Tôi nghĩ rằng điều này sẽ thu thập ý kiến ​​không trả lời.
Michael Durrant

1
... và ý kiến ​​của tôi, từ hàng chục công ty khác nhau là có, đó là tiêu chuẩn ngoại trừ các công ty mới thành lập với một mã mới được viết bằng các kỹ thuật hiện đại (ví dụ 5 năm qua).
Michael Durrant 27/11/13

2
Học? Nó không phải là một nghiên cứu để đi đến một số kết luận khá đúng đắn. Tất cả bạn cần làm là nhìn xung quanh bạn.
Robert Harvey

2
Ngoài ra, các kỹ thuật hiện đại bao gồm KHÔNG viết bình luận - chúng nhanh chóng bị lỗi thời và không bao giờ được duy trì tốt, và di chuyển nhiều hơn theo hướng có nghĩa là tên lớp và phương thức (nghĩ 'pool_of_cảnly_av Available_connections' so với 'pool' và cũng có các bài kiểm tra như " Là người dùng đầu vào x, tôi sẽ thấy x * 2 được hiển thị ", v.v.
Michael Durrant

3
Ime, vâng, hầu hết các công ty đều như thế này, bạn sẽ cần học cách đối phó với nó.
GrandmasterB

Câu trả lời:


13

Có một số lý do tại sao các công ty không đầu tư để làm cho chương trình của họ "tốt hơn", từ góc độ nợ kỹ thuật:

  1. Giảm nợ kỹ thuật không thêm bất kỳ tính năng mới nào vào phần mềm. Do đó, quản lý cảm nhận là không có giá trị tiền tệ (ở một mức độ nhất định chính đáng)

  2. Bản chất của kinh doanh phần mềm trao giải đầu tiên trên thị trường, không phải là tốt nhất.

Tôi có thể tiếp tục, nhưng tất cả những lý do khác chỉ là biến thể của hai điều này. Tất cả về cơ bản đều bổ sung cho tư duy ngắn hạn, tập trung vào lợi nhuận trước mắt thay vì khả năng tồn tại lâu dài.

Tất cả các công ty với các dự án phần mềm hoạt động không tầm thường đều có một số mức độ nợ kỹ thuật. Không có công ty nào hoàn toàn không có nợ.

Mọi dự án phần mềm tôi từng làm đều tích lũy Nợ kỹ thuật theo thời gian - Jeff Atwood .

Về tài liệu cụ thể, càng ít có, càng tốt. Đô la cho đô la, bạn nhận được nhiều tiền hơn bằng cách làm cho phần mềm sử dụng đơn giản hơn và dễ bảo trì hơn so với việc bạn viết thêm tài liệu cho nó.

Có một số khảo sát không chính thức về nợ kỹ thuật và cách các công ty quản lý nó; tất cả bạn phải làm là tìm kiếm chúng. Đây là một :

nhập mô tả hình ảnh ở đây

Hoặc cái này :

nhập mô tả hình ảnh ở đây

Có vẻ như khá rõ ràng rằng công ty của bạn không phải là người duy nhất có vấn đề này. Nó thậm chí có thể không thuộc thiểu số.

Đọc thêm
Hội thảo quốc tế thứ ba về quản lý nợ kỹ thuật - Tổng quan về
quản lý nợ kỹ thuật trong các hệ thống dựa trên phần mềm


Vì vậy, để trả lời câu hỏi của tôi, đây có phải là điển hình của các công ty?
Thunderforge

Bạn có ý nghĩa gì bởi "điển hình?"
Robert Harvey

Có phải hầu hết các công ty hành xử theo cách mà tôi mô tả? Tôi hiểu nợ kỹ thuật, nhưng bạn không thực sự trả lời liệu đây có phải là điều xảy ra ở hầu hết các công ty hay không nếu đây là điều mà chỉ một vài công ty (như của tôi) giải quyết.
Thunderforge

1
Chỉ cần về tất cả mọi người đăng đã làm việc tại ít hơn 10 hoặc 15 công ty trong số hàng triệu. Vì vậy, nó sẽ mất một nghiên cứu chính thức để biết. Tôi không biết Ngoài ra một mã sạch của một người là spaghetti anothers nên tôi nghĩ không thể trả lời.
Michael Durrant

1
Theo kinh nghiệm của tôi vì lợi nhuận so với phi lợi nhuận, chăm sóc sức khỏe so với tư vấn, boston-new york-san fran so với các thị trấn ở trung tâm làm nên sự khác biệt. ymmv
Michael Durrant

8

Một viễn cảnh mà tôi không tin đã được đề cập trong các câu trả lời khác (chưa) là chi phí thay đổi trong ba lĩnh vực:

  1. thử nghiệm
  2. làm quen lại
  3. chi phí cơ hội

Một công ty với một sản phẩm lớn sẽ cần phải kiểm tra tất cả các thay đổi. Các quy trình kiểm tra này cần được theo dõi qua nhiều trục: các nền tảng khác nhau, khối lượng công việc khác nhau, các quan điểm khác nhau (hiệu suất, chức năng, khả năng sử dụng, khả năng tương thích ngược).

Những người làm việc trong lĩnh vực mã mà bạn đang thay đổi cũng sẽ cần phải làm quen lại với mã đó và nó trở nên đặc biệt cồng kềnh với nhiều phiên bản được hỗ trợ ("xin lỗi, đó là phiên bản nào? Ahh, đó là phiên bản mới mã và bạn cần nói chuyện với Bob vì điều đó "). Theo cách tương tự, việc thay đổi mã chỉ để làm cho nó đẹp hơn có xu hướng làm cho những thứ như nhật ký thay đổi (diffs, patch, v.v.) trở nên rất phức tạp để đọc ... và theo dõi các vấn đề trở lại thời điểm cụ thể khi lỗi được đưa ra có thể rất khó khăn nếu có một cái gì đó trong lịch sử mã thay đổi mọi thứ. Ngoài ra, nếu một lỗi tồn tại lâu (những điều này xảy ra) thì đó có thể là nhiều phiên bản được hỗ trợ của mã của bạn và bây giờ bạn phải sửa mã cũ và mã mới, theo những cách rất khác nhau.

Cuối cùng, thường thì quyết định phải được đưa ra ở đâu để dành thời gian và tiền bạc. Đây không chỉ là thời gian của bạn, mà là những gì bạn nên làm với thời gian của mình (và tác động của nó đối với tài nguyên dòng xuống). Bạn nên dành thời gian cho nhóm phát triển của mình cho các tính năng có thể tạo ra nhiều doanh số hơn, giành thị phần mới và tạo ra lợi nhuận hay nên dành thời gian / tiền bạc cho những thứ mà người dùng cuối sẽ không chú ý, không thể đưa vào tài liệu tiếp thị ("hey, mã hiện tại của chúng tôi rất tệ, nhưng chúng tôi đã làm cho nó tốt hơn") và là chi phí thuần túy (không có lợi nhuận).

Dòng dưới cùng, tiền . Luôn luôn (tốt, hầu như luôn luôn).


5

Đúng. Dựa trên 50 công ty mà cá nhân tôi đã gặp, với tư cách là nhân viên hoặc chuyên gia tư vấn, và hơn 200 công ty mà tôi biết thông qua các đồng nghiệp.

Loại sản phẩm (1,5 triệu dòng) mà bạn mô tả phải mất nhiều năm để xây dựng và nhiều nhà phát triển ban đầu đã chuyển sang (hoặc trở thành người quản lý).

Quản lý cấp cao và các khách hàng lớn tiếp tục chỉ muốn thay đổi gia tăng nhỏ: họ muốn sự ổn định. Những gì chúng tôi những người kỹ thuật nghĩ là những cải tiến trong mắt họ có nguy cơ. Ngay cả khi chúng ta có thể hiển thị phiên bản mới vẫn hoạt động giống như phiên bản cũ, họ vẫn thấy rủi ro vì hệ thống cũ có chính xác đặc điểm mà bạn mô tả: đó là không có giấy tờ. Đối với họ, có thể có hành vi không có giấy tờ mà khách hàng dựa vào.

Từ quan điểm của họ: nó không bị hỏng, vì vậy đừng sửa nó. Bạn cũng đang thấy rằng có một văn hóa doanh nghiệp để có hiệu lực đó. Những người chống lại "cải tiến" của bạn có thể đã làm giống như bạn khi họ bắt đầu.

Đừng mong đợi "chiến thắng". Đây là một vấn đề văn hóa, và không thể thay đổi ngoại trừ thay đổi ở cấp CEO.


Quản lý cấp cao và các khách hàng lớn tiếp tục chỉ muốn thay đổi gia tăng nhỏ: họ muốn sự ổn định. - Tôi không chắc lắm về điều đó. Khách hàng cho biết về mã và mức độ thay đổi lớn hay nhỏ, nhưng họ rất quan tâm đến hai lỗi "miễn phí" kỳ diệu: miễn phí 100% và miễn phí. Ồ vâng, và xin vui lòng giao hàng ngày hôm qua. Hầu hết trong số họ chưa bao giờ nghe nói về Phạm vi so với Chi phí so với Lịch biểu hoặc họ đột nhiên quên kiến ​​thức của mình khi nói đến phần mềm. Về vấn đề văn hóakhông bị phá vỡ, tôi không sửa, tôi đồng ý, nhưng tôi cũng hiểu vấn đề kinh doanh đằng sau.
JensG

Đối với tôi, một sản phẩm có được thông qua vòng phản hồi tồn tại (hoặc không) giữa công ty và khách hàng của nó. Các khách hàng khác nhau đưa ra phản hồi mạnh mẽ hơn và có yêu cầu "sâu sắc hơn" hoặc thúc đẩy nhà cung cấp thay đổi hoặc họ chuyển sang đối thủ cạnh tranh (nếu có).
andy256

Cuối cùng, có một trường hợp để nói rằng nó vượt ra ngoài văn hóa. Giả sử quản lý đã dừng tất cả sự phát triển tính năng mới để giải quyết 10% các thói quen có lỗi hàng đầu, nó sẽ phải được quản lý rất cẩn thận để tránh trở thành lao động của Sisyphus.
James Snell

@JamesSnell: Đó là một điểm tốt mặc dù. Tôi biết các ví dụ, trong đó một đoạn mã cụ thể nên được thiết kế lại và viết lại từ đầu nhiều năm trước. Ngày nay, những người duy trì mã đó vẫn đấu tranh để sửa các lỗi cũ vẫn xuất hiện mỗi tuần, chứ đừng nói đến các lỗi đã được giới thiệu trong khi chờ đợi bằng cách thêm nhiều tính năng hơn. Làm thế nào nhiều thời gian có thể đã được lưu trong thời gian dài, nếu chỉ có họ đã quyết định vứt bỏ phiên bản cũ, thiết kế xấu, nhiều năm trước?
JensG

@JensG Tôi đồng ý với bạn. Quản lý nợ kỹ thuật là cách một nhóm / codebase được quản lý tốt nên hoạt động. Nhưng giải quyết các khoản nợ kỹ thuật có nghĩa là làm mất ổn định cơ sở mã ngay cả khi mục đích là cải thiện nó - điều đó liên quan đến rủi ro khi bạn bắt đầu tái cấu trúc rằng nó có thể trở thành một nhiệm vụ bất tận. Mã có thể cần nó, nhưng chi phí ngắn hạn có thể đủ để giết chết dự án trước khi bất kỳ lợi ích dài hạn nào đến và không người quản lý nào muốn khuấy động chiếc thuyền trong khi họ đang ở trong đó.
James Snell
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.