đề xuất thay đổi lớn / viết lại dưới dạng thực tập [đóng]

Bối cảnh:

• đó là một dự án nội bộ (mà tôi không nghĩ nhiều người sử dụng)
• no cu
• chúng tôi đang cập nhật nó

Các vấn đề:

1. nó lạm dụng khung mvc (không sử dụng mô hình, logic nghiệp vụ trong các khung nhìn, v.v.)
2. những gì chúng ta được yêu cầu làm là nhỏ, nhưng vì sự gắn kết thấp, chúng ta có hai lựa chọn:
   1. tiếp tục botch mọi thứ
   2. di chuyển các đoạn mã lớn xung quanh hoặc viết lại điều đó

Các giải pháp (tôi thấy):

1. tiếp tục làm việc với nó, bỏ qua các thực tiễn tốt nhất để sớm được thực hiện và không giới thiệu các lỗi mới bằng cách tái cấu trúc / viết lại
2. tái cấu trúc / viết lại

Tôi đoán câu hỏi của tôi thực sự là: nếu tôi muốn thực hiện những thay đổi lớn cho dự án này, làm thế nào để tôi đề xuất điều đó mà không xúc phạm bất cứ ai? Hoặc sẽ tốt hơn cho tôi chỉ đơn giản là đi theo dòng chảy ngay cả khi điều đó có nghĩa là (băng ẩn dụ) đôi khi?

OK ở đây đi.

Bạn nghĩ rằng ứng dụng này có cấu trúc xấu và được viết xấu.

Khách hàng nghĩ rằng nó làm công việc.

Bạn muốn viết lại nó không vì lý do nào khác ngoài việc cải thiện "vẻ đẹp bên trong" của nó.

Vì vậy, bạn đang yêu cầu khách hàng chi tiền để ứng dụng thực hiện chính xác những gì hiện tại - chỉ những phần mà người dùng không nhìn thấy hoặc hiểu sẽ bằng cách nào đó "tốt hơn".

Sự phản đối chính đối với mã có cấu trúc xấu được viết xấu là khó hiểu.

Mã này khó hiểu và có chức năng và tính năng chỉ có thể dễ dàng thực hiện trong một ứng dụng có cấu trúc xấu. Vì vậy, trừ khi bạn rất giỏi trong việc này, ứng dụng mới sẽ không thực hiện chính xác những gì ứng dụng hiện tại làm, và, vì bạn không hiểu đầy đủ những gì mã gốc đang làm, có lẽ nó sẽ làm sai.

Vì vậy, khách hàng của bạn bây giờ đã chi rất nhiều tiền để có được một ứng dụng tệ hơn rõ rệt so với ứng dụng gốc. Bạn sẽ không nổi tiếng!

May mắn thay, các trường đại học giàu kinh nghiệm hơn của bạn đã sẵn sàng để hài hước với bạn (có lẽ vì họ đã phạm sai lầm tương tự khi họ bắt đầu, và thậm chí có thể đã không may nhận được sự chấp thuận của ban quản lý cho một dự án tồi tệ như vậy).

Vì vậy, lời khuyên của tôi sẽ là giữ cho cơ sở mã cũ hoạt động, và, giữ im lặng. Khách hàng chỉ muốn một hệ thống hoạt động mà họ không thực sự quan tâm nếu bạn nghĩ rằng mã đó là xấu.

Đề xuất thay đổi của bạn. Hãy rõ ràng về trường hợp kinh doanh cho từng trường hợp: Tại sao thay đổi được đề xuất của bạn sẽ giúp toàn bộ hệ thống? Nếu không, mong đợi đẩy lùi. Tại sao chi tiền sửa chữa một cái gì đó không bị hỏng? Những lý do như làm cho hệ thống mở rộng hơn và sự tách biệt mối quan tâm có thể hợp lệ (tùy thuộc vào người bạn đang nói chuyện), nhưng 99% thời gian, chỉ cần nói "nó không được thực hiện chính xác" sẽ không đưa bạn đến đâu. Hãy chắc chắn rằng bạn đang thêm giá trị cho dự án và không chỉ đề xuất thực hiện công việc (ngay cả khi nó làm sạch mã).

Thật không may, trong thế giới chuyên nghiệp, chỉ vì một cái gì đó được thực hiện sai không có nghĩa là nó bị hỏng, và do đó không cần phải sửa chữa. Ngoài ra, trong việc khắc phục nó, bạn có thể đưa ra các sự cố gõ cửa không lường trước có thể ảnh hưởng đến các khu vực khác của dự án.

Đọc câu hỏi của bạn, tôi thực sự hoài nghi rằng viết lại ứng dụng là xứng đáng. Có lẽ bạn đã không bận tâm để làm cho trường hợp đầy đủ trong câu hỏi của bạn. Nhưng làm thế nào có khả năng là lợi ích của việc viết lại đáng giá nếu nó là một ứng dụng nội bộ cũ, hiếm khi được sử dụng? Chi phí viết lại có thể cao hơn tổng của tất cả các bản cập nhật và bản vá lỗi mà nó sẽ có.

Nếu bạn nghĩ rằng điều đó không đúng, bạn sẽ cần tạo ra nhiều trường hợp cho nó hơn là bạn đã làm ở đây.

Đối với việc cải thiện ứng dụng, bạn có thể có một số cơ hội cho một chút tái cấu trúc diễn ra tự nhiên trong quá trình cập nhật của bạn.

Bạn là thực tập sinh. Có lẽ, bạn là thương hiệu mới. Họ có thể nghi ngờ bạn là một thằng ngốc.

Vì vậy, khi bạn đi về việc đưa ra gợi ý, bước đi nhẹ nhàng . Hãy khiêm tốn và khiêm tốn. Hãy để ý tưởng của bạn trôi chảy khi bạn cho phép các thành viên khác thảo luận về ý tưởng của riêng họ về cơ sở mã hóa và những áp lực mà họ có thể phải chịu (có thể có lý do rất chính đáng tại sao một nỗ lực đã được thực hiện để làm sạch mọi thứ).

Bạn muốn kiếm được lòng tin của họ. Bạn làm điều này bằng cách viết mã tốt cho các nhiệm vụ bạn được giao. Viết nó sạch sẽ, sử dụng các thực tiễn tốt nhất mà bạn muốn thấy được thực hiện, nhưng chỉ trên những gì bạn được chỉ định làm. Đây có lẽ sẽ là những điều nhỏ nhặt, những điều mà phần còn lại của đội có thể nghĩ là không đáng kể. Làm những điều đó tốt. Làm sáng góc nơi bạn đang ở và khi nhóm đến xem xét mã của bạn một cách thuận lợi, ý tưởng của bạn sẽ lần lượt phát triển về tầm vóc.

Cuối cùng , khi bạn chứng minh năng lực và kiến ​​thức của mình, bạn có thể đưa ra một hoặc hai gợi ý.

Tôi hoàn toàn sẽ đưa ra đề nghị này, nhưng chỉ cho một nhà phát triển đồng nghiệp . Tôi sẽ không đưa nó lên với quản lý, vì tôi sẽ tưởng tượng rằng quản lý sẽ thấy rằng đó là một kiểu vượt qua ranh giới.

Sau khi đưa ra gợi ý cho nhà phát triển mà bạn đang làm việc, có lẽ họ sẽ có một số lý do chính đáng cho việc tại sao cơ sở mã hóa lại như vậy. Các lý do có thể từ "không, thực ra mã rất ổn, bạn chỉ không hiểu MVC (và đó là lý do tại sao bạn là thực tập sinh") đến "đó là một ý tưởng tuyệt vời, hãy cùng nhau thiết kế ứng dụng mới!"

Hãy nhớ rằng câu trả lời để tái cấu trúc ứng dụng này nhiều khả năng sẽ là không; Tôi sẽ không bao giờ muốn một nhân viên thực tập tiếp quản việc viết lại một ứng dụng nội bộ (điều gì xảy ra khi quá trình thực tập của bạn hoàn thành và việc viết lại chỉ hoàn thành một nửa?) Ngoài ra, có lẽ có nhiều thứ quan trọng bạn có thể làm việc hơn là chọc vào một ứng dụng nội bộ .

Nhưng không bao giờ đau lòng khi hỏi các đồng nghiệp của bạn, và nếu bạn làm thế, bạn sẽ học được điều gì đó. Và đó, 7983879342, là tất cả những gì thực tập.

Bất cứ điều gì xảy ra, tôi hy vọng bạn mang thông điệp sau đi. Như một số câu trả lời ở trên đã chỉ ra đôi khi một mã viết lại, vì lý do kỹ thuật tốt nhất đôi khi không khả thi vì lý do kinh doanh / chi phí. Quá nhiều lập trình viên sống trong giải pháp kỹ thuật và từ chối xem xét rằng, yêu cầu về tính thanh lịch / khả năng đọc / kỹ thuật tốt nhất của họ nên được cân bằng bởi nhu cầu của doanh nghiệp để hoàn thành công việc. Theo kinh nghiệm cá nhân của tôi, anh chàng không đạt được sự cân bằng đó (từ một trong hai hướng) thường được xem là một trách nhiệm trong đội.

Đừng ngừng đặt câu hỏi mặc dù, ngay cả khi bạn gặp phải một số lỗi, đó là cách chúng ta học hỏi và phát triển.

Các câu trả lời khác đã nói rất nhiều về chính trị của tình huống của bạn, và tôi có xu hướng đồng ý. Trừ khi bạn có thể trình bày một trường hợp kinh doanh hấp dẫn, viết lại có lẽ không có trên thẻ.

Tuy nhiên, điều đó không có nghĩa là bạn nên quên Quy tắc Hướng đạo nam :

Luôn luôn để khu cắm trại sạch hơn bạn tìm thấy.

Nếu trong khi bạn đang thực hiện một cái gì đó trên cơ sở mã này, bạn có thể tìm ra cách để làm sạch một số khía cạnh của thiết kế hoặc triển khai, thì đó là điều bạn nên xem xét. Có lẽ bạn không cần phải viết lại toàn bộ ứng dụng để sử dụng tốt hơn mô hình MVC và nếu bạn đang triển khai một số logic nghiệp vụ mới cho một khung nhìn cụ thể, bạn có thể xem xét chuyển logic ra khỏi khung nhìn cũ vào mô hình cũ và thêm logic mới của bạn vào đó.

Như những người khác đã nêu, hãy yêu cầu một nhà phát triển khác (một người quen thuộc với ứng dụng này) thực hiện một hướng dẫn nhanh chỉ để bạn có thể hiểu cách thức / lý do thực hiện. Giải thích rằng trong khi bạn có thể hiểu các khía cạnh công nghệ, nhưng bạn muốn có thể kết nối các dấu chấm với các yêu cầu kinh doanh (yêu cầu kinh doanh vượt qua tất cả).

Khi bạn có thông tin này, bạn có thể đánh giá. Nếu cá nhân bạn nghĩ rằng nó nên được viết lại, nhưng đừng nghĩ người khác sẽ coi đó là một cách sử dụng tốt thời gian, hãy xem nó như một dự án cá nhân. Ngay cả khi đó là một giờ ở đây / ở đó khi bạn có thời gian chết, hãy thực hiện "chính xác". Khi bạn hoàn thành, hãy trình bày cho (các) nhà phát triển khác với tư cách là "này, tôi cảm thấy như điều này có thể sử dụng một số công việc dọn dẹp, vì vậy tôi đã làm một số công việc phụ trong thời gian ngừng hoạt động. Bạn nghĩ sao?" Đừng nhấn vào sự thay đổi của họ - chỉ cung cấp cho họ như một "hey, các bạn thích cái này?" và đi từ đó.

Hầu hết các thay đổi xảy ra gia tăng, như một quy luật chung.

Một vài điều cần ghi nhớ;

• Lịch sử của ứng dụng là gì?
• Tại sao hôm nay nó xấu?
• Lợi ích của những thay đổi kiến ​​trúc là gì?

Một chiến lược tốt là làm việc với những điều nhỏ nhặt và đặt ra rất nhiều câu hỏi về nội dung (những câu hỏi bạn không thể học từ Google hoặc nguồn, đừng lãng phí thời gian của mọi người). Sau khi bạn cảm thấy thoải mái với cơ sở mã và các nhà phát triển, bạn nên có một cảm giác tốt về lý do tại sao mã là như vậy. Đôi khi, chỉ là, "Vâng, chúng tôi đã phải hack một cái gì đó cùng nhau và đẩy nó ra khỏi cửa". Nếu bạn có thể đề xuất những thay đổi nhẹ cho các phần nhỏ của hệ thống xảy ra khi bạn làm việc bình thường, điều đó sẽ nhận được nhiều lực kéo hơn là viết lại triệt để.

Sẽ không có hại gì khi đề xuất viết lại nếu bạn hỏi độc đáo và đưa ra một trường hợp hợp lý (không chỉ là linh cảm hay cách tốt hơn để làm điều đó). Có khả năng cao là viết lại một ứng dụng sử dụng thấp sẽ bị bắn hạ, và rất có khả năng là bất cứ ai ban đầu viết hệ thống vẫn ở xung quanh (và cao hơn trong hệ thống phân cấp so với bạn) và có thể không vui lòng chỉ trích.

Vì vậy, đừng nói "Chúng ta cần viết lại hệ thống được thiết kế khủng khiếp này vi phạm các nguyên tắc MVC cơ bản", hãy hỏi nó như một câu hỏi mở cho những người cấp cao thích hợp (những người trực tiếp ở trên bạn). Một cái gì đó như "Tôi tự hỏi nếu viết lại hệ thống trong mô hình MVC có thể tiết kiệm rất nhiều thời gian trong thời gian dài. Bạn nghĩ gì? Tôi cá là chúng ta có thể giảm một nửa thời gian bảo trì bằng cách viết lại chính (trong 2 tuần) kết hợp mô hình MVC, TDD, v.v. đã được thực hiện và sau hai tháng bảo trì định kỳ, chúng tôi sẽ hòa vốn ". Câu trả lời có thể là, không, chúng tôi không nghĩ rằng điều đó được gọi là - Tôi không đồng ý với ước tính thời gian của bạn và khả năng hệ thống mới sẽ là sự thay thế phù hợp. Hoặc câu trả lời có thể là, tốt thôi, nhưng hãy nhớ nếu hệ thống mới của bạn không ' T hoạt động tốt / tốt hơn hệ thống mới trong khung thời gian bạn đề xuất rằng mọi người sẽ đổ lỗi cho bạn. Và ngay cả khi hệ thống ít được sử dụng; có thể không chấp nhận được việc dừng cập nhật nó với các sửa lỗi nhỏ trong giai đoạn viết lại.