Làm thế nào để bạn chuyển đổi một chương trình từ đang phát triển sang phát hành?


67

Tại một số điểm một chương trình đang được phát triển. Các tính năng đang được thêm hoặc xóa hoặc thay đổi mọi lúc. Mỗi phiên bản không có gì ngoài một nguyên mẫu. Vì vậy, tôi không lãng phí nhiều thời gian vào việc viết mã siêu sạch vào thời điểm đó bởi vì tôi không bao giờ biết điều gì đó kéo dài bao lâu. Tất nhiên tôi cố gắng giữ chất lượng mã theo các tiêu chuẩn nhất định, nhưng thời gian luôn là một vấn đề.

Sau đó đến thời điểm chương trình kết thúc và người đưa ra quyết định nói rằng "đó là". Tôi có một nguyên mẫu hoạt động vào thời điểm này, nhưng mã bên trong hơi lộn xộn từ tất cả các lần qua lại trong giai đoạn phát triển. Tôi dự kiến ​​sẽ bắt đầu thử nghiệm / gỡ lỗi cuối cùng nhưng ruột của tôi nói rằng bây giờ tôi nên dọn dẹp và viết lại các công cụ để cung cấp cho nó kiến ​​trúc phù hợp giúp bảo trì vv dễ dàng hơn.

Một khi công cụ đã được kiểm tra và phê duyệt, sẽ không có ý nghĩa gì khi viết lại. Một cách thường xuyên, tôi đang đứng đó với một nguyên mẫu 'đã hoàn thành' đang hoạt động và tôi gặp một lỗi trong quá trình thử nghiệm và tôi thấy rằng đó là kết quả của mã hóa không thông minh, là kết quả của toàn bộ quá trình phát triển. Tôi đang trong giai đoạn thử nghiệm và bản sửa lỗi sẽ được viết lại ... đó là một mớ hỗn độn!

Có những cách tốt hơn / sách giáo khoa, tôi chắc chắn. Nhưng tôi phải làm việc trong một môi trường làm việc thực tế, nơi không phải mọi thứ đều là sách giáo khoa.

Vậy làm cách nào để chuyển đổi nguyên mẫu làm việc của tôi sang phiên bản phát hành với cơ sở mã ổn định? Có lẽ tôi không nên coi sự phát triển đã kết thúc một khi tôi làm và thực sự coi đó là giai đoạn dọn dẹp ... Tôi không biết, tôi cần sự giúp đỡ ở đây.

BIÊN TẬP

Tôi muốn làm rõ một vài điều.

  • Tôi 100% đứng về phía thực hiện nó ngay trước và không sau, mã sạch và dễ đọc. Nhưng tôi cũng phải hoàn thành công việc và không thể mơ về vẻ đẹp của mã sạch sẽ và sáng bóng. Tôi phải tìm một sự thỏa hiệp.

  • thường thì một tính năng mới thực sự chỉ là thứ mà chúng tôi muốn dùng thử và xem liệu nó có hợp lý để thực hiện một cái gì đó như thế này không. (đặc biệt trong các ứng dụng di động, để có được giao diện thực trên thiết bị thực tế) Vì vậy, có một điều nhỏ nhặt mà (imho) không biện minh cho quá nhiều công việc trong lần lặp "hãy xem" đầu tiên. Tuy nhiên, đôi khi câu hỏi đặt ra KHI tôi phải trả tech.debt này? Đó là những gì câu hỏi này là tất cả về.

Nếu tôi biết rằng một nửa các tính năng sẽ bị loại bỏ một ngày sau đó (đủ kinh nghiệm trong công ty của chúng tôi) Tôi thực sự thấy khó tin rằng cách tốt nhất để tiếp cận vấn đề của mình là dù sao hãy đầu tư thêm thời gian để viết mọi thứ ngay cả khi hầu hết sẽ bị loại bỏ ngay sau đó. Tôi cảm thấy rằng tôi sẽ tiết kiệm thời gian nếu tôi thực hiện một lần dọn dẹp lớn một khi điều đó là vững chắc, do đó câu hỏi của tôi.


68
Câu hỏi của bạn là "Tôi tự đào một cái hố; làm thế nào để tôi thoát ra?" Câu trả lời tiêu chuẩn dĩ nhiên là bước một, DỪNG LẠI NỀN TẢNG. Quá trình phát triển của bạn có thể được tóm tắt là "tạo ra một lượng nợ kỹ thuật khổng lồ và sau đó bỏ qua nó khi đến hạn". Nếu đây là một vấn đề, thay đổi quá trình phát triển của bạn. Chỉ kiểm tra mã sạch, làm việc, gỡ lỗi, xem xét cẩn thận đáp ứng đặc điểm kỹ thuật được viết cẩn thận của nó. Đừng mắc nợ và bạn sẽ không phải thoát khỏi nợ nần.
Eric Lippert

11
@NikkyD Nếu bạn không có thời gian để thực hiện đúng, bạn cần có một cuộc trò chuyện với người quản lý của bạn về tác động đến chất lượng của phần mềm. Hiểu những gì mọi người ở đây đang nói với bạn: không đầu tư thời gian lên phía trước đang làm hỏng khả năng làm việc hiệu quả của bạn sau này. Một vấn đề khác mà bạn muốn đưa ra với họ: nếu bạn rời khỏi công ty (hoặc "chạy qua xe buýt"), sẽ rất tốn kém cho các nhà phát triển mới để làm quen với mã. Số tiền họ nghĩ rằng họ đang tiết kiệm bây giờ sẽ trả cho họ sau này.
jpmc26

32
Nếu bạn đang tạo một nhánh tính năng nhỏ để mô phỏng giao diện người dùng được đề xuất cho một tính năng, điều đó thật tuyệt. Làm cho nó nhanh và bẩn như bạn muốn, hiển thị nó cho khách hàng, và sau đó xóa chi nhánh đó . Khi các nhà sản xuất ô tô chế tạo ô tô bằng đất sét và giấy để chế tạo một thiết kế mới, sau đó họ không thử đặt một động cơ vào mô hình đất sét. Quá trình xác định xem tính năng này có đáng để làm hay không. Khi bạn đã quyết định thực hiện tính năng này, hãy đảm bảo rằng bạn đang bắt đầu từ mã sạch và luôn tạo mã sạch, vì mã đó hiện là mã sản xuất .
Eric Lippert

10
"Không thể mơ về vẻ đẹp của mã sạch và sáng bóng" Đây là một sự hiểu lầm cơ bản về "mã sạch" nghĩa là gì. Mã sạch không có nghĩa là bạn dành một buổi chiều để sắp xếp các tab của mình để bạn có thể in mã và đóng khung nó. Mã sạch mã tốt và mã tốt mã sạch. Mã sạch là mã hoạt động đúng, có thể gỡ lỗi và có thể hiểu được. Nếu bạn không có thời gian để viết mã sạch ngay từ đầu, thì bạn chắc chắn không có thời gian để viết mã lộn xộn và sau đó sửa nó sau. Đó chỉ là bao lâu nhiệm vụ.
GrandOpener

8
"Tôi cũng phải hoàn thành công việc và không thể mơ về vẻ đẹp của mã sạch sẽ và sáng bóng. Tôi phải tìm một sự thỏa hiệp." Một sự thỏa hiệp có nghĩa là một nền tảng trung gian "đủ tốt" cho cả hai bên. Nếu mã của bạn lộn xộn - đặc biệt là nếu nó đủ lộn xộn đến mức bạn nghĩ rằng bạn sẽ gặp khó khăn trong việc duy trì nó - thì đó không phải là "đủ tốt", và bạn cần tìm một sự thỏa hiệp tốt hơn.
anaximander

Câu trả lời:


98

Vì vậy, tôi không lãng phí nhiều thời gian vào việc viết mã siêu sạch vào thời điểm đó bởi vì tôi không bao giờ biết điều gì đó kéo dài bao lâu.

Không biết một cái gì đó kéo dài bao lâu sẽ không bao giờ là một cái cớ cho sự chậm chạp - hoàn toàn ngược lại. Mã sạch nhất là IMHO, mã không đi theo cách của bạn khi bạn phải thay đổi thứ gì đó. Vì vậy, khuyến nghị của tôi là: luôn cố gắng viết mã sạch nhất bạn có thể - đặc biệt là khi mã hóa nguyên mẫu. Bởi vì nó sẽ dễ dàng hơn để thích nghi với nó khi một cái gì đó phải được thay đổi (điều chắc chắn sẽ xảy ra).

Đừng hiểu sai ý tôi - sự hiểu biết của tôi về "mã sạch nhất" không liên quan gì đến việc làm cho mã đẹp vì mục đích làm đẹp. Đó thực sự là một cái gì đó có thể làm chậm bạn. Theo quan điểm của tôi, mã sạch là mã mà phần lớn là tự giải thích (không cần phải viết quá nhiều tài liệu - gây tăng tốc), dễ hiểu (ít lỗi hơn, do đó cần ít gỡ lỗi hơn - tăng tốc, cần ít thời gian hơn để tìm đúng nơi để thay đổi - tăng tốc), giải quyết vấn đề nhất định với số lượng mã cần thiết ít nhất (ít mã hơn để gỡ lỗi - tăng tốc rõ ràng), là DRY (chỉ có một nơi để thay đổi khi phải thay đổi - tăng tốc - và ít rủi ro hơn để giới thiệu lỗi mới bằng cách quên thay đổi vị trí thứ hai), tuân theo các tiêu chuẩn mã hóa (những thứ ít cồng kềnh hơn để suy nghĩ - tăng tốc), sử dụng nhỏ,

Tôi dự kiến ​​sẽ bắt đầu thử nghiệm / gỡ lỗi cuối cùng nhưng ruột của tôi nói rằng bây giờ tôi nên dọn dẹp và viết lại các công cụ để cung cấp cho nó kiến ​​trúc phù hợp giúp bảo trì dễ dàng hơn v.v.

Làm "dọn dẹp" sau đó không bao giờ làm việc. Hãy xem xét việc bạn dọn dẹp trước khi bạn triển khai một tính năng mới hoặc khi bắt đầu thực hiện nó, nhưng không phải sau đó. Ví dụ: bất cứ khi nào bạn bắt đầu chạm vào một phương thức cho một tính năng và bạn nhận thấy nó dài hơn 10 dòng, hãy cân nhắc để cấu trúc lại nó thành các phương thức nhỏ hơn - ngay lập tức , trước khi hoàn thành tính năng. Bất cứ khi nào bạn phát hiện ra một biến hoặc tên hàm hiện có mà bạn không biết chính xác ý nghĩa của nó, hãy tìm hiểu xem nó tốt cho cái gì và đổi tên thứ đó trước khi làm bất cứ điều gì khác. Nếu bạn làm điều này thường xuyên, bạn sẽ giữ mã của mình ít nhất ở trạng thái "đủ sạch". Và bạn bắt đầu tiết kiệm thời gian - vì bạn cần ít thời gian hơn để gỡ lỗi.

Tôi đang trong giai đoạn thử nghiệm và bản sửa lỗi sẽ được viết lại

... đó là bằng chứng thực tế cho những gì tôi đã viết ở trên: bị "bẩn" ám ảnh ngay lập tức trở lại với bạn khi bạn bắt đầu gỡ lỗi mã của mình và sẽ khiến bạn chậm hơn.

Bạn có thể tránh điều này gần như hoàn toàn nếu bạn dọn dẹp ngay lập tức. Sau đó, sửa lỗi chủ yếu sẽ có nghĩa là thay đổi nhỏ cho mã, nhưng không bao giờ thay đổi kiến ​​trúc lớn. Nếu bạn thực sự phát hiện bằng chứng cho một cải tiến kiến ​​trúc trong quá trình thử nghiệm, hãy trì hoãn nó, đưa nó vào hệ thống theo dõi vấn đề của bạn và triển khai nó vào lần tới khi bạn phải triển khai một tính năng có lợi từ thay đổi đó ( trước khi bạn bắt đầu với tính năng đó).

Điều này có một số kỷ luật, và một số kinh nghiệm mã hóa, tất nhiên. Đó là một ý tưởng tương tự như ý tưởng đằng sau "phát triển dựa trên thử nghiệm", thực hiện những việc này trước đó thay vì thực hiện chúng sau đó (TDD cũng có thể giúp, nhưng những gì tôi đã viết vẫn hoạt động ngay cả khi bạn không sử dụng TDD). Khi bạn làm điều này do đó, bạn sẽ không cần bất kỳ "giai đoạn làm sạch" đặc biệt nào trước khi phát hành.


40
@NikkyD Các đề xuất của Doc Brown là những thói quen thực sự làm giảm thời gian thực hiện và rất thực tế trong thời gian dài. Hãy suy nghĩ bạn tiết kiệm được bao nhiêu thời gian nếu bạn không cần kiểm tra mã của mình để tìm ra cách không phá vỡ nó mỗi khi bạn cần thay đổi nó . Lợi ích tương tự như thay đổi từ gõ "săn và mổ" sang học cách chạm. Nó có thể mất nhiều thời gian ban đầu, khi bạn đang học, nhưng một khi thói quen ở đó thì tốt hơn không thể phủ nhận và sẽ có lợi cho bạn trong phần còn lại của sự nghiệp. Nếu bạn chọn không thử, bạn sẽ không bao giờ đến đó.
Daniel

44
@NikkyD: Nó không làm mờ khung thời gian. Khung thời gian đã bị đầy hơi; bạn chỉ không giải thích cho sự phình to khi bạn viết phần mềm và mắc nợ kỹ thuật mà bạn đã dự trù ngân sách.
Eric Lippert

7
@NikkyD: Tôi giới thiệu với bạn Thần tượng với Bàn chân đất sét và khái niệm Nợ kỹ thuật . Cái trước có nghĩa là bạn có thể xây dựng phần mềm âm thanh trên nền tảng rung lắc, cái sau là về "sự quan tâm" (chi phí tăng thêm) được trải nghiệm bởi các tính năng mà bạn cố gắng giải quyết khi cấu trúc không có âm thanh.
Matthieu M.

10
@NikkyD: không, tôi đề nghị viết mã của bạn tương tự như cách một chuyên gia bi-a chơi bóng của anh ấy: mỗi cú đánh có vẻ đơn giản cho người ngoài, vì sau khi quả bóng dừng lại ở vị trí cho một "cú đánh đơn giản" mới. Và trong môn bi-a hoặc mã hóa, việc này cần vài năm luyện tập ;-)
Doc Brown

16
@NikkyD: theo kinh nghiệm của tôi, khi "thêm một tính năng nhỏ đòi hỏi nhiều phép tái cấu trúc" thì mã đã là một mớ hỗn độn và nhu cầu "rất nhiều phép tái cấu trúc" xuất phát từ thực tế bạn cần thay đổi một hàm hoặc lớp mà bạn đã làm không giữ đủ sạch trong quá khứ. Đừng để mọi thứ đi quá xa. Nhưng nếu bạn ở trong tình huống đó, hãy tìm một sự thỏa hiệp. Ít nhất là tuân theo "quy tắc tẩy chay" và để lại mã ở trạng thái tốt hơn so với trước khi bạn thêm tính năng này. Vì vậy, ngay cả khi tính năng đã bị xóa vào tuần tới, mã phải ở trạng thái tốt hơn so với trước đây.
Doc Brown

22

Bạn có hai vấn đề riêng biệt, cả hai đều có cùng một triệu chứng (mã cẩu thả):

Vấn đề # 1: Kiểm soát yêu cầu không đầy đủ Tôi không có nghĩa là các bên liên quan của bạn thay đổi yêu cầu của bạn quá thường xuyên, ý tôi là bạn đang cho phép các yêu cầu thay đổi trong chu kỳ kiểm tra lỗi / lỗi. Ngay cả các phương pháp nhanh cũng không hỗ trợ điều đó; bạn xây dựng, bạn kiểm tra, bạn cung cấp, bạn tiêm yêu cầu mới.

Vấn đề # 2: Bạn tin rằng những thứ bạn viết là "ngay bây giờ" Trong phát triển phần mềm "ngay bây giờ" mã thực sự rất hiếm. Bạn đã nhận thấy rằng một khi bạn đã thỏa mãn yêu cầu của người dùng, sự khắt khe về cung và cầu khiến cho việc chứng minh trở lại và thực hiện lại một tính năng "đã hoàn thành" rất khó khăn. Vậy giờ làm gì với nó? Luôn viết mã sản xuất. Về mặt chức năng đối với bạn, điều đó có nghĩa là ước tính của bạn cho các bên liên quan của bạn cần phải lớn hơn đáng kể để bạn có thời gian thực hiện đúng.

Ngoài ra, xin vui lòng hiểu rằng bạn đang làm việc ở vị trí khó khăn nhất với tư cách là nhà phát triển: Đọc Joel Spolsky đảm nhận cuộc sống của một nhà phát triển nội bộ . Vì vậy, bạn cần phải hết sức cảnh giác nếu bạn muốn tiếp tục với sự tỉnh táo của mình.


21

Đây là một vấn đề phổ biến - đặc biệt là khi chế tạo những gì thực chất là một quả bóng dùng thử phần mềm .

Có một số cách tiếp cận có thể giúp đỡ. Đầu tiên, cách tiếp cận TDD có thể giúp giảm cơ sở mã theo yêu cầu nghiêm ngặt. Nếu các bài kiểm tra của bạn đi đôi với mã của bạn, thì ít nhất bạn có thể tin tưởng rằng mã của bạn hoạt động như bình thường.

Hãy dành thời gian để tái cấu trúc khi bạn đi. Một khi bạn có một nguyên mẫu và khách hàng cực kỳ háo hức để có được bàn tay của họ, thật khó để nói rằng bạn cần thời gian để đánh bóng những gì (với họ) là hoàn thành. Tôi muốn kiểm tra hàng ngày sau đó là kiểm tra tái cấu trúc nhưng YMMV.

Các nhà phát triển viết mã nhanh chóng thường có nhu cầu - chúng tôi đã có một nhà phát triển như vậy trong bộ phận cuối cùng của tôi. Mọi đội đều muốn anh ấy vì anh ấy làm việc siêu nhanh. Khi thời gian đến để kiểm tra và phát hành mã của anh ấy, các bánh xe nhanh chóng tắt. Công cụ mã hóa cứng, hack và phím tắt ở khắp mọi nơi. Cổ phiếu của ông sớm giảm - ồ ạt.

Việc cắt mã sản xuất ngay từ đầu có vẻ giống như một lực cản nhưng tùy thuộc vào môi trường của bạn, có nhiều công cụ có thể giúp bạn phát triển như GhostdocStylecop .

Đó là giá trị nhận được trong tư duy phát triển đúng ngay từ đầu. Bạn sẽ ngạc nhiên khi có bao nhiêu hệ thống hỗ trợ được coi là giải pháp ngăn chặn trở thành ứng dụng nền tảng.


Bạn có nghĩa là mọi giải pháp khoảng cách dừng từng được viết, phải không?
RubberDuck

4
Một điểm tuyệt vời về sự biện minh cho khách hàng. Tôi có nhiều kinh nghiệm với những khách hàng nghĩ rằng khi GUI xuất hiện, ứng dụng cũng được thực hiện. Tôi đã học cách làm cho GUI trông không hoàn chỉnh trong khi mã ở chế độ nền chưa sẵn sàng và do đó, chỉ làm cho những gì khách hàng nhìn thấy được đánh bóng khi mã (và logic nghiệp vụ). Thật khó để giải thích rằng những gì có vẻ đã hoàn thành cho khách hàng vẫn sẽ mất một hoặc hai tháng để thực sự giao hàng.
Luaan

11

Liên tục

Tốc độ phát triển là lý do chính để viết mã sạch, dễ đọc và kiểm tra được; nó không được thực hiện cho vẻ đẹp, cũng không phải các giá trị trừu tượng khác. Tại sao tôi lại phủ nhận điều đó với chính mình và chỉ làm điều đó sau đó cho một số lập trình viên tương lai?

Chắc chắn có thể có những thay đổi chủ yếu là mỹ phẩm và do đó không cần thiết; Tôi cho rằng việc sử dụng mã đẹp vừa phải sẽ hữu ích hơn rất nhiều ngay bây giờ, trong quá trình phát triển, hơn là có một mớ hỗn độn ngay bây giờ và hy vọng làm cho nó hoàn hảo sau này (điều này, hãy đối mặt với nó, nó sẽ không bao giờ xảy ra, ngay cả khi bạn đã có thời gian).


6
+1 và theo quan điểm cá nhân, tôi thấy quá khó khăn để thay đổi bánh răng từ việc hack các dự án cá nhân tại nhà và viết mã sản xuất trong công việc hàng ngày của tôi. Viết mã chuyên nghiệp trong các dự án sở thích của tôi đã trả cổ tức ngay lập tức - mã dễ đọc hơn và có ít lỗi hơn rất nhiều.
Robbie Dee

Một lý do sẽ không bao giờ xảy ra là bạn (tốt hơn) trở nên tốt hơn với những gì bạn làm theo thời gian. Vì vậy, nếu bạn chờ đợi nửa năm để "dọn dẹp" thứ gì đó, bạn sẽ không chỉ quên tất cả các minutae cần thiết để dọn dẹp một cách an toàn, bạn cũng sẽ trở thành một lập trình viên tốt hơn trước đây và bạn có thể sẽ bị cám dỗ chỉ cần ném mọi thứ đi và bắt đầu lại. Và vì đó là rất nhiều công việc (và thường là một ý tưởng tồi), có lẽ bạn sẽ bỏ qua việc dọn dẹp một lần nữa.
Luaan

"Tại sao tôi lại phủ nhận điều đó với chính mình và chỉ làm điều đó sau đó cho một số lập trình viên tương lai?" Mặc khải! Và đoán xem? Bạn đôi khi (và đôi khi, thường xuyên) là lập trình viên tương lai.
radarbob

@RobbieDee, Quan sát siêu hạng! Trong một cuộc phỏng vấn, Malcom Gladwell - người đã đưa "quy tắc 10.000 giờ" vào nhận thức phổ biến (trong cuốn sách Outliers ) - nói rằng đó phải là "thực hành có chủ ý" hoặc nó chỉ lãng phí thời gian. Có nghĩa là tập trung vào cải tiến, thực hành các chi tiết cụ thể với mục đích cải thiện khía cạnh cụ thể đó của một kỹ năng, v.v.
radarbob

@ThanosTintinidis, sau đó có vấn đề "không có hành động tốt không bị trừng phạt". Đã viết mã sạch như vậy, chắc chắn ai đó sẽ làm hỏng nó. Đảm bảo bạn là người đánh giá mã khi có người khác chạm vào mã sạch của bạn. Một phương pháp được thêm vào đơn giản đã thổi bùng sự đóng gói và kết hợp thậm chí được ghi lại thành dòng . Tôi đã tức giận trong một tuần; và một năm sau, mỗi lần tôi thấy mã đó.
radarbob

4

Bạn làm điều này bằng cách phân biệt giữa mã "Tôi chỉ đang thử điều này để xem mã hoạt động như thế nào" và mã "điều này được đưa vào sản phẩm". Có một số cách để làm điều đó.

Một là phân nhánh hoặc bất cứ từ nào trong hệ thống kiểm soát nguồn của bạn. Bạn tạo một nhánh cho báo cáo mới hoặc bố cục nhập mới hoặc bất cứ điều gì. Nếu mọi người thích nó, công việc đưa nó trở lại vào chi nhánh chính là một công việc riêng biệt, có thể theo dõi. Nó có thể được chỉ định cho ai đó và được báo cáo và không mong muốn chỉ xảy ra một cách kỳ diệu việc quản lý (hoặc bán hàng) đồng ý rằng tính năng này thuộc về sản phẩm.

Một cái khác là gai. Bạn không làm điều đó thay đổi trong sản phẩm. Bạn đi vào một số ứng dụng riêng biệt, siêu đơn giản, chỉ tồn tại để bạn có một nơi để đặt mã. Bạn có thể lộn xộn như bạn muốn bởi vì bạn chỉ đang khám phá API mới hoặc bất cứ điều gì. Và một lần nữa, nếu bạn quay lại và báo cáo "có, chúng tôi có thể làm điều đó, tôi đã tìm ra cách" có một nhiệm vụ có thể theo dõi, có thể báo cáo, có thể phân công là viết mã sẵn sàng cho sản phẩm để làm những gì bạn muốn.

Trong cả hai trường hợp, sản phẩm sẵn sàng có nghĩa là dễ đọc, gọn gàng, tuân theo các tiêu chuẩn đặt tên, với các bài kiểm tra và tuân thủ phong cách mã và các mục tiêu hiệu suất của bạn. Trong cả hai trường hợp, bạn làm cho công việc đó hiển thị. Tôi đồng ý rằng bạn không muốn thực hiện tất cả công việc đó mỗi khi ai đó có khả năng loại bỏ tính năng này ra khỏi sản phẩm. Nhưng bạn cũng không muốn để công việc đó trở nên vô hình. Làm việc trong các bản sao riêng biệt của sản phẩm hoặc trong một sản phẩm không liên quan nhiều hơn một khai thác thử nghiệm cho phép bạn thể hiện công việc để tạo mã sẵn sàng cho sản phẩm một khi ai đó quyết định họ muốn thứ gì đó.

Nhược điểm là họ không thể quyết định họ muốn một cái gì đó và gửi nó (có nghĩa là phiên bản nửa khẳng định, lộn xộn, chưa được kiểm chứng, không có giấy tờ, có thể chậm mà bạn đã triển khai như một bằng chứng về khái niệm) vào ngày mai. Lần đầu tiên bạn nhận được phản hồi ở mặt trước đó, chỉ cần hỏi xem bạn có nên thực hiện theo cách lâu dài (đắt tiền hơn) chỉ trong trường hợp, làm chậm đường dẫn đến các tính năng bị từ chối. Nếu bạn hỏi chính xác, bạn sẽ nhận được "không".


1

Thực sự tôi nghĩ bạn đã hiểu vấn đề rồi. Vấn đề là phong cách mã hóa của bạn đang đòi hỏi bạn phải làm lại quá nhiều. Lý do cần phải làm lại quá nhiều là vì (a) nó được đặt cùng với tầm nhìn và kế hoạch không đủ và (b) các bản vá ngắn hạn gia tăng thường xuyên được đưa vào trong quá trình phát triển kết hợp làm tăng độ phức tạp của bất kỳ việc làm lại nào.

Do đó, câu trả lời là

(a) thay đổi phong cách phát triển của bạn hơn một chút về phía thác nước và nhanh nhẹn hơn một chút. Đừng đi hết con đường này, vì thác nước cổ điển có những cạm bẫy riêng. Có một sự cân bằng lành mạnh để có được. Tôi biết đôi khi có thể liên quan đến việc chỉ nghĩ về những thứ trong vài ngày, giống như không có sự phát triển nào được thực hiện, nhưng bạn phải tin tưởng vào quá trình này. Trong kỹ thuật, bạn không thể đóng đinh mọi thứ lại với nhau và sau đó đóng đinh lên trên và hy vọng đưa ra một giải pháp thanh lịch. Nếu không có ai làm kiến ​​trúc và thiết kế kỹ thuật cấp cao hơn, điều đó có nghĩa là công việc của bạn. Bạn đã phải trả giá khi bỏ bê công việc đó.

(b) cố gắng tránh vá những thứ trên. Đừng nghĩ dài hạn chỉ khi đến lúc phải làm QA. Thực sự bạn nên kiểm tra mọi phần nhỏ bạn xây dựng mọi lúc và bao gồm tất cả các trường hợp đầu vào, những trường hợp không nằm trên đường hạnh phúc. Một bản vá / hack gần như theo định nghĩa là một bản sửa lỗi ngắn hạn, có thể có chi phí dài hạn, đánh vào khách hàng Tổng chi phí sở hữu trong hệ thống. Một lần nữa, áp lực phải lấy mã ra, do đó phải có sự cân bằng. Nhưng cố gắng không đặt các bản sửa lỗi ngắn hạn tại chỗ, đặc biệt. những thành phần kết hợp chặt chẽ mà thực sự nên được ghép lỏng lẻo. Sẽ có công việc lại, vì vậy hãy làm nó SỚM để làm cho nó dễ dàng hơn nhiều, để tránh các bản hack và bản vá sẽ gắn kết theo thời gian và trở nên không thể quản lý được.


2
Chỉ cần một lưu ý - nhanh nhẹn không có nghĩa là "thay đổi thường xuyên mà không suy nghĩ" hoặc "thiết kế ít hơn". Trên thực tế, tôi thấy rằng nhanh nhẹn đòi hỏi thiết kế nhiều hơn nhiều so với những gì mọi người thường gọi là thác nước. Việc thiếu thiết kế tốt là một trong những lý do thác nước không hoạt động tốt trong thực tế - nếu bạn thực sự đầu tư vào thiết kế đúng cách, nó sẽ hoạt động tốt; nó cũng đắt hơn nhiều so với nhanh nhẹn. Nếu bạn bỏ qua phần thiết kế một cách nhanh nhẹn, bạn chỉ cần kết hợp mã với nhau, và điều đó sẽ không hoạt động tốt hơn bất kỳ thực hành nào khác tránh thiết kế.
Luaan

Sự tập trung nhanh nhẹn ở những dòng máy ngắn, chạy nước rút vv, nhận được nguyên mẫu ra nhanh chóng, nhất thiết phải gây áp lực thêm về bỏ đủ thiết kế lên phía trước
Brad Thomas

Không, nó tập trung vào việc thiết kế các bộ phận nhỏ hơn. Nhưng nhìn chung, bạn phải thiết kế rất nhiều, nếu không bạn sẽ tạo ra một sản phẩm khủng khiếp. Điều quan trọng là làm cho mọi thứ nhỏ và được thiết kế tốt, cũng có thể thay thế cho nhau. Nếu bạn thiết kế ít nhanh nhẹn hơn, bạn đang tự làm cho mình (và khách hàng của mình) một sự bất đồng. Lặp lại ngắn là lợi ích của việc sử dụng nhanh, không phải là điều kiện tiên quyết hoặc chỉ là một phần của quy trình - một khi bạn nhận được mọi thứ đủ tốt, bạn có thể bất ngờ mua các lần lặp ngắn, không phải cách khác.
Luaan 11/03/2016

Đặt trọng tâm hơn vào việc thiết kế các bộ phận nhỏ hơn là một vấn đề lớn, khi thực sự bức tranh lớn hơn thường là nguyên nhân quan trọng nhất của việc làm lại. Tôi đã thấy lãng phí nhiều tiền hơn cho việc kinh doanh đột ngột nói rằng "nhưng chúng tôi cần nó để làm điều này", điều đó đòi hỏi một cuộc đại tu rộng khắp mà tôi từng thấy trong sự thay đổi thiết kế của một thành phần nhỏ được ghép lỏng lẻo
Brad Thomas

Có, nhưng đến thời điểm đó bạn đã mất (và bất kể bạn đang cố gắng nhanh nhẹn hay thác nước). Khi "bức tranh lớn" của bạn gồm nhiều phần nhỏ tương đối biệt lập, đại tu duy nhất trên phạm vi rộng bạn nhận được là khi bạn cần thay thế khá nhiều thứ. Cách tiếp cận nào không khiến bạn mất tất cả khi bạn cần bắt đầu lại từ đầu? Ngay cả các cấp độ thiết kế của NASA cũng dẫn đến một lần "chúng ta cần thay đổi mọi thứ". Bằng cách giữ cho mình linh hoạt và dễ thích nghi, bạn sẽ có được không gian cơ động hơn cho việc thay đổi chỗ ở, dù nhỏ hay lớn.
Luaan 11/03/2016

0

Bạn viết:

Mỗi phiên bản không có gì ngoài một nguyên mẫu. Vì vậy, tôi không lãng phí nhiều thời gian vào việc viết mã siêu sạch vào thời điểm đó bởi vì tôi không bao giờ biết điều gì đó kéo dài bao lâu. ...

Sau đó đến thời điểm chương trình kết thúc và người đưa ra quyết định nói rằng "đó là". Tôi có một nguyên mẫu hoạt động vào thời điểm này, nhưng mã bên trong hơi lộn xộn từ tất cả các lần qua lại trong giai đoạn phát triển.

Phiên bản đăng ký có thể là "nguyên mẫu" ở chỗ nó thiếu các tính năng hoặc một số tính năng không được bổ sung, nhưng tất cả các mã được kiểm tra phải là mã chất lượng sản xuất không cần phải dọn sạch.

Tôi nghĩ rằng bạn đang trì hoãn bạn "dọn dẹp" nhiều.

Nguyên tắc của tôi là:

  • Bắt đầu với tính năng (phụ)
  • cảm thấy thoải mái khi viết những thứ không đầy đủ và không đầy đủ, có thể một số c & p để cảm nhận về những gì tôi đang thực hiện hoặc nếu tôi phải cào nát (các) giờ mã hóa cuối cùng (lưu ý rằng điều này có thể đi đôi với TDD / bài kiểm tra, chỉ là mọi thứ được làm dịu đi một chút để có được phản hồi nhanh về không gian triển khai mà tôi đang khám phá)
  • Tính năng phụ "hoạt động" đủ tốt cho bây giờ
  • Bây giờ làm sạch: trước một cam kết SCC .
    • Nhìn qua mã để xem những gì rõ ràng
    • Thực hiện một khác biệt so với cam kết cuối cùng để xem xét các thay đổi và có thể gặp một số vấn đề
    • Khắc phục sự cố tôi ghi chú trên Scratchpad của tôi
  • Bây giờ tôi thực hiện cam kết - chất lượng mã này đã sẵn sàng để giao

Tại thời điểm này, mã đã cam kết vẫn có thể chứa một số cách giải quyết hoặc "nợ kỹ thuật" rằng sẽ rất tốt để dọn sạch và có thể tôi sẽ xóa nó khi đó là điều tự nhiên phải làm cho một tính năng phụ sau, nhưng nó sẽ ổn nếu mã đó được phát hành.

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.