Đánh giá mã vốn dĩ là sai lầm. Đây là cách khắc phục

Ngày nay, chúng ta nên suy nghĩ chín chắn về cách chúng ta làm những việc trong lập trình. Chúng tôi cần áp dụng cách tiếp cận kỹ thuật cho các quy trình của mình. Chúng tôi, các kỹ sư phần mềm, tự tin trong các cuộc thảo luận về các lớp trừu tượng và các hàm thuần túy. Mặt khác, chúng tôi bỏ chạy khi cần bàn bạc những việc mang tính chất “quản lý”. Quá trình lập trình phổ biến rộng rãi yêu thích của tôi có rất nhiều sai sót là xem xét mã. Câu chuyện này sẽ nhìn nhận nó từ những góc độ khác nhau và đề xuất những cải tiến. Sự thật quan trọng đầu tiên tôi đọc được về việc kiểm tra phần mềm là trong cuốn sách "Sự thật và Sai lầm của Kỹ thuật Phần mềm" của Robert Glass. Nó tuyên bố những điều sau: Việc kiểm tra nghiêm ngặt có thể loại bỏ tới 90 phần trăm lỗi từ một sản phẩm phần mềm trước khi chạy trường hợp thử nghiệm đầu tiên. Tôi không thể xác định liệu những từ này có phải chỉ để xem xét mã hay không. Tôi coi chúng như là các loại kiểm tra khác nhau, mà tôi sẽ mô tả sau. . Michael Fagan đã hình thành ý tưởng về việc kiểm tra vào năm 1976 trong bài báo "Thiết kế và kiểm tra mã để giảm lỗi trong quá trình phát triển chương trình". Chú Bob Martin đã giúp tôi khám phá nguồn gốc của các bài đánh giá hiện đại của chúng tôi Tôi đã phát hiện ra ba loại kiểm tra sau đây: Kiểm tra thiết kế, Kiểm tra mã trước khi thử nghiệm đơn vị, Kiểm tra mã sau khi kiểm tra đơn vị. Công trình của Fagan không đề xuất một cách tiếp cận mới để viết mã mà ghi lại các hiện tượng đã tồn tại và lập luận cho nó. Tuy nhiên, bài báo là dấu hiệu thanh tra bằng văn bản sớm nhất mà tôi tìm thấy. Kiểm tra mã giống như đánh giá mã hiện đại của chúng tôi. Tại sao chúng ta bỏ lỡ các loại kiểm tra khác ngày nay? Tại sao chỉ có đánh giá mã ngày hôm nay: Một số giả định Sự phổ biến của kiểm tra mã và hầu như không tồn tại của các loại kiểm tra khác ngày nay đến từ các công cụ của chúng tôi. GitHub, BitBucket hoặc GitLab đều có các công cụ đánh giá mã tích hợp sẵn và chúng phù hợp một cách tự nhiên với luồng Git, luồng GitHub và các phương pháp tiếp cận khác. Bạn sử dụng công cụ nào cho các hoạt động thiết kế? Nó không phải về giao diện người dùng / người dùng. Đó là về cấu trúc của mã bạn sẽ xây dựng. Bạn có thể đã nghe nói về các công cụ CASE hoặc UML. Tôi chưa thấy chúng được sử dụng nghiêm túc trong bất kỳ công ty nào mà tôi từng làm việc, và tôi đã làm việc được bảy lần. Trên HackerNoon, truy vấn tìm kiếm " " chỉ đưa ra hai kết quả có liên quan. Vì vậy, không có nơi nào để giới thiệu việc kiểm tra thiết kế khi không có quy trình thiết kế giải pháp hữu hình. Trong nhóm mà tôi dẫn dắt, chúng tôi đã sử dụng Miro để thiết kế giao diện. Quá trình này có thể thỏa mãn hơn: như với các công cụ vẽ sơ đồ khác, bạn sẽ sớm bắt đầu vẽ thay vì giải quyết vấn đề của mình. Chúng tôi có thể độc lập với các công cụ của chúng tôi. Dưới đây là một trích dẫn nhỏ để hỗ trợ điều này từ cuốn sách "Đầu tư không giới hạn": UML ... nếu chúng ta chỉ làm những gì mà các công cụ có thể làm - thì chúng ta sẽ luôn bị giới hạn khả năng của các công cụ của mình. Các bài đánh giá mã hiện tại có những Flaws nào? Chúng ta hãy nhìn vào quá trình ở dạng cổ điển của nó từ các góc độ khác nhau. Mỗi người trong số họ cho thấy những vấn đề đáng kể. Phối cảnh BPMN BPMN là một ký hiệu mô hình hóa quy trình kinh doanh. Nó mô tả các quy trình với các hành động, sự kiện, cổng logic, thông điệp và các phương tiện khác. Tôi thậm chí khuyên bạn nên sử dụng nó nếu bạn muốn phát triển một thuật toán, vì nó mang tính mô tả nhiều hơn là một lưu đồ. Hãy mô tả quá trình xem xét mã cho một người đánh giá duy nhất với ký hiệu này và phân tích nó. Tôi đã sử dụng một công cụ dựa trên văn bản để tạo . Có một chút trục trặc trên đó với nhiều thư trả về. sơ đồ sắp tới Tất cả đều bắt đầu với một sáng tạo PR, và không có gì đáng chú ý ở đây. Bước tiếp theo là thông báo cho người đánh giá, đây là cách đơn giản hóa tất cả các phương tiện khác nhau có sẵn để nói: "Này, PR của tôi đang chờ bạn! 👋" Điều quan trọng ở đây là giải phóng khỏi các hoạt động hiện tại. Ở đây PR chờ đợi trong một khoảng thời gian không xác định. Sau đó, người đánh giá đi sâu vào nhiệm vụ và tiến hành đánh giá. Có cơ hội là một PR sẽ được hợp nhất ngay lập tức. Tuy nhiên, điều ngược lại có thể xảy ra: một vài nhận xét yêu cầu sửa lỗi sẽ xuất hiện. Tác giả của mã có thể đã ở trong nhiệm vụ tiếp theo và có thêm một thời gian chờ không xác định. Ngoài ra, việc quay lại yêu cầu khôi phục ngữ cảnh, giải thích các nhận xét và sửa chữa chúng. Bước tiếp theo là thông báo của người đánh giá. Chúng ta đã đến đó rồi sao? Vâng, bạn đã đúng. Chúng tôi vừa hoàn thành lần lặp đầu tiên của vòng lặp vô hạn tiềm năng. Vâng, vô hạn. Luôn có cơ hội xuất hiện các bình luận mới. Hoặc một trong những khoảng thời gian chờ đợi sẽ kéo dài mãi mãi. Chúng ta có muốn vòng lặp vô hạn tiềm năng như một phần của hoạt động hàng ngày của chúng ta không? Tôi không chắc, vì giao hàng nhanh hơn thường tốt hơn. Giải pháp Tầm nhìn Phối cảnh Đôi khi, chúng tôi có các nhà phát triển hoặc kiến trúc sư cấp cao trong nhóm của mình làm người đánh giá. Họ muốn có một cơ sở mã nhất quán, tuân theo một số phương pháp và mẫu và tránh những phương pháp khác. Họ có một tầm nhìn. Các nhà phát triển cũng có ý tưởng của họ. Thông thường, họ không nhận thức được ý định của tiền bối. Nó yêu cầu phát sóng nhất quán hoặc một môi trường phụ trợ, điều này hiếm khi xảy ra. Chúng ta hãy nhìn vào hình ảnh sau đây. Bạn có thể thấy hai tầm nhìn của những người tham gia đánh giá mã khác nhau như thế nào. Sau lần lặp đầu tiên, chúng bắt đầu liên kết, nhưng vẫn còn một con đường để đi. Người đánh giá điều chỉnh tầm nhìn của một người và tác giả mã di chuyển theo cách giải thích của các đề xuất. Chúng ta có thể sử dụng phép ẩn dụ "tưởng tượng bạn đã yêu cầu một ngôi nhà và sau đó ngạc nhiên! Đó không phải là ngôi nhà bạn mong đợi". Hoặc chúng ta có thể nhìn vào cốt lõi của nó. Hãy tưởng tượng bạn đã yêu cầu một người đạt được điều gì đó. Sau đó, bạn quay lại và xem kết quả, nhưng bạn trở nên ngạc nhiên trước hàng loạt các quyết định mà người thành công đã đưa ra. Đừng ngạc nhiên, vì bạn không yêu cầu một khuôn khổ ra quyết định cụ thể. Quan điểm giữa các cá nhân Hình ảnh tự nó nói lên điều đó. Bạn có yêu cầu kỹ sư đồng nghiệp của mình khắc phục sự cố thiết kế sau nhiều ngày làm nhiệm vụ không? Hãy tưởng tượng rằng nước rút của bạn kết thúc, và chiếc vé là nguyên nhân gây ra một số căng thẳng khi đứng lên. Bạn sẽ giúp đồng nghiệp của mình hợp nhất nó nhanh nhất có thể. Mặt khác, có thể có một kỹ sư cấp cao đang xem xét mã của cấp dưới. Anh ta có thể yêu cầu anh ta đi một chặng đường dài để sửa chữa quyết định đã đưa ra lúc ban đầu. Tuy nhiên, liệu đây có phải là thời điểm thích hợp để đưa ra những lời khuyên như vậy? Vì vậy, nhiều quyết định đứng trên sự lựa chọn sai lầm rồi. Sản xuất tinh gọn vẫn chưa ảnh hưởng đến lập trình. Tuy nhiên, chúng ta đã có một công cụ từ cuốn sách "Lean Software Development" của Mary Poppendieck và Tom Poppendieck. Công cụ này là bảy lãng phí phát triển phần mềm: Đã hoàn thành một phần công việc, Các tính năng bổ sung, Đang tìm hiểu, Bàn giao, Sự chậm trễ, Chuyển đổi nhiệm vụ, Khuyết tật. Đánh giá mã cổ điển thắng 6 trên 7! 🎉 . Một nhiệm vụ trong bài đánh giá bị bỏ qua hầu hết thời gian. Tôi thường coi giai đoạn phát triển này như một sự xếp hàng hơn là một nơi diễn ra hành động. Tạo một bản đánh giá cũng có một hiệu ứng tâm lý thú vị: "Nhiệm vụ đã sẵn sàng, và nó không phải là công việc của tôi nữa!" Rà soát quy tắc là "vùng đất không có trách nhiệm của ai", đó là lý do tại sao chúng ta thường thấy nó leo thang lên các cấp trên. Công việc đã hoàn thành một phần . Bạn có thể thấy sự phân bổ lại trên biểu đồ BPMN ở trên. Khôi phục bối cảnh đang phân loại lại. Đang học . Nếu chúng tôi trung thực, đây không phải là một sự lãng phí ở đây. Đó là cơ học cốt lõi. Điểm chấp nhận . Thiết kế xem xét mã có hai loại chậm trễ mà chúng ta đã thảo luận trước đó. Điều thậm chí còn đáng sợ hơn là vòng lặp của họ. Sự chậm trễ . Mọi người tạm dừng nhiệm vụ của mình để dành sự chú ý cho việc xem xét. Chuyển đổi tác vụ . Đánh giá là tốt để tìm ra các vấn đề về thẩm mỹ nhưng không phải lỗi thiết kế, điều này sẽ gây hại nhiều nhất. Việc thiếu động lực đề cập ở trên để yêu cầu các nghiên cứu sinh thay đổi đáng kể dẫn đến những khiếm khuyết đáng kể trong dự án. Những khiếm khuyết Chúng tôi đã đề cập đến các vấn đề của việc đánh giá mã từ nhiều phía. Chúng ta có thể làm gì để khắc phục quá trình này? Thiết kế lại Mã xem xét Trong phần này, chúng tôi sẽ đề cập đến các chủ đề tương tự như phần trước nhưng từ quan điểm sửa chữa. Sửa cấu trúc quy trình Ở đây chúng tôi có một tác giả mã đang chờ đánh giá hoàn tất và một phiên lập trình ghép nối sau tổng quan của người đánh giá. Trong quy trình được đề xuất, chúng ta có thể thấy một số thay đổi đáng kể so với quy trình trước đó: Không có vòng xem xét vô hạn tiềm năng nữa; Thời gian chờ duy nhất trong khoảng thời gian không xác định, chúng tôi cũng sẽ xử lý nó; Không cần khôi phục ngữ cảnh hoặc giải thích phản hồi cho tác giả mã. Nhận xét bây giờ đóng vai trò như lời nhắc nhở cho cặp đôi. Điều kiện tiên quyết cốt lõi để quá trình này xảy ra là gì? Bây giờ một nhóm cần một vai trò bổ sung. Nó ngụ ý rằng ai đó thực hiện các hoạt động phụ trợ, ví dụ, xử lý nợ kỹ thuật hoặc sửa các lỗi có mức độ ưu tiên thấp hơn. Khi đánh giá mã xuất hiện trên radar, người này ngay lập tức bỏ nhiệm vụ hiện tại và nhảy vào PR đã đến. Nếu bạn đã bao giờ tự hỏi tại sao bạn cần một số điểm sơ sài trong cấu trúc công việc của mình, thì đây là một ví dụ. Nếu mọi người đều bận rộn với các tính năng ưu tiên hàng đầu, bạn sẽ phân phối chúng sau. Khắc phục sự phân kỳ tầm nhìn Chúng ta thảo luận gì về đánh giá mã? Các quyết định được thực hiện trong quá trình phát triển. Chúng tôi đã thực hiện một số trong số chúng một giờ trước và một số khác cách đây một tuần. Các lựa chọn của chúng tôi đứng trên nhau và không độc lập. Làm thế nào thú vị để bạn tìm thấy một cơ hội để đặt câu hỏi về một trong những quyết định đầu tiên mà hàng trăm người tiếp theo đứng? Bạn có thể không hài lòng về cơ hội. Thời điểm thích hợp nhất để thảo luận về các quyết định thiết kế là khi chúng xuất hiện. Chúng tôi cần một loại đánh giá bổ sung: đánh giá thiết kế. Đôi khi, khi vấn đề là thách thức, tốt hơn là bạn nên dành một chút thời gian cho kế hoạch và thảo luận với những đồng nghiệp hiểu biết của bạn. Có một câu ngạn ngữ quân sự nổi tiếng: Không có kế hoạch chiến đấu nào tồn tại khi tiếp xúc với kẻ thù. Nếu chúng tôi dịch nó sang ngôn ngữ tại các hệ thống, chúng tôi sẽ nhận được một cái gì đó như: "Hệ thống chắc chắn sẽ cần điều chỉnh hành vi của nó khi có phản hồi đầu tiên". Trong trường hợp lập trình, phản hồi sẽ là những vấn đề chúng tôi gặp phải khi cố gắng triển khai thiết kế vào hệ thống của mình. Một số quyết định cần được sửa đổi. Chúng tôi sẽ cần thay đổi chúng và một lần nữa phân tích tầm nhìn của chúng tôi với một người đánh giá. Adam Thornhill, trong cuốn sách "Thiết kế phần mềm X-Rays" choáng ngợp của mình, đã đề xuất một phương pháp: Đó là lý do tại sao tôi khuyên bạn nên thực hiện hướng dẫn mã ban đầu của mình sớm hơn nhiều. Thay vì đợi hoàn thành một tính năng, hãy tập trình bày và thảo luận về mỗi lần triển khai khi hoàn thành một phần ba. Tập trung ít hơn vào chi tiết và nhiều hơn vào cấu trúc tổng thể, các yếu tố phụ thuộc và thiết kế phù hợp với miền vấn đề như thế nào. Tất nhiên, việc hoàn thành một phần ba là chủ quan, nhưng nó phải là điểm có cấu trúc cơ bản, hiểu rõ vấn đề và tồn tại bộ thử nghiệm ban đầu. Ở giai đoạn đầu này, việc làm lại thiết kế vẫn là một giải pháp thay thế khả thi và việc giải quyết các vấn đề tiềm ẩn ở đây sẽ mang lại lợi ích lớn. Tôi đã đặt ra một thuật ngữ cho nhóm của mình để có một ngôn ngữ thuận tiện: đánh giá bộ xương. Tôi hy vọng nó sẽ giúp phản ánh ý tưởng đằng sau hoạt động. Quan điểm tinh gọn về quy trình được đề xuất Quy trình được đề xuất loại bỏ hoặc giải quyết đáng kể các chất thải được phát hiện. . Không được phép chuyển sang tác vụ khác trong thời gian dự kiến đối với tác giả mã, vì vậy không có công việc nào được thực hiện một phần do người dùng thực hiện. Các hoạt động được thực hiện một phần ít ưu tiên hơn là sự đánh đổi. Công việc đã hoàn thành một phần . Không có phân cấp lại nào xảy ra khi có rất ít thời gian trôi qua giữa việc hoàn thành mã hóa và lập trình cặp. Đang học . Chúng tôi đã rút ngắn đáng kể sự chậm trễ của người đánh giá mã và loại bỏ tác giả. Sự chậm trễ . Không còn được phép cho một tác giả và được quản lý cho một người đánh giá. Chuyển đổi tác vụ . Giờ đây, việc sửa chữa các lỗi thiết kế trở nên rẻ hơn, và điều quan trọng nhất trong số đó, các lỗi thiết kế, đã được sửa chữa. Những khiếm khuyết Suy nghĩ bổ sung Chúng tôi đã xem xét phương pháp đánh giá mã cho một tác giả và một người đánh giá duy nhất. Khi nhiều người đánh giá xuất hiện hơn, các vấn đề sẽ nhân lên. Vì vậy, thật không may, không phải tất cả các lỗi đều trở nên nông cạn nếu gần đây bạn thêm người để xem xét tất cả các quyết định bạn đã đưa ra. Thay vào đó, bạn sẽ thực hiện hợp nhất mã của mình sau này. Hai trong số những vấn đề khó khăn nhất mà tôi phải đối mặt khi cố gắng giới thiệu quy trình được đề xuất là: Các nhà phát triển coi giai đoạn xem xét như một công việc đã hoàn thành. Các nhà quản lý cảm thấy kinh hoàng khi đề xuất đưa sự dư thừa vào công việc hàng ngày. Thật tuyệt khi họ không quản lý đội lính cứu hỏa. Cách chữa trị cho vấn đề đầu tiên là sự lặp lại và tốc độ. Vấn đề thứ hai phức tạp hơn. Ở đây tôi muốn trích dẫn cuốn sách "Các thước đo linh hoạt khả thi cho khả năng dự đoán" của Daniel Vacanti: Có rất nhiều chiến lược mà FedEx áp dụng, nhưng chiến lược có lẽ quan trọng nhất là tại bất kỳ thời điểm nào FedEx đều có máy bay trống trên không. Vâng, tôi đã nói những chiếc máy bay trống rỗng. Bằng cách đó, nếu một vị trí bị quá tải hoặc nếu các gói hàng bị bỏ lại vì một máy bay theo lịch trình thường xuyên đã đầy thì một máy bay trống sẽ được chuyển hướng (đúng lúc cần thông báo) đến vị trí sự cố. Tại bất kỳ thời điểm nào FedEx đều có "phụ tùng trong không khí"! Nếu bạn là người quản lý, hãy cân nhắc điều này vào lần tiếp theo khi lập kế hoạch tối đa hóa việc sử dụng. Chúng tôi có hài lòng với bản cập nhật không? Vâng, nó trông đẹp hơn những gì chúng ta có bây giờ. Chúng ta có thể làm tốt hơn không? Có, chúng tôi có thể. Mục tiêu là loại bỏ việc xem xét mã tại thời điểm khi chúng tôi có thể đảm bảo rằng tất cả chất lượng cần thiết đã có trong mã. Để đạt được điều này, chúng ta cần xây dựng một khuôn khổ ra quyết định bổ trợ để giúp các nhà phát triển áp dụng những gì được coi là một phương pháp tốt và tránh một phương pháp xấu. Tôi chưa bao giờ nghe nói về một khuôn khổ như vậy, nhưng linters in-IDE là một bước tiến tới nó. Cảm ơn bạn đã đọc! Viết bình luận nếu bạn muốn thảo luận về các ý tưởng được mô tả.