Sau này bạn sẽ không bao giờ sửa được - Cách kéo nhóm của bạn ra khỏi cát lún

Không có công ty khởi nghiệp nào bắt đầu với một người thử nghiệm.

Sau đó 2 năm, công ty khởi nghiệp đó không thể phát hành một tính năng mới cho khách hàng lớn nhất của họ trừ khi họ viết lại toàn bộ với một cú nổ lớn. Thật đau đớn khi xem đi xem lại điều này.

Có những việc đơn giản cần làm để giữ cho chất lượng vệ sinh của phần mềm của chúng tôi, để bạn không rơi vào tình huống này.

Đầu tiên, hãy nắm lấy nỗi sợ hãi của bạn. Các kỹ sư là những người dũng cảm và chúng tôi sẽ không dễ dàng thừa nhận rằng chúng tôi có những lo lắng. Nhưng chúng ta có, và càng sớm thừa nhận và chia sẻ những lo lắng đó, chúng ta càng sớm chuẩn bị để đối mặt với chúng.

Cách chúng tôi xây dựng phần mềm ngày nay

Chúng tôi quá vội vàng nên luôn bị trễ. Không có thời gian để thử nghiệm. Không có thời gian để thử nghiệm đơn vị. Không có thời gian để tái cấu trúc.

Chà, sẽ không bao giờ có đủ thời gian để làm điều đó đúng trong khi chúng ta tiếp tục phá hoại bản thân với tư cách là đội kỹ thuật.

Chúng tôi được hỏi sẽ mất bao nhiêu thời gian và chúng tôi tiếp tục loại trừ thử nghiệm đơn vị, thử nghiệm thủ công và thậm chí cả thử nghiệm và tái cấu trúc API khỏi các ước tính của mình.

Vì vậy, chúng tôi xây dựng phần mềm như thế này:

• Nhanh chóng và hèn hạ

• Không nhanh, vẫn bẩn

• Đường chéo nhanh và hạnh phúc đã được thử nghiệm

• Mọi thứ khác được coi là một trường hợp cạnh. (Không có thứ gọi là trường hợp cạnh.)

  
  

Ít người trong chúng ta thậm chí còn dũng cảm hơn để nói không với nhanh hoặc bẩn và xây dựng phần mềm nhanh và ổn định.

Những gì bạn nên cắt bỏ khỏi ước tính của mình là phạm vi chứ không phải chất lượng.

Bạn biết gì về chất lượng của thành phần mà bạn đang làm việc?

• Bạn biết nó mong manh, nhưng bạn không muốn chạm vào nó vì nó rất dễ vỡ.

• Bạn đã làm điều này từ lâu, bạn hầu như không chạm vào nó, nó sẽ hoạt động.

• Bạn không biết nó rất mong manh.

• Không có bài kiểm tra nào và không có ai để kiểm tra và cho thấy nó thực sự mong manh như thế nào.

  
  

Bạn có vui khi xử lý hàng ngày với phần mềm bẩn này không?

Bạn có hài lòng khi thỏa hiệp với chất lượng công việc của mình mỗi ngày dù biết rằng nó còn lâu mới đạt kết quả tốt? Đối phó với việc "chúng tôi không có thời gian để dọn dẹp" và vẫn bị trễ vì nó bẩn và bạn không thể tiếp tục nếu không dọn dẹp.

Hãy tưởng tượng bạn đang ở cuộc phỏng vấn việc làm tiếp theo của bạn. Bạn sẽ khoe khoang điều gì trong công việc hiện tại? Rằng bạn có thể thực hiện dưới áp lực và sửa chữa vào ban đêm? Họ sẽ yêu bạn vì điều đó, nhưng họ cũng sẽ hỏi bạn tại sao bạn không làm điều gì đó để giải quyết vấn đề đó. Có lẽ đó không phải là công việc của bạn.

Có những trưởng nhóm và giám đốc kỹ thuật để đưa ra những quyết định đó. Nếu nó tùy thuộc vào bạn, bạn sẽ làm điều gì đó. Bạn đã nói với họ rằng mã cần được tái cấu trúc và bạn cần lập kế hoạch thời gian cho bộ phận công nghệ ở mỗi lần cải tiến và không ai lắng nghe.

Chà, đoán xem - bạn không cần sự cho phép. Chất lượng công việc của bạn chỉ phụ thuộc vào bạn. Không ai có thể bắt bạn viết mã nhảm nhí. Áp lực thời gian là một cái cớ ngắn hạn. Các giải pháp nhanh và bẩn làm trì hoãn toàn bộ dự án và tốn nhiều chi phí hơn so với việc bạn làm đúng ngay từ đầu.

Bạn sẽ không bao giờ sửa nó sau này

Bạn có sẵn sàng tạo ra sự khác biệt đó không?

Sau đó, đây là những gì cần làm: bị kỷ luật. Tôi xin lỗi, nhưng không còn cách nào khác. Và nó nên ở tất cả các cấp.

Những bước đầu tiên của bạn để xây dựng mã với chất lượng cao hơn là gì?

Thực hiện ghi nhật ký và cảnh báo

Có rất nhiều công cụ để ghi nhật ký và cảnh báo. Đây là điều đầu tiên cần làm. Phần mềm của bạn đang gặp sự cố và bạn hoàn toàn không biết.

Tìm một giải pháp cho phép bạn dễ dàng tạo phiếu yêu cầu từ các cảnh báo ngoại lệ và đánh dấu chúng là "đã biết" hoặc nhóm chúng sau khi chúng được báo cáo.

Xây dựng thói quen nhóm để theo dõi và báo cáo cảnh báo

Nếu bạn nghĩ nó buồn tẻ, hãy để tôi hỏi bạn: Bạn có ở sâu trong khu vực đó trong cả ngày làm việc không? Sau tất cả các cuộc họp và công việc lập trình nặng nề, bạn cần giảm bớt sự tập trung của mình một chút. Chà, duyệt qua kênh cảnh báo tốt hơn nhiều so với duyệt qua bất kỳ kênh nào khác.

Chỉ cần nhấp vào nút "Báo cáo vé" hoặc nút "Đánh dấu là đã biết". Và nếu bạn cảm thấy hứng thú, có lẽ bạn sẽ sửa một hoặc hai cái.

Đây là điểm tranh luận lớn nhất - chúng tôi có thể sửa một số lỗi, nhưng chúng tôi đang viết các bài kiểm tra mà ai đó cần xác nhận, chúng tôi cần triển khai và điều này tạo ra nhiều công việc ngoài kế hoạch hơn cho nhóm.

Thủ tướng sẽ hét vào mặt chúng tôi rằng chúng tôi không làm việc trên các hạng mục ưu tiên cao mà chỉ mạ vàng các cảnh báo nhỏ.

Nhóm có tất cả các vai trò "M" trong đó đồng ý về điều đó.

Đưa ra quy tắc ngón tay cái - "Nếu nó có vẻ nhỏ và ít rủi ro, và hoàn toàn không có công việc nào khác đang được tiến hành, chỉ cần tiếp tục và sửa chữa nó. Chúng tôi có thể xử lý một hoặc hai cảnh báo nhỏ được sửa "ngoài phạm vi" trên mỗi Sprint , cùng với những kế hoạch."

Vậy là xong, rất đơn giản.

Bắt đầu dọn dẹp từng nhật ký và cảnh báo

Ngoài các bản sửa lỗi không thường xuyên, hãy lập kế hoạch dọn dẹp hợp lý. Lưu ý rằng khi lập kế hoạch, ý tôi là phân bổ thời gian hàng ngày/hàng tuần để khắc phục chúng bất kể mức độ nghiêm trọng hoặc mức độ ưu tiên của chúng . Bạn sẽ lãng phí nhiều thời gian hơn để đánh giá mức độ ưu tiên của chúng hơn là sửa 5 cái đầu tiên. Vì vậy, hãy bắt đầu sửa.

Đảm bảo rằng có một cảnh báo cho mỗi nhà phát triển hoặc nếu bạn thường xuyên di chuyển, hãy đặt khung thời gian hàng ngày cho các cảnh báo. Và tôi sẽ làm điều đó đầu tiên vào buổi sáng vì nếu không, bạn sẽ không bao giờ làm được.

Một lần nữa, đây không phải là một tính năng mới và có vẻ như nó ngốn thời gian từ các ưu tiên quan trọng của bạn, nhưng các ưu tiên quan trọng của bạn đã bị trễ do những vấn đề tiềm ẩn đó. Bạn đã trễ rồi!

Xóa tất cả các câu lệnh Try-Catch trống rỗng và để nó sụp đổ!

Mặc dù cảnh báo và ghi nhật ký sẽ hiển thị rất nhiều, nhưng chúng sẽ không thể ghi nhật ký những gì bạn ẩn. Vì vậy, hãy ngừng quét các vấn đề của bạn dưới tấm thảm.

Điều gì đã xảy ra cách đây 2 năm và bạn không biết tại sao ngày nay lại hoàn toàn khác. Hãy để nó sụp đổ, và sửa chữa nó. Nó thậm chí có thể sẽ không bị lỗi theo cùng một cách hoặc nó thậm chí không bị lỗi, vì vậy bằng cách này hay cách khác, mã của bạn sẽ ở trạng thái tốt hơn nếu không có những thứ đó.

Bắt đầu viết bài kiểm tra đơn vị ngay bây giờ

Ý tôi là vậy. Bạn đang làm việc trên một số mã ngay bây giờ. Sau đó, không có gì ngăn cản bạn viết bài kiểm tra đơn vị.

Ồ, tôi hiểu rồi! Không có cơ sở hạ tầng sẵn sàng để thử nghiệm đơn vị, phải không? Cố lên! Dù sao thì bạn cũng sẽ trì hoãn tính năng Wannabe đó.

Bạn không cần nhiều hơn một ngày để thiết lập khung thử nghiệm đơn vị và CI của bạn để chạy thử nghiệm. Cứ làm đi.

Bắt đầu TDD để sửa lỗi

"Chúng tôi không biết vấn đề là gì và chúng tôi sẽ khắc phục nó như thế nào. Chúng tôi không thể viết bài kiểm tra cho mã chưa tồn tại."

Nhà phát triển thân mến, mục đích của thử nghiệm là để kiểm tra một giả thuyết. Điều đó có giá trị đối với kiểm thử nói chung, không chỉ đối với kiểm thử phần mềm. Vì vậy, những gì bạn cần để viết một bài kiểm tra không phải là mã. Bạn cần hành vi và kết quả mong đợi.

Bây giờ, nếu câu chuyện của người dùng mơ hồ và không rõ ràng và bạn chưa sẵn sàng bắt đầu viết bài kiểm tra đối với câu chuyện của người dùng, thì tôi cũng có một giải pháp cho vấn đề này, nhưng trước đó - hãy bắt đầu viết mã thử nghiệm đầu tiên để tìm lỗi.

Có một thành phần của mô tả lỗi được gọi là "Kết quả mong đợi" và các bước để sao chép là trường hợp thử nghiệm của bạn. Vì vậy, bạn đã có trường hợp thử nghiệm trước mặt bạn. Bây giờ, hãy viết mã trước khi bạn bắt đầu mã hóa bản sửa lỗi.

Phát triển dựa trên thử nghiệm đang viết một bài kiểm tra xác nhận bạn đã thực hiện đúng công việc chứ không phải bạn đã thực hiện đúng. Bài kiểm tra đơn vị xác minh xem bạn đã thực hiện đúng chưa.

Vẽ lộ trình phủ sóng

Tự động hóa thử nghiệm và nợ công nghệ có số phận bi thảm tương tự - chúng không bao giờ được bắt đầu bởi vì "chúng tôi không bao giờ có thể trang trải mọi thứ, chúng tôi không bao giờ có thể dọn dẹp mọi thứ, đó là quá nhiều chi phí. Chúng tôi không có thời gian cho việc đó."

Hãy nghe tôi nói: bạn không cần phải tự động hóa mọi thứ!

Nhưng bạn chắc chắn phải tự động hóa các yếu tố quan trọng trong nhiệm vụ của mình - các trường hợp sử dụng có mức độ ưu tiên cao, cơ sở hạ tầng quan trọng và các chức năng cốt lõi. Gọi nó là gì bạn thích, nhưng doanh nghiệp dựa vào 20% mã và cơ sở hạ tầng của bạn và khách hàng của bạn đang sử dụng 20% tính năng của bạn.

Bạn thấy nơi tôi đang đi với điều này.

Bạn thậm chí không cần bắt đầu viết bài kiểm tra tự động cho các tính năng này ngay bây giờ. Điều bạn cần làm đầu tiên là ưu tiên chúng.

Tập hợp thành một nhóm trước các sơ đồ kiến trúc cấp cao và cấp thấp của bạn. Không có cái nào, phải không? Hay những cái tồn tại là một bức ảnh bảng trắng được chụp cách đây 2,5 năm? Tôi biết.

Có, bạn cần dành nửa ngày để cập nhật những thông tin này. Tin vui là có những công cụ thú vị có thể trợ giúp bạn, vì vậy bạn không cần phải bảo trì nó theo cách thủ công. Làm một vài nghiên cứu.

Rốt cuộc, bạn là một nhóm R&D, phải không?!

Đừng nhằm mục đích bảo hiểm đầy đủ - thay vào đó hãy nhắm đến rủi ro thấp và độ tin cậy cao

Trong khi lập sơ đồ kiến trúc và cơ sở hạ tầng cập nhật của bạn, hãy thêm ghi chú hoặc vòng tròn, hoặc in đậm hoặc tô màu đỏ ở tất cả các vị trí:

• Nhiệm vụ quan trọng đối với doanh nghiệp và phần mềm của bạn

• Rất cần tái cấu trúc, hoặc bạn sẽ tiếp tục trì hoãn tính năng quan trọng khác trong nhiệm vụ đó mọi lúc.

• Việc liên tục làm hỏng và ngốn thời gian của bạn để sửa chúng là vô ích vì chúng sẽ lại hỏng sau vài ngày.

Khi các bản vẽ đã sẵn sàng, hãy ngồi với nhóm của bạn và suy nghĩ xem cần kiểm tra những gì cho tất cả các thành phần được khoanh tròn này.

• Đừng rơi vào cái bẫy "điều này là quá nhiều! Chúng ta phải dừng tất cả các công việc khác để giải quyết tất cả điều này!" Bạn không cần phải bao gồm tất cả những điều này cùng một lúc. Nhưng bạn cần một kế hoạch. Bây giờ, hãy mở một bảng khác và bắt đầu viết Mục tiêu thử nghiệm của bạn. Ví dụ:

  
  

  • Bao gồm tất cả các yêu cầu API tìm nạp dữ liệu về thành công và thất bại để bạn biết rằng bạn không gửi yêu cầu xấu và nếu thất bại thì đó là lỗi do nhà cung cấp.

    
    

  • Phác thảo hành trình quan trọng của người dùng. Chia nhỏ nó thành các đơn vị. Viết các bài kiểm tra đơn vị. Khi kim tự tháp thử nghiệm được phát minh, một đơn vị có nghĩa là một thành phần, không phải là một phương thức, vì vậy nó bao hàm chức năng, không phải phương thức và lớp.

    
    

  • Xác định tắc nghẽn giao thông và quyết định cách bạn sẽ gỡ rối chúng.

    
    

  • Kế hoạch để làm điều đó đúng. Mã nhanh và bẩn của bạn sẽ vẫn bẩn với các bài kiểm tra bẩn.

Tôi đã cố tình sử dụng Bản đồ phủ sóng chứ không phải Kim tự tháp thử nghiệm vì... ở giai đoạn này, khi bạn chưa có bất kỳ thử nghiệm nào, thủ công hay tự động, bạn chưa sẵn sàng cho Kim tự tháp.

Nhiều nhóm có ấn tượng sai lầm rằng trước tiên họ phải đạt được phạm vi kiểm tra đơn vị 96%, sau đó chuyển sang kiểm tra tích hợp, v.v. Vấn đề với phạm vi kiểm tra đơn vị hiện đại là chúng tôi kiểm tra Phương thức và Lớp chứ không phải chức năng.

Thậm chí nhiều nhóm bắt đầu với tự động hóa giao diện người dùng, điều này cũng sai.

Đó thực sự là điều tồi tệ nhất bạn có thể làm, và nó chắc chắn sẽ thất bại.

Vì vậy, đừng bắt đầu từ trên đỉnh hoặc từ dưới cùng của Kim tự tháp mà thay vào đó hãy xây dựng một bản đồ rủi ro.

Một số tính năng có thể cần thử nghiệm tích hợp rộng rãi, các tính năng khác có thể cần thử nghiệm giao diện người dùng rộng rãi và phần tiếp theo thực sự có thể là tính năng cốt lõi mà mọi thứ phụ thuộc vào (tuy nhiên, một lá cờ đỏ khác) và bạn phải kiểm tra đầy đủ từ trên xuống dưới.

Hoặc đó là một dịch vụ thu thập dữ liệu và bạn cần tập trung vào hiệu suất của các API chẳng hạn.

Xây dựng bản đồ các điểm nóng phần mềm cần thử nghiệm nghiêm ngặt của bạn.

Sau đó, hãy nghĩ về cách bạn có thể tự động hóa thử nghiệm đó.

Bạn không thể tiến bộ trong cát lún và chỉ bạn mới có thể tự kéo mình ra khỏi đó

Hãy kết thúc nó - không có thử nghiệm, mã ở tình trạng xấu và bạn không có thời gian. Bạn tiếp tục thỏa hiệp vì "bạn không có thời gian". Bạn không hoàn toàn hài lòng, hoặc ít nhất là bạn khá thiếu hiểu biết - họ trả tiền, đó là cuộc gọi của họ và đó không phải là quyết định của bạn.

Nếu họ không hài lòng, bạn sẽ chuyển sang công ty tiếp theo.

Chà, mọi thứ đã thay đổi rất nhiều vào năm ngoái, phải không?! Bạn cần phải là một nhà phát triển xuất sắc để được tuyển dụng. Các công ty đã học được rằng họ có thể loại bỏ mọi người bất kể đóng góp của họ là gì.

Tuy nhiên, vẫn có những kỹ sư mà một công ty sẽ làm mọi cách để giữ lại. Để trở thành một trong số họ, bạn cần thúc đẩy sự thay đổi và liên tục chứng minh rằng công việc kinh doanh phụ thuộc vào những người như bạn.

Mọi người đều có thể viết phần mềm tồi, nhưng những người thực sự giỏi không chỉ viết phần mềm xuất sắc một cách vui vẻ mà còn truyền cảm hứng cho những người khác và truyền bá văn hóa mã chất lượng.

Bạn không thể tiến bộ trong cát lún, và chỉ có bạn mới có thể tự mình thoát ra.