Làm thế nào để tránh viết lại các phần của ứng dụng


13

Tôi đang làm việc tại một công ty trong một dự án cho bộ phận Bán hàng của họ. Đó là công việc lập trình chuyên nghiệp đầu tiên của tôi, nhưng tôi đã tự mình viết mã và học hỏi trong nhiều năm. Một phần của dự án liên quan đến việc lấy một số dữ liệu và kết hợp nó với đầu vào để sản xuất và biểu đồ. Sau đó lưu dữ liệu ... cứ như vậy. Vì vậy, tôi đã viết mã cho điều này trong một ít dưới một ngày. Ngày hôm sau tôi chỉ cho người giám sát dự án của mình và anh ấy thích nó, nhưng "nếu chúng ta có cái này thì sao" và muốn tôi thêm thứ gì đó vào biểu đồ. Đây không phải là một thay đổi lớn đối với giao diện hoặc chức năng của chương trình, nhưng nó đã thay đổi mạnh mẽ cách tôi cần để lưu trữ dữ liệu, xử lý nó, v.v.

Một lần nữa, tôi mất khoảng một ngày để cấu trúc lại bảng cơ sở dữ liệu và viết lại mã về cơ bản từ đầu để hỗ trợ yêu cầu mới này. Tôi lấy lại cho anh ta một lần nữa, và điều tương tự chính xác đã xảy ra. Anh ấy yêu cầu một cái gì đó khác đã thay đổi mạnh mẽ cách tôi cần để xử lý dữ liệu. Vì vậy, tôi đã phải viết lại một lần nữa. Cuối cùng anh ấy đã ký vào đó và hy vọng, tôi sẽ không phải viết lại lần nữa.

Chỉ cần rõ ràng, tôi không bash quản lý của tôi hoặc bất cứ điều gì như thế. Anh ấy là một chàng trai tuyệt vời và những điều anh ấy yêu cầu không nằm ngoài thế giới này, chúng chỉ không tương thích với những gì tôi đã làm trước đây.

Tôi chỉ tự hỏi liệu có bất cứ điều gì tôi có thể làm trong tương lai để tránh viết lại hoàn toàn. Tôi hiểu việc tạo mã linh hoạt và đã cố gắng làm như vậy, nhưng tôi chỉ muốn biết về bất kỳ thực tiễn hoặc việc nào tôi có thể làm khác đi để làm cho việc này dễ dàng hơn, vì vậy, trong tương lai, tôi không dành 3 ngày cho việc gì đó nên lấy 1.


2
Bạn đang sử dụng mô hình lập trình nào? Thủ tục, hướng đối tượng, chức năng, khác?
Tulains Córdova

2
Để tránh viết lại - tách rời cơ sở dữ liệu và lớp ứng dụng của bạn. Nó không phải là một khái niệm đơn giản để áp dụng cho cách bạn viết mã. Đó là một khái niệm phức tạp làm cho mã của bạn đơn giản và dễ thích nghi.
StackOverFowl

6
Có vẻ như các yêu cầu không rõ ràng hoặc bạn hiểu nhầm chúng. Không có nguyên tắc hoặc thực tiễn tốt nhất nào có thể cứu bạn khỏi làm lại toàn bộ ứng dụng nếu việc triển khai được thực hiện trên các giả định sai. Trước khi gõ xuống một LỘC đơn của nó tốt để yêu cầu các yêu cầu " gì Nếu ... " ... Đừng chờ đợi cho người quản lý ngạc nhiên cho bạn một mới gì Nếu ... . Dành một chút thời gian để tìm kiếm các khoảng trống chức năng cũng sẽ làm giảm yếu tố bất ngờ .
Laiv

3
Phụ thuộc tiêm là bạn của bạn. Google nó và xem cách áp dụng nó vào ngôn ngữ / khung của bạn. Nó sẽ cho phép bạn viết một mã mô-đun nhiều hơn, điều này sẽ làm giảm số lượng mã cần được viết lại khi các yêu cầu thay đổi.
Eternal21

2
Mặc dù có vẻ như rất nhiều bài viết lại là một điều tồi tệ, nhưng điều thực sự quan trọng là bạn có thể trả lời các yêu cầu từ người dùng cuối nhanh như thế nào. Mặc dù phụ thuộc vào mức độ phức tạp của dự án, tôi muốn nói rằng 1 ngày là thời gian dẫn đầu khá tốt - bạn phải làm gì đó ngay! Trong thực tế phần mềm thấy những thay đổi đáng kể là một dấu hiệu tốt - nó có nghĩa là nó hữu ích và đang được cải thiện. Phần mềm không bị thay đổi đáng kể trong nhiều năm khó bảo trì hơn nhiều.
Justin

Câu trả lời:


22

Như tôi đã nhận xét, tôi có một cảm giác mạnh mẽ rằng các yêu cầu không rõ ràng ngay lần đầu tiên hoặc có lẽ bạn đã bỏ lỡ một số chi tiết quan trọng.

Không phải mọi thứ đều có thể được giải quyết với mã tốt hơn, thực tiễn tốt nhất, mẫu thiết kế hoặc nguyên tắc OOP. Không ai trong số họ sẽ ngăn bạn làm lại toàn bộ ứng dụng nếu việc triển khai dựa trên các giả định sai hoặc các tiền đề sai.

Đừng vội vàng viết mã cho giải pháp. Trước khi gõ xuống một LỘC, hãy dành một chút thời gian để làm rõ các yêu cầu. Bạn càng đi sâu vào các yêu cầu, càng có nhiều câu hỏi nếu xuất hiện. Đừng đợi Người quản lý làm bạn ngạc nhiên với những gì tiếp theo . Dự đoán những điều bản thân. Bài tập nhỏ này có thể làm giảm đáng kể yếu tố bất ngờ .

Đừng ngại hỏi nhiều lần bạn cần. Đôi khi, những cái cây (chi tiết) không cho chúng ta thấy khu rừng (bức tranh tổng thể). Và đó là khu rừng mà chúng ta cần nhìn thấy đầu tiên.

Khi các yêu cầu rõ ràng, sẽ dễ dàng đưa ra quyết định tốt hơn trong giai đoạn thiết kế.

Cuối cùng, hãy nhớ rằng bức tranh tổng thể là một mục tiêu. Con đường đến mục tiêu này không đơn giản cũng không đơn giản. Những thay đổi sẽ tiếp tục xảy ra, vì vậy hãy nhanh nhẹn.


3
Điều này. Câu trả lời này là cách tốt nhất nó có thể được đặt. Nhận những yêu cầu đó trước khi bạn hoàn toàn làm bất cứ điều gì.
Rhys Johns

1
Đây là một câu trả lời tốt, nhưng tôi có một cảm giác dai dẳng rằng có một cách tốt hơn để cấu trúc ứng dụng để làm cho nó dễ dàng hơn để đáp ứng các yêu cầu này. Tôi không tin bất kỳ cái gì gọi là "nguyên tắc" trôi nổi sẽ giúp ích; giải pháp phải cụ thể cho vấn đề. Không có thêm thông tin, câu trả lời của bạn là duy nhất có ý nghĩa.
Frank Hileman

Chà, tôi có cảm giác mạnh mẽ rằng vấn đề là do tôi bình luận vì đó chính xác là những gì đã xảy ra với tôi trong những ngày đầu làm nhà phát triển. Tôi ngay lập tức dịch các cụm từ sang LỘC hoặc các mô-đun, và khi tôi phải thay đổi một cái gì đó khá kịch tính đối với tôi. Refactor hơn refactor mỗi ngày hoặc tuần. Thậm chí không làm hết sức mình với SoC, XUÂN, đa hình, ... Nhiều mâu thuẫn tôi gặp phải với những thay đổi là do rò rỉ tầm nhìn tổng thể của tôi.
Laiv

2
Để xây dựng trên đầu câu trả lời này: Điều quan trọng là cũng phải nhanh nhẹn trong việc thu thập yêu cầu. Đôi khi mọi người nhận được ý tưởng mới hoặc nhớ một cái gì đó họ quên khi nhìn thấy sản phẩm. Họ có thể nói: "Tôi biết tôi đã yêu cầu bạn xây dựng cái này nhưng đó không phải là ý tôi" hoặc "Tôi biết tôi đã yêu cầu cái này, nhưng bây giờ tôi thấy nó, tôi muốn thứ khác." Bạn có thể ngăn điều này gây ra sự thất vọng và làm lại bằng cách tạo ra một "Bằng chứng khái niệm" nhanh chóng và bẩn thỉu. Điều này thậm chí có thể là một mockup giống như một biểu đồ giả. Nó giúp khách hàng của bạn suy nghĩ.
Akhil

1
Một số người có thể lập luận rằng việc trừu tượng hóa db từ mã không phải là điều bắt buộc bởi vì "các nhà cung cấp db hiếm khi thay đổi". Tôi đồng ý với bạn, nhưng quan điểm của câu trả lời của tôi là: trong khi thu thập các yêu cầu, hãy quên bạn là một nhà phát triển, Tập trung vào thu thập yêu cầu. Hãy suy nghĩ như một người quản lý, hãy hỏi như một người quản lý. Đừng vội nghĩ như một nhà phát triển.
Laiv

4

Không có cách nào để biết rằng dựa trên những gì bạn đã đưa ra. Nó nhanh và bẩn hơn, đó là những gì bạn cần tại thời điểm đó. Nhưng, sau đó ai đó thích nó và nó trở nên phức tạp, vì vậy bây giờ bạn bắt đầu thấy rằng nhiều vấn đề không thể hiện ra cho đến khi sự phức tạp xuất hiện. Có rất nhiều điều khác nhau có thể được thực hiện, nó chỉ đơn giản là quá sức.

Có cái cũ, "Không có viên đạn bạc", và đó là sự thật. Một lần nữa, không có cách nào để biết phải làm gì với thông số kỹ thuật đầy đủ (hoặc thông số kỹ thuật đang diễn ra tốt hơn cho Agile) và khả năng sử dụng các nguyên tắc lập trình tốt và thiết kế tốt. Lập trình viên thích viết lại, hơn và hơn . Tôi không nói rằng bạn rơi vào điều này nhất thiết vì nó, tại thời điểm này, là nhỏ.

Sử dụng cơ hội này để áp dụng một số nguyên tắc cơ bản. Bạn sẽ thấy rằng họ làm việc nhưng sau đó ai đó sẽ nói, "Ồ không, điều đó thật tệ" hoặc bạn sẽ làm một cái gì đó khác mà bạn thích. Bạn không thể làm tất cả bằng tiền của công ty, nhưng nếu họ cho phép bạn có thời gian khám phá, hãy sử dụng nó như một cơ hội. Luôn luôn có một ai đó, một số nền tảng, một số người, có cách "tốt nhất" hoặc một số cách làm "mới".


Bài viết hay mà bạn liên kết.
SH7890

1
Bài viết tốt thực sự! Tôi nghĩ không phải là trường hợp OP nhưng tôi không thể đồng ý nhiều hơn với tác giả.
Laiv

1
Tôi đã không nghĩ rằng nó là một cho một, nhưng nó đọc như thể nó có thể là một ngày. Hy vọng điều này sẽ giúp OP.
johnny

2

Người quản lý của bạn rất có thể đúng trong từng bước bạn đã trải qua. Không phải vì anh ta là người quản lý, mà vì anh ta đang xem xét kết quả và khả năng sử dụng và có lẽ số lượng giao dịch trước đó với khách hàng hoặc yêu cầu của khách hàng.

UI là thứ cứng, thông thường, 5 người có 15 góc nhìn khác nhau. Và dữ liệu và cấu trúc dữ liệu và phân tích dữ liệu có xu hướng thay đổi nhân với hệ số 10 :). UI giống như thời trang, một số kết hợp rất tuyệt, một số là khủng khiếp hoặc thiếu ý nghĩa thông thường.

Chưa kể, ví dụ như trong quá trình LEAN, không có gì được đặt trong đá. Bạn đang trải qua một cái gì đó như đánh giá lặp đi lặp lại và trong mỗi bước, đó là con đường tốt hơn hoặc sai ít hơn là tránh.

Vì vậy, câu trả lời đơn giản là, không có gì là không viết lại cả.


2

Phát triển lặp lại (đó là những gì bạn đã làm về cơ bản, mặc dù lặp đi lặp lại một ngày) thường như thế này. Những nỗ lực ban đầu đối với các giải pháp thường không được thực hiện và bằng cách thu thập thông tin phản hồi, hệ thống sẽ hội tụ thành một giải pháp. Tôi sẽ mượn Hình 2.2 từ tài liệu hướng dẫn của Craig Larman cho cuốn sách Áp dụng UML và Mẫu thiết kế của anh ấy .

nhập mô tả hình ảnh ở đây

Khi bắt đầu một dự án, bạn học cách sống với các phiên bản không ổn định rõ ràng. Tôi sẽ không đồng ý với câu trả lời rằng "bạn phải nhận được nhiều yêu cầu sớm hơn", vì đó là suy nghĩ về Thác nước. Đúng là bạn nên cố gắng đạt được càng nhiều càng tốt về các yêu cầu, nhưng vì nhiều lý do, không thể có yêu cầu đầy đủ và chính xác.

Điều này không có nghĩa là bạn không thể giảm số lượng bạn phải viết lại sau khi nhận được phản hồi. Một điều thường đúng là phần mềm tương tác giữa người và máy tính rất có thể thay đổi, bởi vì đó là một phần khó để có được ngay lần đầu tiên.

Hãy suy nghĩ về Microsoft Word và cách định dạng dữ liệu của nó (.doc) không thực sự phát triển nhiều trong những năm qua. Đó là bởi vì một tài liệu văn bản như một miền vấn đề không thực sự phát triển nhiều (một trang vẫn là một trang, một đoạn vẫn là một đoạn, v.v.). Tuy nhiên, giao diện người dùng của Word đã phát triển rất nhiều (và tiếp tục). Mã cho bản trình bày hoặc đầu vào có xu hướng không ổn định giữa các phiên bản, vì vậy tốt nhất không nên có các phần khác của hệ thống được ghép trực tiếp với chúng (để cách ly chúng khỏi việc viết lại).

Các kiến ​​trúc phần mềm có thể tách rời phần trình bày khỏi logic và dữ liệu cơ bản về vấn đề cho phép viết lại ít hơn. Nhiều mẫu phần mềm như tách biệt Model-View xuất hiện do những người như bạn phải chịu đựng nhiều lần viết lại và tìm kiếm một cách tốt hơn.

Điều này nghe có vẻ rất Phật giáo, nhưng bạn may mắn đã chịu đựng những lần viết lại này! Vì vậy, nhiều người tìm hiểu về các mẫu MVC hoặc các mẫu thiết kế khác mà không phải "chịu đựng" những cơn ác mộng viết lại mà các mẫu được cho là nên tránh.


Tôi muốn câu trả lời này là câu trả lời được chấp nhận. Lặp lại hướng tới một giải pháp tốt hơn là cố gắng thiết lập tất cả các yêu cầu lên phía trước. Đặc biệt là nếu toàn bộ ứng dụng có thể được viết lại trong vòng một ngày.
Euphoric

Tôi chắc rằng ông chủ không biết họ muốn gì ở lần lặp thứ hai cho đến khi lần đầu tiên hoàn thành. Tập hợp nhiều yêu cầu trước đó sẽ là không thể.
gnasher729

1

Tôi không có câu trả lời, nhiều như một bài tập - một bài tập mà bạn có thể sẽ phải làm trong thời gian của mình, mặc dù tùy thuộc vào tổ chức của bạn, bạn có thể được phép thực hiện trong giờ làm việc.

Thiết kế lại giải pháp đầu tiên của bạn để làm chính xác những gì nó đã làm, nhưng làm cho nó dễ dàng hơn để thêm các bước thứ 2 hoặc thứ 2 và thứ 3. Đừng thêm các bước đó, đừng bỏ chúng ra. Chỉ cần tạo một giải pháp đáp ứng tất cả các yêu cầu ban đầu nhưng có thể dễ dàng nâng cấp để bao gồm tính năng mới. Làm tương tự cho giải pháp thứ 2 của bạn.


1

Yêu cầu thay đổi, đó là một thực tế của cuộc sống. Nhìn nhận lại: giải pháp đầu tiên có thể khác đi nên tổng thời gian lập trình sẽ ít hơn? Đó là những gì bạn học được cách làm với kinh nghiệm.

Đó là đường cong học tập dốc đầu tiên. Khi bạn quản lý vấn đề này, sẽ có thách thức thứ hai: Làm thế nào để bạn xử lý các yêu cầu đã thay đổi khi người dùng đã lưu trữ dữ liệu trị giá một năm mà họ không muốn vứt bỏ?


-1

Từ câu chuyện của bạn, rõ ràng là các yêu cầu và quyết định kiến ​​trúc ưa thích chưa được truyền đạt đủ tốt. Do đó một trong hai bạn, hoặc có thể cả hai, là những người giao tiếp tồi.

Cũng có thể là kiến ​​trúc sư, vì một số kiến ​​trúc sư đạt được vị trí cao vì thành tích tốt khi lập trình một mình, hoặc giáo dục tuyệt vời (đó cũng thường là về học tập một mình), hoặc là nhà phát triển đầu tiên trong công ty (rõ ràng là một mình) và không cần thiết tốt trong giao tiếp với nhóm. Không có gì lạ khi họ tiếp tục tập trung mạnh vào lập trình thay vì tài liệu thiết kế và hỗ trợ nhóm.

Tuy nhiên, trong trường hợp này, bạn có thể cố gắng bù đắp bằng cách nói chuyện lâu hơn, đặt câu hỏi và ghi chú. Bạn thậm chí có thể tự viết một đặc tả nhỏ và yêu cầu kiến ​​trúc sư phê duyệt nó.

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.