paint-brush
Làm thế nào để trở thành một kỹ sư giỏi hơn: Sợi théptừ tác giả@jaderubick
1,173 lượt đọc
1,173 lượt đọc

Làm thế nào để trở thành một kỹ sư giỏi hơn: Sợi thép

từ tác giả Jade Rubick7m2023/03/17
Read on Terminal Reader

dài quá đọc không nổi

Các sợi thép vượt qua sự phức tạp của thiết kế và giảm bớt khó khăn khi tích hợp.
featured image - Làm thế nào để trở thành một kỹ sư giỏi hơn: Sợi thép
Jade Rubick HackerNoon profile picture

Steel Threads là một cách tiếp cận thiết kế phần mềm mạnh mẽ nhưng ít người biết đến. Tìm hiểu về Chủ đề thép sẽ giúp bạn trở thành một kỹ sư giỏi hơn. Bạn có thể sử dụng chúng để tránh các vấn đề phổ biến như đau tích hợp. Và bạn có thể sử dụng chúng để vượt qua sự phức tạp của thiết kế hệ thống.

Quá tối nghĩa, nó đã bị xóa khỏi Wikipedia vào năm 2013

Làm thế nào không biết là chủ đề thép? Khái niệm này đã bị xóa khỏi Wikipedia vào năm 2013 vì “ý tưởng này không đáng chú ý trong công nghệ phần mềm và chưa nhận được sự đưa tin đáng kể từ các nguồn đáng chú ý.” Hãy thêm vào phạm vi bảo hiểm và cũng nói về lý do tại sao nó là một cách tiếp cận hữu ích.

Chủ đề thép là gì?

Một sợi thép là một phần chức năng rất mỏng luồn qua một hệ thống phần mềm. Chúng được gọi là “luồng” vì chúng len lỏi qua các phần khác nhau của hệ thống phần mềm và thực hiện một trường hợp sử dụng quan trọng.


Chúng được gọi là “thép” vì sợi chỉ trở thành nền tảng vững chắc cho những cải tiến sau này.


Với cách tiếp cận Sợi thép, bạn xây dựng phiên bản mỏng nhất có thể vượt qua các ranh giới của hệ thống và đáp ứng một trường hợp sử dụng quan trọng.

Ví dụ về cách tiếp cận thông thường, có vấn đề

Giả sử bạn đang xây dựng một dịch vụ mới để thay thế một phần cơ sở mã nguyên khối của mình. Cách phổ biến nhất để làm điều này sẽ là


  1. Nhìn vào mã cũ và tìm ra nhu cầu của hệ thống mới.


  2. Thiết kế và xây dựng các API cung cấp các khả năng bạn cần.


  3. Đi vào mã cũ và cập nhật tài liệu tham khảo để sử dụng API mới. Làm điều đó đằng sau một cờ tính năng.

  4. Cắt qua bằng cách sử dụng cờ tính năng.


  5. Khắc phục mọi sự cố xảy ra cho đến khi nó hoạt động, tắt cờ tính năng nếu cần để quay lại đường dẫn mã cũ.


  6. Khi nó ổn định, hãy xóa các đường dẫn mã cũ.


Nghe có vẻ hợp lý đúng không? Chà, đây là cách phổ biến nhất mà các kỹ sư phần mềm vận hành, nhưng cách tiếp cận này có rất nhiều bom mìn.


Những vấn đề tôi sẽ mong đợi trong dự án này?


  1. Có thể hấp dẫn để xây dựng dịch vụ mới theo cách không kết nối với hệ thống cũ. Rốt cuộc, thiết kế có thể cảm thấy tinh khiết hơn. Nhưng bạn cũng đang giới thiệu nhiều thay đổi cấu trúc hơn đáng kể và bạn đang thực hiện những thay đổi này mà không có bất kỳ sự tích hợp nào với hệ thống cũ. Điều này làm tăng nỗi đau tích hợp đáng kể. Kỳ vọng của tôi là tất cả các ước tính cho dự án là không thực tế. Và tôi cho rằng dự án sẽ bị coi là thất bại sau khi hoàn thành, ngay cả khi dịch vụ tạo ra có thiết kế nhìn chung là tốt.


  2. Tôi cho rằng việc chuyển đổi sang hệ thống mới sẽ gặp vấn đề. Sẽ có một loạt vấn đề được phát hiện khi bạn chuyển đổi, đòi hỏi phải quay lại các đường dẫn mã cũ hoặc làm việc tích cực để khắc phục sự cố trong giai đoạn cuối của dự án.


Cả hai điều này đều có thể tránh được, bằng cách không có một sự cắt giảm lớn. Lưu ý rằng ngay cả việc cắt hơn một phần trăm lưu lượng truy cập vào dịch vụ mới bằng cờ tính năng cũng là một phương pháp cắt. Tại sao? Bạn đang cắt giảm tất cả một phần trăm lưu lượng truy cập đó cho tất cả các thay đổi cùng một lúc.


Tôi vẫn không mong đợi nó sẽ diễn ra tốt đẹp. Bạn đang thực hiện các bước quá lớn.

Ví dụ sử dụng một sợi thép

Ngược lại cách tiếp cận đó với cách làm của Steel Thread.


  1. Hãy nghĩ về hệ thống mới mà bạn đang xây dựng. Hãy nghĩ ra một số trường hợp sử dụng hẹp đại diện cho Sợi thép của hệ thống – chúng bao gồm chức năng hữu ích trong hệ thống, nhưng không xử lý tất cả các trường hợp sử dụng hoặc bị hạn chế theo một số cách.


  2. Chọn trường hợp sử dụng bắt đầu càng hẹp càng tốt để cung cấp một số giá trị. Ví dụ: bạn có thể chọn một API mà bạn nghĩ sẽ là một phần của dịch vụ mới.


  3. Xây dựng API mới trong một dịch vụ mới.


  4. Làm cho nó hoạt động cho trường hợp sử dụng hẹp đó. Đối với bất kỳ trường hợp sử dụng nào khác, hãy sử dụng đường dẫn mã cũ. Đưa nó ra sản xuất và sử dụng đầy đủ. (Mẹo: bạn thậm chí có thể thực hiện cả đường dẫn mã mới VÀ cũ và so sánh!)


  5. Sau đó, bạn dần dần thêm các trường hợp sử dụng bổ sung, cho đến khi bạn chuyển tất cả chức năng cần thiết sang dịch vụ mới. Mỗi trường hợp sử dụng là trong sản xuất.


  6. Khi bạn đã hoàn tất, bạn trích xuất mã cũ và các cờ tính năng. Điều này hoàn toàn không rủi ro vì bạn đã chạy trên hệ thống mới.


Đây chẳng phải cũng là mô hình “strangler” sao? Có, nhưng điều này cũng có thể được sử dụng cho các dự án mới. Đọc về một ví dụ về lĩnh vực xanh.

Chủ đề thép tránh đau khi tích hợp và mang lại cho bạn sự tự tin cao hơn

Nỗi đau tích hợp là một trong những nguyên nhân lớn hơn gây ra các vấn đề vào phút cuối trong các dự án. Khi bạn chuyển sang một hệ thống mới, bạn luôn gặp phải những vấn đề mà bạn không ngờ tới. Bạn nên nghi ngờ bất cứ điều gì liên quan đến việc cắt giảm. Làm mọi thứ theo từng bước nhỏ.


Chủ đề thép tích hợp ngay từ đầu, vì vậy bạn không bao giờ gặp nhiều khó khăn trong việc tích hợp để vượt qua. Thay vào đó, bạn có một nỗi đau tích hợp nhỏ, trong suốt quá trình.


Ngoài ra, dịch vụ của bạn không bao giờ cần phải được thử nghiệm trước khi đi vào hoạt động, bởi vì bạn đã thử nghiệm nó dần dần trong suốt quá trình. Bạn biết nó có thể xử lý tải sản xuất. Bạn đã thêm độ trễ mạng nên bạn biết ý nghĩa của điều đó.


Tất cả những bất ngờ được chuyển tiếp và xử lý dần dần, như một phần trong cách bạn dần dần triển khai dịch vụ.


Điều quan trọng là bạn có một hệ thống tích hợp, đang hoạt động và khi bạn làm việc với nó, bạn sẽ giữ cho nó hoạt động. Và bạn thịt nó ra theo thời gian.

Chủ đề thép có thể giúp cắt giảm độ phức tạp

Khi bạn đang thiết kế một hệ thống, bạn có RẤT NHIỀU phức tạp. Xây dựng một tập hợp các yêu cầu cho hệ thống mới có thể là một nỗ lực đầy thách thức.


Khi sử dụng cách tiếp cận Chủ đề thép, bạn chọn một số yêu cầu cốt lõi và diễn đạt chúng theo cách xuyên suốt các lớp của hệ thống và thực hiện thiết kế của bạn. Nó cung cấp một loại cấu trúc khung cho toàn bộ hệ thống.


Việc triển khai Sợi thép đó sau đó trở thành xương cốt để có thể xây dựng các yêu cầu tiếp theo.


Do đó, Chủ đề thép là một tập hợp con của các yêu cầu của một hệ thống.

Chủ đề thép cũng có thể được sử dụng trên Greenfield Work

Giả sử bạn đang triển khai một bản sao của Slack. Chủ đề thép ban đầu của bạn có thể giống như:


“Bất kỳ người nào không được xác thực đều có thể đăng một tin nhắn trong phòng #chung được mã hóa cứng trong tài khoản được mã hóa cứng. Tin nhắn vẫn tồn tại thông qua các lần làm mới trang.”


Lưu ý mức độ hạn chế của Sợi thép ban đầu này. Nó không xử lý xác thực, người dùng hoặc tài khoản. Nó xử lý việc viết tin nhắn và duy trì chúng.


Sợi thép thứ hai của bạn có thể giúp hệ thống trở nên hữu ích hơn. Ví dụ, bạn có thể có một Chủ đề thép cho phép người đăng thông báo chọn tên mà họ đăng bên dưới.


Sợi chỉ thép thứ hai này thực sự chưa làm được gì nhiều. Bạn vẫn chưa có xác thực, tài khoản hoặc thậm chí là khái niệm về người dùng. Nhưng bạn đã tạo một phòng trò chuyện đủ hoạt động để có thể bắt đầu sử dụng nó.


Ngoài ra, hãy lưu ý rằng bạn chưa kéo Chỉ thép qua mọi phần của hệ thống. Nhưng bạn đã bỏ qua các khái niệm về người dùng và tài khoản.

Chủ đề thép cung cấp phản hồi sớm

Lưu ý rằng trong ví dụ nhân bản Slack này, bạn có thể nhận được phản hồi sớm về hệ thống mà bạn đang xây dựng, mặc dù bạn chưa xây dựng nhiều như vậy. Đây là một lý do mạnh mẽ khác để sử dụng Chủ đề thép.


Chỉ sau hai Sợi dây thép đó, nhóm của bạn có thể bắt đầu sử dụng phòng trò chuyện toàn thời gian. Hãy nghĩ xem nhóm của bạn sẽ học được bao nhiêu khi sử dụng hệ thống của bạn. Đó là một hệ thống làm việc.


So sánh điều đó với những gì bạn đã học được khi xây dựng hệ thống Người dùng và Tài khoản, kết nối mọi thứ và cuối cùng là xây dựng một phòng trò chuyện.

Bắt đầu với chủ đề thép

Chủ đề thép thường là một nơi tốt để bắt đầu khi thiết kế các dự án của bạn. Họ tạo ra một bộ xương cho phần còn lại của công việc tiếp theo. Họ đóng đinh các bộ phận cốt lõi của hệ thống để có những nơi tự nhiên để khai thác.


Tôi khuyến khích bạn thử phương pháp có ren thép. Tôi nghĩ bạn sẽ thấy nó có thể biến đổi các dự án của bạn. Hãy cho tôi biết kinh nghiệm của bạn với nó!

Chủ đề thép có liên quan chặt chẽ đến các lát dọc

Bạn có thể đã nghe nói về thuật ngữ "cắt dọc". Tôi mô tả khái niệm này trong bài viết của tôi trên Milestones .


Steel Threads là một kỹ thuật thiết kế phần mềm dẫn đến việc cung cấp phần mềm của bạn theo các lát dọc. Thuật ngữ này có xu hướng được sử dụng để mô tả các lát dọc ban đầu của một hệ thống.


Chúng là những khái niệm liên quan chặt chẽ, nhưng không hoàn toàn giống nhau.


Tôi cũng đã nghe nói về Chỉ thép được gọi là "đạn đánh dấu".


Hình ảnh được cung cấp bởi Steen Jepsen từ Pixabay


Câu chuyện này ban đầu xuất hiện tại: https://www.rubick.com/steel-threads/