Phương pháp sửa lỗi mã (Tình huống ác mộng)


16

Tôi thường xuyên được giao nhiệm vụ gỡ lỗi một ứng dụng trong công việc của tôi. Đó là Ứng dụng BI mà chúng tôi triển khai cho các doanh nghiệp, bao gồm môi trường thử nghiệm và môi trường sản xuất. Tôi tự hỏi nếu có bất kỳ ứng dụng / công cụ / phương pháp nào mà mọi người có thể đề xuất, dựa trên các ràng buộc sau:

  1. Trình gỡ lỗi không thể được sử dụng trên trang web của khách hàng hoặc cục bộ, vì phần mềm phụ thuộc vào các ứng dụng bên thứ ba tùy chỉnh mà chúng tôi không có môi trường thử nghiệm. (EDIT: để công bằng, có thể gỡ lỗi cục bộ trong một số trường hợp. Nếu chúng tôi không sử dụng gì ngoài mã lõi. Phần lớn mã có vấn đề nằm trong một dll đóng gói giao tiếp cụ thể của bên thứ ba: ổ cắm, đường ống xử lý, cuộc gọi xà phòng, logic tùy chỉnh thay đổi hành vi của mã lõi. Thông thường trong quá trình triển khai hoặc nâng cao cho máy khách, chúng tôi sẽ viết mã mới cho khu vực này.)

  2. Hầu như không có đăng nhập được thực hiện trong các ứng dụng của chúng tôi. Không có bài kiểm tra đơn vị.

  3. Kiểm soát phiên bản chỉ có 1 phiên bản của giải pháp đầy đủ (sử dụng nguồn safe 2005). Vì vậy, không thể có được phiên bản trước của toàn bộ giải pháp, chỉ có các tệp riêng lẻ. (Trừ khi ai đó biết cách xung quanh này).

  4. Không thể sao chép cục bộ, thường không thể sao chép trên môi trường thử nghiệm (Khả năng cao là thử nghiệm và sản xuất không phải là cùng một phiên bản).

  5. Có khả năng cao là phiên bản máy khách đang sử dụng khác với phiên bản nguồn an toàn. Điều này là do các tệp riêng lẻ được cập nhật, có nhúng logic tùy chỉnh cho máy khách cụ thể đó. Thông thường những gì xảy ra là một bản cập nhật được thực hiện thành nhị phân, yêu cầu thay đổi một số nhị phân khác, nhưng khi một cam kết được thực hiện, không ai có bất kỳ hồ sơ hoặc kiến ​​thức nào về việc này. Một lỗi khá phổ biến tôi thấy là 'Không tìm thấy Hàm / Phương thức' hoặc 'Cuộc gọi phương thức có quá nhiều / quá ít tham số được chỉ định' trên môi trường máy khách.

  6. Đây là một giải pháp VB .net

  7. Không thể cài đặt bất kỳ phần mềm nào trên các trang web của khách hàng, nhưng có thể cục bộ

  8. Ứng dụng của chúng tôi cực kỳ tùy biến, nhưng thật không may, logic tùy biến được trải rộng trên tất cả các lớp và tệp, từ mặt trước cho đến lớp dữ liệu, bao gồm các thay đổi tùy chỉnh được thực hiện cho cơ sở dữ liệu trên cơ sở từng máy khách.

  9. Hầu như không có ý kiến ​​trong mã. Không có tài liệu về kiến ​​trúc. Không có tài liệu về api. Điều duy nhất chúng ta có là hàng trăm trên hàng trăm chuỗi email giải thích phần nào những gì đang diễn ra. Những người duy nhất biết mã là những người ban đầu đã viết nó, nhưng họ không còn là nhà phát triển mỗi lần nói nữa nên họ không tham gia nhiều như vậy.

Và trước khi bạn nói điều đó ... vâng tôi biết; Tôi muốn tự bắn mình. Điều đó không giúp ích gì cho việc có mã spaghetti, hàng trăm cảnh báo về trình biên dịch và tính đa hình bị hỏng mà THỰC SỰ nên được sửa, nhưng tôi không có tiếng nói trong đó.

Các loại lỗi phổ biến nhất mà tôi gặp phải là lỗi tham chiếu null, không hợp lệ và thiếu chức năng / chữ ký hàm thiếu. Đôi khi tôi may mắn và người xem sự kiện sẽ ghi nhật ký lớp, phương thức và thông báo ngoại lệ. Nó không phải là hữu ích nhất, nhưng nó vẫn là một cái gì đó. Tệ nhất là các lỗi không có dấu vết, không có các bước repro bên cạnh ảnh chụp màn hình và là các thông báo lỗi chung giống như các lỗi được đề cập ở trên. Đôi khi không thể tìm hiểu lý do tại sao chúng xảy ra, chỉ để cầu nguyện rằng môi trường không được cấu hình đúng, và nó sẽ biến mất sau đó.

Tôi biết điều này xảy ra như một chút giận dữ, và ở một mức độ nào đó nó là. Nhưng tôi đang tuyệt vọng cho các lựa chọn. Có phương pháp / công cụ nào khác tôi có thể sử dụng không?


43
Bạn có sơ yếu lý lịch không?
Robert Harvey

5
+1 cho "Tôi cũng muốn tự bắn mình". Nguồn An toàn 2005, ouch. Chà, ít nhất bạn nên 'tập trung' vào bài học lịch sử tuyệt vời - về cơ bản bạn là người du hành thời gian! Bạn sẽ học được những bài học của một thập kỷ kiến ​​thức được phát triển cẩn thận về "vì vậy đây là lý do tại sao chúng ta không làm điều đó nữa". Thần tốc, châu chấu.
BrianH

7
Đưa ra yêu cầu số 1, cách duy nhất để có hiệu quả trong việc gỡ lỗi mớ hỗn độn này là phải thấu thị. Nghiêm túc mà nói, không có viên đạn ma thuật nào sẽ tạo ra thứ này ngoại trừ một crapshoot. Trong một số cách, điều này sẽ giảm bớt áp lực cho bạn, vì việc gỡ lỗi nhất thiết phải là vấn đề may mắn. Hoặc là quản lý của bạn sẽ ra lệnh cho bạn được may mắn? Rõ ràng điều này không bền vững, vì vậy bạn nên tìm kiếm các cơ hội khác.
Charles E. Grant

14
Đây là một số lời khuyên nghề nghiệp thực tế: Dành quá nhiều thời gian trong một ngôi nhà có các thực hành kỹ thuật phần mềm khủng khiếp và bạn có thể sẽ bị quản lý đổ lỗi vì là một nhà phát triển tồi cho các vấn đề chắc chắn xảy ra. Tôi đã từng ở đó và tôi chắc chắn những người khác cũng vậy. Rất, rất tốt, nó dẫn đến thói quen phát triển xấu.
Gort Robot

2
Làm thế nào tôi quản lý những tình huống này: nếu tôi không được trả lương cao trên thị trường, tôi sẽ đi tìm việc khác để làm.
kevin cline

Câu trả lời:


22

Lời khuyên của Robert Harvey có khả năng là tốt nhất, nhưng vì lời khuyên về nghề nghiệp không có chủ đề, tôi sẽ đưa ra câu trả lời nào có thể được đưa ra:

Bạn đang ở dưới cùng của một ngọn núi rất dốc được bao phủ trong những đống gạch và bùn và những con dê núi khó chịu. Không có cách nào dễ dàng lên. Nếu bạn muốn lên đỉnh, bạn phải cố gắng tiến lên từng bước cực kỳ đau đớn.

Có vẻ như bạn biết chính xác mọi thứ nên hoạt động như thế nào . Nếu không ai khác sẽ giúp bạn sau đó (một lần nữa, bỏ qua lời khuyên nghề nghiệp), lựa chọn duy nhất của bạn là bắt đầu tự sửa những thứ này.

Đầu tiên, đối với tất cả những gì là thần thánh, hãy lấy những thứ đó trong một hệ thống kiểm soát phiên bản thực . Khá nhiều thứ, nhưng Source Safe, vốn nổi tiếng là một đống rác hôi thối. gitlà miễn phí và có thể được thiết lập khá dễ dàng. Bạn không thể khắc phục các sự cố trong quá khứ thiếu kiểm soát phiên bản, nhưng ít nhất ngăn vấn đề tiếp tục trong tương lai.

Tiếp theo, xem xét đăng nhập. Tìm, hoặc trường hợp xấu nhất, viết một hệ thống đăng nhập và bắt đầu sử dụng nó. Sử dụng một cái có thể được sử dụng trên các trang web của khách hàng, vì vậy khi mọi thứ đi ngang bạn có ít nhất một cái gì đó.

Và bắt đầu viết bài kiểm tra, ít nhất là cho những thay đổi mới mà bạn thực hiện.

Không có lớp phủ đường nào: không có câu trả lời nào ở đây mà không liên quan đến nhiều công việc, hoặc coi đây là một câu hỏi về sự nghiệp.


Tin tôi đi, tôi không muốn gì hơn là thêm các xác nhận, bảo vệ và ghi nhật ký, có thể viết lại lớp dữ liệu (Tôi đang viết một trình xác nhận cấu hình để chẩn đoán các vấn đề cấu hình điển hình). Thật không may, nó không phụ thuộc vào tôi. Tôi có thể đưa ra yêu cầu để có thứ gì đó được đưa vào nguồn an toàn, nhưng phản hồi điển hình là 'ý định của bạn là tốt, nhưng đây không phải là thứ chúng ta nên tập trung vào'. Than ôi, tôi nhưng một thiếu niên với 1/2 năm kinh nghiệm. Tôi sẽ leo lên ngọn núi này một lúc.
Igneous01

9
@ Igneous01 Thành thật mà nói, hãy cố gắng tìm một ngọn núi khác để leo lên. Điều kiện làm việc ở những nơi khác có thể không hoàn hảo, nhưng tôi đoán ít nhất là tốt hơn đáng kể so với những gì bạn đang trải qua. Nếu những người gác cổng của bạn từ chối các cải tiến của bạn với "đây không phải là điều chúng tôi nên tập trung vào", đó là quyết định của họ và họ sẽ gặt hái kết quả của chính sách thất bại đó (họ đã mất hàng tấn tiền vì mất thời gian phát triển) . Câu hỏi là, bạn có muốn gắn bó với họ cho đến khi họ làm không?
cmaster - phục hồi monica

6
Và hãy nhớ rằng khi các chính sách tồi thất bại, mọi người tham gia đều có vẻ xấu, ngay cả những người không đồng ý.
Gort Robot

1
Yup, bắt đầu đăng nhập và truy tìm. Cũng bắt đầu tài liệu, và thêm ý kiến. Từng chút một, tất cả sẽ cộng lại. Ngoài ra, bạn nói rằng bạn đủ may mắn để vẫn có một số lập trình viên gốc trong công ty, nếu không phải là nhóm. Đẩy quản lý để nhận được accecss cho họ Nếu có thể, hãy thuyết phục họ rằng họ muốn tạo ra một số tài liệu hơn là liên tục tiếp cận với các câu hỏi.
Mawg nói rằng phục hồi Monica

4
@ Igneous01: Chạy đi, đừng đi bộ. Nơi này bị bệnh và sẽ làm cho bạn bị bệnh.
Phục hồi Monica - M. Schröder

8

1) Trình gỡ lỗi không thể được sử dụng trên trang web của khách hàng ...

Điều đó hoàn toàn bình thường.

... hoặc cục bộ

Bây giờ đó là một vấn đề.

2) Hầu như không có đăng nhập được thực hiện trong các ứng dụng của chúng tôi.

Ghi nhật ký gỡ lỗi sản xuất.

Không có bài kiểm tra đơn vị.

Trời ơi. Tất cả để phổ biến, mặc dù.

3) Kiểm soát phiên bản chỉ có 1 phiên bản của giải pháp đầy đủ

Sau đó, bạn không sử dụng Kiểm soát phiên bản.

4) Không thể sao chép cục bộ, thường không thể sao chép trên môi trường thử nghiệm (Khả năng cao là thử nghiệm và sản xuất không phải là cùng một phiên bản).

Vì vậy, chỉ có triển khai, môi trường máy khách hiển thị các lỗi.

Trong trường hợp đó, bạn cần ghi nhật ký không xác định được nhúng trong mã ứng dụng rằng (a) bẫy và [đầy đủ] ghi lại các lỗi [gây tử vong] và (b) có thể được "quay số" theo yêu cầu để tạo ra các chẩn đoán bổ sung, liên tục, hữu ích trong theo dõi (các) vấn đề.

5) Có nhiều khả năng phiên bản máy khách đang sử dụng khác với phiên bản nguồn an toàn.

Một lần nữa, bạn không sử dụng kiểm soát phiên bản để lợi thế của bạn.

8) Ứng dụng của chúng tôi cực kỳ tùy biến

Đó là khá điển hình.

Sự khác biệt cụ thể theo trang web phải được quản lý thông qua Kiểm soát phiên bản "Phân nhánh".

9) Hầu như không có ý kiến ​​trong mã.

Một lần nữa, đó là tất cả quá phổ biến, bởi vì Nhà phát triển viết mã "tự viết tài liệu", phải không?
Hoặc, ít nhất, mã mà họ hiểu vào ngày họ viết nó.

Không có tài liệu về kiến ​​trúc.

Trời ơi.

Không có tài liệu về api.

Trời ơi, trời ơi.

Và trước khi bạn nói điều đó ... vâng tôi biết; Tôi muốn tự bắn mình.

Không; bạn muốn bắn những người đã viết tất cả những thứ này, tạo ra một mớ hỗn độn không có giấy tờ và sau đó chuyển sang đồng cỏ mới, để lại những mớ hỗn độn vô thức phía sau họ.

Các loại lỗi phổ biến nhất mà tôi gặp phải là lỗi tham chiếu null, không hợp lệ và thiếu chức năng / chữ ký hàm thiếu.

Tài liệu tham khảo Null và phôi không hợp lệ là lỗi thời gian chạy; ở một mức độ nào đó, bạn nên mong đợi họ và thực tế họ đang nhận được chúng thường xuyên cho thấy sự thiếu lập trình phòng thủ (hoặc sự dư thừa của sự lạc quan) của các tác giả ban đầu.

Chữ ký chức năng không phù hợp sẽ gây ra một bản dựng bị hỏng ; những thứ đó sẽ gây ra "các bản dựng bị hỏng" và không bao giờ được đưa ra khỏi cửa!


2
"Luôn luôn mã như thể người cuối cùng duy trì mã của bạn là một kẻ tâm thần bạo lực, người biết bạn sống ở đâu"
PerryC

Lỗi thời gian chạy được gây ra nhiều hơn bởi sự thiếu hiểu biết hơn là thiếu lập trình phòng thủ. Lập trình phòng thủ chỉ là một cách để che giấu thực tế là mã không hoạt động.
dùng253751

1
"Không có tài liệu về kiến ​​trúc" thường có nghĩa là "không có kiến ​​trúc" ...
gnasher729

The site-specific differences should be managed through Version Control "Branching".- Tôi không nghĩ rằng đây là cách tốt nhất để tiến hành. Sử dụng các tệp cấu hình và các tính năng bật tắt dường như phổ biến hơn và dễ lý do hơn.
sixtyfootersdude

5

Bắt đầu với việc đăng nhập. Điều này sẽ có tác động lớn nhất. Triển khai khung đăng nhập vào cơ sở mã, như Log4Net hoặc tương tự. Bắt đầu đăng nhập những gì mã làm.

Gỡ lỗi nên có thể cục bộ. Nếu không, hãy lấy các tệp biểu tượng (PDB) để bạn có thể gỡ lỗi vào các dll của bên thứ 3 để có được một bức tranh hoàn chỉnh về các vấn đề đang xảy ra. Các công cụ như WINDBG có thể chỉ ra các DLL nào có vấn đề nếu hệ thống gặp sự cố. Người ta có thể cấu hình bất kỳ máy chủ nào để xử lý bộ nhớ khi có sự cố. Về cơ bản, đây là ảnh chụp nhanh những gì đang xảy ra khi sự cố xảy ra. Người ta có thể kiểm tra các bãi rác tại địa phương để tìm manh mối cho những gì đang xảy ra. Nếu không thể gỡ lỗi, hãy làm cho nó có thể. Tài liệu các bước cần thiết để gỡ lỗi. Đôi khi trên các hệ thống phức tạp, có khá nhiều thiết lập cần thiết để gỡ lỗi hoàn toàn.

Theo dõi lỗi ... Nếu bạn không sử dụng một, hãy bắt đầu sử dụng một. Điều này đi đôi với một hệ thống kiểm soát phiên bản thích hợp. Về cơ bản, bắt đầu theo dõi lỗi và sửa đổi mã của bạn. Bắt đầu xây dựng một lịch sử của hệ thống.

Thực hiện phân tích mã tĩnh. Đầu tư vào một công cụ như ReSharper. Nó sẽ nhanh chóng chỉ ra tất cả các ngoại lệ tham chiếu null có thể và các thực tiễn mã hóa xấu khác. Nó có thể giúp lấy mã ở trạng thái tốt hơn chỉ bằng vài cú nhấp chuột và tự động hóa các mục tẻ nhạt như định dạng mã, đặt tên biến, v.v. Đo mã của bạn, tìm ra các điểm nóng để tái cấu trúc thông qua các số liệu mã.

Tái cấu trúc và kiểm tra đơn vị. Tôi sẽ giả định rằng có lẽ hầu hết các mã được viết là không thể kiểm tra được, vì vậy tôi sẽ không cố gắng thêm các thử nghiệm cho nó. Bất kỳ mã mới, tạo một dự án thử nghiệm và bắt đầu viết thử nghiệm, cả đơn vị và tích hợp. Nếu thử nghiệm đơn vị thất bại, thất bại xây dựng. Vì vậy, khi bạn tái cấu trúc, cần có các bài kiểm tra. Một điều với các bài kiểm tra là người ta có thể viết một bài kiểm tra để gọi bất kỳ phương thức nào và gỡ lỗi vào phương thức đó mà không cần tải lên toàn bộ ứng dụng hoặc cơ sở mã. Điều này rất hữu ích để giúp khắc phục sự cố.

Tài liệu bất kỳ kiến ​​thức bộ lạc khi cần thiết. Mã phải được tự ghi lại để các bình luận trở nên thưa thớt, nhưng nhiều hệ thống có cách làm "bất thường", chỉ ra những điều đó trong WIKI mã hóa hoặc loại kho lưu trữ không chính thức khác. Ngoài ra, xem xét đến với các tiêu chuẩn và thực hành mã hóa. Thực thi các tiêu chuẩn đó thông qua một bộ công cụ như Resharper. Vì hầu hết các mã có thể không tuân theo bất kỳ tiêu chuẩn và hướng dẫn nào, nên thực hiện các tiêu chuẩn về mã mới được viết.

Vì bạn mới, tôi sẽ coi đây như một chuyến công tác. 6 tháng đến 2 năm, và sau đó đưa ra lựa chọn ở lại hoặc tiếp tục. Hãy hài lòng từ việc làm cho mọi thứ tốt hơn một chút so với ngày trước.


4

Đầu tiên, tất cả những điều trên ... ditto.

Một số heuristic:

  • Sử dụng kiểm soát nguồn trên máy tính phát triển của bạn. Đó là điều tốt nhất tôi đã làm. Nó không phải là sự thay thế cho kiểm soát phiên bản của dự án mà chúng ta có. Đó là một công cụ mang lại sự tự do đáng kinh ngạc để thử nghiệm một cách không sợ hãi, hack, các vấn đề công việc đồng thời độc lập, v.v. Tôi tốt hơn trong việc sử dụng kiểm soát phiên bản vì tôi có quyền tự do táo bạo, làm hỏng và học hỏi.
  • Trong phạm vi bạn thêm nhận xét, hãy ưu tiên các yếu tố giao diện công cộng, để tận dụng lợi thế của intellisense. Làm điều này khi bạn giải mã trong cuộc phiêu lưu gỡ lỗi của bạn.
  • Hãy kiên trì với tái cấu trúc nhỏ. Sớm hay muộn, đối với một đoạn mã nhất định, bạn sẽ nhận được một khối quan trọng cho phép tái cấu trúc lớn như DRYing lên mã dự phòng trên các lớp.
  • Không trộn lẫn định dạng lại mã và các thay đổi thực tế trong cùng một cam kết kiểm soát phiên bản.
  • Nguyên tắc RẮN
    • Không bao giờ bỏ qua trách nhiệm duy nhất. Làm tốt lắm, đây là con đường dẫn đến lời hứa hướng đối tượng; IMHO.
    • Luôn bỏ qua Mở / Đóng.
    • Chúng tôi không nói mã mới ở đây.
    • Làm giao diện mà không có thiết kế có mục đích cản trở bảo trì.
  • Tái cấu trúc
  • Một số tệp mã cần định dạng lại hoàn toàn, đổi tên biến, v.v. trước khi thử gỡ lỗi. Đừng ngại sử dụng menu tái cấu trúc của studio trực quan mà không cần kiểm tra đơn vị.
  • Tài liệu duy nhất không thể bị thất lạc là trong các tệp mã.
  • Khi bạn nhận được kiểm soát phiên bản, hãy suy nghĩ trước về kế hoạch VC. Và tài liệu đó! Và đưa ra một quy ước đặt tên cho các chi nhánh, thẻ sẽ làm nổi bật các phiên bản phần mềm và cột mốc chính.
  • Sử dụng thiết bị tốt
    • Nhận một màn hình mà pivots. Dọc là cách đọc mã nhanh chóng.
    • Ổ đĩa ngoài để sao lưu, bàn phím với đúng loại phím , chuột đa chức năng. Ít nhất 1 ổ USB thực sự tốt. Tôi thậm chí có ghế Herman Miller của riêng tôi .
    • Nhận phần mềm so sánh rất tốt. Tôi hài lòng với Beyond So sánh .
  • Thực hành gỡ lỗi cao su
  • Đôi khi điều tồi tệ nhất có thể xảy ra là họ không sa thải bạn.

Biên tập

Phát triển ứng dụng Brownfield trong .NET

Hãy thử cuốn sách này. Một trang bìa ban đầu để đọc qua có lẽ là tốt nhất. Cuốn sách này sẽ giúp bạn suy nghĩ về bức tranh lớn, khả năng và phát triển cả kế hoạch chiến lược và chiến thuật tấn công.

Dán nó ra

Ở lại, nói, 1,5 năm nếu bạn có thể; đủ lâu để biết nếu bạn đang tiến bộ kinh nghiệm. Bạn sẽ biết nếu bạn nhận được 2 năm kinh nghiệm hoặc 6 tháng kinh nghiệm 4 lần.

Là "thiếu niên với 1/2 năm kinh nghiệm" Tôi lo ngại rằng một nhà tuyển dụng tiềm năng sẽ xem nó như được bảo lãnh sớm vì bạn không thể hack nó. Đó là một điều để nói rằng bạn đã học z, y, x, lấy một số tên và đá vào mông - nhưng không được phép đóng góp vào khả năng của bạn; và một cách khác chỉ đơn giản là mạo hiểm mổ xẻ công việc, mã, quản lý, vv bằng cách giải thích.

Tôi có thể không dựa trên cơ sở này nhưng "thời gian tốt nhất và thời gian tồi tệ nhất" của tôi là công việc đầu tiên của tôi, đó là mã không thể nhầm lẫn theo nghĩa đen. Tôi đã có một người giám sát tuyệt vời (tất cả những người còn lại là từ chương trình quản lý chăn nuôi), người đã cho tôi không gian để viết lại một số chương trình chính. Kinh nghiệm đó là sự mặc khải.

kết thúc chỉnh sửa


+1 cho Không trộn lẫn định dạng lại mã và các thay đổi thực tế trong cùng một cam kết kiểm soát phiên bản.- lời khuyên tuyệt vời
kiwiron

0

Tôi muốn nói (5) là cái bạn cần sửa trước. Nếu bạn không biết mã nào đang chạy trong sản xuất, bạn không có cách nào để tái tạo và khắc phục sự cố một cách an toàn. Điều này làm cho bất kỳ thay đổi nào khác mà bạn giới thiệu trở nên nguy hiểm, vì nó có thể gây ra sự cố mà bạn không thể thấy trước và không thể tái tạo.

Bạn có thể cần thực hiện một số công việc thám tử và có lẽ là kỹ thuật đảo ngược để tìm ra phiên bản mã nào và thư viện nào được triển khai. (Và bạn cần có một hệ thống xây dựng và triển khai nhất quán để đưa tất cả mã được triển khai phù hợp với kiểm soát nguồn trong tương lai.)

Bạn có thể phải xây dựng nhiều môi trường thử nghiệm để nhân rộng các triển khai khác nhau. (Tất nhiên cách khắc phục đơn giản nhất là tạo một bản dựng sạch mới và triển khai nó một cách nhất quán ở mọi nơi, nhưng có vẻ như điều này là không thể?)

Chỉ khi bạn biết các phiên bản chính xác được triển khai và có môi trường thử nghiệm tương ứng, bạn mới nên bắt đầu thử sửa / cải thiện mã.

Ưu tiên tiếp theo của bạn là hợp nhất thành một cơ sở mã duy nhất có thể được triển khai ở mọi nơi. Có vẻ như bạn có các phiên bản mã khác nhau được triển khai do tùy chỉnh? Bạn nên hợp nhất thành một phiên bản duy nhất và sau đó sử dụng các công tắc cấu hình cho logic tùy chỉnh.

Sau này, bạn có thể bắt đầu cải tiến cẩn thận cơ sở mã để cho phép gỡ lỗi dễ dàng hơn. Thêm đăng nhập có lẽ là cải tiến ít rủi ro nhất.

Bạn sẽ muốn thêm các bài kiểm tra tự động, nhưng thường không thể thêm vào một dự án không được thiết kế ban đầu để thử nghiệm. Thay vào đó, tôi khuyên bạn nên bắt đầu với các thử nghiệm tích hợp đầu cuối tự động. Đây là những khó khăn hơn để thiết lập, nhưng không yêu cầu bạn phải kiến ​​trúc lại giải pháp, do đó ít rủi ro hơn.


0

Bỏ qua các vấn đề bạn có trong nhóm của mình, có vẻ như vấn đề đầu tiên cần giải quyết là gỡ lỗi mã phù hợp với những gì đang sản xuất. Nếu không, bạn có thể đang theo đuổi một lỗi đã được sửa trong mã bạn có trong "Kiểm soát nguồn". Vì đây là .NET nên bạn có thể dễ dàng "dịch ngược" các nhị phân sản xuất để so sánh mã với những gì bạn có. Đây không phải là một nhiệm vụ dễ dàng nhưng nếu bạn thành công thì đây là một lập luận mạnh mẽ cho một công cụ kiểm soát nguồn tốt hơn có thể gắn thẻ các phiên bản đã phát hành.


Khi bạn có nghĩa là dịch ngược, bạn có nghĩa là sử dụng cái gì đó như IDA Pro để xem mã máy? Tôi có lẽ sẽ là người duy nhất sử dụng nó sau đó bởi vì không ai ở đây biết lắp ráp (và tôi biết những điều cơ bản).
Igneous01

Chà, vì đây là .NET, các mã nhị phân không phải là mã máy, chúng nằm trong CIL ( en.wikipedia.org/wiki/Common_Inter liền_Lingu ). Điều này có thể được chuyển đổi khá dễ dàng và chính xác trở lại mã c # hoặc VB, đặc biệt nếu nó không bị xáo trộn. Bạn có thể dùng thử với ILSpy chẳng hạn ( ilspy.net ) nhưng có thể có các công cụ khác mà bạn có thể sử dụng.
20c
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.