Làm thế nào để bạn giải thích tái cấu trúc cho một người phi kỹ thuật?


52

Làm thế nào để bạn giải thích về tái cấu trúc (và nợ kỹ thuật) cho một người không có kỹ thuật (thường là PHB hoặc khách hàng)? ("Cái gì, nó sẽ khiến tôi mất một tháng làm việc mà không có sự khác biệt rõ ràng ?!")

CẬP NHẬT Cảm ơn tất cả các câu trả lời cho đến nay, tôi nghĩ rằng danh sách này sẽ cung cấp một số tương tự hữu ích để chúng tôi có thể chỉ ra những người thích hợp (mặc dù việc chỉnh sửa các tham chiếu đến PHB có thể là khôn ngoan!)


Tôi không nhớ Apple đã thuyết phục rất nhiều người thay đổi từ Leopard thành Snow Leopard như thế nào. Có lẽ giá: $ 100 ít hơn bình thường vào thời điểm đó.
mouviciel

Câu hỏi này có thể mang lại một số câu trả lời hữu ích đáng ngạc nhiên cho bất kỳ ai làm việc với mã trong ngành. Chú ý mọi người.
joshin4colours

Tại sao nó sẽ khôn ngoan?
Louis Rhys

Câu trả lời:


53

Khi bạn có một rạp hát tại nhà lớn và bạn thêm mọi thứ, từ từ nhưng chắc chắn một con chuột lớn hình thành tổ ở phía sau.

Nếu bạn thường xuyên thay thế các bộ phận, đôi khi giá trị của nó làm thẳng ra tất cả những thứ đó.

Chắc chắn, nếu bạn làm điều đó, nó đã hoạt động trước đó và nó sẽ không hoạt động tốt hơn so với khi bạn bắt đầu, nhưng khi bạn phải làm lại với nó, mọi thứ sẽ dễ dàng hơn rất nhiều.

Trong mọi trường hợp, có lẽ tốt nhất để thực hiện một so sánh tương tự với một số lĩnh vực chủ đề, PHB hoặc khách hàng đã quen thuộc, ví dụ như xe hơi hoặc xây dựng hoặc một cái gì đó ...


1
Không phải là sự tương tự tốt nhất bởi vì nó làm cho nó nghe như những thứ tồi tệ chỉ tự nhiên bò vào nhà hát của bạn, trái ngược với những thứ xấu xuất hiện là kết quả trực tiếp của việc liên tục xây dựng nhà hát của bạn.
doppelgreener

21
@Axidos: "chuột tổ" là một thành ngữ tiếng Anh có nghĩa là "dường như không thể tháo gỡ rối" (trong trường hợp này là dây và dây cáp phía sau trung tâm giải trí)
HedgeMage

8
Về mặt khái niệm nó khá tốt - cần "dây cáp" sau "tổ chuột"
Murph

2
@Peter: Tôi nghĩ rằng tất cả chúng ta phải đi đằng sau TV ít nhất một lần. Chỉ cần giải thích nó tồi tệ hơn hàng trăm lần và quay một sợi cáp ở khắp mọi nơi và kéo cái này và kéo cái đó và khám phá một nền văn minh đã chết ở đâu đó trong mớ hỗn độn.
doppelgreener

3
Nếu ai đó không thể liên quan, hãy cho họ thấy điều này: google.com/images?q=do+not+touch+any+of+these+wires
Steve S

41

Tái bao thanh toán cũng giống như quá trình đóng gói lại vali cho đến khi mọi thứ vừa vặn gọn gàng. Đôi khi, trong quá trình này, bạn tự hỏi tại sao bạn lại cố gắng để có quá nhiều rác trong đó để bắt đầu.


1
Tôi sẽ đăng một số tương tự với một nhà để xe hoặc nhà kho, nhưng điều này là tốt hơn.
Matt Ellen

Hoặc đôi khi bạn đi mua thêm một vài chiếc vali và nhận ra rằng việc trả các khoản phí quá cân không phải là vấn đề lớn, vì chi phí phần mềm không bằng với thế giới vật lý. Sau đó, bạn có thể thực sự phù hợp với mọi thứ một cách độc đáo và sự ràng buộc của một chiếc vali duy nhất hóa ra là tùy tiện và vô lý.
Dan Rosenstark

+1 Điều này thật tuyệt. Cùng với việc khiến mọi thứ chiếm ít không gian hơn, có những thứ bạn nhận ra mình thậm chí không cần và vì vậy có thể bỏ đi.
Robbie Dee

21

Tôi sẽ không giải thích khái niệm nợ kỹ thuật, vì nó không cần thiết. Thay vào đó, hãy tập trung vào tái cấu trúc: Bạn đang thay đổi thiết kế chương trình của mình, không nhất thiết phải là "tốt hơn" hay "được cải thiện", bạn đang thay đổi nó để nó có thể chấp nhận thay đổi mà bạn cần thực hiện.

Một sự tương tự xe hơi có thể phù hợp: Bạn cần thêm một máy điều hòa không khí cho xe hơi, nhưng ban đầu nó không được thiết kế cho một chiếc. Bạn không chỉ phải làm một chiếc điều hòa không khí hình chữ L kỳ lạ, mà bạn còn cần phải di chuyển một số thứ khác ra khỏi đường trước và thay đổi hệ thống thông gió.

Tôi cũng nghĩ rằng đó là một chiến lược tốt hơn để tái cấu trúc khi bạn cung cấp các tính năng mới: nếu không, bạn có thể thay đổi thiết kế thành một thứ trông "tốt hơn", nhưng thực sự có thể không phù hợp với hoàn cảnh xung quanh việc bổ sung tính năng tiếp theo của bạn.


Di chuyển các bộ phận trong xe hơi để mang lại hiệu suất tốt hơn hoặc bảo dưỡng dễ dàng hơn - hoạt động cho bất kỳ ai nâng nắp trên xe của họ, nhưng có bao nhiêu PHB đã làm điều đó?
Peter Boughton

3
Tôi thích cái này vì nó nhấn mạnh rằng việc tái cấu trúc đang được thực hiện để thực hiện một thay đổi cần thiết dễ dàng hơn (hoặc có thể). Tái cấu trúc thường không nên được thực hiện vì mục đích riêng của nó, nhưng để đáp ứng một mục tiêu cụ thể.
Kristopher Johnson

Vì vậy, câu trả lời ngắn gọn trở thành: Đừng nói với họ! Chỉ cần yếu tố thời gian vào các tính năng mới và tái cấu trúc cho phù hợp.
Jonathan van de Veen

12

Tôi sử dụng thuật ngữ Nợ kỹ thuật và liên quan trực tiếp đến điều họ hiểu - Nợ doanh nghiệp. Nợ kỹ thuật giống như vay tiền. Bạn trả lãi cho nó. Ví dụ, bạn có thể xây dựng một nhà máy mới và trả tiền cho nó hoàn toàn hoặc bạn có thể vay tiền cho nó. Nếu bạn nhận được một khoản vay, bạn thực sự sẽ trả nhiều tiền hơn cho nó trong dài hạn, nhưng nó có ý nghĩa về mặt tài chính nếu các điều khoản là đúng .

Tuy nhiên, nếu bạn đang trả lãi 25% cho khoản vay như vậy, bạn sẽ đặt mình vào vị trí không bền vững. Điều này cũng tương tự với nợ kỹ thuật. Đôi khi nó có ý nghĩa để đảm nhận một số nợ kỹ thuật. Tuy nhiên, có một điểm mà lãi suất quá cao và nó cần phải được trả hết. Một số nợ techincal giống như một khoản vay mua nhà và một số nó giống như nợ thẻ tín dụng. Trong trường hợp khẩn cấp nợ thẻ tín dụng là một tài sản quan trọng và có giá trị. Tuy nhiên, nó cũng có thể phá vỡ ngân hàng (hoặc hộ gia đình nếu bạn chọn) nếu sử dụng không đúng cách.

Một ví dụ khác: bạn có thể trả 10.000 đô la cho việc thả thư tiếp thị để thu hút thêm khách hàng tiềm năng trong tương lai. Bạn đang trả hết "nợ bán hàng". Đây là một chi phí với tiền chi trả dài hạn. Tương đương với lý do tại sao bạn muốn "tiêu" tiền ngay bây giờ để tái cấu trúc một đoạn mã. Trong cả hai trường hợp không có khoản thanh toán ngay lập tức, nhưng bạn đang thiết lập cho mình hiệu suất tốt hơn trong tương lai.

Tôi có xu hướng sử dụng thuật ngữ "nợ xxxx" như một cách tương tự khi nói chuyện với bất kỳ ai là đối tượng mục tiêu. Ví dụ: Nợ hoạt động - Báo in chúng tôi hiện đã hoạt động tốt, nhưng bằng cách ngừng sản xuất trong một ngày (hoặc một tuần) và nâng cấp lên máy mới, chúng tôi có thể tăng sản lượng thêm 25%.

EDIT - Đây là một cái khác về điều này


1
+1 cho câu trả lời hợp lý cũng thể hiện tính kinh tế thực tế. Nợ đôi khi là hợp lý, và những người theo chủ nghĩa thuần túy bỏ lỡ quá nhiều cơ hội nếu họ không thể chịu đựng được.
Macneil

1
Và mọi người hiểu rằng việc vay các khoản vay để trả lãi cho các khoản vay cũ là không bền vững.
Christopher Mahan

1
Đây là sở thích của tôi để giải thích, vì tôi muốn đề cập đến việc loại bỏ mọi thứ và viết lại (thường là lựa chọn duy nhất còn lại do nợ quá nhiều kỹ thuật) khi phá sản kỹ thuật
Wayne Molina

4
Đây là một câu trả lời khủng khiếp. (1) Điều này phức tạp hơn giải thích kỹ thuật về tái cấu trúc. (2) Điều này không giải thích "tại sao" tái cấu trúc; nó giải thích "khi nào" tái cấu trúc (nghĩa là: khi nó có hiệu quả về chi phí). Hoặc có lẽ tôi thực sự không hiểu bài này, và do đó (1).
Thomas Eding

2
@ThomasEding (1) Đây không phải là một lời giải thích về tái cấu trúc, nó là một lời giải thích về nợ kỹ thuật. (2) Điều này giải thích lý do tại sao khi nào tái cấu trúc - cho một người kinh doanh. Thành thật mà nói, họ không quan tâm đến lý do kỹ thuật, bạn làm. Họ muốn một lý do chính đáng mà bạn đang làm việc trên một cái gì đó ngoài tính năng tiếp theo sẽ thúc đẩy doanh số. Đây là lý do tại sao hầu hết các lập trình viên không thể nói chuyện với ông chủ của họ và phàn nàn ông chủ là ngu ngốc. Họ không ngu ngốc, họ chỉ có trình điều khiển khác với bạn.
Nemi

8

Dọn dẹp mùa xuân.

Bạn không làm bất kỳ sửa đổi cho ngôi nhà. Bạn chỉ cần thay đổi công cụ xung quanh và loại bỏ một số bụi. Có thể vứt bỏ một số thứ mà bạn không sử dụng hoặc cần nữa. nhưng bạn không thêm bất cứ điều gì.


1
+1: Đây là câu trả lời hay nhất imo: và khá nhiều người có thể liên quan. "Bạn sống trong ngôi nhà của mình, mọi thứ trở nên bẩn thỉu / bụi bặm / vừa phải - định kỳ bạn cần làm sạch sâu."
Steven Evers

7

"Bạn đã bao giờ chơi Bẫy chuột chưa? Khi chúng tôi sử dụng các tính năng mới, thay đổi giao diện và sửa lỗi, mã có thể bắt đầu trông rất giống như vậy. Có một điểm chúng tôi phải bỏ ra rất nhiều vốn (thời gian và công sức , số tiền tương đương) đảm bảo tất cả các bộ phận chuyển động đều hoạt động tốt với mỗi thay đổi hoặc bổ sung mới, hoặc thay vào đó chúng ta có thể đặt thời gian sang một bên để tái cấu trúc thiết kế, dẫn đến việc chúng ta phải quản lý ít bộ phận chuyển động hơn mỗi khi chúng ta thực hiện thay đổi. có thể dường như , từ góc nhìn của một người dùng cuối, rằng cấu trúc lại không có bất kỳ lợi ích, nhưng lợi ích xảy ra mỗi khi một tính năng mới được thêm vào sau cấu trúc lại. quá trình này nhanh hơn, giới thiệu ít lỗi, và ít tốn kém sau đó, chưa kể rằng mã được cấu trúc lại thường hiệu quả hơn về tổng thể.

Bạn có thể tự hỏi tại sao chúng ta lại để nó bắt đầu giống như Bẫy chuột ở nơi đầu tiên:

  • Đôi khi hoàn thành một cái gì đó ngay bây giờ có nghĩa là chúng ta phải hy sinh sự thanh lịch và hiệu quả để chỉ "làm cho nó hoạt động".
  • Các tính năng ngôn ngữ và các công nghệ khác có sẵn cho chúng tôi khi các lập trình viên thường thay đổi. Đôi khi các tính năng mới cho phép chúng ta thay thế một mớ bòng bong gồm sáu phần chuyển động bằng một.
  • Thông thường, khi chúng tôi thêm tính năng C vào tính năng A và B, chúng tôi không biết rằng B cuối cùng sẽ bị loại bỏ và D thêm vào. Một cách để hoàn thành C có thể hoạt động rất tốt với B, nhưng không tốt lắm với D.

Trong một nỗ lực để tiếp tục xây dựng một cái bẫy chuột tốt hơn, chúng tôi phải liên tục quay lại và tìm những nơi để giảm sự phức tạp và hợp lý hóa những gì chúng tôi có. Đó là sự khác biệt giữa việc chỉ có phần mềm với nhiều tính năng và có phần mềm thực sự chất lượng cao. "


6

văn bản thay thế

Đây là một phiên bản đồ họa hơn một chút của tương tự rạp hát gia đình.

Nếu bạn muốn thêm một thiết bị mới [aka, chức năng mới], tại một nhúm có thể bạn có thể đặt nó ở một nơi nào đó.

Nếu bạn muốn thêm một thiết bị khác, bạn có thể mua một khách hàng tiềm năng mở rộng, sẽ mua cho bạn một chút thời gian.

Nhưng ở mỗi lần bổ sung, việc tìm giải pháp trở nên khó khăn hơn. Và bạn đang phải đối mặt với nguy cơ hỏa hoạn 1 [hay còn gọi là bọ], và bạn sẽ phải rút ra một số tiền lớn để trả cho ai đó để cắm ổ cắm mới vào tường, điều này hoàn toàn có thể leo lên đến tận chính bảng mạch, hoặc thậm chí xa hơn.

1 Một điều nữa PHB không hiểu rõ lắm: "Chà nếu điều đó chỉ có thể xảy ra, bạn đang lo lắng về điều gì?"


5

Tái cấu trúc - giống như tổ chức tủ quần áo / Ngăn kéo dụng cụ của bạn.

  • Bạn không vứt bỏ quần áo / dụng cụ của bạn chỉ vì chúng ở khắp mọi nơi.

  • Bạn có thể lập luận rằng họ sẽ không bao giờ bị vô tổ chức. Nhưng họ làm.

Cũng giống như mã không. Đặc biệt là khi nó phát triển theo thời gian.

Và nếu bạn không làm sạch nó, bạn sẽ tiếp tục tự hỏi điều gì đã xảy ra với chiếc áo phông mà bạn yêu thích hoặc chiếc cờ lê mà bạn luôn cần nhưng không bao giờ có thể tìm thấy!


4

Tôi sẽ nói rằng mã bảo trì mã hóa . Điều quan trọng là sử dụng những từ mà người phi kỹ thuật quen thuộc và có ý nghĩa đối với thế giới phi kỹ thuật. Nếu người không có kỹ thuật (khách hàng) quen thuộc với bảo trì ứng dụng thì có thể dễ dàng thực hiện song song việc bảo trì mã và bảo trì ứng dụng. Ngay cả khi chúng không giống nhau, bạn có thể giải thích rằng khách hàng cuối cùng ở đây là nhà phát triển hoặc những người duy trì hệ thống.


1
Những người không có kỹ thuật có quen với bảo trì ứng dụng? Tôi hỏi bà tôi: bà không phải là người không có kỹ thuật nhất mà tôi tìm thấy. Ngoài ra: Vì một người không có kỹ thuật không biết sự khác biệt giữa mã và ứng dụng ("Nếu mã là ứng dụng, ứng dụng là mã"), sự tương tự của bạn sẽ không hoạt động.
Martin

2
ở những nơi tôi đã làm việc, các loại tiếp thị và projman đã hiểu "bảo trì" có nghĩa là "sửa lỗi sau khi phát hành", và sẽ không công bằng khi cho rằng tái cấu trúc là sửa lỗi.

Đối với tôi người phi kỹ thuật là khách hàng. Nếu khách hàng biết bảo trì ứng dụng là gì thì anh ấy / cô ấy cũng nên hiểu bảo trì mã.
Amir Rezaei

"Bảo trì mã" nghe có vẻ như mã của bạn trải qua hao mòn hoặc bị sử dụng hết. Một chiếc xe cần được bảo dưỡng, bởi vì việc sử dụng bình thường làm căng thẳng các thành phần của nó, sử dụng hết chất lỏng, v.v. Một ứng dụng không giống như vậy - mã ngồi trên ổ cứng không tự "già" hay "xấu".
Dan Ray

Tôi sẽ cung cấp cho bạn một số ví dụ về bảo trì: Các vấn đề về hiệu suất. Thành phần, toàn bộ hệ thống hoặc ứng dụng của bạn được viết bằng VB và Microsoft ngừng hỗ trợ nó. HĐH không hỗ trợ công nghệ mà mã của bạn dựa trên. Vân đê bảo mật. Việc bảo trì các vấn đề này không bổ sung bất kỳ chức năng mới nào mà người dùng cuối có thể nhận thấy, tuy nhiên chúng rất quan trọng để duy trì ứng dụng.
Amir Rezaei

4

Giả sử bạn là một thợ cơ khí chuyên tùy chỉnh xe hơi, thậm chí chế tạo chúng từ đầu nếu khách hàng yêu cầu. Có khách hàng này thường xuyên quay lại cửa hàng của bạn để luôn đặt một số thứ sáng bóng mới trong chiếc limo siêu cỡ của mình.

Một khi anh ấy đến để có một hệ thống âm thanh tốt được cài đặt. Bạn siêng năng thực hiện các nhiệm vụ đi qua dây và kết nối tất cả đúng cách. Anh ấy đi ra ngoài một ngày sau đó, anh ấy hạnh phúc và trả tiền rất nhiều, như thường lệ.

Tháng sau anh ta quay lại nhưng lần này anh ta muốn lắp đặt một rạp hát tại nhà đầy đủ. Một lần nữa, bạn đi xe limo. Là một chuyên gia, bạn xem lại hệ thống âm thanh và giúp bảo trì dễ dàng hơn bằng cách lắp đặt hệ thống ống để chạy dây điện quanh xe. Bằng cách này, dây được bảo vệ và dễ dàng hơn để kéo ra và nếu bạn cần thêm nhiều hơn cũng sẽ dễ dàng thực hiện. Vì vậy, bạn xé các dây cũ ra, cài đặt ống và truyền hệ thống âm thanh và các dây bổ sung cho rạp chiếu phim, đóng tất cả lên và bạn đã hoàn thành.

Nhận ra rằng khách hàng đã không yêu cầu bạn thay thế hệ thống âm thanh cũ mà bạn bỏ ra một số chi phí thay thế và của các ống. Tuy nhiên, bạn vẫn kiếm được tiền từ thỏa thuận, Chỉ là bạn sẽ không ném hệ thống như bạn đã làm lần đầu tiên.

Một tháng sau anh ấy trở lại, lần này anh ấy muốn có một hệ thống chiếu sáng và anh ấy muốn những chiếc loa mới đã làm hỏng những cái cũ vào đầu tuần.

Vì bạn giữ mọi thứ đẹp và gọn gàng, bạn có thể nhanh chóng chạy dây ánh sáng mới qua ống của mình, cài đặt hệ thống và thay thế loa. Tuy nhiên, lần này bạn được thực hiện nhanh hơn nhiều, việc bao thanh toán lại được đền đáp bằng cách giữ bạn đứng đầu trò chơi của bạn.

Đối thủ cạnh tranh của bạn, người đã cười nhạo bạn vì đã xé dây hoàn toàn tốt và lắp đặt tất cả các ống phụ này vẫn đang cố gắng để làm cho khách hàng của mình hài lòng. Chắc chắn anh ấy đã hoàn thành nhanh hơn bạn hầu hết thời gian nhưng khi thời gian trôi qua, khách hàng của anh ấy đang phàn nàn rằng ngày càng có nhiều sự chậm trễ và chất lượng công việc chung đang xuống cấp.

Nhìn vào điều này, bạn nhận ra rằng mục tiêu của bạn không chỉ là duy trì công việc kinh doanh mà còn là khẩu súng hàng đầu là cân bằng những gì bạn làm để đáp ứng nhu cầu của khách hàng và những gì bạn làm để giúp cuộc sống của bạn dễ dàng hơn. Rất hiếm khi khách hàng trả tiền cho cả hai vì vậy bạn phải quản lý chặt chẽ. Bạn đánh cược rằng bằng cách chủ động làm mọi việc ngay cả với chi phí thực hiện hai lần, bạn sẽ giữ chi phí bảo trì ở mức phần trăm ổn định được kiểm soát trong năng suất của bạn.

Phần mềm là như nhau, ngoại trừ các lập trình viên có thể chơi với băng keo kỹ thuật số trong một thời gian RẤT lâu trước khi các hiệu ứng thực sự được cảm nhận bởi khách hàng và người quản lý. Thật không may, vào thời điểm đó, chi phí làm lại mọi thứ đúng theo cấp số nhân liên quan đến số lượng băng keo hiện tại và tuổi trung bình của băng keo nói trên.

Đây là lý do tại sao điều quan trọng là chúng tôi tiếp tục bao thanh toán lại hệ thống. Kinh nghiệm rất thường xuyên sẽ cho chúng ta thấy cách mới hiệu quả hơn để làm điều tương tự hoặc chúng ta có thể kết hợp chức năng tương tự và khai thác các dự phòng thay vì chỉ sao chép qua chúng. Đây là cách chúng tôi giữ cho hệ thống nạc và có ý nghĩa. Thời gian sẽ cho thấy rằng việc liên tục bao thanh toán lại hệ thống để đáp ứng nhu cầu sẽ giữ năng suất không đổi bằng cách kiểm soát lượng đặt trong bảo trì.

Đặt băng keo trong giây lát sẽ tăng năng suất với chi phí mang theo một hệ thống tối ưu phụ. Nợ kỹ thuật phát sinh bất cứ khi nào năng suất ngay lập tức được ưa chuộng gây bất lợi cho các khía cạnh khác của một hệ thống. Sự tương tự về nợ là tốt vì cũng giống như tiền lãi từ vốn vay ăn mòn lợi nhuận thời gian vay khiến mọi thứ nhanh chóng phải chịu sự bảo trì cao hơn và làm tăng tính mong manh của hệ thống buộc một đội phải tiêu tốn thêm nguồn lực để duy trì thay vì tạo ra. Giống như người thân tài chính của nó, nếu việc vay tiếp tục không suy giảm, hầu hết các nguồn lực được dành cho việc trả lãi để lại rất ít cho các cải tiến. Nợ kỹ thuật sẽ ăn mòn các tài nguyên kỹ thuật đến mức mà hầu hết các tài nguyên được sử dụng chỉ để giữ cho hệ thống hoạt động ổn định để ngăn chặn tất cả các cải tiến có thể khác.

Vì vậy, cuối cùng các câu hỏi không phải là chúng ta nên hay không nên làm mà là đạo đức để cho các nhà quản lý và khách hàng tin rằng họ có thể dựa vào các số liệu năng suất đầy ắp một cách giả tạo khi sử dụng băng keo kỹ thuật số. Một số người sẽ nghĩ rằng đó là một quyết định kinh doanh nhưng thật lòng mà nói điều này chỉ vì các nhà quản lý không hiểu nó. Cuối cùng, một người nào đó sẽ phải trả khoản nợ dù là tái bao thanh toán nặng hoặc bằng cách chuyển sang một hệ thống mới. Cuối cùng, đối với chúng tôi, các lập trình viên, để giữ cho các hệ thống có thể duy trì được, bạn không cần phải yêu cầu tái xác định vì đây là một phần vốn có của công việc, không hiểu điều này là không hiểu công nghệ phần mềm là gì. Điều này nói rằng, tôi nhận ra rằng có những hệ thống đã phát sinh một khoản nợ quan trọng và việc trả hết khoản nợ này sẽ đòi hỏi quyết định từ những người trả tiền. Công việc của bạn là tình huống như vậy là ít nhất là làm phần của bạn để ngừng vay. Khoản nợ này đã phát sinhBỞI CHÚNG TÔI có thể vì chúng tôi không biết rõ hơn, vì chúng tôi bị áp lực phải làm điều đó, tuy nhiên, chúng tôi đã gánh khoản nợ này và rất thường những người chúng tôi đưa nợ không hiểu nó, do đó không thể quản lý nó đúng cách.

Đây là phần mềm của bạn, tất cả đã được thực hiện, hy vọng bạn thích nó .... Nhân tiện, tôi đã sử dụng tối đa thẻ tín dụng của bạn để làm điều đó, hy vọng bạn không phiền ... cya


3

Điểm của bao thanh toán lại là đơn giản hóa thiết kế và loại bỏ sự thiếu hiệu quả. Điều này giúp dễ dàng sửa lỗi và thêm các tính năng mới trong tương lai.

Gỡ lỗi khó gấp đôi so với viết mã ở vị trí đầu tiên. Do đó, nếu bạn viết mã càng khéo léo càng tốt, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi.

Nếu bạn tiếp tục thêm các tính năng mới vào mã, bao thanh toán lại sẽ nhanh chóng tự trả tiền. Điều này sẽ được hiển thị ở tỷ lệ lỗi thấp hơn, gỡ lỗi nhanh hơn và sửa chữa nhanh hơn.


Nhưng clever == 0vì vậy 2 * clever == 0...
Thomas Eding

3

Viết phần mềm rất giống như viết một cuốn sách phi hư cấu lớn, hoặc một cuốn bách khoa toàn thư.

Bản thảo đầu tiên luôn hút. Nó luôn có thể được cải thiện bằng cách sắp xếp lại nó, loại bỏ các phần không cần phải ở đó và đảm bảo một phong cách nhất quán xuyên suốt.

Bất cứ khi nào bạn phải sửa lại, điều đơn giản nhất để làm là chỉ cần thêm một phần mới, thay đổi một vài từ, v.v. Nhưng khi các bản sửa đổi chồng chất, cuốn sách bắt đầu mất tổ chức. Vì vậy, bạn phải thực hiện thêm các lần sắp xếp lại. Nếu bạn không, cuốn sách trở thành một mớ bòng bong vô nghĩa.


3

Lấy máy tính để bàn của bạn làm ví dụ. Bạn có một tháp, màn hình, bàn phím, chuột, máy in, máy quét và loa. Cuối cùng tất cả những gì bạn muốn là một bàn làm việc có tổ chức tốt đẹp. Vì vậy, bạn chỉ cần cắm mọi thứ một cách mù quáng, và một vài phút sau, lo và kìa, mọi thứ được thiết lập theo cách bạn muốn. Chà ... gần như cách bạn muốn.

Một ngày sau khi bạn thay đổi số dư trên loa, bạn nhận ra rằng bạn đã vô tình đặt loa trái và phải của bạn vào sai khu vực, vì vậy bạn muốn trao đổi vị trí của chúng. Nhưng ôi không! Có một rừng dây rối; Khi bạn tiến hành di chuyển loa, dây chuột của bạn sẽ bị mắc kẹt và bây giờ chuột của bạn được kéo cùng với loa. Ngoài ra, bàn phím của bạn bây giờ không có bất kỳ sự chậm chạp nào - bạn đã từng có thể di chuyển bàn phím từ bàn lên đùi.

Được rồi, bạn chỉ cần rút chuột và bàn phím và lắp lại chúng để mọi thứ được cố định. Nhưng điều này sẽ không giúp tổ chức lại trong tương lai và bổ sung trong tương lai. Ngoài ra, việc dệt dây chuột và bàn phím của bạn trong rừng là một rắc rối.

Giải pháp tốt hơn là cắm lại mọi thứ để cắm lại chúng một cách gọn gàng sạch sẽ, nơi mỗi dây không can thiệp vào dây khác. Bây giờ thay đổi trong tương lai là dễ dàng và tiếp tục dễ dàng. Bạn đầu tư một chút lên phía trước để đạt được lợi nhuận lớn sau này.

Điểm mấu chốt là giải pháp ban đầu chủ yếu là LÀM VIỆC. Đó là điều về tái cấu trúc: nó bắt đầu hoạt động, nhưng bạn cần thay đổi cách mọi thứ đã tồn tại để dễ dàng thực hiện các thay đổi trong tương lai (di chuyển loa).


2

Nó giống như dọn dẹp nhà cửa sau một bữa tiệc hoang dã và điên rồ từ đêm hôm trước.

Hãy nói rằng phòng khách đã hoàn toàn bị hỏng. Nhà vẫn là nhà, phòng khách vẫn là phòng khách. Nó hoạt động nhưng nó không phải là như vậy. Sau khi nhìn chằm chằm vào mớ hỗn độn bạn nhận ra rằng nó cần được dọn dẹp.

Vì vậy, bạn bắt đầu đóng gói rác. Có vẻ tốt hơn rồi. Vì vậy, bạn nhìn quanh phòng và quyết định làm thẳng đồ đạc. Bạn đặt một mảnh trở lại, sau đó tiếp theo và tiếp theo. Wow, căn phòng trông thực sự tốt. Bạn là niềm tự hào.

Em gái của bạn bước vào và nói rằng căn phòng trông giống như thùng rác, bạn nên sửa kệ sách và tiêm thảm. Cô ấy đúng. Căn phòng trông thực sự, thực sự tốt.

Bạn nhìn xung quanh và thấy rằng các sắc thái cửa sổ sẽ đẹp hơn nhiều nếu tất cả chúng đều có cùng chiều cao. Làm xong. Wow, căn phòng thật tuyệt vời.

Đối xử với mã của bạn theo cùng một cách.


1
Tôi thích nó, nhưng tôi sẽ thay đổi nó để làm sạch nhà bếp. Không nấu ăn trong một thời gian, nhưng mọi thứ sẽ tốt hơn sau đó. PHB có thể gặp khó khăn liên quan đến việc tổ chức một bữa tiệc đúng giờ của công ty :)
Jaap

Tương tự như vậy, nhưng có một lỗ hổng mà độc giả nên biết: Nếu bạn không dọn dẹp nhà cửa, thì ngôi nhà của bạn theo nghĩa đen sẽ trở nên ít sử dụng hơn theo thời gian. Trong khi đó với một chương trình, điều này không xảy ra.
Thomas Eding

1

Dễ dàng!

Lấy nó với một ví dụ ... mọi người trong cuộc đời họ đã viết một lá thư cho một người thân yêu. Nó phải là một người thân yêu bởi vì trong những bức thư đó, chúng ta thường chú ý đến bố cục.

Vì vậy, bạn có văn bản của bạn, ... ý nghĩa sẽ đi qua một trong hai cách, nhưng bạn muốn toàn bộ điều này nghe hay! Đúng?

Tái cấu trúc, cùng một thứ ... cùng một mẩu thông tin, ít nhiều, nhưng thành phần tốt hơn. Và nó có thể sẽ dẫn đến một đánh giá tốt hơn bởi người đọc.

Một ví dụ khác - viết một bài báo cho một tạp chí. Hai nhà văn, cả hai đều biết "công cụ của họ", sự khác biệt duy nhất là một người biết "cách viết" và người khác viết như anh ta đã học cách viết từ những câu trả lời như thế này.

Bạn sẽ nhớ bài viết của ai?


1

Tất cả những điều tương tự với những thứ trong thế giới vật chất - như xây dựng một nhà hát - là, IMO, thật tồi tệ.

Bạn cần giải thích rằng mã tái cấu trúc giống như ... mã tái cấu trúc. Phần mềm có thể uốn được theo cách mà các chất tương tự vật lý không có. Khi mọi thứ ngày càng phức tạp hơn, người ta phải phản ứng (hoặc làm lại, như bạn muốn) các phần lớn hoặc nhỏ của một cơ sở mã để chúng ta có thể tiếp tục tăng độ phức tạp mà không phát điên.

Tại sao chúng ta tái cấu trúc? Bởi vì mã không bao giờ được cấu trúc lại chi phí nhiều hơn mỗi phút để duy trì và thay đổi, và cuối cùng trở nên có vấn đề hơn.

Điều thú vị về tái cấu trúc là chúng tôi làm lại codebase, nhưng, ít nhất là ngay từ đầu, chức năng vẫn giữ nguyên.


/ Tất cả các tương tự /? Tôi rất không đồng ý. Bạn chỉ cần sáng tạo hơn. Cũng không trả lời câu hỏi của OP.
Thomas Eding

@ThomasEding cảm ơn bình luận của bạn. Tôi không đồng ý ở điểm thứ hai: trên thực tế, tôi đang trả lời câu hỏi. Tuy nhiên, tôi sẽ chỉnh sửa ngay bây giờ cho bạn.
Dan Rosenstark

0

Tái bao thanh toán cũng giống như dọn dẹp một cái gì đó và cho công cụ một nơi mới để 'ở lại'

Dễ dàng đơn giản và một cái gì đó có thể mất rất nhiều lần. Đôi khi tôi còn thêm người X đó để lại một mớ hỗn độn rất lớn và tôi phải dọn dẹp nó.


0

Tôi nghĩ về một ví dụ khác, mà dường như không ai ở đây đã đề cập: tái cấu trúc khá giống với việc sắp xếp lại một phương trình trong toán học (mặc dù điều đó có thể nằm ngoài phạm vi của 'người không có kỹ thuật, tôi đoán vậy).

Khi bạn sắp xếp lại một phương trình, bạn chỉ cần 'di chuyển các thứ xung quanh' để làm cho nó dễ đọc hơn và dễ sử dụng hơn mà không thay đổi ý nghĩa .


1
Vậy nếu tôi là PHB hoặc khách hàng (người sẽ trả tiền cho nỗ lực tái cấu trúc này), tại sao tôi phải quan tâm? Mã này hoạt động (theo quan điểm của tôi)
Dan Pichelman

0

Cho chúng một phương trình toán học đơn giản. Ví dụ:

Cái nào đơn giản hơn?

y = x + x

hoặc là

y = 2x

Tái cấu trúc là một khái niệm tương tự ngoại trừ thay vì các phương trình toán học đơn giản, bạn đưa vào các thuật toán. Ý tưởng chính là bạn có thể trao đổi giữa hai cách làm vì chúng sẽ mang lại kết quả như nhau.

Việc tái cấu trúc đơn giản nhất có thể được thực hiện là đổi tên.

doX() { ... }
{
   doX()
}

Bây giờ bởi vì chúng tôi không thực sự muốn mọi thứ được gọi là doX vì chúng tôi thực sự không biết ý nghĩa của nó, chúng tôi đổi tên nó thành một thứ khác tự giải thích hơn và thay thế bất cứ nơi nào chúng tôi đã sử dụng nó.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

Điều này sẽ giúp bạn tiết kiệm tiền sau này khi có sự cố hoặc nâng cao vì nó giảm thời gian để mọi người hiểu và sửa ứng dụng của bạn. Để tiếp tục tiết kiệm tiền, có những công cụ miễn phí thực hiện công việc này cho bạn tự động tùy thuộc vào ngôn ngữ bạn đang sử dụng. Các công cụ này cũng được cấp phép sao cho không hạn chế và sẽ yêu cầu bạn làm bất cứ điều gì đặc biệt ngoài việc thừa nhận nó nếu bạn sử dụng trực tiếp.


1
Tôi thực sự thích sự tương tự này bởi vì nó dễ hiểu với mọi người và thực sự giống với mã.
Venkat D.

Cảm ơn, tôi thậm chí đã đăng nó trên blog của mình cũng như trajano.net/2013/05/refactoring-explained
Archimedes Trajano

0

Một bức tranh nói một ngàn chữ. Ví dụ, tái cấu trúc có hai trường hợp sử dụng:

  • Khi mọi thứ không được thực hiện ngay lần đầu tiên:

tái cấu trúc khi mọi thứ không được thực hiện ngay lần đầu tiên

  • Khi mọi thứ tẻ nhạt:

tái cấu trúc khi mọi thứ tẻ nhạt

Người giới thiệu


XKCD đáng để bỏ qua thời gian bỏ qua thực tế là làm cho một công việc thường xuyên hiệu quả hơn có thể có nghĩa là bạn cuối cùng sẽ làm được nhiều việc hơn bạn có thể làm. Vì vậy, bạn cần phải tính đến giá trị bạn nhận được từ các màn trình diễn thêm của nhiệm vụ.
bdsl

@bdsl Điều đó được bảo hiểm tại nơi làm
việc.se

0

Hãy xem xét một câu trả lời được đưa ra trong Tái cấu trúc và đừng giải thích nó cho một người không có kỹ thuật. Tái cấu trúc là một hoạt động kỹ thuật mà họ không cần biết về:

Tất nhiên, nhiều người nói rằng họ được thúc đẩy bởi chất lượng nhưng được thúc đẩy nhiều hơn bởi lịch trình. Trong những trường hợp này, tôi đưa ra lời khuyên gây tranh cãi hơn: Đừng nói!

Lật đổ? Tôi không nghĩ vậy. Các nhà phát triển phần mềm là các chuyên gia. Công việc của chúng tôi là xây dựng phần mềm hiệu quả nhanh nhất có thể. Một người quản lý theo lịch trình muốn tôi làm mọi thứ theo cách nhanh nhất có thể; Làm thế nào tôi làm điều đó là kinh doanh của tôi. Cách nhanh nhất là tái cấu trúc; do đó tôi tái cấu trúc.

(Tái cấu trúc, Martin Fowler, 2000, trang 61)

Tất nhiên điều này sẽ không hiệu quả nếu bạn sẽ dành một tháng không làm gì ngoài việc tái cấu trúc, nhưng tôi nghĩ dù sao đó cũng là một ý tưởng tồi, và tốt hơn hết là chỉ cần tái cấu trúc đến mức cần thiết để thực hiện công việc hiện tại hoặc tiếp theo của bạn hoặc để dọn sạch mã mà bạn vừa làm việ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.