Làm thế nào để tôi xử lý tái cấu trúc mất nhiều thời gian hơn một lần chạy nước rút?


49

Tôi làm việc với một cơ sở mã có hơn 500K dòng mã. Đó là cần nghiêm túc của tái cấu trúc. Đã có những nỗ lực tái cấu trúc được xác định sẽ mất nhiều thời gian hơn so với nước rút hai tuần bình thường. Chúng không thể được chia thành các nhiệm vụ nhỏ hơn như tôi đã thấy đề xuất trong các câu trả lời khác trên trang web này. Sản phẩm cần phải hoạt động vào cuối vòng lặp và tái cấu trúc một phần sẽ khiến hệ thống ở trạng thái không sử dụng được vì sự phụ thuộc giữa các mục là khủng khiếp. Vì vậy, cách tốt nhất để tiếp cận rào cản này là gì? Một lần nữa tôi đề cập, chia nó thành các phần nhỏ hơn không phải là một lựa chọn, điều đó đã được thực hiện.

Cập nhật: Mọi người dường như cần một lời giải thích về lý do tại sao điều này không thể phù hợp với nước rút 2 tuần. Có nhiều thứ liên quan đến nước rút hơn là chỉ viết mã. Chúng tôi có một chính sách không có mã mà không có bài kiểm tra. Chính sách đó không phải lúc nào cũng tồn tại và một phần lớn cơ sở mã không có chúng. Ngoài ra một số bài kiểm tra tích hợp của chúng tôi vẫn là bài kiểm tra thủ công. Vấn đề không phải là bản thân cấu trúc lại quá lớn. Thực tế là những thay đổi nhỏ có ảnh hưởng đến nhiều bộ phận của hệ thống và chúng tôi cần đảm bảo rằng những bộ phận đó vẫn hoạt động chính xác.

Chúng tôi không thể tắt hoặc mở rộng nước rút vì chúng tôi có các hotfix hàng tháng. Vì vậy, thay đổi này kéo dài qua một lần chạy nước rút không thể ngăn công việc khác được thêm vào hotfix.

Tái cấu trúc so với thiết kế lại: Chỉ vì quá trình phát triển của chúng tôi không đủ hiệu quả để xử lý việc tái cấu trúc này trong chu kỳ hai tuần không đảm bảo đổi tên nó thành thiết kế lại. Tôi muốn tin rằng trong tương lai chúng ta có thể hoàn thành chính xác nhiệm vụ tương tự trong vòng hai tuần khi quá trình của chúng ta được cải thiện. Mã được đề cập ở đây đã không phải thay đổi trong một thời gian rất dài và khá ổn định. Bây giờ, khi định hướng của công ty đang trở nên dễ thích nghi hơn để thay đổi, chúng tôi muốn phần cơ sở mã này có thể thích ứng như phần còn lại. Mà đòi hỏi phải tái cấu trúc nó. Dựa trên các câu trả lời ở đây, rõ ràng là thiếu giàn giáo cần thiết để làm cho việc tái cấu trúc này hoạt động trong khung thời gian của các lần chạy nước rút thông thường.

Câu trả lời:

Tôi sẽ thực hiện phương pháp tiếp cận chi nhánh và hợp nhất mà Corbin March đã đề xuất lần đầu tiên để chúng tôi có thể tìm hiểu thêm về các lĩnh vực vấn đề này và cách xác định các bài kiểm tra còn thiếu. Tôi nghĩ rằng tiến về phía trước, chúng ta nên thực hiện phương pháp mà Buhb đề xuất để xác định các khu vực đang thiếu các bài kiểm tra và thực hiện những khu vực đó trước, sau đó thực hiện tái cấu trúc. Nó sẽ cho phép chúng tôi giữ cho chu kỳ chạy nước rút hai tuần bình thường của chúng tôi, giống như nhiều người ở đây đã nói nên luôn luôn là trường hợp để tái cấu trúc.


23
Như một lưu ý phụ, đây là theo định nghĩa thiết kế lại quy mô lớn, không tái cấu trúc . Hy vọng bạn không coi điều này là nitpicking - IMHO điều quan trọng là sử dụng thuật ngữ rõ ràng để tránh các vấn đề giao tiếp :-)
Péter Török

9
@Charles, "Tái cấu trúc thường được thực hiện theo các bước nhỏ. Sau mỗi bước nhỏ, bạn sẽ có một hệ thống làm việc không thay đổi về chức năng. " Trích dẫn từ trang tôi liên kết ở trên.
Péter Török

2
@Charles: tái cấu trúc luôn có thể được thực hiện tăng dần, trong khi vẫn giữ cho hệ thống hoạt động. đặt một nhận xét "Tái cấu trúc đang tiến hành" lớn ở đầu lớp / gói / mô-đun đang được tái cấu trúc và thực hiện từng phần một. Nếu bạn cắt một bản phát hành tạm thời trong khi mô hình đối tượng đang trong quá trình chuyển đổi, thì đó là Được.
Sean McMillan

7
Nếu bạn đang thực hiện các bước lớn như vậy mà bạn không thể có một đoạn mã hoạt động thường xuyên, thì đó chính là định nghĩa khi tái cấu trúc trở thành thiết kế lại. Xin đừng tức giận với mọi người vì đã gọi bạn bằng cách sử dụng sai từ này. Không có gì sai khi hỏi về thiết kế lại. Những người bình luận chỉ đang cố gắng chỉ ra rằng bạn sẽ không nhận được câu trả lời mình muốn vì bạn đang lạm dụng từ này, đó là những gì đã xảy ra.
jprete

5
Tôi biết đó là một chủ đề hơi lạc hậu, nhưng bạn đã khiến tôi chết tò mò về những tình huống khiến cho việc tái cấu trúc trong các bước nhỏ là không thể. Xin chia sẻ thêm một số nền tảng liên quan đến điều này.
Buhb

Câu trả lời:


14

Nếu bạn có thể trì hoãn việc tái cấu trúc, tôi khuyên bạn nên tập trung vào các lần lặp lại để thêm kiểm tra đơn vị và kiểm tra tích hợp tự động đến điểm mà bạn có thể thoải mái cấu trúc lại cơ sở mã, sau đó tái cấu trúc trong một lần chạy nước rút.


68

Đề xuất của tôi:

  1. Tạo một nhánh
  2. Hợp nhất hàng ngày từ thân cây đến chi nhánh của bạn và giải quyết xung đột.
  3. Làm việc cho đến khi hoàn thành. Chi nhánh của bạn có thể nằm ngoài sự phát triển cốt lõi trong một vài lần chạy nước rút.
  4. Hợp nhất trở lại thân cây.

Không có xung quanh thực tế là nó có thể sẽ trở nên xấu xí. Tôi không ghen tị với bạn. Theo kinh nghiệm của tôi, khi bạn thay đổi mạnh mẽ một dự án, việc hợp nhất sự phát triển đang diễn ra vào mô hình mới sẽ dễ dàng hơn so với việc bằng cách nào đó hợp nhất mô hình mới vào một thân cây đã thay đổi sau khi mọi thứ kết thúc. Tuy nhiên, nó sẽ bị tổn thương.


1
Chúng tôi đã thảo luận bằng cách sử dụng phương pháp này và nếu không có ý tưởng nào khác xuất hiện trước khi chúng tôi giải quyết nó, đây là những gì chúng tôi dự định thực hiện.
Charles Lambert

3
Tôi e rằng bạn sẽ có rất nhiều chi phí hợp nhất qua lại giữa thân cây và nhánh nếu bạn muốn thực hiện tái cấu trúc kỹ lưỡng như vậy.
Giorgio

Trong hầu hết các trường hợp (hy vọng) những thay đổi được hợp nhất đó sẽ không ảnh hưởng đến mã được đề cập ở đây. Tôi sẽ không kéo dài dòng thời gian cho sự thay đổi này nếu nó đảm bảo một kết quả đáng tin cậy.
Charles Lambert

1
Xem xét sự biến động mà bài thuyết trình của bạn dường như gợi ý, có lẽ bạn nên xem xét Git , vì nó tạo điều kiện cho loại phân nhánh và sáp nhập đầu cơ này.
John Tobler

1
@Giorgio: tôi cũng vậy, việc hợp nhất hàng ngày có vẻ hơi hoang tưởng, nhưng sau đó nó thực sự phụ thuộc vào quy mô đội. Càng nhiều người, càng nhiều thay đổi và bạn nên hợp nhất thường xuyên hơn. Hàng ngày dường như giới hạn dưới cùng, nếu bạn muốn có thời gian để làm việc.
Matthieu M.

40

Không phải mọi nhiệm vụ đều có thể được thực hiện trong giai đoạn nước rút 2 tuần (nhân tạo), vì vậy lẽ thường được yêu cầu. Nếu nó không thể bị phá vỡ thêm nữa, và nó phải được thực hiện, chỉ cần tiếp tục và làm điều đó. Quá trình không quan trọng hơn kết quả cuối cùng, và nên được xem như một hướng dẫn chứ không phải là một luật không bao giờ bị phá vỡ.


3
Câu trả lời của bạn là thông tin rất tốt về chủ đề này. Tôi ở đây để "bắt tay vào làm" như bạn nói. Tôi đã đặt câu hỏi với hy vọng có được một số thông tin để tôi có thể đưa ra một quy trình để chạy song song với quy trình hiện tại của mình hoặc bằng cách nào đó sửa đổi quy trình hiện tại để giải quyết tình huống hiện tại của tôi. Tôi cần một cái gì đó để nói với các nhà phát triển để họ có hướng dẫn để làm việc, vì điều này sẽ xảy ra ít nhất 2 lần nữa.
Charles Lambert

+1 cho "Quá trình không quan trọng hơn kết quả cuối cùng và nên được xem như một hướng dẫn chứ không phải là một luật không bao giờ bị phá vỡ." - Mọi người dường như thực sự quên điều này.
Bjarke Freund-Hansen

32

Chỉ cần chạy nước rút 3, 4 hoặc 5 tuần. Ai quan tâm? Rõ ràng bạn đã bị thuyết phục rằng không có gì có thể được thực hiện trong một khung thời gian ngắn hơn, vì vậy hãy ngừng chiến đấu với nó.

Chỉ cần đừng nói với các đồng nghiệp của bạn tại Hiệp hội tuân thủ mù nhanh của Hoàng gia.


dường như vì lý do tổ chức (hotfix hàng tháng), nước rút 2 tuần khá khó thay đổi.
Steve Bennett

10

Tôi khuyên bạn nên bắt đầu với cuốn sách Làm việc hiệu quả với Bộ luật kế thừa , của Michael Feathers. Ông bao gồm nhiều kỹ thuật khác nhau để giảm phạm vi thay đổi kiểu tái cấu trúc.


Một cuốn sách tốt chắc chắn, nhưng tôi không nghĩ rằng nó bao gồm việc phân tách tái cấu trúc qua nhiều lần chạy nước rút.
Adam Lear

4
Tôi sẽ cho điểm này +1 vì đây có lẽ là cuốn sách tốt nhất để bắt đầu khi bạn bắt đầu học, như tiêu đề nói, hoạt động hiệu quả với mã kế thừa. Nó có liên quan đến một người có thể hỏi câu hỏi này và không hiểu những gì liên quan đến việc phá vỡ mọi thứ thành các bước nhỏ hơn.
Charles Lambert

@Anna - sau đó bạn có thể muốn (đọc lại) chương 25, nói về các kỹ thuật để phá vỡ các loại khớp nối ngăn chặn những thay đổi nhỏ.
kdgregory

@kdgregory Hội chợ đủ. :) Tâm trí thêm vào câu trả lời của bạn để làm cho nó tuyệt vời hơn?
Adam Lear

7

Trong cửa hàng của chúng tôi, khi chúng tôi có các tác vụ tái cấu trúc hoặc viết lại lớn không thể hoàn thành trong cửa sổ phát hành, chúng tôi sẽ để lại chức năng như trong hệ thống. Nhưng, chúng tôi bắt đầu với các chức năng khối lego mới, được tái cấu trúc khi thời gian cho phép. Cuối cùng, chúng ta đến một trạng thái nơi chúng ta đã thực hiện đủ các khối lego, rằng một lần chạy nước rút cung cấp đủ thời gian để cắm các khối lego vào ứng dụng và bật nó cho người dùng.

Chính xác hơn, chúng tôi chia tay hoặc làm lại các chức năng lớn bằng cách sử dụng tên mới. Sau đó, cuối cùng, chúng tôi sử dụng công việc được đổi tên, tái cấu trúc của chúng tôi thay vì mã cũ khó chịu.


Đây là một ý tưởng tốt, nhưng nó sẽ đòi hỏi một mức độ giao tiếp cao để ban hành. Ví dụ: khi tôi đang mã hóa, nếu tôi xác định một phương thức không được sử dụng ở bất cứ đâu và nó không công khai, tôi sẽ xóa nó.
Charles Lambert

5

Dành một lần chạy nước rút để tìm ra cách giữ cho mã hoạt động đúng giữa bộ tái cấu trúc. Điều này có thể ở dạng các phương thức và các lớp không dùng nữa, các hàm bao, bộ điều hợp và các thứ tương tự. Tái cấu trúc của bạn có thể làm cho mã bẩn hơn trong một thời gian ngắn để được sạch hơn về lâu dài; vậy là được rồi. Ngay bây giờ bạn đang nói rằng nó không thể được thực hiện. Tôi không nghĩ điều đó đúng - hãy nghĩ về quá trình của bạn sẽ như thế nào nếu nó có thể được thực hiện, hãy nghĩ về những bước bạn có thể thực hiện để làm cho nó trở nên như vậy. Sau đó lặn xuống.


Chúng tôi đã thực hiện tất cả điều này. Đó là lý do tôi bày tỏ rõ ràng rằng nó không thể bị phá vỡ.
Charles Lambert

Có thật không? Bạn đã dành toàn bộ nước rút chỉ đơn giản là lập kế hoạch làm thế nào để cấu trúc lại mà không phá vỡ hệ thống của bạn, và không có gì? Tôi thấy khó có thể tin rằng một cuộc chạy nước rút kế hoạch chuyên dụng đã không có gì; có lẽ bạn cần phải mang đến một nhà tư vấn (và không, tôi không phải là một, không cố gắng để có được một buổi biểu diễn).
Carl Manaster

1
Tôi không nói gì về loại này. Tôi đã nói rằng chúng tôi đã trải qua một quá trình tương tự như những gì bạn đã mô tả và xuất hiện ở đầu bên kia với một số mã không thể được tái cấu trúc trong một lần chạy nước rút.
Charles Lambert

Tôi nói: "Dành một lần chạy nước rút để tìm ra cách giữ cho mã hoạt động chính xác giữa bộ tái cấu trúc." Bạn nói, "Chúng tôi đã thực hiện tất cả những điều này." Bây giờ bạn có nói khác không? Tôi xin lỗi nếu điều này nghe có vẻ gây tranh cãi, nhưng tôi không hiểu.
Carl Manaster

5

+1 trên câu trả lời của Corbin March, đó chính xác là những gì tôi đã nghĩ. Có vẻ như cơ sở mã của bạn là một chút xấu xí và nó sẽ mất nhiều hơn một chu kỳ nước rút duy nhất để làm sạch nó.
Cũng giống như Corbin đã nói,

  1. phân nhánh nó thành một "dự án tái cấu trúc"
  2. kiểm tra sự thay đổi chi nhánh của bạn
  3. quảng bá đến môi trường kiểm tra của bạn để kiểm tra QA
  4. tăng dần hợp nhất nó trở lại vào thân cây cho đến khi tái cấu trúc được thực hiện.

Tôi chắc chắn rằng bạn sẽ không gặp vấn đề gì khi bán nó cho người quản lý nhà phát triển của mình, nếu Thủ tướng của bạn gặp khó khăn khi thấy điều đó thì hãy giải thích với họ rằng Rome không được xây dựng trong một ngày và dọn sạch rác thải được ném vào Rome đường phố sẽ không được thực hiện trong một ngày. Việc tái cấu trúc sẽ mất một thời gian nhưng cuối cùng sẽ có giá trị về mặt bảo trì dễ dàng hơn, phát hành nâng cao nhanh hơn, vé sản xuất ít hơn và SLA hoàn thiện hơn.


1
Tôi có tất cả đạn tôi cần để nói chuyện với mọi người về nó. Tôi chỉ cần một kế hoạch chính thức để thực hiện nó, khi tôi trình bày nó. Từ các câu trả lời ở đây, tôi không có nghi ngờ rằng tôi sẽ đưa ra một giải pháp lặp lại.
Charles Lambert

4

Mặc dù thiết kế lại mà bạn thực sự muốn làm là một nhiệm vụ lớn, nhưng liệu có thể cấu trúc lại các phần nhỏ hơn để phá vỡ / tách rời các phụ thuộc riêng lẻ? Bạn biết đấy - khi nghi ngờ, hãy thêm sự quyết đoán. Mỗi phân tách này phải là một nhiệm vụ nhỏ hơn so với voi ma mút mà bạn không thể hoàn thành.

Khi các phụ thuộc được loại bỏ, bạn sẽ có thể chia nhỏ các nhiệm vụ tái cấu trúc còn lại để có thể đạt được trong các lần chạy nước rút.


3

Trong dự án tôi đang làm việc tại thời điểm này, chúng tôi đang sử dụng nước rút 4 tuần. Và đôi khi chúng tôi không thể hoàn thành một câu chuyện của người dùng và chúng tôi chỉ khởi động lại nó trong giai đoạn nước rút sau.

Tuy nhiên, IMHO có thể chia nhỏ một cấu trúc lại thành những câu chuyện nhỏ hơn phù hợp với giai đoạn nước rút 4 tuần. Nếu bạn không thể đưa mã vào trạng thái nhất quán trong vòng 4 tuần, tôi có cảm giác rằng bạn đang viết lại ứng dụng của mình thay vì cấu trúc lại nó.


chạy nước rút 4 tuần nên bao gồm nó. Tuy nhiên, chúng tôi không thể dừng chạy nước rút 2 tuần hiện tại do các sửa lỗi khác, v.v. Vì vậy, điều này sẽ phải kéo dài qua hơn một lần chạy nước rút. Do đó, mấu chốt của vấn đề của tôi.
Charles Lambert

Như tôi đã nói, chúng tôi đang sử dụng 4 tuần nước rút và, nếu một câu chuyện chưa kết thúc sau 4 tuần, chúng tôi chỉ lên lịch cho lần chạy nước rút tiếp theo. Ít nhất bạn có thể có hệ thống ở trạng thái nhất quán vào cuối giai đoạn nước rút 2 tuần (và sau đó tiếp tục trong giai đoạn nước rút sau)?
Giorgio

Không phải là một trạng thái nhất quán có thể kiểm chứng .
Charles Lambert

Tôi phải thêm làn sóng của mình vào nỗ lực mà người khác đã làm để hy vọng rằng bạn sẽ tìm thấy một từ khác để sử dụng thay vì "tái cấu trúc". Tái cấu trúc được xác định rõ và phạm vi của nó là ngay lập tức và ngắn hạn hơn nhiều so với việc tái thiết kế và lập trình lại khổng lồ và tốn thời gian mà bạn cần phải làm.
John Tobler

2

Tôi khuyên rằng khi một số nhiệm vụ nhất định sẽ mất nhiều thời gian hơn chu kỳ chạy nước rút 2 tuần, thì nhiệm vụ sẽ được thực hiện trong một thời gian khác. Nhóm của bạn đã xác định nhu cầu tái cấu trúc và đó là điều quan trọng. Đôi khi, không có lựa chọn nào khác ... và, vâng, điều đó thật tệ.

Khi đến lúc bắt đầu tái cấu trúc, bạn sẽ đơn giản tạm dừng các lần chạy nước rút thông thường. Bạn không có lựa chọn nào khác. Sử dụng kiểm soát phiên bản thông minh - chi nhánh, tái cấu trúc, kiểm tra, hợp nhất. Luôn luôn có một thời điểm mà việc tái cấu trúc một số dự án lớn được ưu tiên hơn các tính năng. Nếu có thể, tôi cũng sẽ cố gắng tách các mối quan tâm để linh hoạt hơn.


Chúng tôi không thể tắt nó mãi mãi và câu trả lời của bạn không đề cập đến cách thực hiện tái cấu trúc.
Charles Lambert

@Charles: 'dự kiến ​​vào lúc khác.' ;) Tôi không nói hủy dự án.
Tôi chấp nhận

2

Gần đây đã trải qua vấn đề tương tự với một phần của cơ sở mã của chúng tôi (cũng lớn hơn một chút), tôi hy vọng tôi có thể chia sẻ một vài hiểu biết với bạn. Trong tình huống của tôi, codebase đã được phát triển bởi một nhóm khác, vì vậy không có ai từ các nhà phát triển ban đầu tham gia vào việc tái cấu trúc này. Kinh nghiệm của tôi với codebase là khoảng 1 năm và một nhà phát triển khác đã giao nhiệm vụ đó 2 năm.

Cho phép tôi hai lưu ý nhỏ liên quan đến các câu trả lời khác ở đây:

  • Phân nhánh sẽ giúp bạn thiết lập một sân chơi cho chính mình, nhưng không bao giờ hợp nhất các thay đổi của bạn với thân cây trong một thay đổi lớn. Bạn sẽ gặp rắc rối nghiêm trọng với phần còn lại của đội.
  • Bạn cần phải làm điều đó tăng dần, và nó có thể được thực hiện. Không có lời bào chữa. Đọc làm việc hiệu quả với bìa Mã kế thừa để trang trải. Đọc lại lần nữa.
  • Nghĩ rằng bạn có thể làm điều đó một bước lớn là một ngụy biện. Mặc dù có vẻ nhiều công việc hơn, nhưng thực hiện nó tăng dần dễ quản lý hơn nhiều.

Dường như "không đặt chỗ trước" trong hai tuần trở lên sẽ không được chú ý. Bạn cần đảm bảo bạn được hỗ trợ bởi quản lý dự án và quan trọng hơn là nhóm. Nếu nhóm không cam kết tái cấu trúc này (và điều này có nghĩa là, hãy thực hiện ngay bây giờ, không phải trong tương lai xa), bạn sẽ gặp rắc rối.

Đừng làm một mình, hãy sử dụng lập trình cặp. Điều này không hoàn toàn có nghĩa là bạn cần phải ngồi trước cùng một bàn phím, nhưng có thể xử lý các tác vụ nhỏ và hẹp (ví dụ: viết các bài kiểm tra nắm bắt hành vi của lớp này).

Thực hiện tái cấu trúc Scratch và xử lý nó như vậy. (Một loại tái cấu trúc nguyên mẫu "vứt bỏ", bit "vứt bỏ" rất quan trọng!) Thành thật mà nói, không chắc bạn biết tất cả các hàm ý mà phép tái cấu trúc của bạn sẽ có. Tái cấu trúc đầu sẽ giúp bạn trong một số vấn đề nhất định:

  • Bạn sẽ khám phá những phần của hệ thống mà bạn không bao giờ biết chúng tồn tại.
  • Bạn sẽ có cái nhìn tốt hơn nhiều về cách các mô-đun kết nối với nhau
  • Bạn sẽ khám phá một cách mới để nhóm hệ thống của bạn thành các mô-đun, có thể khác nhiều so với hiểu biết hiện tại của bạn. Thảo luận về những hiểu biết với đối tác của bạn. Cố gắng chắt lọc quan điểm mới của bạn. Viết một whitepaper kiến ​​trúc ngắn (hoặc vẽ sơ đồ) cho biết nơi hiện tại và nơi chúng nên thuộc về logic.

Khi bạn đã thực hiện tái cấu trúc đầu, tôi hy vọng bạn sẽ khám phá ra rằng bạn không thể đi và thay đổi mọi thứ. Bạn sẽ cảm thấy tồi tệ, đó chỉ là một mớ hỗn độn lớn và bạn không thể bật công tắc và làm cho nó hoạt động. Đây là những gì đã xảy ra với tôi, nó có thể khác trong tình huống của bạn.

Tuy nhiên, đối tác của tôi và tôi đã hiểu rõ hơn về hệ thống của chúng tôi. Bây giờ chúng tôi đã có thể xác định các cấu trúc lại / thiết kế lại nhỏ hơn (mặc dù vẫn lớn). Chúng tôi đã nắm bắt tầm nhìn của chúng tôi về hệ thống trong một sơ đồ và chia sẻ nó với nhóm, cùng với các mục tồn đọng mà chúng tôi đã đưa ra để thực hiện tầm nhìn đó. Được trao quyền bởi sự đồng thuận chung, chúng tôi đã quyết định những mục nào chúng tôi sẽ thực hiện trong quá trình lặp lại tiếp theo.

Một điều cuối cùng đã giúp chúng tôi là sử dụng một bảng trắng lớn. Có quá nhiều thứ phải giữ trong đầu. Nó là hoàn toàn quan trọng bạn giữ ghi chú. Viết cho mình một ghi chú ngắn gọn vào cuối ngày, ghi lại những gì bạn đã làm hôm nay và muốn làm vào ngày mai. Nó giúp thư giãn thời gian lớn, và bạn cần một thời gian thư giãn nếu bạn muốn theo kịp nhiệm vụ. Chúc may mắn!


1

Bắt đầu một cửa sổ bảo trì trong đó không có sự phát triển tiếp theo được thực hiện. Thực hiện thiết kế lại, sau đó tiếp tục chạy nước rút phát triển.


0

Chúng tôi có hai loại công việc trong tay:

  1. Man-giờ làm việc
  2. Thiên tài làm việc

Refactoring thường bao gồm các loại đầu tiên của tác phẩm, vì có rất nhiều phương pháp được biết đến đã được các nhà phát triển như DRY , SRP , OCP , DI , vv Vì vậy khi một dự án phải mất hai tháng để được refactored, nó chỉ đơn giản là phải mất hai tháng , có không có cách nào xung quanh nó Vì vậy, đề nghị của tôi sẽ là không cấu trúc lại dự án ban đầu và để nó hoạt động theo tình hình hiện tại của nó. Ngừng nhận các yêu cầu và yêu cầu mới từ các bên liên quan và chủ sở hữu sản phẩm . Sau đó, để nhóm làm việc trong dự án cho đến khi nó được tái cấu trúc và sẵn sàng để đi.


0

Một gợi ý có thể giúp: Nếu bạn có mã chưa được kiểm tra sao cho bạn không có đủ thời gian để cấu trúc lại kiểm tra lại trong vòng hai tuần, hãy xem xét trước tiên thực hiện một số thay đổi nhỏ không liên quan đến mã để bạn có thể tập trung trong bài kiểm tra viết cho lần chạy nước rút đầu tiên hoặc hai. Có lẽ bạn có thể xác định một số khách hàng chưa được kiểm tra của mã bạn muốn cấu trúc lại; chọn một khách hàng và thực hiện một số thay đổi khác về việc sử dụng cho doanh nghiệp sẽ buộc bạn phải viết bài kiểm tra cho khách hàng đó. Khi bạn đã quen thuộc hơn với mã, khi làm việc với nó và bạn có nhiều thử nghiệm hơn và bạn có thể hoàn thành một vài phép tái cấu trúc đóng góp nhỏ, bạn sẽ ở vị trí tốt hơn nhiều để thực hiện tái cấu trúc và (bây giờ dễ dàng hơn ) kiểm tra cả hai trong một lần lặp.

Một cách tiếp cận khác là tạo một bản sao của mã vi phạm, cấu trúc lại mã và sau đó chuyển từng máy khách sang mã mới. Công việc này có thể được chia thành các lần lặp.

Và đừng bỏ cuộc: Đừng chấp nhận rằng việc tái cấu trúc lớn có thể được chia thành các bước nhỏ hơn. Cách tiếp cận dễ nhất / nhanh nhất / tốt nhất có thể mất nhiều thời gian hơn một lần lặp. Nhưng điều đó không có nghĩa là không có cách nào để thực hiện các đoạn có kích thước lặp.

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.