Làm thế nào để thu hút sự chú ý của lập trình viên trong những điều kiện nhất định?


13

Hãy bắt đầu với một ví dụ.

Giả sử, tôi có một phương thức được gọi exportphụ thuộc rất nhiều vào lược đồ DB. Và bởi phụ thuộc rất nhiều, tôi có nghĩa là tôi biết rằng việc thêm một cột mới vào một bảng nhất định thường xuyên (rất thường xuyên) dẫn đến exportthay đổi phương thức tương ứng (thông thường bạn cũng nên thêm trường mới vào dữ liệu xuất).

Các lập trình viên thường quên thay đổi exportphương thức vì nó không thực sự rõ ràng, bạn thậm chí nên nhìn vào điều này. Mục tiêu của tôi là buộc lập trình viên đưa ra quyết định rõ ràng để xác định liệu anh ta quên xem exportphương thức hay chỉ không muốn thêm một trường vào dữ liệu xuất. Và tôi đang tìm giải pháp thiết kế cho vấn đề này.

Tôi có hai ý tưởng, nhưng cả hai đều có sai sót.

Thông minh đọc tất cả các gói bọc

Tôi có thể tạo trình bao bọc thông minh để đảm bảo tất cả dữ liệu được đọc rõ ràng.

Một cái gì đó như thế này:

def export():
    checker = AllReadChecker.new(table_row)

    name    = checker.get('name')
    surname = checker.get('surname')
              checker.ignore('age') # explicitly ignore the "age" field

    result = [name, surname] # or whatever

    checker.check_now() # check all is read

    return result

Vì vậy, checkerkhẳng định nếu table_rowcó chứa các trường khác không được đọc. Nhưng tất cả những thứ này có vẻ nặng và (có thể) ảnh hưởng đến sự hoàn hảo.

Kiểm tra phương pháp đó

Tôi chỉ có thể tạo một số nhỏ nhất nhớ lại lược đồ bảng cuối cùng và thất bại mỗi khi bảng được thay đổi. Trong trường hợp đó, lập trình viên sẽ thấy một cái gì đó giống như đừng quên kiểm tra exportphương thức. Để ẩn người lập trình cảnh báo sẽ (hoặc sẽ không - đó là một vấn đề) kiểm tra exportthủ công (đó là một vấn đề khác) khắc phục kiểm tra bằng cách thêm các trường mới vào đó.

Tôi có một vài ý tưởng khác nhưng chúng quá rắc rối để thực hiện hoặc quá khó hiểu (và tôi không muốn dự án trở thành một câu đố).


Vấn đề trên chỉ là một ví dụ về loại vấn đề rộng hơn mà tôi gặp phải theo thời gian. Tôi muốn liên kết một số đoạn mã và / hoặc cơ sở hạ tầng để thay đổi một trong số chúng ngay lập tức cảnh báo lập trình viên để kiểm tra mã khác. Thông thường bạn có một số công cụ đơn giản như trích xuất logic thông thường hoặc viết không đáng tin cậy, nhưng tôi đang tìm kiếm công cụ cho các trường hợp phức tạp hơn: có thể một số mẫu thiết kế mà bây giờ tôi biết.


Bạn có thể tạo exportdựa trên Schema không?
coredump

Nó không thể được tạo ra ngoài ý muốn, đó là lý do tại sao tôi nên yêu cầu lập trình viên xem mã và đưa ra quyết định.
Vadim Pushtaev

Nó có phải là một giải pháp để thêm hai danh sách tên trường (xuất và không xuất) vào lớp xuất và có một bài kiểm tra đơn vị kiểm tra xem hai danh sách đó có bao gồm toàn bộ các trường từ cơ sở dữ liệu không?
Sjoerd Công việc Postmus

Bạn có thể tự động tạo một bài kiểm tra mặc dù kiểm tra xem exportcó tất cả mọi thứ bạn thực sự cần không?
biziclop

1
một nhận xét trong mã nguồn quá đơn giản một giải pháp? Thông thường mọi thứ bị bỏ lỡ vì không có lời nhắc, một bình luận sẽ khắc phục điều đó.
gbjbaanb

Câu trả lời:


11

Bạn đang đi đúng hướng với ý tưởng kiểm tra đơn vị của bạn, nhưng việc thực hiện của bạn là sai.

Nếu exportliên quan đến lược đồ và lược đồ thay đổi, có hai trường hợp có thể xảy ra:

  • Hoặc exportvẫn hoạt động hoàn toàn tốt, bởi vì nó không bị ảnh hưởng bởi một thay đổi nhỏ trong lược đồ,

  • Hoặc nó phá vỡ.

Trong cả hai trường hợp, đó là mục tiêu của bản dựng để theo dõi hồi quy có thể này. Một loạt các bài kiểm tra, đó sẽ là các bài kiểm tra tích hợp, hoặc các bài kiểm tra hệ thống, hoặc các bài kiểm tra chức năng hoặc một thứ khác mà đảm bảo rằng exportquy trình của bạn hoạt động với lược đồ hiện tại , độc lập với thực tế là nó có thay đổi hay không kể từ lần cam kết trước. Nếu những bài kiểm tra đó vượt qua, thật tuyệt. Nếu họ thất bại, đây là một dấu hiệu cho nhà phát triển rằng anh ta có thể đã bỏ lỡ điều gì đó, và một dấu hiệu rõ ràng nơi để tìm.

Tại sao việc thực hiện của bạn sai? Vâng, vì nhiều lý do.

  1. Nó không có gì để làm với các bài kiểm tra đơn vị ...

  2. ... Và, thực sự, nó thậm chí không phải là một bài kiểm tra.

  3. Điều tồi tệ nhất là việc sửa lỗi thử nghiệm trên máy tính, đòi hỏi phải thực sự thay đổi thử nghiệm trên máy tính, đó là thực hiện một thao tác hoàn toàn không liên quan đến export.

Thay vào đó, bằng cách thực hiện các thử nghiệm thực tế cho exportquy trình, bạn chắc chắn rằng nhà phát triển sẽ sửa lỗi export.


Tổng quát hơn, khi bạn gặp phải tình huống thay đổi một lớp luôn hoặc thường yêu cầu thay đổi ở một lớp hoàn toàn khác, đây là một dấu hiệu tốt cho thấy bạn đã thiết kế sai và vi phạm Nguyên tắc Trách nhiệm duy nhất.

Trong khi tôi nói cụ thể về các lớp, nó cũng áp dụng ít nhiều cho các thực thể khác. Chẳng hạn, một thay đổi trong lược đồ cơ sở dữ liệu sẽ được phản ánh tự động trong mã của bạn, ví dụ thông qua các trình tạo mã được sử dụng bởi nhiều ORM hoặc ít nhất nên được bản địa hóa dễ dàng: nếu tôi thêm Descriptioncột vào Productbảng và tôi không sử dụng ORM hoặc trình tạo mã, Tôi ít nhất mong đợi thực hiện một thay đổi duy nhất trong Data.Productlớp của DAL, mà không cần phải tìm kiếm trong tất cả các cơ sở mã và tìm thấy một số lần xuất hiện của Productlớp trong lớp giả sử.

Nếu bạn không thể hạn chế một cách hợp lý sự thay đổi ở một địa điểm (vì bạn đang ở trong trường hợp đơn giản là nó không hoạt động hoặc vì nó đòi hỏi một lượng lớn sự phát triển), thì bạn sẽ có nguy cơ thoái lui . Khi tôi thay đổi lớp Avà lớp Bở đâu đó trong cơ sở mã ngừng hoạt động, đó là một hồi quy.

Kiểm tra làm giảm nguy cơ hồi quy và, điều quan trọng hơn nhiều, cho bạn thấy vị trí của hồi quy. Đây là lý do tại sao khi bạn biết rằng những thay đổi ở một vị trí gây ra sự cố ở một phần hoàn toàn khác của cơ sở mã, hãy đảm bảo bạn có đủ các bài kiểm tra làm tăng cảnh báo ngay khi hồi quy xuất hiện ở cấp độ này.

Trong mọi trường hợp, tránh dựa vào những trường hợp như vậy chỉ dựa trên các ý kiến. Cái gì đó như:

// If you change the following line, make sure you also change the corresponding
// `measure` value in `Scaffolding.Builder`.

không bao giờ làm việc Không chỉ các nhà phát triển sẽ không đọc nó trong hầu hết các trường hợp, mà nó thường sẽ kết thúc hoặc bị xóa hoặc di chuyển ra xa khỏi dòng liên quan và trở nên không thể hiểu được.


Đúng vậy, đó là thử nghiệm mà thực sự không phải là một thử nghiệm, đó là một loại bẫy, một loại nào If you change the following line...đó hoạt động tự động và không thể bỏ qua đơn giản. Tôi chưa bao giờ thấy ai đó thực sự sử dụng bẫy như vậy do đó nghi ngờ.
Vadim Pushtaev

1
Vấn đề là lớp Bkhông ngừng hoạt động, nó có thể bắt đầu hoạt động không đúng. Nhưng tôi không thể dự đoán tương lai và không thể viết các bài kiểm tra dự đoán tương lai, vì vậy tôi cố gắng nhắc nhở nhà phát triển viết bài kiểm tra mới đó.
Vadim Pushtaev

@VadimPushtaev: khi nói đến thử nghiệm, có thể bắt đầu làm việc không đúng cách và RÚT dừng hoạt động của chính xác là điều tương tự. Bạn không thể dự đoán tương lai, nhưng bạn sẽ có thể biết chính xác các yêu cầu và kiểm tra xem các yêu cầu đó có được đáp ứng bởi sản phẩm thực tế của bạn không.
Arseni Mourzenko

Vâng, đó là một điều. Tôi thực sự muốn nhắc nhở các nhà phát triển suy nghĩ về các yêu cầu mới . Tôi chỉ muốn vẫy tay: Chào Xin chào, bạn có chắc là bạn không quên xuất khẩu không? Hãy hỏi người quản lý hoặc một cái gì đó, đó là một vấn đề phổ biến.
Vadim Pushtaev

Dù sao cũng cảm ơn bạn, câu trả lời của bạn đã giúp tôi sắp xếp suy nghĩ của mình và bây giờ tôi đã có một kế hoạch nhất định.
Vadim Pushtaev

3

Tôi nghe có vẻ như những thay đổi của bạn chưa được xác định rõ. Giả sử bạn sống ở một nơi không có mã bưu chính, vì vậy bạn không có cột mã bưu chính trong bảng địa chỉ. Sau đó, mã bưu chính được giới thiệu hoặc bạn bắt đầu giao dịch với những khách hàng sống ở nơi có mã bưu chính và bạn phải thêm cột này vào bảng.

Nếu mục công việc chỉ nói "thêm cột mã bưu chính vào bảng địa chỉ" thì có, việc xuất sẽ bị hỏng hoặc ít nhất là không xuất mã bưu chính. Nhưng những gì về màn hình đầu vào được sử dụng để nhập mã bưu chính? Báo cáo liệt kê tất cả các khách hàng và địa chỉ của họ? Có hàng tấn thứ cần thay đổi khi bạn thêm cột này. Công việc ghi nhớ những điều đó là một điều quan trọng - bạn không nên dựa vào các tạo phẩm mã ngẫu nhiên để "bẫy" các nhà phát triển ghi nhớ.

Khi quyết định được đưa ra để thêm một cột có ý nghĩa (nghĩa là, không chỉ một số tra cứu tổng thể hoặc không chuẩn hóa được lưu trong bộ nhớ cache hoặc giá trị khác không thuộc về xuất hoặc báo cáo hoặc trên màn hình nhập), các mục công việc được tạo phải bao gồm TẤT CẢ các thay đổi cần thiết - thêm cột, cập nhật tập lệnh dân số, cập nhật các bài kiểm tra, cập nhật xuất, báo cáo, màn hình nhập, v.v. Những điều này có thể không được chỉ định cho (hoặc được chọn bởi) cùng một người, nhưng tất cả đều phải được thực hiện.

Đôi khi các nhà phát triển chọn tự thêm các cột như một phần của việc thực hiện một số thay đổi lớn hơn. Ví dụ, ai đó có thể đã viết một mục công việc để thêm một cái gì đó vào màn hình nhập và báo cáo, mà không cần suy nghĩ về cách nó được thực hiện. Nếu điều này xảy ra nhiều, bạn sẽ cần phải quyết định xem trình bổ sung mục công việc của bạn có cần biết chi tiết triển khai hay không (để có thể thêm tất cả các mục công việc phù hợp) hoặc liệu nhà phát triển có cần biết rằng mục công việc- adder đôi khi bỏ đi. Nếu đó là sau này thì bạn cần một văn hóa "không chỉ thay đổi lược đồ; dừng lại và suy nghĩ về những gì khác ảnh hưởng."

Nếu có nhiều nhà phát triển và điều này đã xảy ra hơn một lần, tôi sẽ thiết lập một cảnh báo kiểm tra cho trưởng nhóm hoặc người cao cấp khác để được cảnh báo về các thay đổi lược đồ. Người đó sau đó có thể tìm kiếm các mục công việc liên quan để giải quyết hậu quả của việc thay đổi lược đồ và nếu các mục công việc bị thiếu, không chỉ có thể thêm chúng mà còn giáo dục bất cứ ai rời khỏi kế hoạch.


2

Hầu như luôn luôn, khi tạo xuất tôi cũng tạo một lần nhập tương ứng. Khi tôi có các thử nghiệm khác điền đầy đủ cấu trúc dữ liệu đang được xuất, sau đó tôi có thể xây dựng thử nghiệm đơn vị khứ hồi so sánh bản gốc được điền đầy đủ với bản sao được nhập sau đó được nhập. Nếu chúng giống nhau, thì xuất / nhập hoàn tất; nếu chúng không giống nhau thì kiểm tra đơn vị thất bại và tôi biết rằng cơ chế xuất khẩu cần cập nhật.


điều này có thể kiểm tra, rằng mọi đối tượng được lưu và tải lại từ db. Nó không bao gồm trường hợp trường db hiện tại không có trường đối tượng tương ứng.
k3b

@ k3b đúng. Ít nhất là trong các hệ thống của tôi, điều đó thường xảy ra nếu một cái gì đó không còn được sử dụng nhưng đã bị xóa khỏi lược đồ, nằm ngoài phạm vi của cơ chế xuất khẩu - đơn vị kiểm tra tính bền vững của đối tượng kiểm tra xem từng trường của đối tượng có vẫn tồn tại, nhưng tôi không kiểm tra các cột không sử dụng vì điều đó sẽ không có tác dụng quan sát được đối với chức năng hệ thống.
Pete Kirkham
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.