Lời khuyên: Làm thế nào để thuyết phục nhóm trưởng mới được bổ nhiệm của tôi chống lại việc viết mã cơ sở từ đầu


8

Tôi làm việc trong một MNC khá nổi tiếng và mô-đun mà tôi làm việc đã được gán cho một "khách hàng tiềm năng" mới. Cơ sở mã là khá lớn (~ 130K trở lên, với sự phụ thuộc lẫn nhau vào các mô-đun khác), nhưng ổn định - một số phần đã trở nên xấu xí trong những năm qua, nhưng nó có thể chứng minh được ở trạng thái hoạt động. (Sản phẩm của chúng tôi đang chạy trong nhiều năm trên chúng, ngay cả những sản phẩm mới). Vấn đề là, khách hàng tiềm năng của chúng tôi muốn viết lại mã từ đầu , để bao gồm "độ chi tiết mịn hơn và thiết kế chủ động".

Tôi biết trong lòng mình rằng đó không phải là một ý kiến ​​hay, nhưng làm thế nào để tôi thuyết phục anh ấy / phần còn lại của đội (những người cao cấp hơn tôi rất nhiều về số năm kinh nghiệm), mà bản thân tôi không có vẻ gì quá đáng viết lại, như Joel et al có bài viết rõ ràng cấm nó)?

Tôi có mối quan hệ làm việc tốt với người có liên quan và không muốn hủy hoại nó, nhưng tôi cũng không muốn tham gia một quyết định chắc chắn sẽ làm chúng tôi thất vọng trong nhiều năm tới !! Bất kỳ đề xuất cho một cách tiếp cận nhẹ nhàng hơn, nhưng hiệu quả? Ngay cả những tài khoản về cách bạn đã giải quyết một tình huống như vậy theo ý thích của bạn cũng sẽ giúp tôi rất nhiều!

EDIT: Cơ sở mã mà tôi đang nói đến không phải là một sản phẩm / GUI, mà ở cấp độ kernel với tất cả các chức năng quan trọng cho sản phẩm của chúng tôi. Tôi hy vọng bây giờ bạn biết tại sao tôi nghe rất e ngại !!


chỉ để đảm bảo, trước khi cho bạn lời khuyên kiểu này ... Bạn có đang thực hiện nhiều công việc tiến hóa / bảo trì cho đoạn mã này (và cuối cùng đã dành rất nhiều thời gian để sửa lỗi hồi quy)? Bạn có cần thêm chức năng mới nhưng bạn không thể vì bạn sẽ cần phải chạm vào các phần "xấu xí" trong mã của bạn? Tôi nghĩ rằng viết lại không phải là một ý tưởng tồi ...

@paolo - Không, codebase đang hoạt động tốt (tôi ước tôi có thể đặt tên cho sản phẩm của chúng tôi, có lẽ bạn đang sử dụng nó :)). Có một số lỗi đối với một số khách hàng, nhưng không có sự hack lớn nào trong mã (ngoại trừ khi chúng tôi phải che đậy cho các lỗ hổng CTNH !!)
TCSGrad 15/03/2016

1
Có rất nhiều ưu và nhược điểm trên c2.com/cgi/wiki?RewriteCodeFromScratch
k3b

130k mã hạt nhân như vậy, với các trình điều khiển là độ chi tiết tốt và thiết kế chủ động. Là nó đủ thách thức hoặc gần như không thể thực hiện / giao diện các thiết bị hoặc giao thức mới? Liệu kết quả của những thay đổi dự định có làm cho khách hàng / người dùng hạ lưu dễ dàng hơn không?
JustinC

Khách hàng sẽ không cảm thấy gì - giao diện khá đơn giản và đủ mạnh. Như tôi đã xác định, ý định là gì để giảm "sự phức tạp của việc đọc mã". IMHO, đó là một cái nhìn khá chủ quan ... nếu bạn viết lại toàn bộ mã từ đầu, tất nhiên bạn sẽ dễ đọc hơn - nhưng những kỹ sư mới, những người phải đọc qua cả hai thì sao !!
TCSGrad

Câu trả lời:


8

Làm toán cùng anh ấy:

Về phía nợ:

  • Sẽ mất bao lâu để tạo lại các tính năng bạn có ngay bây giờ. Cái đó giá bao nhiêu (devs + phí)

  • Công ty sẽ mất bao nhiêu vì không thể triển khai bất kỳ tính năng / lỗi mới nào hoặc chỉ với tốc độ chậm hơn nhiều?

  • Rủi ro của việc không thể hoàn thành việc viết lại và quay trở lại cơ sở nguồn hiện tại sau n tháng là gì? Bao gồm cả nguy cơ giết chết tất cả các sản phẩm cùng nhau.

  • Sẽ mất bao lâu cho đến khi cơ sở mã mới trông xấu xí như hiện tại?

Về mặt tài sản:

  • Mã sẽ tốt hơn bao nhiêu sau khi viết lại (tính bằng chi phí bảo trì đã lưu mỗi tháng)

Thêm tất cả, có thể làm một so sánh trường hợp tốt nhất / tồi tệ nhất.

Cuối cùng, bạn sẽ có câu trả lời. Nếu anh ta bỏ qua câu trả lời, hãy nói chuyện với ông chủ của mình.


Sự liệt kê tuyệt vời !! Tôi sẽ thêm chúng vào ghi chú cuộc họp của tôi !!
TCSGrad

3
Bạn sẽ nghĩ rằng đây là cách để đi nhưng thật điên rồ khi bạn ước tính quá mức thời gian cần thiết để đưa vào các tính năng mới trong cơ sở mã cũ đồng thời đánh giá thấp thời gian cần thiết để có được "mới" "Mã dựa trên danh sách tính năng cũ.
Wheaties

Điểm tuyệt vời Sẽ thực sự tốt khi có được những ước tính này từ tất cả các nhà phát triển có liên quan Vì vậy, mọi người đều có được một bức tranh rõ ràng.
Aditya P

@wheaties Điều đó tất nhiên là một vấn đề với mọi ước tính. Cách để chiến đấu là lặp lại ước tính thường xuyên và so sánh nó với tiến độ thực tế. (Nghĩ về sản phẩm Burn Down)
Jens Schauder

khá thường xuyên 'tài sản' của mã mới không tốt hơn những gì nó đã thay thế - đặc biệt là sau một vài lần lặp lại tăng cường và bảo trì. IMHO tổng số viết lại không bao giờ là ý tưởng tốt nhất.
gbjbaanb

13

Bắt buộc: Những điều bạn không bao giờ nên làm, Phần 1 (Bạn đã xem rồi, nhưng trong trường hợp có ai tìm thấy câu hỏi này và không.)

Viết lại từ đầu rất hấp dẫn cho các nhà phát triển. Không ai muốn làm việc với mã kế thừa, mọi người đều muốn viết mã mới gợi cảm. Nhưng vào cuối ngày, đó là về những gì tốt nhất cho doanh nghiệp. Tại sao cần phải viết lại? Họ có thể trình bày trường hợp đó một cách rõ ràng chứng minh giá trị gia tăng cho doanh nghiệp không?

Bạn không cần phải thuyết phục họ không tiêu tốn tài nguyên. Họ cần phải thuyết phục các công ty để dành tài nguyên.


Tôi thích bài viết đó. Tôi ghét viết lại mọi thứ!
Đánh dấu Canlas

3
@Mark Canlas: Thật sự rất buồn cười, vì tôi thường là người đề xuất viết lại. Tôi ghét mã kế thừa :) Nhưng tôi cũng hiểu rằng nếu tôi không thể chứng minh giá trị gia tăng cho doanh nghiệp thì việc viết lại không nên xảy ra. Ý kiến ​​của tôi cần được hỗ trợ bởi những con số.
David

2
Tôi cũng ghét mã kế thừa, nhưng từ khi đọc bài viết đó, tôi đã học được cách coi trọng việc chạy tàu so với lý thuyết. Một con tàu bị hỏng, đang chạy đang tạo ra nhiều tiền hơn mỗi giờ so với một con tàu giả định được vẽ bằng khăn ăn. Đó là một hành động cân bằng!
Đánh dấu Canlas

1
@Mark Canlas: Hoàn toàn đúng. Và đó là nơi mà rất nhiều nhà phát triển (thậm chí là những người rất có kinh nghiệm trong nhiều trường hợp) mất khả năng nắm bắt toàn bộ hoạt động kinh doanh. Nó phải có giá trị hữu hình thực tế cho doanh nghiệp và rất thường xuyên sản phẩm hiện có có giá trị đó. Mặc dù một lý lẽ tôi luôn ghét từ doanh nghiệp là "chúng tôi đã chi tiền cho việc này, vì vậy chúng tôi cần sử dụng điều này". Đôi khi, như trong trường hợp công việc cuối cùng của tôi, một quyết định như thế đẩy họ xuống đất. Đó không phải là "luôn luôn viết lại" hay "không bao giờ viết lại." Như bạn đã nói ... cân bằng.
David

8

Cách tiếp cận thử nghiệm của bạn bao gồm cơ sở mã? Làm thế nào về kiểm tra đơn vị?

Nếu nó không phải là alreayd ở đó, đề nghị rằng bất kỳ mã nào chỉ được viết lại một phần tại một thời điểm và bất kỳ phần nào được viết lại có độ bao phủ mã đơn vị thử nghiệm gần như hoàn thành (90% +). Khi bạn làm điều này, bạn sẽ xác định một phần của mã mà cả hai đều được xác định rõ (chúng tôi có thể kiểm tra nó) và cũng có một giao diện đã biết.

Tại thời điểm đó, viết lại mã đó có rủi ro thấp hơn nhiều. Những sai lầm cần được bắt gặp bằng các bài kiểm tra đơn vị / các bài kiểm tra khác và giả sử bạn cũng có thể dễ dàng kiểm soát nguồn.

Việc viết lại trong các phần nhỏ hơn cũng cho phép cả bạn và nhóm của bạn dẫn đến cảm giác chính xác hơn để viết lại hoàn toàn. Cả hai bạn có biết những gì bạn đang nhận được vào? Là một trong số bạn quá bi quan / tối ưu?


130k mã hạt nhân như vậy, với các trình điều khiển là độ chi tiết tốt và thiết kế chủ động. Là nó đủ thách thức hoặc gần như không thể thực hiện / giao diện các thiết bị hoặc giao thức mới?
JustinC

2

Có một số yếu tố liên quan để xem xét:

  • Thực tế là nó hoạt động theo cách người dùng muốn là một dấu hiệu để cấu trúc lại chứ không phải viết lại
  • Nếu bạn có bài kiểm tra đơn vị, chắc chắn tái cấu trúc thay vì viết lại. Nếu bạn không làm như vậy, thì mức độ nỗ lực giữa tái cấu trúc và viết lại (giả sử mục tiêu của bạn là kiểm tra đơn vị cho hệ thống kết quả). Nếu bạn không có bài kiểm tra đơn vị và tất cả mã nằm trong lớp GUI, việc viết lại có thể nhanh hơn, đặc biệt là nếu chức năng hầu như bị hỏng. Đó là kinh nghiệm của tôi.
  • Nếu mục tiêu của bạn là thay đổi hoàn toàn các nền tảng (mã không được quản lý -> .NET hoặc Windows -> Linux hoặc PHP -> python, v.v.) thì đó là một đối số rõ ràng hỗ trợ cho việc viết lại.

Không, chúng tôi không có bất hạnh.
TCSGrad

Người mới cũng không thể có nó, nhìn thấy khối lượng công việc mà nó đã tham gia. Ngoài ra, cơ sở mã mà tôi đang nói đến không phải là một sản phẩm / GUI, mà ở cấp độ kernel với chức năng quan trọng cho sản phẩm của chúng tôi. Tôi hy vọng bây giờ bạn biết tại sao tôi nghe rất e ngại !!
TCSGrad

1
@ shan23 - tại sao bạn sẽ bắt đầu viết lại và không ít nhất là duy trì một bộ kiểm tra chấp nhận? Bạn sẽ chỉ tạo ra cùng một mớ hỗn độn. Thực tế là nó không có GUI chỉ giúp kiểm tra dễ dàng hơn nhiều!
Scott Whitlock

0

Chỉ cần nói không." Hãy thuyết phục, nhưng sẵn sàng nói "Bạn không chỉ không đúng về lợi ích của nó, mà bạn còn sai vì nó lãng phí công sức của con người".


0

Trường hợp kinh doanh cho một viết lại? Bạn có một cơ sở mã đang đáp ứng nhu cầu. Cấp, nó có thể không hoàn hảo, nhưng nó thể hiện một sự đầu tư đáng kể về thời gian và nguồn lực. Lần duy nhất mà việc viết lại hoàn toàn được bảo hành là khi chất lượng mã kém đến mức nó khiến tổ chức của một người mất tiền hoặc cơ hội kinh doanh. Người ta cần nhớ câu ngạn ngữ cũ, nếu nó không bị hỏng, đừng sửa nó!


Tôi phải đưa ra ý kiến ​​này vì câu nói đó là điều tồi tệ nhất trong ngành của chúng tôi; nó thúc đẩy sự lười biếng, bất tài và hành vi lười biếng trong các nhà phát triển vì không ai có bóng để giải quyết vấn đề một cách đúng đắn vì "nó hoạt động" trong một số khả năng nhỏ.
Wayne Molina

@WayneM: tùy chọn "viết lại" là tùy chọn tồi tệ nhất, thường là do bản ngã và sự bất tài giữa các nhà phát triển không thể làm việc với mã hiện có. Họ muốn torewrite là những thứ mới mẻ, và cuối cùng đã phạm phải những sai lầm tồi tệ hơn trong thái độ sai lầm của họ rằng họ đã làm tốt hơn rất nhiều so với những người đã làm những thứ cuối cùng. Chỉ khi mã cũ đã phát triển trong nhiều thời gian (hoặc là tào lao để bắt đầu), bạn mới nên viết lại, và thậm chí sau đó nên xem xét lại một cấu trúc nghiêm túc.
gbjbaanb

0

Mua càng nhiều quần short trên cổ phiếu càng tốt. Nếu quản lý đồng ý tự tử, ít nhất bạn nên kiếm một số tiền từ nó. Rốt cuộc, bạn sẽ sớm có mặt trên đường phố sau khi họ tank.

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.