Tái cấu trúc hoặc tập trung hoàn thành ứng dụng

Bạn sẽ cấu trúc lại ứng dụng của mình khi bạn đi hay tập trung hoàn thành ứng dụng trước? Tái cấu trúc sẽ có nghĩa là tiến độ của ứng dụng sẽ chậm lại.

Hoàn thành ứng dụng sẽ có nghĩa là bạn có thể rất khó duy trì ứng dụng sau này?

Ứng dụng này là một dự án cá nhân. Tôi thực sự không biết làm thế nào để trả lời "Điều gì thúc đẩy chức năng và thiết kế", nhưng tôi đoán nó sẽ giải quyết sự thiếu hiệu quả trong phần mềm hiện tại. Tôi thích phần mềm dễ sử dụng tối thiểu quá. Vì vậy, tôi đang loại bỏ một số tính năng và thêm một số tính năng mà tôi cảm thấy sẽ giúp ích.

Lam cho no hoạt động. Sau đó làm cho nó nhanh. Cuối cùng, làm cho nó đẹp.

Nếu bạn có sự phân tách tốt giữa mã của bạn (lớp trình bày, doanh nghiệp và lớp dữ liệu) bằng cách sử dụng các giao diện và đó không phải là một thiết kế nguyên khối, thì việc tái cấu trúc sẽ không quá khó khăn.

Nếu bạn gặp khó khăn trong việc tái cấu trúc, đó có thể là mùi mã - tôi khuyên bạn nên xem Nguyên tắc vững chắc

Tôi nghĩ rằng điểm quan trọng là giữ cho giao diện sạch sẽ . Bạn luôn có thể cấu trúc lại hoặc thậm chí viết lại mô-đun / lớp / bất kỳ triển khai nào sau này, miễn là các lớp giao tiếp giữa chúng là lành mạnh. Dành thời gian để tìm ra những gì dễ dàng thay đổi sau này và những gì không. Làm cho cái sau đúng.

Điều này phù hợp với tinh thần của TDD. Để viết bài kiểm tra tốt, bạn cần một giao diện tốt để kiểm tra. Làm thế nào lộn xộn đằng sau hậu trường vào lúc này không quan trọng, bởi vì bạn có thể cải thiện nó sau này.

Tôi luôn luôn cấu trúc lại khi tôi đi, đặc biệt là sử dụng TDD.

1. Viết bài kiểm tra

2. Làm cho các bài kiểm tra vượt qua

3. Cấu trúc lại

Điều này sẽ giúp bạn có ít lỗi hơn và mã tốt hơn cho thành phẩm. Nó cũng sẽ cho phép bạn có ít mã hơn để duy trì khi bạn hoàn thành.

Tái cấu trúc sớm và thường xuyên! Thời gian bạn "tiết kiệm" khi không thực hiện nó đã dành nhiều lần cho việc cố gắng hack trong tính năng tiếp theo và tìm kiếm các lỗi trong mã quá phức tạp hoặc hỗn loạn.

Tái cấu trúc giống như chọn phòng của bạn.

Nếu bạn giữ mọi thứ gọn gàng, bạn có một chi phí tuyến tính, tỷ lệ thuận với số lượng công việc sản xuất bạn đang làm trên mã, O (n) theo thuật ngữ của nhà thuật toán học. Giả sử bạn dành 10% thời gian để tái cấu trúc (hoặc giữ phòng của bạn gọn gàng), thì 10% đó là nhất định và nó sẽ không đổi theo thời gian.

Tuy nhiên, nếu bạn ném quần áo bẩn của bạn vào một góc, và tiếp tục làm việc đó, lượng thời gian bạn sẽ dành để chọn phòng của bạn tăng lên khi sự lộn xộn trở nên phức tạp hơn. Giả sử rằng mỗi mảnh quần áo bẩn riêng lẻ đóng góp theo cấp số nhân cho thời gian dọn dẹp cần thiết, bạn hiện đang ở trong tình huống O (e ⁿ ).

Bất cứ ai đã từng đào sâu vào khái niệm về độ phức tạp thuật toán sẽ quan sát thấy rằng có một điểm hòa vốn ở đâu đó, nghĩa là, có một lượng quần áo bẩn tối ưu để tích lũy; bao nhiêu đó phụ thuộc vào các yếu tố không đổi được loại bỏ trong ký hiệu big-O. Một yếu tố khác là giá trị công việc của bạn theo thời gian: nếu công việc của bạn có giá trị rất nhiều ngay bây giờ, nhưng giá rẻ vào tuần tới (nghĩa là có thời hạn vào thứ sáu này cho dự án này và ba ngày nữa, nhưng sau đó, bạn sẽ hầu như không hoạt động ), phương trình có thể có lợi cho việc không tái cấu trúc.

Và sau đó là khối lượng quan trọng phức tạp. Tại một số điểm, mớ hỗn độn ('mớ hỗn độn quan trọng', nếu bạn sẽ) trở nên tồi tệ đến mức có vẻ dễ dàng hơn để đốt cháy toàn bộ căn phòng và mua quần áo mới. Trong thực tế, điều đó thường không xảy ra, nhưng nó xuất hiện theo cách đó và các hiệu ứng tâm lý sẽ khiến việc giải quyết vấn đề trở nên khó khăn hơn gấp mười lần.

Và rõ ràng, nếu bạn bước vào một dự án là một mớ hỗn độn dư thừa khổng lồ, bạn có sự lựa chọn hạn chế.

TL; DR: Nếu nghi ngờ, tái cấu trúc. Bạn nên có bằng chứng thực sự tốt trước khi quyết định không.

Nếu bạn có cơ hội để thêm các tính năng hoặc phá vỡ các lỗi để có được sự hài lòng của khách hàng / khách hàng nơi bạn nghĩ nó nên làm, hãy làm điều đó. Một khi có ít nhu cầu mới, bạn có thể cân bằng với tái cấu trúc. Tại một số điểm bạn phải đảm bảo rằng bạn đang viết mã mọi người muốn. Tất cả mọi thứ đều bình đẳng, tôi thà vứt bỏ 100 giờ mã hơn 1000. Đó là những gì bạn sẽ làm nếu không ai muốn nó.

Thực sự phụ thuộc vào nơi bạn đang ở!

Những điều khác để suy nghĩ:

Bạn chắc chắn như thế nào, bạn đã thực sự có thiết kế chức năng phải không? Bạn có thể kết thúc việc thiết kế lại sau khi bạn nhận được một số phản hồi của người dùng?

Tôi muốn phát hành hơn là viết lại. Tối ưu hóa sau khi bạn chắc chắn rằng bạn đã đóng đinh thiết kế chức năng.

Miễn là bạn chắc chắn bạn có thể đáp ứng thời hạn, chắc chắn bạn có thể cấu trúc lại tất cả những gì bạn muốn. Tuy nhiên, ngay cả khi có một chút không chắc chắn tốt hơn để gắn bó với sự phát triển và có thể chỉ là cấu trúc lại trong bước tăng khiêm tốn.

Nếu thiết kế xấu mà bạn muốn cấu trúc lại thực sự gây tổn thương cho bạn, tốt nhất bạn nên sửa nó ngay bây giờ hơn là tạo thêm mã phụ thuộc vào nó. Tái cấu trúc sau này sẽ khó khăn hơn và tốn kém hơn; rất có thể bạn sẽ không thể làm điều đó nữa.

Mặt khác, nếu vấn đề duy nhất của bạn là sự xấu xí, bạn có thể muốn hoàn thành phần mềm của mình trước tiên, bởi vì hầu như không có gì vượt qua được mọi thứ .

Tái cấu trúc sẽ rất quan trọng khi bạn hoàn thành đơn đăng ký của mình.

+ VES

1. Xóa dòng: Tái cấu trúc sẽ cho mã rõ ràng vì đôi khi nếu mã không có cấu trúc, hiểu dòng mã sau một thời gian sẽ trở nên khó khăn và mã tái cấu trúc có thể trở thành một nhiệm vụ khó khăn và lỗi có thể được đưa vào.

2. Cải thiện hiệu suất: Tái cấu trúc đúng ứng dụng chắc chắn sẽ giúp cải thiện hiệu suất của ứng dụng.

3. Bảo trì: Cuối cùng nhưng không kém phần quan trọng, việc bảo trì về lâu dài sẽ dễ dàng hơn .

-ĐÃ

1. Tiêu tốn thời gian : Sẽ tốn nhiều thời gian hơn ở mỗi giai đoạn tiến trình của bạn. Vì vậy, có thể có một sự chậm trễ trong việc hoàn thành.

Dòng dưới cùng

Tùy thuộc vào loại dự án, bạn có thể ưu tiên về chất lượng mã hoặc hoàn thành bất cứ điều gì đang đòi hỏi cho tình huống hiện tại.

Dựa trên kinh nghiệm cá nhân của tôi, tôi thường sẽ hoàn thành các ứng dụng trước với điều kiện phải có thời hạn. Một khi bạn hoàn thành, bạn có thể cấu trúc lại nó.

Hoàn thành nó và tái cấu trúc nó. Nhưng nếu không có thời hạn để vội vàng hoặc khung thời gian, tôi khuyên bạn nên tái cấu trúc nó sẽ tốt.