Bug Là Gì

Bug là gì? Những tác dụng mang lại từ các việc “chiến đấu” cùng với bug là gì? Đó là 1 trong những câu hỏi ko mấy sung sướng, vày chắc hẳn rằng đa số lập trình sẵn viên hầu hết ao ước có tác dụng tính năng vượt trội, chứ đọng chả mấy ai ưng ý phải bảo trì thành phầm có sẵn hay là fix bug.

Bạn đang xem: Bug là gì

Song, với cá thể tôi, việc đào bới tìm kiếm cùng fix bug đưa về rất nhiều nụ cười cũng giống như cơ hội giao lưu và học hỏi, cải tiến và phát triển nghề nghiệp và công việc. Sau đó là một trong những tổng kết của tôi về:

Bug là gì? 4 ích lợi của việc fix bugCách khắc ghi bug hiệu quả3 bài học kinh nghiệm phệ với 18 tay nghề xương ngày tiết về fix bug

Xem vấn đề làm Developer chất tại bigbiglands.com

Bug là gì? Debug là gì? Fixbug là gì?

Bug là gì? Bug là hầu hết lỗi phần mềm vào lịch trình hoặc khối hệ thống máy tính khiến cho tác dụng không đúng đắn hoặc ko vận động như ý. – Theo Wikipedia

Debug là quy trình tìm tìm và phát hiện tại lỗi vào phần mềm trước lúc launching, gửi sản phẩm mang đến tay người tiêu dùng. Debug ra mắt ngay sau khoản thời gian đầy đủ cái code trước tiên được viết và liên tiếp được tiến hành cho tới Khi kết phù hợp với đầy đủ unit khác của lập trình chế tác thành một sản phầm phần mềm hoàn chỉnh.

Fixbug (sửa lỗi) là quy trình thực hiện ngay sau debug, nhằm mục tiêu gia hạn hoặc nâng cao quality sản phẩm.

Lợi ích của bài toán gặp mặt bug là gì?

Trong mỗi trường phù hợp, chúng ta phần đa có thể học vài điều về phong cách lập trình, sản phẩm hoặc về nghành nghề cơ mà ứng dụng vẫn hoạt động.

Trên không còn, bao gồm 4 lí do thiết yếu, cũng là 4 niềm vui đặc trưng nhất nhưng mà bài toán fix bug hoàn toàn có thể đưa về cho lập trình sẵn viên nlỗi sau:

Mỗi bug luôn luôn dạy bạn điều gì đó

Feedbaông chồng luôn luôn là chiếc chìa khóa của phát triển sản phẩm và mặt khác cũng chính là triết lý căn bản của mô hình agile.

Cả unit testing với iterative development phần đông nhằm chỉ dẫn feedbaông xã nkhô hanh hơn. Với unit testing, bạn cảm nhận feedbachồng về việc code gồm chạy hay là không. Với mỗi release, bạn có thể lắng tai feedback của người sử dụng về các tính năng lạ.

Báo cáo bug cũng chính là bề ngoài feedback khác về code của người sử dụng.

cũng có thể có không ít nguyên nhân gây nên một bug. Ví dụ:

Quý Khách gồm các câu lệnh if lồng nhau với vô tình lại đặt lệnh else ở không nên nhánh.Giả định không đúng chuẩn. Chẳng hạn: truy nã xuất một trực thuộc tính ko lâu dài, ráng là dính NullPointerExceptionKhông bao hàm hết những ngôi trường vừa lòng. Chẳng hạn, các bạn cần trả về một quý hiếm không giống đi giả dụ hàm được điện thoại tư vấn cùng với tđam mê số XHoặc, người tiêu dùng áp dụng phần mềm Theo phong cách mà lại chúng ta bất ngờ cho tới (cơ mà vẫn hợp lệ), và nuốm là bùm! Dính bug!

Đào sâu mày mò ngulặng nhân gây ra bug, các bạn sẽ đúc kết được không ít bài học quý giá.

Code của bạn sẽ dễ dàng debug hơn

Một lúc đã buộc phải vứt công sức, thời hạn ra nhằm kiếm tìm và fix bug, trường đoản cú tự khắc bạn sẽ mong muốn viết code càng dễ debug càng xuất sắc. Bởi do sẽ rất khốn khổ nếu như không tồn tại đều tài liệu quan trọng.

Một vụ việc rất là dễ dàng chạm mặt là các Exceptions (biệt lệ) không đựng dữ liệu có ích.

ví dụ như nlỗi, tất cả một đoạn code hưởng thụ cực hiếm từ 0 – trăng tròn. Bao nhiêu lần chúng ta dính exception chỉ vỏn vẹn “Illegal value”? Nó hoàn toàn không hỗ trợ gì nếu như khách hàng phải sửa lỗi. Chẳng hạn, ví như nhỏng quý hiếm 21 được nhập lệ, exception phải nói là “Illegal value: 21, not in range 0 – 20”.

Việc hiển thị quý hiếm được nhập vào thuộc với mức cực hiếm mong ước, ví dụ cực kỳ có lợi. Giá trị hiện giờ hoàn toàn có thể là 21, -128 xuất xắc 65535. Chúng gần như giúp đỡ bạn có mai dong để đưa ra lỗi, hơn được coi là dòng “Illegal value” ngắn thêm gọn.

Ngay cả Steve sầu McConnell thi thoảng cũng phá nguyên tắc này trong cuốn sách tuyệt đối Code Complete. Chẳng hạn, trong cmùi hương 15, McConnell nêu ra trường hợp phát hiện tại một hình dạng ký từ không hề muốn, tuy thế thông báo lỗi lại không hiển thị ký trường đoản cú đó.

vì vậy, mỗi một khi tra cứu và fix bug, bạn phải từ hỏi: liệu rất có thể chuyển đổi điều gì vào code nhằm về sau không gặp mặt yêu cầu phần đông bug dạng này không? Liệu gồm cách nào hoặc điều gì mình đề xuất làm, nhằm sau này tìm thấy gần như bug dạng này dễ dàng hơn không?

Việc làm cho Developer TP. HCM

Việc có tác dụng Developer Hà Nội

Fix bug đưa về thú vui cho tất cả các bạn với khách hàng hàng

giữa những thú vui nhưng mà các bước lập trình sẵn đem đến, theo tôi, đó là làm điều có lợi cho tất cả những người khác. Fix bug cũng mang lại niềm vui tương tự như, với thậm chí còn nhanh lẹ hơn.

Bởi lẽ, để tạo nên một tính năng mới phải tốn không hề ít thời gian, trong khi Việc fix một bug có thể chỉ việc một giờ đồng hồ đồng hồ đeo tay. Mỗi bug được fix kết thúc vẫn mang đến kích thích sinh lý đang trả thành/đạt được điều gì. Và kia là một trong xúc cảm tốt vời!

Fix bug cũng mang đến niềm vui mang đến người sử dụng (cho dù nghe có vẻ oái oăm). Nếu tức thì từ trên đầu không tồn tại bug, chưa phải fix bug, thì chẳng cần quý khách hàng sẽ vui rộng sao?. Nhưng, từ bỏ kinh nghiệm tay nghề rộng 20 năm lập trình và “chiến đấu” với bug, tôi dám khẳng định: khách hàng đích thực hài lòng mỗi khi thừa nhận về bug đã có được fix dứt gấp rút.

Vấn đề là vậy: Tất cả số đông fan các biết SẼ LUÔN CÓ BUG! Cho yêu cầu, miễn là tất cả fan chuẩn bị sẵn sàng fix thật nkhô nóng ngay khi bug được khui ra.

Thư giãn cùng với video: Fix bug “chất” nhỏng Vinh Râu

Niềm vui của việc giải câu đố

Rất nhiều lập trình viên mê say giải câu đố, như đùa trò Sudoku, giải ô chữ, giải IQ tân oán học, xuất xắc tsi gia những thách thức thiết kế.

Thậm chí, phát âm truyện trinh thám làm thịt bạn cũng đưa về rất nhiều hứng khởi: bạn lần theo những đầu mối để khám phá các cthị trấn đang diễn ra ra sao.

Debug với fix bug cũng thế. Mỗi bug là một bí ẩn nên khám phá.

Thông thường, phản ứng thứ nhất của doanh nghiệp khi trông thấy một báo cáo bug đã là: Không thể nào! Tại sao hoàn toàn có thể xảy ra bug này được?!?

Và cũng từ bỏ kia, các bạn bắt đầu hành trình dài khám phá bí hiểm. quý khách lần theo những mối manh. Logs nói gì? Có báo cáo lỗi như thế nào tự khối hệ thống không? Tại thời đặc điểm đó, khối hệ thống có xẩy ra sự việc gì khác tuyệt không? Gần trên đây có đồ vật gi bị biến đổi ko – phần mềm new, chuyển đổi cấu hình, lưu lại lượt truy vấn ảnh hưởng?

Cách kết quả độc nhất nhằm đánh dấu bug là gì?

Lý bởi của việc rất cần được khắc ghi bug là gì? Để chúng ta có thể giao lưu và học hỏi kết quả độc nhất tự hầu như bug bạn vẫn fix. Pmùi hương pháp nhưng tôi sử dụng là luôn luôn để dành ra vài ba phút ít nhằm ghi chụ lại những thông tin: biểu thị bug, bí quyết fix, bài học kinh nghiệm tay nghề.

Ngulặng tắc

Chỉ ghi chú đông đảo bug cực nhọc nhằn hoặc thực sự thú vui. Đây chưa hẳn là bug tracker.Ghi crúc hầu như bug vày thiết yếu mình tạo ra. (Trừ ngôi trường đúng theo bug của fan khác tuy vậy đầy đủ trúc vị).Ghi lại bug tức thì sau khoản thời gian fix hoàn thành. Tránh lưu giữ nhầm, lưu giữ không cụ thể.

Cách khắc ghi bug

Tôi hay được dùng form dưới đây nhằm ghi lại bug bên dưới dạng file text (bugs.txt). quý khách hàng hoàn toàn có thể tìm hiểu thêm thông qua ví dụ sau:

tin tức nền:

Cách sửa – Quá trình sửa:

Sửa: Nếu chiều lâu năm tìm thấy bởi 0, đặt nó lại bằng 1. Bởi vậy chúng ta vẫn luôn luôn đi tiếp được.Sửa vào file(s): callh/q931_msg.cxxThủ phạm là tôi: Đúng vậy.Thời gian sửa bug: 1 tiếng.

Bài học tập đúc rút được:

Bài học: Đặt “tinh thần lầm chỗ” vào tài liệu của biểu hiện gửi tặng. Giá trị tài liệu hoàn toàn có thể quá rộng làm lịch trình chạy sai. Ngoài ra Khi chiều dài bởi 0 cũng rất có thể là 1 trong dấu hiệu xấu.

Ba bài học bự giành riêng cho lập trình viên

Về coding

Những lỗi phạm đề nghị vào code? Có phải đã quên một else-part? Có bắt buộc một lệnh hotline hệ thống bị thất bại, nhưng mà hồi đáp chưa được check? Làm sao chỉnh sửa code để tránh hầu hết vấn đề này trong tương lai?

Trình từ sự kiện

khi xử lý sự kiện, những thắc mắc sau sẽ rất tất cả ích:

Liệu sự kiện rất có thể đến theo đơn nhất tự khác được không?Sẽ chũm nào còn nếu không nhận được sự kiện này? Sẽ nuốm nào giả dụ sự khiếu nại này ra mắt nhị lần liên tiếp?Thậm chí, nếu như nó ko bao giờ xảy ra, bugs nghỉ ngơi phần lớn phần khác của hệ thống (hoặc của những hệ thống không giống có tương tác) vẫn có thể khiến nó xẩy ra.Quá sớm

Cái này là một trong trường thích hợp quan trọng đặc biệt của phần “Trình từ bỏ sự kiện” ở trên. Nhưng cũng chính vì nó tạo ra một vài lỗi siêu nặng nề tìm kiếm cho nên nó được đưa ra riêng.

Chẳng hạn, ví như bộc lộ cảm nhận vượt sớm, trước khi những các bước thiết lập với khởi rượu cồn hoàn toàn, năng lực chương trình sẽ sở hữu đông đảo biểu thị kỳ cục.

Một ví dụ khác: khi một liên kết được lưu lại là down ngay cả trước lúc nó được chuyển vào danh sách idle. Lúc bắt buộc tìm kiếm lỗi này, bọn họ luôn mang định rằng nó bị đánh dấu down trong khi sẽ ngơi nghỉ trong list idle (mà lại lúc đó tại vì sao nó không được mang ra ngoài danh sách?).

Đó là một sai lạc trong dấn thức của chúng ta khi không xét mang lại trường thích hợp có những vật dụng xảy ra quá nhanh chóng.

“Cái chết êm đềm”

Một trong những phần đông lỗi nặng nề phạt hiện nay duy nhất là khi bọn chúng âm thầm ra đi với chương trình thường xuyên được triển khai nhưng mà ko quăng ra exception làm sao.

Chẳng hạn như các lệnh Hotline khối hệ thống (bind chẳng hạn) trả về mã lỗi nhưng lại không được kiểm soát.

Hoặc nlỗi, phần code nhằm so với biểu lộ chỉ dễ dàng và đơn giản return Lúc phát hiện một yếu tố chưa hợp lệ, trong những khi đáng lẽ cần quăng lỗi.

Cmùi hương trình tiếp tục chạy vào tâm trạng sai, làm cho debug càng khó khăn rộng. Nói chung cực tốt là một trong những lỗi buộc phải được quăng ra càng nhanh càng giỏi.

If

Lệnh if với rất nhiều điều kiện, if (a or b), nhất là lúc được nối lại cùng nhau, if (x) else if (y), tạo ra thừa trời lỗi cho tôi.

Dù cho câu lệnh if về phương diện có mang vượt dễ dàng và đơn giản đi, bọn chúng vẫn dễ bị không đúng Khi có khá nhiều ĐK đi kèm theo.

Bây giờ tôi nỗ lực viết code đơn giản dễ dàng hơn nhằm tách bắt buộc giải pháp xử lý đông đảo câu if phức hợp.

Else

Cũng có thừa trời lỗi là do không xét đến trường phù hợp bỏ qua mất lệnh else. Gần nhỏng toàn bộ trường thích hợp, luôn nên gồm một lệnh else cho từng câu if. mà còn, nếu như bạn đặt một thay đổi phía bên trong lệnh if, kỹ năng cao là các bạn phải để nó ngơi nghỉ phần đa nơi khác nữa.

Một ví dụ khôn xiết liên quan là những đoạn lệnh chất vấn cờ (flag). Quá thuận tiện lúc để ĐK nhằm nhảy cờ, nhưng mà lại rất thú vị quên đặt điều kiện để tại vị lại cờ. Để lá cờ nhảy liên tiếp có chức năng cao là sẽ sở hữu được lỗi trong tương lai.

Xem thêm: Brand Perception Là Gì - Các Yếu Tố Ảnh Hưởng Đến Nhận Thức

Tgiỏi đổi những trả định

Những lỗi khó khăn phòng rời tốt nhất trong quy trình đầu thường xuyên là vì biến đổi đưa định.

Chẳng hạn, thuở đầu hoàn toàn có thể chỉ gồm một sự khiếu nại customer mỗi ngày. Thế là rất nhiều code được viết với mang định này. Một ít ngày sau, kiến tạo biến đổi cho phép các sự khiếu nại customer ra mắt trong ngày. Lúc chuyện này xẩy ra, có thể rất khó khăn để thay đổi không còn toàn bộ trường vừa lòng bị tác động vì chưng thiết kế new.

Nói phổ biến không cực nhọc nhằm kiếm tìm tất cả các phần dựa vào phân biệt. Cái khó khăn là tìm ra rất nhiều phần phụ thuộc vào tiềm ẩn bên phía trong xây dựng cũ.

Chẳng hạn rất có thể gồm phần code thu thập tất cả sự kiện của customers trong một ngày nhất thiết. Một đưa định rõ ràng rất có thể là tác dụng trả về không lúc nào to hơn số lượng customers.

Tôi không biết phương pháp làm sao xuất sắc nhằm đề phòng phần nhiều ngôi trường phù hợp này, nếu bạn nào biết thì gợi ý giúp tôi với nhé.

Logging

Điều tối quan trọng đặc biệt là tất cả nhận thức về đều gì chương trình chuyển động, đặc biệt quan trọng Một trong những công tác có súc tích phức tạp.

Cần chắc chắn logging được đặt toàn vẹn cùng đúng địa điểm, nhằm bạn có thể lý luận tại vì sao công tác lại chạy điều này.

khi phần lớn sản phẩm hoạt động suôn sẻ tru thì ko có gì, nhưng mà ngay trong khi chương trình xảy ra lỗi (cthị trấn chẳng thể tránh khỏi), không nhiều ra bạn sẽ thấy niềm hạnh phúc bởi đang logging đúng chỗ.

Về Testing

Có đều bug cụ thể đề nghị được “khui” ra tức thì vào quá trình demo. Nếu vậy, phần demo nào sẽ thiếu hụt sót – unit, functional, giỏi system? Test case làm sao đã bị thiếu?

0 với null

Luôn chắc chắn là đánh giá với cái giá trị 0 cùng null (nếu như gồm thể). Đối với chuỗi, nên lưu ý chuỗi trống rỗng, cùng chuỗi là null.

Một ví dụ khác: kiểm soát ngôi trường vừa lòng đứt kết nối TCPhường. trước khi bất cứ dữ liệu (zero bytes) như thế nào được gửi.

Bỏ qua bài toán khám nghiệm các ngôi trường hòa hợp trên là nguyên do số một làm cho bug lọt ngoài phần demo của tôi.

Thêm vào với xóa đi

Thường những tính năng mới vẫn dính tới cthị xã thêm những tùy chỉnh cấu hình new vào khối hệ thống, ví dụ như một loại định dạng mới số điện thoại thông minh.

Thông thường bạn sẽ kiểm soát coi rất có thể thêm định dạng mới hay không, nhưng lại tôi thấy là rất dễ dàng quên kiểm soát trường vừa lòng xóa định dạng cũ.

Xử lý lỗi

Phần code dùng để giải pháp xử lý lỗi thường xuyên hết sức khó đánh giá. Tốt tốt nhất là yêu cầu gồm những demo tự động hóa để kiểm tra phần này, nhưng lại thỉnh thoảng vấn đề này trlàm việc yêu cầu bất khả.

Một mẹo tôi giỏi cần sử dụng là sửa code trong thời điểm tạm thời nhằm kích hoạt phần cách xử lý lỗi. Dễ độc nhất là đảo ngược điều kiện if lại, ví dụ như chuyển if error_count > 0 thành if error_count == 0.

Một ví dụ khác là giả vờ viết không đúng tên một column vào database nhằm kích hoạt lỗi.

Sử dụng tài liệu nguồn vào ngẫu nhiên

Một biện pháp soát sổ khác rất có thể dùng để làm phạt hiện nay bug là sử dụng tài liệu đầu vào tự dưng.

Chẳng hạn như, phần giải mã ASN.1 của giao thức H.323 hoạt động bên trên dữ liệu nhị phân. Bằng phương pháp gửi các bytes thiên nhiên nhằm giải thuật, Shop chúng tôi vẫn đưa ra rất nhiều lỗi trong phần này.

Một ví dụ không giống là tạo thành đông đảo cuộc Gọi phân tách, với thời hạn Gọi, độ trễ lúc trả lời, mặt làm sao ngắt lắp thêm trước, v.v.. được tạo thành tự nhiên. Những cuộc gọi này làm lộ ra một đụn bug, đặt biệt là lúc bọn chúng xen vào hồ hết sự khiếu nại xảy ra gần như đồng thời.

Kiểm tra hành vi không hề muốn tất cả thiệt sự KHÔNG diễn ra

Thường testing liên quan cho xem demo hành động mong ước gồm xảy ra không. Nhưng lại rất giản đơn làm lơ trường vừa lòng ngược chở lại – kiểm soát hành động không muốn thật sự ko ra mắt.

Tự làm tool

Tôi hay từ bỏ có tác dụng những tool nhỏ dại để test dễ dàng hơn.

lấy ví dụ, Khi lúc tôi làm việc cùng với giao thức SIPhường. mang đến VoIPhường, tôi viết một quãng mã nhỏ tuổi hoàn toàn có thể trả lời cùng với headers với cực hiếm tôi mong ước. Đoạn mã này góp tôi soát sổ hầu như ngôi trường phù hợp quan trọng đặc biệt tiện lợi rộng.

Một ví dụ khác là một trong những công tác chiếc lệnh chuyên dùng để làm Điện thoại tư vấn API.

Bằng cách ban đầu nhỏ tuổi, và từ từ phát triển thêm tác dụng đến nó, sau cùng tôi có vào nay gần như mức sử dụng hết sức hữu dụng. Lợi ích của bài toán này là tôi có những phương pháp đúng như tôi ước muốn.

Về Debugging

Cách nkhô giòn hơn để “khui” bug là gì? Tôi sẽ cần sử dụng đúng tool chưa? Có cần tôi đang bỏng đoán thừa nhiều? Tôi bao gồm buộc phải logging xuất sắc rộng không?

Thảo luận

Nếu chúng ta hỏi tôi bí quyết tác dụng độc nhất để xử trí bug là gì? Tôi đang vấn đáp là trao đổi cùng với người cùng cơ quan. Trong cơ hội search cách lý giải cho bọn họ đọc vụ việc gặp mặt phải là gì, tôi cũng mặt khác gọi sâu và rõ rộng về nó.

Thêm nữa, mặc dù không rất gần gũi cùng với code trong câu hỏi, thường xuyên bọn họ sẽ sở hữu được tầm nhìn một cách khách quan nhằm đã cho thấy vấn đề hoàn toàn có thể phát sinh từ đâu.

Đây là giải pháp cực kì kết quả góp tôi giải quyết và xử lý đầy đủ bug khó khăn nhằn duy nhất.

Cẩn thận đến từng đái tiết

lúc câu hỏi debug ngốn quá nhiều thời hạn, thì hay là vì tôi đã suy đoán sai.

ví dụ như, tôi nghĩ về vấn đề xẩy ra tại 1 method nào đó, trong khi thực tiễn không dễ thường cthị trấn kia xẩy ra.

Hoặc, một nước ngoài lệ xẩy ra trái cùng với nước ngoài lệ tôi suy đân oán. Hoặc, tôi suy nghĩ phần mềm chạy version mới nhất, trong khi thực chất này lại chạy một version cũ rộng.

Cho đề nghị, hãy chắc chắn rằng các bạn đã kiểm soát lại tất cả cụ thể nắm vày khoác định phần đa trang bị. Thật dễ dàng để xem phần nhiều gì bạn muốn thấy, hơn là tất cả những gì thật sự làm việc đó.

Tgiỏi thay đổi nhất

Khi số đông lắp thêm từng hoạt động bỗng dưng trục trặc, thường xuyên là do số đông thay đổi mới nhất gây nên.

Có trường thích hợp, bạn chỉ chuyển đổi logging, tuy vậy một lỗi vào logging sẽ gây ra sự thế to hơn nhiều.

Để dễ dàng truy hỏi kiếm tìm các sự rứa loại này, bạn nên commit hồ hết cầm cố biến đổi nhau giữa những commit khác biệt, và ghi chụ cụ thể về câu hỏi đổi khác.

Tin trên bạn dùng

thường thì người dùng report một sự việc nào đó, ý nghĩ đầu tiên của tôi là: Không thể nào! Chắc bọn họ lầm lẫn chứ cthị xã đó sao xẩy ra được! Nhưng rồi, hóa ra bọn họ đang report đúng.

Những kinh nghiệm tay nghề tmùi hương nhức đã dạy tôi rằng: Hãy tin vào người dùng.

Dĩ nhiên tôi vẫn cần đánh giá lại giúp xem đều trang bị đã được tùy chỉnh cấu hình đúng không. Nhưng tôi vẫn gặp gỡ tương đối nhiều trường thích hợp lạ mắt xảy ra chính vì một thiết lập cấu hình không thường gặp, một phương pháp sử dụng ko được dự đoán trước, hay đưa định thuở đầu của tớ rằng bọn chúng cần những điều đó. Và cố gắng là chương trình chạy không đúng.

Test phần vẫn sửa

Sau Khi vẫn sửa kết thúc, bước tiếp sau bạn phải có tác dụng với bug là gì? lúc bug đang sửa chấm dứt thì chúng ta bắt buộc chạy thử lại. Thứ nhất, hãy chạy code nhưng mà không cần sử dụng phần sẽ sửa cùng theo dõi bug. Sau đó, áp dụng phần sẽ sửa cùng chạy lại demo case.

Tuân theo mọi bước trên sẽ giúp đỡ bạn chắc hẳn rằng bug kia đích thực là bug, với phần đang sửa thực sự kết quả. Đơn giản tuy vậy cần thiết.

Nếu chúng ta suy nghĩ đông đảo share này có thể giúp ích mang đến bằng hữu hoặc người cùng cơ quan thì đừng trinh nữ dìm nút ít Share bên dưới nhé!