(Bản dịch từ link gốc https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html)

Một năm trước, tôi bắt đầu làm việc toàn thời gian tại Bloomberg. Đó là khi tôi tưởng tượng viết bài này.Tôi tưởng tượng mình có đầy những ý tưởng mà tôi có thể thốt ra trên giấy khi đến lúc. Chỉ một tháng sau, tôi nhận ra rằng nó sẽ không dễ dàng như vậy: tôi đã quên mất những điều tôi đã học. Nó trở nên nội tâm đến mức tâm trí tôi lừa tôi tin rằng tôi luôn biết nó, hoặc nó đánh trượt tâm trí của tôi.

 

Đó là một trong những lý do tôi bắt đầu ghi Nhật ký. Mỗi ngày, bất cứ khi nào tôi gặp một tình huống thú vị, tôi đều ghi lại nó. Tất cả là nhờ ngồi cạnh một kỹ sư phần mềm cao cấp, tôi có thể quan sát chặt chẽ những gì họ đang làm và nó khác với những gì tôi sẽ làm. Chúng tôi đã lập trình cặp rất nhiều, điều này làm cho việc này dễ dàng hơn. Hơn nữa, trong văn hóa đội của tôi, họ không cau mày với những kẻ rình mò phía sau người viết mã. Bất cứ khi nào tôi cảm nhận được điều gì đó thú vị đang diễn ra, tôi sẽ lăn lộn và xem những gì đang xảy ra. Tôi luôn luôn có ngữ cảnh, nhờ vào theo dõi thường xuyên.

Tôi ngồi cạnh một kỹ sư phần mềm cao cấp trong một năm. Đây là những gì tôi học được.

—– Review tiep —–

Viết mã

Cách gọi tên

Một trong những điều đầu tiên tôi làm việc là UI React. Chúng tôi đã có một nhà ở thành phần chính mỗi thành phần khác. Tôi thích một chút hài hước trong mã của tôi, và tôi muốn đặt tên nó là GodComponent . Đến thời gian xem xét mã, và đó là khi tôi hiểu tại sao việc đặt tên lại khó khăn.

Có hai điều khó khăn trong khoa học máy tính: vô hiệu hóa bộ đệm, đặt tên và lỗi do lỗi một. – Leon Bambrick

Mỗi đoạn mã tôi rửa tội đều có một ý nghĩa ngầm kèm theo nó. GodComponent ? Đó là thành phần mà tất cả những thứ nhảm nhí mà tôi không thể bận tâm để đặt đúng chỗ. Nó chứa tất cả mọi thứ. Nếu tôi gọi nó là LayoutComponent , tương lai tôi sẽ nhận ra rằng tất cả những gì nó làm là gán bố cục. Nó không có nhà nước.

Một lợi ích tuyệt vời khác mà tôi phát hiện ra là: Nếu nó có vẻ quá lớn, như một LayoutComponent chứa hàng tấn logic kinh doanh, tôi sẽ biết rằng đã đến lúc phải cấu trúc lại, bởi vì logic kinh doanh không thuộc về nó. Với tên GodComponent , logic kinh doanh trong đó sẽ không tạo ra sự khác biệt.

Đặt tên cho cụm của bạn? Đặt tên cho chúng sau khi dịch vụ chạy trên chúng là tuyệt vời, cho đến khi bạn bắt đầu chạy một cái gì đó khác trên chúng. Chúng tôi đã kết thúc việc đặt tên cho họ với tên nhóm của chúng tôi.

Đó là cùng một ý tưởng với các chức năng. doEverything() là một cái tên khủng khiếp và sự phân nhánh rất nhiều. Nếu chức năng này làm mọi thứ, sẽ rất khó kiểm tra các phần cụ thể của chức năng.Cho dù chức năng này có lớn đến đâu, bạn sẽ không bao giờ nghĩ nó quá kỳ lạ, vì xét cho cùng, chức năng này được cho là làm mọi thứ. Đổi tên. Cấu trúc lại.

Đặt tên có ý nghĩa cũng có một mặt trái của nó. Điều gì nếu tên quá ý nghĩa và ẩn giấu một số sắc thái?Ví dụ: đóng phiên không đóng kết nối DB cơ bản khi bạn gọi session.close() trong SQLAlchemy. (Tôi nên có RTFM và ngăn chặn lỗi đó – nói thêm về điều đó trong Gỡ lỗi )

Trong trường hợp này, nghĩ về các tên như x, y, z thay vì count(), close(), insertIntoDB()ngăn việc gán nghĩa ẩn cho chúng – và buộc tôi phải xem xét kỹ những gì chúng đang làm. 2

Tôi chưa bao giờ tưởng tượng rằng tôi sẽ có nhiều hơn một dòng để nói về cách đặt tên công cụ.

Mã kế thừa và nhà phát triển tiếp theo

Bạn đã bao giờ nhìn vào một số mã và cảm thấy nó kỳ lạ? Tại sao họ làm theo cách này? Điều này làm cho không có ý nghĩa.

Tôi có đặc quyền làm việc với một cơ sở mã di sản. Các loại có ý kiến ​​như mã Uncomment mã khi tình huống tìm ra với Mohammad. Bạn làm gì ở đây? Mohammad là ai?

Tôi có thể thực hiện đảo ngược vai trò ở đây – nghĩ về người tiếp theo đến mã của tôi – họ có thấy lạ hay không. Đánh giá ngang hàng giải quyết điều này phần nào. Điều này dẫn tôi đến ý tưởng về bối cảnh: Hãy nhận biết bối cảnh mà nhóm của tôi đang làm việc.

Nếu tôi quên mã, và quay lại mã sau và tôi không thể tạo lại bối cảnh, tôi sẽ đi như sau: Tại sao các f lại làm theo cách này? Điều này làm cho không có cảm giác nào. Ồ, chờ đã, tôi đã làm điều này.

Và đó là nơi tài liệu và nhận xét mã đến.

Tài liệu và bình luận mã

Họ giúp bảo tồn bối cảnh, và chia sẻ kiến ​​thức.

Như Li đã đưa nó vào Cách xây dựng phần mềm tốt , giá trị chính của phần mềm không phải là mã được tạo ra, mà là kiến ​​thức được tích lũy bởi những người sản xuất ra nó.

Giá trị chính trong phần mềm không phải là mã được tạo ra, mà là kiến ​​thức được tích lũy bởi những người sản xuất ra nó.

Chúng tôi có ứng dụng khách ngẫu nhiên này phải đối mặt với điểm cuối API mà dường như không ai sử dụng. Chúng ta chỉ cần xóa nó? Rốt cuộc, đó là nợ công nghệ.

Điều gì sẽ xảy ra nếu tôi nói với bạn, mỗi năm một lần ở một quốc gia cụ thể, 10 nhà báo gửi báo cáo của họ đến điểm cuối đó? Làm thế nào để bạn kiểm tra điều này? Nếu không có tài liệu (không có), chúng tôi không thể. Vì vậy, chúng tôi đã không. Chúng tôi đã xóa điểm cuối đó. Một vài tháng xuống dòng đến thời điểm đó trong năm. Mười nhà báo không thể gửi 10 báo cáo quan trọng vì điểm cuối không còn tồn tại nữa.

Những người có kiến ​​thức về sản phẩm đã rời khỏi đội. Chắc chắn, bây giờ có ý kiến ​​trong mã giải thích điểm cuối là gì.

Từ những gì tôi đã nghe, tài liệu là thứ mà mọi đội bóng phải vật lộn với. Không chỉ tài liệu mã mà các quy trình xung quanh mã.

Chúng tôi chưa tìm ra một giải pháp hoàn hảo cho việc này.

Tôi rất thích phân tích của Antirez về các loại nhận xét mã xứng đáng khác nhau

Cam kết nguyên tử

Nếu bạn phải quay lại (và bạn sẽ. Xem phần Kiểm tra ), liệu cam kết này có ý nghĩa như một đơn vị không?

Trở nên tự tin về việc xóa mã shit

Tôi đã rất khó chịu khi xóa shit hoặc mã lỗi thời. Tôi xem xét những gì đã được viết trước đây thiêng liêng. Suy nghĩ của tôi đi trên mạng Họ phải có một cái gì đó trong tâm trí khi họ viết điều này. Truyền thống và văn hóa so với suy nghĩ nguyên tắc đầu tiên . Đó là điều tương tự đã xảy ra với việc xóa điểm cuối mỗi năm một lần. Tôi đã học quá cụ thể một bài học ở đó. 3

Tôi sẽ cố gắng làm việc xung quanh mã, các tiền bối cố gắng làm việc với nó. Xóa tất cả Một tuyên bố nếu sẽ không bao giờ đạt được? Một chức năng không nên được gọi? Đúng, tất cả đã biến mất. Tôi? Tôi chỉ cần viết chức năng của tôi trên đầu trang. Tôi đã không giảm nợ công nghệ. Nếu bất cứ điều gì, tôi chỉ tăng độ phức tạp mã và định hướng sai. Người tiếp theo sẽ có một thời gian thậm chí còn khó khăn hơn để chắp nối mọi thứ lại với nhau.

Các heuristic tôi hiện đang sử dụng là thế này: Có mã bạn không hiểu và có mã bạn biết bạn sẽ không bao giờ tiếp cận được. Xóa mã bạn sẽ không bao giờ tiếp cận và thận trọng với mã bạn không hiểu.

Nhận xét mã

Mã đánh giá là tuyệt vời cho việc học tập. Đó là một vòng phản hồi bên ngoài về cách bạn viết mã so với cách họ viết nó. Khác biệt là gì? Là một cách tốt hơn so với cách khác? Tôi đã tự hỏi mình câu hỏi này với mỗi bài đánh giá mã tôi đã làm: Tại sao họ lại làm theo cách này? Bất cứ khi nào tôi không thể tìm thấy một câu trả lời phù hợp, tôi sẽ nói chuyện với họ.

Sau tháng đầu tiên, tôi bắt đầu bắt lỗi trong mã đồng đội của mình (giống như họ đang làm cho tôi).Điều này thật điên rồ. Các đánh giá ngang hàng trở nên thú vị hơn đối với tôi – đó là một trò chơi mà tôi mong đợi – một trò chơi để cải thiện ý thức về mã của tôi.

Kinh nghiệm của tôi: Đừng phê duyệt mã cho đến khi tôi hiểu cách thức hoạt động của nó.

Số liệu thống kê Github của tôi

Kiểm tra

Tôi đã yêu thích thử nghiệm rất nhiều đến nỗi tôi cảm thấy không thoải mái khi viết mã trong một cơ sở mã mà không cần kiểm tra.

Nếu toàn bộ ứng dụng của bạn làm một việc (như tất cả các dự án trường học của tôi), thì việc kiểm tra thủ công vẫn ổn 4 . Đó là những gì tôi đã từng làm. Nhưng điều gì xảy ra khi có 100 điều khác nhau mà ứng dụng làm? Tôi không muốn dành nửa giờ để kiểm tra mọi thứ và đôi khi quên mất tất cả những gì tôi cần kiểm tra. Đó là một cơn ác mộng.

Ở đây có kiểm tra và tự động hóa thử nghiệm.

Tôi nghĩ về thử nghiệm như tài liệu. Đó là tài liệu cho các giả định của tôi về mã. Các thử nghiệm cho tôi biết làm thế nào tôi (hoặc người trước mặt tôi) mong đợi mã hoạt động và nơi tất cả những gì họ mong đợi sẽ xảy ra.

Vì vậy, khi tôi viết bài kiểm tra bây giờ, tôi viết với ý nghĩ này:

  1. Chỉ ra cách sử dụng lớp / chức năng / hệ thống mà tôi đang thử nghiệm.
  2. Cho thấy những gì tôi nghĩ có thể đi sai.

Một hệ quả của những điều trên là trong hầu hết các trường hợp, tôi đang thử nghiệm hành vi chứ không phải việc thực hiện. Đây là một ví dụ tôi đã chọn trong giờ nghỉ trong phòng tắm tại Google)

Những điều tôi nhớ ở # 2 là nơi các lỗi đến từ.

Vì vậy, bất cứ khi nào tôi phát hiện ra một lỗi, tôi chắc chắn rằng sửa lỗi mã có một thử nghiệm tương ứng (được gọi là kiểm tra hồi quy) để ghi lại thông tin: Đây là một cách khác mà mọi thứ có thể sai. 5

Tuy nhiên, chỉ viết các bài kiểm tra này không cải thiện chất lượng mã của tôi, viết mã thì không. Nhưng những hiểu biết tôi có được từ việc đọc các bài kiểm tra giúp tôi viết mã tốt hơn.

Đó là bức tranh lớn của thử nghiệm.

Nhưng, đó không phải là loại thử nghiệm duy nhất để làm. Đây là nơi môi trường triển khai đến.

Bạn có thể có các bài kiểm tra đơn vị hoàn hảo, nhưng nếu bạn không có bài kiểm tra hệ thống, điều tương tự sẽ xảy ra:

Khóa hoạt động (?) Nguồn

Điều này cũng đúng với mã được kiểm tra tốt: Nếu bạn không có các thư viện bạn cần trên máy của mình, bạn sẽ gặp sự cố và bị cháy.

  • Có những máy bạn phát triển trên (nguồn của tất cả các máy Nó hoạt động trên máy của tôi! Mem memes).
  • Có những máy bạn thử nghiệm (có thể giống như những máy bạn phát triển).
  • Cuối cùng, có những máy bạn triển khai (xin đừng để nó giống với những máy bạn phát triển)

Nếu có sự không phù hợp về môi trường giữa các máy thử nghiệm và triển khai, bạn sẽ gặp rắc rối. Và đây là nơi môi trường triển khai đến.

Chúng tôi có sự phát triển cục bộ, nằm trong docker – trên máy của tôi.

Chúng tôi có một môi trường dev, nơi các máy có một bộ thư viện (và các công cụ dev) được cài đặt và chúng tôi cài đặt mã chúng tôi viết trên đó. Tất cả các thử nghiệm với các hệ thống phụ thuộc khác có thể diễn ra ở đây.

Sau đó là môi trường beta / giai đoạn, giống hệt như môi trường sản xuất.

Cuối cùng, prod hoặc môi trường sản xuất, là các máy mà mã chạy trên đó và phục vụ khách hàng thực tế.

Ý tưởng là để thử và bắt lỗi mà đơn vị và hệ thống kiểm tra sẽ không. Ví dụ: API không khớp giữa hệ thống yêu cầu và phản hồi.

Tôi đoán mọi thứ sẽ rất khác trong một dự án cá nhân hoặc một công ty nhỏ. Không phải ai cũng có đủ tài nguyên để thiết lập cơ sở hạ tầng của riêng mình. Tuy nhiên, ý tưởng vẫn còn tồn tại với các nhà cung cấp đám mây như AWS và Azure.

Bạn có thể có các cụm riêng biệt được thiết lập cho dev và prod. AWS ECS sử dụng hình ảnh docker để triển khai, vì vậy mọi thứ tương đối nhất quán giữa các môi trường. Một mẹo nhỏ là sự tích hợp giữa các dịch vụ AWS khác. Bạn đang gọi đúng điểm cuối từ môi trường phải không?

Bạn thậm chí có thể tiến thêm một bước: Tải xuống hình ảnh container thay thế cho các dịch vụ AWS khác và thiết lập môi trường chính thức cục bộ bằng cách sử dụng docker-compose. Nó tăng tốc các vòng phản hồi. 6

Có lẽ tôi sẽ có nhiều kinh nghiệm hơn ở đây khi tôi khởi động dự án phụ của mình.

Gây rối

Giảm rủi ro là nghệ thuật giảm rủi ro với mã mà bạn triển khai.

Tất cả các bước bạn có thể làm để giảm nguy cơ thảm họa?

Nếu đó là một thay đổi đột phá mới, làm thế nào bạn có thể đảm bảo sự gián đoạn tối thiểu khi có sự cố xảy ra?

Chúng tôi không cần phải triển khai toàn bộ hệ thống với tất cả những thay đổi mới đó. Làm thế nào tôi không bao giờ nghĩ về điều này!

Thiết kế

Tại sao tôi đặt thiết kế sau khi viết mã và thử nghiệm? Chà, thiết kế có thể đến trước, nhưng nếu tôi không được mã hóa và thử nghiệm trong môi trường tôi đang ở, tôi có lẽ sẽ không giỏi trong việc thiết kế một hệ thống tôn trọng những điều kỳ quặc của môi trường. 7

Có quá nhiều thứ để suy nghĩ khi thiết kế một hệ thống.

  • Số lượng sử dụng là gì?
  • Có bao nhiêu người dùng tồn tại? và sự tăng trưởng dự kiến ​​là gì? (Điều này sẽ chuyển thành có bao nhiêu hàng db)
  • Điều gì có thể là những cạm bẫy trong tương lai?

Tôi cần chuyển đổi nó thành một danh sách kiểm tra thích hợp có tiêu đề Yêu cầu thu thập. Tôi không có đủ kinh nghiệm với nó trong năm nay, đó là điều cần giải quyết trong năm tới tại Bloomberg.

Quá trình này đi ngược lại với Agile – bạn có thể thiết kế bao nhiêu trước khi thực hiện? Đó là một sự cân bằng – và bạn cần chọn khi nào nên làm gì. Khi nào lặn trong cơn đau đầu có ý nghĩa, và khi nào lùi một bước?

Tất nhiên, chỉ thu thập các yêu cầu không phải là tất cả mọi thứ để suy nghĩ. Tôi nghĩ rằng nó cũng được đền đáp để bao gồm các quá trình phát triển trong thiết kế. Những thứ như

  • Phát triển địa phương sẽ hoạt động như thế nào?
  • Chúng tôi sẽ đóng gói và triển khai như thế nào?
  • Làm thế nào chúng ta sẽ làm thử nghiệm đầu cuối?
  • Làm thế nào chúng ta sẽ kiểm tra căng thẳng dịch vụ mới này?
  • Làm thế nào chúng ta sẽ quản lý bí mật?
  • Tích hợp CI / CD?

Gần đây chúng tôi đã phát triển một hệ thống tìm kiếm mới cho BNEF . Làm việc trên này là tuyệt vời.Tôi đã thiết kế phát triển địa phương, tìm hiểu về DPKG (đóng gói và triển khai) và vật lộn với việc triển khai bí mật.

Ai nghĩ triển khai bí mật để sản xuất có thể có được khó khăn đó?

  1. Bạn không thể đặt chúng vào mã, vì khi đó bất cứ ai cũng có thể nhìn thấy chúng.
  2. Đặt chúng như một biến env, như ứng dụng 12 yếu tố gợi ý? Đó là một ý tưởng tốt. Làm thế nào để bạn đặt chúng ở đó? (Truy cập các máy sản xuất để nhập các biến env mỗi khi máy khởi động là một nỗi đau)
  3. Triển khai như một tập tin bí mật? Tập tin đến từ đâu? Làm thế nào là dân cư?

Chúng tôi không muốn mọi thứ phải thủ công.

Cuối cùng, chúng tôi đã đi với một cơ sở dữ liệu với kiểm soát truy cập vai trò (chỉ máy của chúng tôi và chúng tôi có thể nói chuyện với cơ sở dữ liệu). Mã của chúng tôi có được những bí mật từ cơ sở dữ liệu này khi khởi động. Điều này sao chép rất tốt trên dev, beta và prod – với các bí mật trong cơ sở dữ liệu tương ứng.

Một lần nữa, điều này có thể rất khác với một nhà cung cấp đám mây như AWS. Bạn không cần phải suy nghĩ nhiều về bí mật. Nhận tài khoản vai trò của bạn, bí mật đầu vào trong giao diện người dùng và mã của bạn sẽ tìm thấy chúng khi cần. Thật tuyệt vời khi nó đơn giản hóa mọi thứ – nhưng tôi rất vui khi có trải nghiệm để đánh giá cao sự đơn giản.

Thiết kế với bảo trì trong tâm trí

Thiết kế hệ thống rất thú vị. Duy trì chúng? Không nhiều lắm.

Hành trình của tôi thông qua bảo trì đã dẫn tôi đến câu hỏi này. Tại sao và làm thế nào để hệ thống xuống cấp?

Phần đầu tiên không được tán thành những thứ cũ, luôn luôn bổ sung thêm. Một thiên vị đối với bổ sung thay vì xóa. (Nhắc bạn về ai đó?)

Phần thứ hai là thiết kế với một mục tiêu cuối cùng trong tâm trí. Một hệ thống phát triển để làm những việc mà nó không nhất thiết phải làm là không hoạt động cũng như một hệ thống được thiết kế từ đầu để làm điều tương tự. Đây là cách tiếp cận thực hiện một bước thay vì hack đi bằng sự nhanh nhẹn.

Bây giờ tôi biết ít nhất ba cách để giảm tốc độ xuống cấp.

  1. Giữ logic kinh doanh và cơ sở hạ tầng tách biệt: Thông thường cơ sở hạ tầng xuống cấp – mức tăng sử dụng, khung công tác trở nên lỗi thời, lỗ hổng zero-day xuất hiện, v.v.
  2. Xây dựng quy trình xung quanh bảo trì. Áp dụng các bản cập nhật tương tự cho các bit mới và bit cũ. Điều này ngăn chặn sự khác biệt giữa mới và cũ và giữ cho toàn bộ mã hiện đại.
  3. Đảm bảo bạn tiếp tục cắt tỉa tất cả những thứ không mong muốn / cũ của bạn.

Triển khai

Tôi có muốn kết hợp các tính năng lại với nhau hoặc triển khai từng cái một không?

Tùy thuộc vào các quy trình hiện tại, nếu câu trả lời là kết hợp các tính năng lại với nhau, sẽ có một vấn đề.

Câu hỏi đặt ra là tại sao bạn muốn kết hợp các tính năng lại với nhau?

  • Việc triển khai có mất quá nhiều thời gian không?
  • Các đánh giá mã không dễ dàng xảy ra?

Dù lý do là gì, đó là nút thắt để khắc phục.

Tôi biết ít nhất hai vấn đề với bó.

  1. Bạn đang tự chặn một tính năng nếu có lỗi khác.
  2. Bạn đang chống lại, hoặc tăng nguy cơ xảy ra sự cố.

Sau đó, bất cứ quy trình triển khai nào bạn chọn, bạn luôn muốn máy móc của mình giống như gia súc, không giống như thú cưng. Chúng không quý giá. Bạn biết chính xác những gì đang chạy trên mọi máy và cách tái tạo chúng trong trường hợp tử vong. Bạn không buồn khi một máy bị chết, bạn chỉ cần quay một cái mới. Bạn chăn chúng, không nuôi chúng.

Khi mọi việc không như mong muốn

Vì khi có sự cố xảy ra, và họ sẽ làm như vậy, nguyên tắc vàng là giảm thiểu tác động của khách hàng.

Xu hướng tự nhiên của tôi khi mọi thứ đã sai là sửa chữa các vấn đề. Hóa ra, đó không phải là giải pháp tối ưu nhất.

Thay vì sửa chữa những gì đã sai, ngay cả khi đó là một dòng một thay đổi, thì điều đầu tiên cần làm là khôi phục lại. Quay trở lại trạng thái làm việc trước đó. Đây là cách nhanh nhất để đưa khách hàng trở lại phiên bản làm việc.

Chỉ sau đó tôi mới nên xem xét những gì đã sai và sửa những lỗi đó.

Cùng một ý tưởng với một máy bẻ khóa của người Viking trong cụm của bạn – đặt nó xuống, đánh dấu nó không có sẵn, trước khi cố gắng tìm ra những gì sai với máy.

Tôi thấy điều này thật kỳ lạ, làm thế nào xu hướng tự nhiên và bản năng của tôi phân kỳ khỏi giải pháp tối ưu.

Tôi nghĩ rằng bản năng này cũng dẫn tôi xuống con đường dài hơn để giải quyết lỗi. Đôi khi, tôi cho rằng nó không hoạt động vì có gì đó không đúng với những gì tôi đã viết và tôi đi vào đám cỏ trải qua từng dòng mã tôi đã viết. Một cái gì đó như tìm kiếm sâu đầu tiên.

Khi nó trở thành một sự thay đổi cấu hình, nghĩa là, tôi đã không kích hoạt tính năng này ngay từ đầu, nó làm tôi bực mình. Tôi đã rất tối ưu trong quá trình phát hiện lỗi.

Kể từ đó, heuristic của tôi đã thực hiện tìm kiếm theo chiều rộng trước khi tìm kiếm theo chiều sâu, để thoát khỏi các nút cấp cao nhất. Tôi có thể xác nhận những gì bằng cách sử dụng các tài nguyên hiện tại?

  • Là máy lên?
  • Là mã đúng được cài đặt?
  • Là cấu hình tại chỗ?
  • <Cấu hình mã cụ thể>, như định tuyến trong mã có đúng không?
  • Là phiên bản lược đồ đúng?
  • Sau đó, nhận được vào mã.

Chúng tôi nghĩ rằng nginx đã không cài đặt đúng trên máy, nhưng hóa ra, chỉ là cấu hình được đặt thành false.

Tất nhiên, tôi không cần phải làm điều này luôn. Đôi khi, chỉ cần thông báo lỗi là đủ để cắt giảm không gian tìm kiếm ngay với mã của tôi.

Khi tôi không thể tìm ra vấn đề, tôi cố gắng và giữ các thay đổi từ mã thành mã để tìm ra những gì sai đến mức tối thiểu. Số lượng thay đổi càng ít, tôi càng có thể nhanh chóng khắc phục vấn đề thực sự. Giữ các bước nhảy suy luận đến mức tối thiểu.

Bây giờ tôi cũng ghi lại các lỗi đã khiến tôi mất hơn 1 giờ để giải quyết: Tôi còn thiếu gì? Tôi thường quên kiểm tra, như thiết lập định tuyến, đảm bảo phiên bản lược đồ và phiên bản dịch vụ khớp, v.v. Đây là một bước khác để làm quen với ngăn xếp công nghệ tôi sử dụng và một điều chỉ trải nghiệm đưa ra – trực giác để tìm ra chính xác lý do tại sao mọi thứ không hoạt động.

Câu chuyện chiến tranh

Đó là một điệu nhảy giữa các thông số tinh chỉnh và chơi với các số liệu thống kê so với việc khắc phục nguyên nhân cơ bản.

Làm thế nào bài này có thể được hoàn thành mà không có một câu chuyện chiến tranh ? Tôi thích đọc chúng, và tôi đã có ít nhất một để chia sẻ bây giờ.

Đó là câu chuyện về tìm kiếm và SQLAlchemy. Tại BNEF, chúng tôi có rất nhiều nhà phân tích viết báo cáo nghiên cứu. Bất cứ khi nào một báo cáo được công bố, chúng tôi nhận được một tin nhắn. Bất cứ khi nào chúng tôi nhận được một thông báo, chúng tôi sẽ truy cập vào cơ sở dữ liệu của mình thông qua SQLAlchemy, lấy tất cả những thứ chúng tôi cần, chuyển đổi nó và gửi nó đến ví dụ solr của chúng tôi để lập chỉ mục. Bây giờ, thời gian cho lỗi AF kỳ lạ.

Mỗi buổi sáng, việc kết nối với cơ sở dữ liệu sẽ thất bại với lỗi máy chủ MYSQL lỗi đã biến mất. Đôi khi, vào buổi chiều cũng vậy. Các máy móc quay vào buổi chiều, vì vậy đó là điều đầu tiên tôi kiểm tra.Không, lỗi không bao giờ xảy ra khi máy đang quay. Chúng tôi thực hiện hàng ngàn yêu cầu trong suốt cả ngày đến cơ sở dữ liệu, không có yêu cầu nào thất bại. Làm thế nào đến, sau đó, kích hoạt tải rất thấp này sẽ thất bại?

Ồ, có lẽ chúng ta sẽ không kết thúc phiên của mình sau khi giao dịch? Vì vậy, nếu đó là cùng một phiên và yêu cầu tiếp theo xuất hiện sau nhiều năm, chúng tôi đã bỏ lỡ thời gian chờ và máy chủ đã biến mất.Xem nhanh mã và chắc chắn, chúng tôi đang sử dụng trình quản lý ngữ cảnh cho mỗi lần đọc gọi session.close() trên __exit__() .

Sau một ngày trải qua mọi thứ có thể sai, không đi đến đâu, tôi đến làm việc vào sáng hôm sau và có cơ hội gặp gỡ. Các lỗi xảy ra sáng nay là tốt. Và một giây sau lỗi, ba yêu cầu chỉ mục khác đã thành công.Điều này có tất cả các triệu chứng của một phiên không đúng cách đóng. Bạn biết câu chuyện này kết thúc như thế nào.

Session.close() trong phương ngữ mysql của SQLAlchemy không đóng kết nối DB cơ bản, trừ khi bạn đang sử dụng NullPool . Đúng, đó là sửa chữa.

Thật buồn cười khi lỗi này xảy ra đơn giản vì chúng tôi đã không xuất bản báo cáo nghiên cứu vào ban đêm và trong giờ ăn trưa. Và trong đó có một bài học khác – hầu hết các câu trả lời tràn chồng (tất nhiên tôi đã xử lý nó!) Cho lỗi này là điều chỉnh thời gian chờ của phiên hoặc lượng dữ liệu kiểm soát tham số bạn có thể gửi cho mỗi câu lệnh SQL. Không có ý nghĩa với tôi, bởi vì chúng không liên quan nhiều đến vấn đề gốc. Tôi đã kiểm tra rằng kích thước truy vấn của chúng tôi nằm trong giới hạn và chúng tôi đã đóng các phiên ( lol ) để thời gian chờ sẽ không xảy ra.

Chúng tôi có thể khắc phục lỗi này bằng cách tăng giá trị thời gian chờ phiên lên 8 giờ thay vì 1 giờ. Nó đã xuất hiện để khắc phục vấn đề, cho đến lần tiếp theo chúng tôi có một kỳ nghỉ trong tuần – và báo cáo nghiên cứu đầu tiên vào sáng hôm sau sẽ thất bại.

Đó là một điệu nhảy giữa các thông số tinh chỉnh và chơi với các số liệu thống kê so với việc khắc phục nguyên nhân cơ bản.

Giám sát

Đây là điều mà tôi chưa bao giờ nghĩ về việc làm trước đây. Công bằng mà nói, trước khi viết mã toàn thời gian tôi không bao giờ duy trì hệ thống. Tôi chỉ xây dựng chúng, sử dụng chúng trong một tuần và tiếp tục.

Làm việc với hai hệ thống, một hệ thống có khả năng giám sát tuyệt vời và hệ thống còn lại không nhiều, tôi đã đánh giá cao việc giám sát rất nhiều. Tôi không thể sửa lỗi nếu tôi không biết chúng tồn tại.Một trong những cảm giác tồi tệ nhất là tìm hiểu từ khách hàng về lỗi. “Tôi đang làm gì vậy?! Tôi thậm chí không biết những gì đang xảy ra với một hệ thống mà tôi sở hữu?

Tôi nghĩ rằng ba thành phần tạo nên sự giám sát – ghi nhật ký, số liệu và báo động.

Đăng nhập mã, giống như nhật ký của con người , là một quá trình tiến hóa.

Bạn tìm ra những thứ bạn có thể cần theo dõi, bạn đăng nhập những thứ đó, bạn chạy hệ thống của mình. Theo thời gian, bạn tìm thấy một vài lỗi bạn không có đủ thông tin để giải quyết. Đó là thời điểm tốt để tăng cường đăng nhập – mã của bạn thiếu gì?

Tôi nghĩ rằng bạn trực giác tìm ra những gì sẽ quan trọng để đăng nhập. Có rất nhiều sự khác biệt giữa những thứ anh ấy (SWE cao cấp) và tôi đã đăng nhập vào dịch vụ của chúng tôi. Tôi chỉ nghĩ rằng các nhật ký phản hồi yêu cầu sẽ đủ, trong khi anh ta có rất nhiều số liệu như thời gian thực hiện truy vấn, một số cuộc gọi nội bộ cụ thể được thực hiện bởi mã và cả khi nào để xoay vòng nhật ký, tất cả được sắp xếp.

Hầu như không thể gỡ lỗi mọi thứ mà không có nhật ký – nếu bạn không biết trạng thái của hệ thống, làm thế nào để bạn tạo lại nó?

Số liệu có thể được lấy từ các bản ghi hoặc một mã độc lập riêng trong mã. (Giống như gửi các sự kiện đến AWS CloudWatch và Grafana). Bạn quyết định số liệu của mình và gửi các số trong khi mã chạy.

Báo động là chất keo kết hợp mọi thứ lại với nhau trong một hệ thống giám sát tuyệt vời. Nếu một số liệu là số lượng máy hiện đang chạy trong sản xuất, thì con số này giảm xuống 50% là một báo động tuyệt vời để có – bạn biết có gì đó không ổn.

Thất bại đếm trên một ngưỡng nhất định? Đúng, một báo động khác.

Tôi có thể ngủ ngon vào ban đêm, biết nếu có vấn đề gì xảy ra, tôi sẽ thức dậy. (Đợi đã, cái gì?)

Gợi ý này ở một thói quen khác để phát triển. Khi bạn sửa lỗi, bạn không chỉ tập trung vào cách sửa lỗi, mà còn tại sao bạn không tìm ra nó sớm hơn? Đã có báo động tại chỗ? Làm thế nào bạn có thể theo dõi tốt hơn để ngăn chặn các vấn đề tương tự?

Tôi vẫn chưa tìm ra cách giám sát UI. Kiểm tra các thành phần tại chỗ không đủ để biết về những điều không ổn. Đây thường là nơi khách hàng đến và nói với chúng tôi – mọi thứ không ổn.

Phần kết luận

Trong năm qua, tôi đã học được rất nhiều. Tôi rất vui vì tôi đã đưa ra quyết định khi tôi bắt đầu viết bài này – tôi có thể đánh giá cao hơn nhiều về mức độ tôi đã phát triển khi có tài liệu này để xem lại. Và tôi hy vọng có một cái gì đó bạn có thể lấy từ này, quá!

Tôi cũng khá may mắn khi có được một nhóm tuyệt vời – chúng tôi viết mã rất nhiều, chúng tôi cười rất nhiều, chúng tôi có thể thiết kế hệ thống từ đầu và làm việc với nhiều đội khác.

Năm nay, tôi đang ngồi cạnh hai nhà phát triển cấp cao. Chúng ta hãy xem điều này diễn ra như thế nào!Cảm ơn, đội!

Các kỹ sư giỏi tự thiết kế các hệ thống mạnh mẽ hơn và dễ hiểu hơn bởi những người khác. Điều này có hiệu ứng nhân lên, cho phép các đồng nghiệp của họ xây dựng công việc của họ nhanh hơn và đáng tin cậy hơn – Cách xây dựng phần mềm tốt

Những điều tôi không chắc chắn về

Tôi chưa bẻ khóa mã kỹ thuật phần mềm. Vì vậy, phần này phục vụ như một lời nhắc nhở cho tôi: Có quá nhiều thứ để học! Nếu tôi đang làm đúng, danh sách này sẽ còn dài hơn vào năm tới.

  1. Hãy suy nghĩ về mặt trừu tượng hoặc thực hiện?
  2. Tôi có nên có ý kiến ​​mạnh mẽ về cách làm việc? Có lẽ là kết quả của việc bị cắn trước? Tôi đã làm công việc cần thiết để có ý kiến ?
  3. Phát triển các quy trình cho quy trình công việc. Nếu bạn cần thay đổi cách bạn làm mọi thứ vì trường hợp khẩn cấp hoặc sự kiện – thì quá trình có bị hỏng không? Nó có phải là một cái gì đó để sửa chữa?
  4. Các dụng cụ (thư mục nơi bạn đặt các thứ ngẫu nhiên mà bạn không biết đặt ở đâu khác) có mùi mã không?
  5. Làm thế nào để đối phó với tài liệu cho mã và quy trình công việc?
  6. Làm cách nào để theo dõi UI để xem khi nào mọi thứ không ổn?
  7. Dành thời gian để thiết kế hợp đồng API / mã hoàn hảo so với việc hack nó và lặp đi lặp lại nhiều lần, để tìm ra cái gì hoạt động tốt nhất. Cái nào tốt hơn?
  8. Cách dễ dàng vs đúng cách? Tôi không tin đúng cách là luôn luôn vượt trội.
  9. Tự làm mọi thứ so với việc chỉ cho những người không biết cách thực hiện chúng. Cái trước được thực hiện nhanh chóng, cái sau có nghĩa là bạn hiếm khi phải tự làm lại.
  10. Khi tái cấu trúc và ngăn chặn các PRs khổng lồ: Trước đây, nếu tôi đã thay đổi tất cả các thử nghiệm thì tôi sẽ thấy tôi có 52 tệp để thay đổi và điều đó rõ ràng là quá lớn nhưng trước tiên tôi đã nhầm lẫn với mã kiểm tra. Có phải phá vỡ nó có giá trị nó?
  11. Khám phá De-risking hơn nữa. Những gì tất cả các chiến lược tồn tại cho các dự án giảm rủi ro?
  12. Cách thu thập hiệu quả yêu cầu?
  13. Làm thế nào để giảm tỷ lệ xuống cấp hệ thống?

Cảm ơn Hemanth Kumar Veeranki vì đã đọc bản thảo này.

  1. Điều này xảy ra với rất nhiều thứ. Bạn có biết đi xe đạp không? Bạn có thể dạy ai đó không? Nói với họ các bước chính xác bạn đã làm? 
  2. Điều này không có nghĩa là viết mã với các tên x(), y(), z() , mà chỉ nghĩ về chúng như x(), y(), z() . Đừng cho rằng WYSIATI
  3. Hàng rào cổ điển của Chesterton. 
  4. Tôi sẽ không làm điều này nữa mặc dù. Một khi bạn vượt qua bên kiểm tra tự động, bạn không bao giờ quay trở lại? 
  5. Có một cuộc tranh cãi về việc này vượt khỏi tầm kiểm soát, bằng cách có một triệu bài kiểm tra cho mọi thứ có thể sai. Từ những gì tôi đã thấy, đây thực sự không phải là trường hợp. 
  6. Tôi đã không làm điều này trong một thời gian, vì vậy không chắc việc tìm / xây dựng hình ảnh docker cụ thể AWS dễ dàng như thế nào. 
  7. Môi trường ở đây có thể có nghĩa là ngăn xếp công nghệ của bạn. 

 

 

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *