Mất 6 ngày để thay đổi một dòng mã (2015)
(edw519.posthaven.com)- Khi tỷ lệ vận hành của nhà máy giảm 10%, công ty muốn tích hàng tồn kho trước mùa cao điểm thay vì sa thải, và từ đó bắt đầu yêu cầu đổi giới hạn backlog 3 tháng thành 4 tháng
- Người phụ trách IT cho rằng chỉ cần đổi một giá trị hardcode trong routine cốt lõi, nhưng trước hết vẫn phải viết ticket, mô tả tác động kinh doanh, xin phê duyệt và điều chỉnh ưu tiên trong hàng đợi
- Lập trình viên đã đổi giá trị
MonthsOfBacklogtừ"3"sang"4"ở line 1252 của Module ORP572 và vượt qua kiểm thử, nhưng trong code review thay đổi này còn bị mở rộng sang cả việc sửa các vi phạm chính sách sẵn có - Phạm vi thay đổi phình ra thành các thủ tục phụ trợ như biến thành record trong file Parameters, bỏ lệnh debug, cảnh báo biến chưa gán, Employee ID hardcode, quyền truy cập, môi trường test, kế hoạch test và chữ ký người dùng
- Thay đổi cần thiết về mặt nghiệp vụ chỉ là 1 dòng·1 byte, nhưng tổng thời gian trôi qua là 6 ngày, cho thấy thủ tục nội bộ và chính sách đã làm tăng mạnh lead time thực tế của một thay đổi nhỏ
Yêu cầu đổi giới hạn từ 3 tháng sang 4 tháng
- Chủ tịch Philip nói rằng nhà máy đang ở trạng thái không vận hành 10%, và muốn sản xuất thêm backlog để tích tồn kho trước mùa cao điểm thay vì sa thải
- Quản lý vận hành Lee nói rằng theo chính sách công ty chỉ được tạo backlog 3 tháng, nên nếu đổi giới hạn thành 4 tháng thì sẽ có đủ việc để làm
- David, người phụ trách IT, nhận định có lẽ chỉ cần đổi một dòng mã trong routine cốt lõi của phần mềm legacy, và yêu cầu gửi ticket cho IT Services
- Quản lý IT Judy gán yêu cầu thành
Ticket# 129281, nhưng nói rằng cần điền phần Business Impact và có phê duyệt của Director- Khi David nói có khả năng phải sa thải, Judy tự điền phần đó và đẩy lên xử lý nhanh
- Sau 2 ngày, yêu cầu vẫn nằm trong Developer Queue ở vị trí enhancement đầu tiên, phía sau 14 Bug Report
- David đánh dấu yêu cầu là khẩn cấp và chỉ đạo gửi thẳng cho Ed
Cách một thay đổi một dòng biến thành thay đổi quy trình
- Ed đổi biến hardcode
MonthsOfBacklogtừ"3"sang"4"ở line 1252 của Module ORP572- Đã vượt qua unit test và chạy 2 lần batch test
- Hàng đợi công việc của Operations tăng đúng như dự kiến là 10%
- Thay đổi được chuyển sang Code Review và User Acceptance Testing của Homer
- Shirley, người phụ trách code review, yêu cầu biến hardcode này phải được chuyển thành một record trong file Parameters vì nó trái với chính sách công ty
- Cô ấy cũng nói 2 lệnh Debug cũ, cảnh báo biến chưa gán và Employee ID hardcode đều phải được sửa trước khi lên production
- Vì Ed được giao ORP572, anh phải chịu trách nhiệm cả với các lỗi cũ đang vi phạm chính sách công ty mới
- Môi trường test cũng trở thành yếu tố gây chậm trễ
- Homer không dùng được do đang test kiểm soát chốt sổ kế toán cuối tháng, nên phải dùng Marge
- Ed không có quyền truy cập Marge, còn Joe bên IT Security nói không thể cấp quyền nếu không có chữ ký của David
- Công việc tạo record Parameters tiếp tục phình ra vì yêu cầu bổ sung
- Tên
MonthsOfDemandbị cho là khó hiểu với lập trình viên ở nước ngoài nên cần tên tốt hơn - Record Parameter mới phải có audit trail, nhưng chính sách đó chưa được tài liệu hóa và wiki cũng đã chậm cập nhật 3 tháng
- Ed đổi tên thành
SelectedMonthsOfBacklogDemandvà thêm Module PAR634 để duy trì record đó cùng audit trail
- Tên
- Tony, người phụ trách kiểm thử, chỉ ra rằng
129281có xuất hiện trên Marge nhưng không có Test Plan- Ed nói chỉ cần chạy theo cách cũ và cách mới rồi xác nhận tổng lượng trong báo cáo
WorkOrdersHourstăng lên là được, nhưng Tony nói vì nó ảnh hưởng đến toàn bộ nhà máy nên cần Test Cases do người dùng chọn, Expected Results, Test Runs được tài liệu hóa và user sign-off - Sau 2 ngày, Philip chỉ thị David yêu cầu Tony đưa ngay chương trình của Ed lên production
- Ed nói chỉ cần chạy theo cách cũ và cách mới rồi xác nhận tổng lượng trong báo cáo
- Tổng thời gian trôi qua là 6 ngày, còn thay đổi đối với mission critical code chỉ là 1 dòng·1 byte
- Đã tiêu thụ 24 viên Excedrin
- Thời gian bực bội ghi trên Hacker News là 14 giờ
1 bình luận
Các ý kiến trên Hacker News
Điểm mấu chốt nằm ở việc người review yêu cầu rằng “muốn đổi cái này thì phải sửa luôn cả các vấn đề tồn đọng khác trong codebase”
Những lúc như vậy, nên đẩy ngược lại rằng: “Hướng nâng cao chất lượng code là tốt, nhưng nếu thay đổi Y thì cần phê duyệt X/Y/Z và sẽ mất thêm vài ngày. Nội dung anh/chị nói tôi sẽ tạo thành công việc nợ kỹ thuật, rồi xử lý trong PR tiếp theo tùy theo mức ưu tiên và nguồn lực. Hiện giờ hãy tập trung vào việc cần gì để triển khai PR cục bộ này.”
Bài học lớn nhất là tạo các PR có phạm vi tập trung, và biết cách phản biện khi reviewer cố mở rộng phạm vi. Nhìn chung các kỹ sư khác tiếp nhận điều đó một cách thực dụng. Việc này không liên quan đến số dòng. Có thể chỉ format lại toàn bộ code mà không thay đổi logic, hoặc chỉ đổi vài feature flag nhưng tác động lại lớn. Mỗi lần chỉ nên làm một thay đổi tập trung.
Nếu đây là việc ưu tiên cao đến mức công ty có thể phải sa thải người nếu không xử lý ngay, thì tuyệt đối không nên có 2–3 ngày chờ trước khi có ai đó xem. Vậy mà trong quy trình phát triển này, có vẻ đó lại là “đường nhanh”
Hai ngày cuối cũng trông như không có gì xảy ra vì kế hoạch kiểm thử bị đánh giá là chưa đủ. “Muốn đổi cái này thì phải sửa luôn cả các vấn đề tồn đọng khác” ở đây chỉ chiếm 2 giờ, và ngay cả trước khi xét đến phần đó, vẫn có ít nhất 2–3 vấn đề khác đáng được chỉ ra là vấn đề cốt lõi của quy trình này
Thay vì để lại FIXME hay TODO, tôi lặng lẽ tạo issue để không quên. Phần này của review đang hỏng. Xử lý nợ kỹ thuật phải được lên kế hoạch riêng, chứ không phải là điều kiện để hoàn thành công việc
Khi các lớp như vậy chồng chất, cuối cùng code trở thành trạng thái tương đương về mặt đạo đức với Atlanta, GA, nơi khét tiếng vì có quá nhiều đường vành đai
Khi thêm quy tắc mới, hệ thống tự động hóa nên gắn chú thích ngoại lệ quy tắc vào tất cả các điểm vi phạm hiện có, và cũng phải theo dõi được chúng. Nếu code cần triển khai gấp buộc phải vi phạm quy tắc, chỉ cần thêm chú thích ngoại lệ và gắn tên mình là người chịu trách nhiệm sửa sau
Theo thời gian, có thể xây dựng văn hóa sửa các vi phạm quy tắc này tách biệt khỏi phát triển tính năng
Nói đúng. Quy trình code review ở hầu hết công ty đầy rẫy bới lông tìm vết và các bình luận vụn vặt
Trước đây tôi từng đề xuất thay những bình luận kiểu này bằng công cụ phân tích tĩnh để loại bỏ chúng và phản hồi nhanh hơn, nhưng câu trả lời tôi nhận được là kiểu code review đó là cần thiết cho mọi người. Vì nó giúp người ta thăng tiến, tạo cảm giác rằng họ đã ngăn được vấn đề trong code, và khiến các quản lý cấp cao nhìn vào số lượng bình luận của reviewer mà thấy các chỉ số code review có vẻ tốt
Giải pháp thật sự là chấp nhận rằng không phải mọi đoạn code đều cần trông như do chính tôi viết, và tự hỏi: “Bình luận này có xử lý một lỗi khách quan trong code không?” Trong nhiều trường hợp, câu trả lời là “không”
Nếu chỉ là tên biến hơi dài dòng hoặc khoảng trắng giữa các phương thức không đều, lý tưởng nhất đó nên là “phản hồi để tham khảo lần sau nếu nó trở thành một pattern”. Nhưng từ góc nhìn reviewer, họ có thể xem số bình luận trên mỗi PR là chỉ số cho việc đã hướng dẫn nhiều đến đâu, hoặc lo phản ứng kiểu “ai lại để cái đó được merge?”, nên cuối cùng vẫn để lại bình luận
Người được review thì sửa vì sợ nếu không xử lý bình luận sẽ bị xem là kém phản hồi với feedback, hoặc nếu phản bác thì reviewer sẽ đánh giá xấu. Thế là phiên bản cập nhật lại phải được phê duyệt lần nữa, và chu kỳ trì hoãn lại bắt đầu
Nhưng cũng có những vấn đề mà một số người cho là chỉ là tiểu tiết, trong khi thực tế hoàn toàn không nhỏ. Có thể vì họ không tự nhìn thấy vấn đề, không hiểu vấn đề, hoặc thiếu khả năng gạt cảm xúc sang một bên để suy nghĩ lại về code mình viết
Ai trong chúng ta cũng từng gắn bó với code mình viết, và có thể từng nghĩ đó là đoạn code tao nhã nhất thế giới. Nhưng đôi khi phải thừa nhận rằng mình sai, và code đó khó đọc, có lỗi, hoặc gây hại cho codebase
Tôi từng chỉ ra một race condition có thể thực sự gây vấn đề trong code của một người senior hơn mình, rồi bị gọi là kẻ bới móc. Với tôi, race condition là vấn đề căn bản của code đã viết và cần được sửa; còn với người đó, vì họ chưa từng thấy nó tự nhiên bị hỏng nên đó vẫn là trạng thái chấp nhận được
Tôi rất thích review đồng nghiệp, và thường tập trung vào “code này sẽ không hoạt động như kỳ vọng”, “làm thế này sẽ khiến việc triển khai bị chặn hoặc đắt hơn nhiều”, “nó hoạt động, nhưng khó hiểu nên sẽ ảnh hưởng xấu đến bảo trì; hãy cân nhắc cách khác hoặc thêm giải thích”, “code ổn, nhưng có thể đọc tốt hơn hoặc hoạt động tốt hơn; tôi sẽ không fail review, nhưng đáng tham khảo cho code sau”
“Julie: Hãy liên hệ với Joe bên đội bảo mật IT. Họ sẽ cấp quyền. Sau 2 giờ.” là hoàn toàn phi thực tế. Đội bảo mật không đời nào phản hồi nhanh như vậy
Đôi khi tôi tự hỏi có phải nhân viên helpdesk chộp lấy ngay khi ticket vừa vào vì đây là loại ticket có thể đóng nhanh để tăng chỉ số cá nhân không
Nếu nói như tiêu đề rằng mất 6 ngày để đổi một dòng mã thì nghe thật kinh khủng
Nhưng hệ thống đã được cải thiện theo vài cách. Cấu hình đã có thể thiết lập trong bảng tham số thay vì hardcode, và cũng có chức năng audit để theo dõi thay đổi cấu hình đó
Tôi không định bênh vực quan liêu. Tôi thật sự ghét khía cạnh đó của các tổ chức lớn. Chỉ muốn chỉ ra rằng ngoài mục tiêu ban đầu, trong 6 ngày đó cũng đã tạo thêm giá trị
Vì vậy khi ước tính cần đưa vào một lượng chi phí phụ trợ nhất định, và nếu chấm story point thì cũng phải tính đến chi phí quy trình kiểu này
Rốt cuộc hai thành quả là “thành quả” tránh được các nghi thức bổ sung quanh việc thay đổi mã, và “thành quả” lấy lại chức năng đã mất do “thành quả” đầu tiên, vì từ nay thay đổi này sẽ không còn nằm trong mã nữa
Đáng lẽ phải nói: “Đây là việc khẩn cấp, xin hãy nhận PR một ký tự này. Các cải tiến anh/chị yêu cầu tôi đã tạo ticket để theo dõi. Trước hết hãy xử lý vấn đề production, phần còn lại làm sau.”
Reviewer chỉ cần “LGTM!” là được. Nếu đa số kỹ sư không thể điều hướng giữa quy tắc và guideline, thì tổ chức đó đang điên rồi, và chính ở những điểm như thế này seniority mới có giá trị
Nếu mất một tuần cũng không ảnh hưởng đến việc làm của ai, thì cứ theo quy trình hoặc chỉ thay đổi tối thiểu. Nếu vì IT mà người ta đang phải nghỉ không lương, thì tất cả những người cần thiết phải ở cùng một phòng, dù là phòng vật lý hay ảo, cho đến khi vấn đề được giải quyết
Ở đây thiếu bối cảnh đó. Nhưng nếu Ed và toàn bộ tuyến phê duyệt không biết bối cảnh ấy, thì đó là thất bại của hệ thống. Nếu biết tiền thuê nhà của ai đó đang phụ thuộc vào việc này, có lẽ senior đã đề xuất tạo ticket thứ hai để sửa ngay sau đó. Nếu không thì đó cũng là vấn đề ban lãnh đạo cần giải quyết
Câu chuyện này là trường hợp một thay đổi một dòng của giá trị hardcode thực ra đã diễn ra suôn sẻ
Có thể tưởng tượng một kịch bản trong đó ai đó lưu số tháng backlog bằng giá trị 2 bit để trông thông minh và khéo léo. Tức là chỉ có thể là 0, 1, 2, 3. Trong quá trình test, nó có thể ẩn sâu qua nhiều tầng, trong một dịch vụ phụ chưa được kiểm thử hoặc một dịch vụ tự động hóa low-code, nên vấn đề không lộ ra
Đổi giá trị đó thành 4 có thể khiến backlog thành 0. Không ai biết kết quả sẽ ra sao. Dịch vụ đó có thể hủy mọi tác vụ trong hàng đợi production, hoặc gửi email cho khách hàng rằng tác vụ đã bị hủy
Bề ngoài trông như một thay đổi dễ dàng, nhưng nếu một thay đổi chính sách được chuyển tới đội phần mềm dưới dạng vấn đề khẩn cấp, thì ban quản lý cần lập kế hoạch tốt hơn, chứ không nên tùy tiện đảo lộn mức ưu tiên của issue
Ngược lại, họ còn yêu cầu refactor nhiều phần xung quanh như “chi phí” của thay đổi, làm tăng rủi ro
Nếu sếp lớn nói “Tôi quyết định chấp nhận rủi ro và thúc đẩy việc này, và tôi chịu cả hậu quả” thì tốt. Nếu các lập trình viên bị đánh thì không tốt
Nếu đây là một cập nhật quan trọng và nhạy cảm về thời gian cho chức năng cốt lõi, người phụ trách vận hành lẽ ra phải biết thời gian triển khai trung bình của phần mềm, và thay vì đưa vào pipeline phát triển thông thường với mức ưu tiên cao, đáng lẽ phải lập một nhóm để xử lý nhanh
Code review bắt đầu với ý định tốt. Nhưng cuối cùng một người gác cổng nào đó sẽ bám trụ vị trí và bắt đầu từ chối mọi thứ vì những lý do vụn vặt
Người đó nói mình quan tâm đến việc giữ “chất lượng mã”. Nhưng không gì tệ hơn việc để mã lỗi đã có bản sửa nằm đó quá lâu, hoặc trì hoãn tính năng đến mức không ai dùng thử được
Tôi khuyến nghị một quy trình cho phép comment nhưng reviewer không thể chặn commit. Cần tin rằng mỗi developer sẽ cẩn thận và thực hiện thay đổi phù hợp với công việc. Có thể dùng cả CI, và tùy đội mà toàn bộ việc này có thể vận hành khá ổn
Sửa quy trình để có thể phớt lờ reviewer bệnh hoạn thì cùng lắm cũng chỉ là biện pháp nửa vời
Tôi có cảm xúc lẫn lộn về việc chặn. Tôi hiểu dấu chặn đỏ chói gây bực bội, nên trong nhiều trường hợp tôi “chặn mềm” bằng cách yêu cầu thay đổi nhưng không chặn hẳn. Tuy nhiên, khi PR đi chệch hướng hoàn toàn, thường là với developer junior, tôi nghĩ gửi một thông điệp rõ ràng là phù hợp
Đây là một câu chuyện mang tính meta về công nhân nhà máy và lập trình viên phần mềm
Lãnh đạo công ty này sẵn sàng sa thải công nhân nhà máy vì mức sử dụng thấp hơn 10%. Có thể điều chỉnh vài biến số để tăng năng suất, nhưng cuối cùng lựa chọn chỉ là được sử dụng hết công suất hoặc thất nghiệp. Có lẽ điều đó khả thi vì những công nhân này có thể thay thế, có thể thuê lại vào mùa cao điểm, và lợi nhuận tạo ra trên mỗi nhân viên không cho phép sự kém hiệu quả
Tôi làm lập trình viên phần mềm. Ở phía chúng tôi, mức sử dụng thấp phải vượt xa 90% thì mới nghĩ đến chuyện cho ai đó nghỉ. Nhiều người chỉ làm 4 giờ mỗi tuần. Không ai quản lý thời gian của chúng tôi theo từng phút hay giờ nghỉ đi vệ sinh
Hiện giờ là giai đoạn vốn hóa quy mô lớn đối với phần mềm. Nó sẽ không kéo dài mãi. Một ngày nào đó, hạ tầng chính của thế giới IT sẽ được xây xong và ngành sẽ chuyển sang chế độ bảo trì. Phần lớn chúng ta sẽ không còn cần thiết nữa, trở nên dễ thay thế, và lợi nhuận chúng ta tạo ra trong chế độ bảo trì sẽ rất nhỏ so với những gì đang thấy hiện nay
Công nhân nhà máy thường bị sa thải trong vài phút hoặc vài giờ nếu năng suất cá nhân bị xem là thấp. Tôi nghĩ chuyện này cũng sẽ bắt đầu xảy ra với lập trình viên phần mềm trong đời chúng ta
Bạn cũng nên đánh giá xem điều đó có thể áp dụng đến mức nào với bộ kỹ năng của mình
Tôi đồng ý với ý chính rằng việc vốn hóa quy mô lớn của phần mềm sẽ không tồn tại mãi. Không phải công ty nào cũng luôn cần kỹ sư để phát triển phần mềm mới. Nó giống một ngành sáng tạo có thịnh suy như sản xuất phim hơn. Nếu chọn phát triển phần mềm thay vì IT, bạn phải chấp nhận rủi ro đó. Chỉ là tôi không hiểu vì sao hiện tại nhất thiết phải là đỉnh điểm
Theo trải nghiệm cá nhân, sau vài năm làm trong các đội có review code chính thức, tôi chuyển sang một đội/công ty không có review code. Ai cũng có thể tự do commit và merge vào bất kỳ branch nào
Khi mới vào tôi có cảm xúc hơi lẫn lộn, nhưng thực tế lại rất sảng khoái và có cảm giác được trao quyền, nên chỉ sau vài ngày tôi đã làm việc hiệu quả
Xét mục tiêu của đội, cách không review code lại rất phù hợp. Vì đó là một nhóm R&D mà mục tiêu chính là trình diễn “tính năng mới hoành tráng” cho các lãnh đạo. Có rất nhiều yêu cầu đến trong thời gian ngắn, nhưng cũng có nhiều code bị bỏ đi
Sau khi demo, lãnh đạo sẽ nói “trông ổn đấy, nhưng không có tính kinh doanh”, rồi repository không bao giờ được đụng đến nữa. Tất nhiên đôi khi thứ chúng tôi làm ra cũng được đưa thành sản phẩm, và khi đó một đội cấp dưới chịu trách nhiệm biến đống code nguệch ngoạc thành chất lượng production. Những người đó ghét chúng tôi bằng một sự căm thù cháy bỏng
Thành viên mới được chỉ định một mentor ngồi cạnh, thường xuyên pair và xem code trong 2–3 tháng đầu
Đó là một dự án kéo dài 2,5 năm, go-live ở tháng thứ 20, đúng tiến độ và ngân sách, đồng thời cung cấp nhiều tính năng hơn phạm vi ban đầu. Nhiều ngày chúng tôi thảo luận 2–3 giờ trước bảng trắng. Nó không chính thức và không phải lúc nào tất cả mọi người cũng tham gia
Kỳ lạ là trong dự án này PM thay đổi ba lần. Chúng tôi có quy tắc nghiêm ngặt là ngoài standup thì không email hay liên lạc, và hai trong ba người có thể “làm việc” được trong thiết lập này. Hai năm sau, giám đốc IT của sân bay mới nhận ra rằng chúng tôi không cần PM
Có một quy tắc là nếu làm việc mới trong codebase thì phải trao đổi với ít nhất một lập trình viên khác. Chúng tôi ngồi cách nhau chỉ vài feet trong một văn phòng riêng rộng có bảng trắng lớn. Story được quản lý bằng thẻ index dán trên một bảng trắng riêng; nếu không thể giải thích cốt lõi trên đó thì phải chia thành phần nhỏ hơn
Mỗi người có thể tự dựng máy và dùng bao nhiêu màn hình tùy thích. Đó là hệ thống thanh toán và phí của một sân bay quốc tế lớn; trưởng bộ phận kế toán, giám đốc và những người dùng khác ở cách đó vài cửa văn phòng. Họ hầu như không bao giờ vắng standup và có chính sách luôn nhận câu hỏi theo thời gian thực
Standup thường không phải báo cáo trạng thái, mà là thảo luận không chính thức, demo, hỏi đáp. Muốn cập nhật trạng thái thì chỉ cần nhìn các thẻ trên bảng trắng
Hệ thống cuối cùng đã cải thiện 8% doanh thu ngay từ tháng đầu tiên và mỗi tháng sau đó. Giám đốc kế toán phải giải trình trước hội đồng quản trị của cơ quan sân bay. Tranh chấp và điều chỉnh hóa đơn với các hãng hàng không giảm từ 9 ngày mỗi tháng xuống còn 1 ngày, còn khối lượng công việc lập hóa đơn hằng tháng giảm từ 18 ngày xuống còn 5 ngày. Có thể chuyển người dùng chính từ kế toán viên cấp cao sang một kế toán viên junior có 3 năm kinh nghiệm
Bug production trong năm đầu tiên là 6 lỗi, hóa đơn sai là 0. Sau đó thì không có dữ liệu. Lần thử viết lại trước đó đã thất bại sau 3 năm
Việc dùng quy trình review code để giữ thay đổi làm con tin cho đến khi nó phù hợp với một lý tưởng cao xa và liên tục thay đổi của đội là rối loạn chức năng
Chính sách “nâng cấp trên đường đi” để lại một cái đuôi dài của những chuyển đổi dở dang, khiến lập trình viên mới khó làm quen với codebase hơn. Không có gì đảm bảo trọng tâm sản phẩm sẽ thường xuyên đi qua mọi phần của codebase, nên quá trình chuyển đổi cũng không bao giờ kết thúc. Một số vùng sản phẩm bị bỏ mặc trong nhiều năm
Nếu việc chuyển sang chính sách mới là quan trọng, hãy cắt nó ra thành một dự án tập trung để xử lý; nếu không, tức là nó không quan trọng
Họ đang kỳ vọng những quả bom hẹn giờ công việc không được lên kế hoạch rải rác trong codebase sẽ nổ thông qua các nhiệm vụ ngẫu nhiên, không liên quan
Nếu tiêu chuẩn mới quan trọng thì phải cập nhật code, còn nếu không thì đừng làm. Dựa vào sự ngẫu nhiên để trì hoãn công việc khẩn cấp không phải là một kế hoạch
Đọc chuyện này như một vấn đề về review code là sai. Vấn đề là công ty đã đặt quy trình gồm các rào cản nội bộ lên trên nguyên tắc
Mọi quy trình đều cần lối thoát. Nếu đó là thay đổi ngăn việc sa thải, thì mọi lối thoát phải được kích hoạt