Lúc đầu, việc hiểu một dự án lớn và cũ luôn khó khăn. Kiến trúc là một trong những hoạt động đánh giá kiến trúc sư. Thông thường bạn phải làm việc với các dự án lớn, cũ và kết quả phải được giao trong một tuần.
Làm cách nào để đánh giá một dự án có 100 nghìn dòng mã trở lên trong một tuần mà vẫn cung cấp kết quả thực sự hữu ích cho khách hàng.
Hầu hết các kiến trúc sư và trưởng nhóm kỹ thuật đều gặp phải những đánh giá dự án tương tự. Điều này có thể giống như một quy trình bán chính thức hoặc như một dịch vụ riêng biệt được thực hiện ở công ty chúng tôi, bằng cách này hay cách khác, hầu hết các bạn đều đã giải quyết vấn đề này.
Bản gốc bằng tiếng Anh dành cho những người bạn không nói tiếng Nga của bạn có ở đây: .
Cách tiếp cận của công ty chúng tôi
Tôi sẽ cho bạn biết cách thức hoạt động trong công ty của chúng tôi và cách tôi hành động trong những tình huống tương tự, nhưng bạn có thể dễ dàng thay đổi cách tiếp cận này tùy theo nhu cầu của dự án và công ty của bạn.
Có hai loại đánh giá kiến trúc.
Nội địa – chúng tôi thường làm việc đó cho các dự án trong công ty. Bất kỳ dự án nào cũng có thể yêu cầu đánh giá kiến trúc vì một số lý do:
- Nhóm cho rằng dự án của họ là hoàn hảo và điều này thật đáng ngờ. Chúng tôi đã gặp những trường hợp như vậy và thường trong những dự án như vậy, mọi thứ đều không còn lý tưởng nữa.
- Nhóm muốn thử nghiệm dự án và giải pháp của họ.
- Nhóm biết mọi thứ là xấu. Họ thậm chí có thể liệt kê các vấn đề và nguyên nhân chính nhưng muốn có danh sách đầy đủ các vấn đề và đề xuất để cải thiện dự án.
Bên ngoài là một quá trình chính thức hơn so với đánh giá nội bộ. Khách hàng luôn chỉ đến trong một trường hợp, khi mọi thứ đều tệ - rất tệ. Thông thường khách hàng hiểu rằng có những vấn đề toàn cầu, nhưng không thể xác định chính xác nguyên nhân và chia chúng thành các thành phần.
Đánh giá kiến trúc cho một máy khách bên ngoài là một trường hợp phức tạp hơn. Quá trình này nên chính thức hơn. Các dự án luôn lớn và cũ. Họ có rất nhiều vấn đề, lỗi và mã quanh co. Một báo cáo về công việc đã hoàn thành phải được hoàn thành trong vòng tối đa vài tuần, trong đó phải bao gồm các vấn đề chính và đề xuất cải tiến. Vì vậy, nếu chúng ta xử lý việc đánh giá bên ngoài dự án thì việc đánh giá bên trong sẽ dễ dàng như vậy. Hãy xem xét trường hợp khó khăn nhất.
Đánh giá kiến trúc dự án doanh nghiệp
Một dự án điển hình để đánh giá là một dự án doanh nghiệp lớn, cũ và có rất nhiều vấn đề. Một khách hàng đến gặp chúng tôi và yêu cầu chúng tôi sửa chữa dự án của anh ấy. Giống như với một tảng băng trôi, khách hàng chỉ nhìn thấy phần nổi của vấn đề và không biết có gì ở dưới nước (ở độ sâu của mã).
Các vấn đề mà khách hàng có thể phàn nàn và có thể nhận thấy:
- Vấn đề hiệu năng
- Vấn đề về khả năng sử dụng
- Triển khai dài hạn
- Thiếu đơn vị và các bài kiểm tra khác
Các vấn đề mà rất có thể khách hàng không biết nhưng chúng có thể hiện diện trong dự án:
- Vấn đề an toàn
- Vấn đề thiết kế
- Kiến trúc sai
- Lỗi thuật toán
- Công nghệ không phù hợp
- Nợ kỹ thuật
- Quy trình phát triển sai
Quy trình xem xét kiến trúc chính thức
Đây là một quy trình chính thức mà chúng tôi tuân theo với tư cách là một công ty, nhưng bạn có thể tùy chỉnh nó tùy thuộc vào công ty và dự án của bạn.
Yêu cầu từ khách hàng
Khách hàng yêu cầu đánh giá kiến trúc của dự án hiện tại. Người chịu trách nhiệm về phía chúng tôi thu thập thông tin cơ bản về dự án và lựa chọn các chuyên gia cần thiết. Tùy thuộc vào dự án, đây có thể là các chuyên gia khác nhau.
Kiến trúc sư giải pháp – người chịu trách nhiệm chính về đánh giá và điều phối (và thường là người duy nhất).
Xếp chồng các chuyên gia cụ thể – .Net, Java, Python và các chuyên gia kỹ thuật khác tùy thuộc vào dự án và công nghệ
Chuyên gia đám mây – đây có thể là kiến trúc sư đám mây Azure, GCP hoặc AWS.
Cơ sở hạ tầng – DevOps, Quản trị viên hệ thống, v.v.
Các chuyên gia khác – chẳng hạn như dữ liệu lớn, học máy, kỹ sư hiệu suất, chuyên gia bảo mật, trưởng nhóm QA.
Thu thập thông tin về dự án
Bạn nên thu thập càng nhiều thông tin càng tốt về dự án. Bạn có thể sử dụng các kỹ thuật khác nhau tùy theo tình huống:
- Bảng câu hỏi và các phương thức liên lạc khác qua thư. Cách không hiệu quả nhất.
- Các cuộc họp trực tuyến.
- Các công cụ trao đổi thông tin đặc biệt như: Google doc, Confluence, repositories, v.v.
- Các cuộc họp “trực tiếp” trên trang web. Cách hiệu quả nhất và tốn kém nhất.
Bạn nên nhận được gì từ khách hàng?
Thông tin cơ bản. các dự án về là gì? Mục đích và giá trị của nó. Mục tiêu và kế hoạch chính cho tương lai. Mục tiêu và chiến lược kinh doanh. Các vấn đề chính và kết quả mong muốn.
Thông tin dự án. Ngăn xếp công nghệ, khung công tác, ngôn ngữ lập trình. Triển khai tại chỗ hoặc trên nền tảng đám mây. Nếu dự án ở trên đám mây thì dịch vụ nào sẽ được sử dụng. Những mẫu kiến trúc và thiết kế nào đã được sử dụng.
những yêu cầu phi lý. Tất cả các yêu cầu liên quan đến hiệu suất, tính khả dụng và tính dễ sử dụng của hệ thống. Yêu cầu an toàn, v.v.
Các trường hợp sử dụng cơ bản và luồng dữ liệu.
Truy cập mã nguồn. Phần quan trọng nhất! Bạn chắc chắn sẽ có quyền truy cập vào kho lưu trữ và tài liệu về cách xây dựng dự án.
Tiếp cận cơ sở hạ tầng. Sẽ thật tuyệt nếu có quyền truy cập vào sân khấu hoặc cơ sở hạ tầng sản xuất để làm việc với hệ thống trực tiếp. Sẽ là một thành công lớn nếu khách hàng có các công cụ để giám sát cơ sở hạ tầng và hiệu suất. Chúng ta sẽ nói về những công cụ này trong phần tiếp theo.
Tài liệu. Nếu khách hàng có tài liệu thì đây là một khởi đầu tốt. Nó có thể đã lỗi thời nhưng vẫn là một khởi đầu tốt. Không bao giờ tin tưởng vào tài liệu - hãy kiểm tra nó với khách hàng, trên cơ sở hạ tầng thực và trong mã nguồn.
Quy trình đánh giá kiến trúc
Làm thế nào một người có thể xử lý một lượng thông tin lớn như vậy trong thời gian ngắn như vậy? Trước hết, hãy song song hóa công việc.
DevOps nên xem xét cơ sở hạ tầng. Dẫn công nghệ vào mã. Kỹ sư hiệu suất để xem số liệu hiệu suất. Một chuyên gia cơ sở dữ liệu nên tìm hiểu sâu hơn về cấu trúc dữ liệu.
Nhưng đây là trường hợp lý tưởng khi bạn có nhiều nguồn lực. Thông thường, một đến ba người đánh giá một dự án. Bạn thậm chí có thể tự mình tiến hành ước tính, điều này thường xảy ra nếu bạn có kiến thức và kinh nghiệm phù hợp trong tất cả các lĩnh vực của dự án. Trong trường hợp này, bạn cần tự động hóa tất cả các quy trình càng nhiều càng tốt.
Thật không may, bạn sẽ phải đọc tài liệu theo cách thủ công. Với lượng kinh nghiệm phù hợp, bạn có thể nhanh chóng hiểu được chất lượng của tài liệu. Điều gì đúng và điều gì rõ ràng không trùng khớp với thực tế. Đôi khi bạn có thể thấy kiến trúc trong tài liệu sẽ không bao giờ hoạt động trong đời thực. Đây là yếu tố kích thích bạn suy nghĩ về cách nó được thực hiện trên thực tế trong dự án.
Các công cụ hữu ích để tự động hóa việc đánh giá dự án
Đánh giá mã là một bài tập đơn giản. Bạn có thể sử dụng máy phân tích mã tĩnh để hiển thị cho bạn các vấn đề về thiết kế, hiệu suất và bảo mật. Dưới đây là một vài trong số họ:
là một công cụ tuyệt vời cho một kiến trúc sư. Nó sẽ cho bạn thấy bức tranh toàn cảnh, sự phụ thuộc giữa các mô-đun và các lĩnh vực tiềm năng để tái cấu trúc. Giống như tất cả các công cụ tốt, nó có giá khá cao nhưng bạn có thể tận dụng phiên bản dùng thử 30 ngày.
- một công cụ cũ tốt. Một công cụ để phân tích mã tĩnh. Cho phép bạn xác định mã xấu, lỗi và sự cố bảo mật cho hơn 20 ngôn ngữ lập trình.
Tất cả các nhà cung cấp đám mây đều có công cụ giám sát cơ sở hạ tầng. Điều này sẽ cho phép bạn đánh giá chính xác hiệu quả của cơ sở hạ tầng về mặt chi phí và hiệu suất. Đối với AWS đây là . Thật dễ dàng cho Azure .
Giám sát và ghi nhật ký hiệu suất bổ sung sẽ giúp tìm ra các vấn đề về hiệu suất ở mọi cấp độ. Bắt đầu từ cơ sở dữ liệu với các truy vấn không hiệu quả, phần phụ trợ và kết thúc bằng giao diện người dùng. Ngay cả khi khách hàng chưa cài đặt những công cụ này trước đây, bạn vẫn có thể tích hợp chúng vào hệ thống hiện có khá nhanh để xác định các vấn đề về hiệu suất.
Như mọi khi, các công cụ tốt đều có giá trị. Tôi có thể giới thiệu một vài công cụ trả phí. Tất nhiên bạn có thể sử dụng nguồn mở nhưng nó sẽ khiến bạn mất nhiều thời gian hơn. Và điều này nên được thực hiện trước chứ không phải trong quá trình đánh giá kiến trúc.
– một công cụ để đánh giá hiệu suất ứng dụng
– Dịch vụ giám sát hệ thống đám mây
Có rất nhiều công cụ có sẵn để kiểm tra bảo mật. Lần này tôi sẽ giới thiệu cho bạn một công cụ quét hệ thống miễn phí.
– một công cụ để quét các ứng dụng web để tuân thủ các tiêu chuẩn bảo mật.
Hãy đặt mọi thứ lại với nhau thành một tổng thể.
Chuẩn bị báo cáo
Bắt đầu báo cáo của bạn với dữ liệu bạn đã thu thập từ khách hàng. Mô tả mục tiêu, ràng buộc, yêu cầu phi chức năng của dự án. Sau này, tất cả dữ liệu đầu vào cần được đề cập: mã nguồn, tài liệu, cơ sở hạ tầng.
Bước tiếp theo. Liệt kê mọi vấn đề bạn tìm thấy theo cách thủ công hoặc sử dụng các công cụ tự động. Đặt các báo cáo lớn được tạo tự động ở cuối phần ứng dụng. Cần có bằng chứng ngắn gọn và súc tích về các vấn đề được tìm thấy.
Ưu tiên các vấn đề được tìm thấy về lỗi, cảnh báo, thang đo thông tin. Bạn có thể chọn thang đo của riêng mình, nhưng đây là thang đo được chấp nhận rộng rãi.
Là một kiến trúc sư thực thụ, bạn có trách nhiệm đưa ra các khuyến nghị để khắc phục các vấn đề được tìm thấy. Mô tả những cải tiến và giá trị kinh doanh mà khách hàng sẽ nhận được. Cách thể hiện giá trị doanh nghiệp từ chúng ta đã thảo luận trước đó.
Chuẩn bị một lộ trình với những lần lặp lại nhỏ. Mỗi lần lặp lại phải bao gồm thời gian hoàn thành, mô tả, lượng tài nguyên cần thiết để cải tiến, giá trị kỹ thuật và giá trị kinh doanh.
Chúng tôi hoàn thành việc đánh giá kiến trúc và cung cấp cho khách hàng một báo cáo
Không bao giờ chỉ gửi một báo cáo. Nó có thể không được đọc hoặc có thể không được đọc và hiểu nếu không có lời giải thích thích hợp. Nói tóm lại, giao tiếp trực tiếp giúp loại bỏ những hiểu lầm giữa mọi người. Bạn nên lên lịch gặp khách hàng và trao đổi về những vấn đề được tìm thấy, tập trung vào những vấn đề quan trọng nhất. Điều đáng làm là thu hút sự chú ý của khách hàng đến những vấn đề mà họ thậm chí có thể không nhận thức được. Chẳng hạn như các vấn đề bảo mật và giải thích chúng có thể tác động đến doanh nghiệp như thế nào. Hiển thị lộ trình của bạn với các cải tiến và thảo luận về các tùy chọn khác nhau phù hợp hơn với khách hàng. Đây có thể là thời gian, nguồn lực, khối lượng công việc.
Để tóm tắt cuộc họp của bạn, hãy gửi báo cáo của bạn cho khách hàng.
Kết luận
Đánh giá kiến trúc là một quá trình phức tạp. Để thực hiện đánh giá đúng cách bạn cần phải có đủ kinh nghiệm và kiến thức.
Có thể cung cấp cho khách hàng những kết quả hữu ích cho họ và doanh nghiệp của họ chỉ trong một tuần. Ngay cả khi bạn làm điều đó một mình.
Dựa trên kinh nghiệm của tôi, nhiều cải tiến đã được tải xuống ở giữa và đôi khi chưa bao giờ bắt đầu. Những người chọn ý nghĩa vàng cho mình và chỉ thực hiện một phần cải tiến hữu ích nhất cho doanh nghiệp với chi phí lao động tối thiểu đã cải thiện đáng kể chất lượng sản phẩm của họ. Những người không làm gì có thể đóng dự án hoàn toàn sau một vài năm.
Mục tiêu của bạn là cho khách hàng thấy những cải tiến tối đa với mức giá tối thiểu.
Các bài viết khác từ phần bạn có thể đọc lúc rảnh rỗi.
Tôi chúc bạn mã sạch và quyết định kiến trúc tốt.
Nhóm facebook của chúng tôi - .
Nguồn: www.habr.com