Các mặc định của framework âm thầm định hướng thói quen code, kiến trúc và bảo mật. Tìm hiểu cách chúng ảnh hưởng đội ngũ—và cách chọn hoặc ghi đè chúng một cách an toàn.
“Mặc định của framework” là những lựa chọn mà framework đã đưa ra cho bạn trước khi bạn viết bất kỳ dòng mã sản phẩm nào. Chúng là điểm khởi đầu: file được sinh, cấu hình đặt sẵn, lệnh scaffold, và thậm chí các ví dụ trong tài liệu chính thức ngầm gửi thông điệp: “Đây là cách thông thường.”
Khi mọi người nghe “mặc định,” họ thường nghĩ đến một thiết lập đơn lẻ—như số cổng hay cờ debug. Thực tế, mặc định bao gồm:
Hướng dẫn dễ bị bỏ qua khi deadline gấp. Mặc định khó tránh hơn vì chúng đã được nối sẵn vào dự án. Chúng ảnh hưởng đến những gì được commit trong ngày đầu, điều đồng đội coi là “idiomatic,” và điều code review chấp nhận là tiêu chuẩn.
Bài viết này sẽ giúp bạn nhận ra các mặc định bạn kế thừa, đánh giá các đổi-trả chúng tạo ra, và điều chỉnh an toàn—mà không biến mỗi dự án thành một framework tùy chỉnh.
Mặc định của framework không chỉ giúp tiết kiệm thời gian—chúng hướng các quyết định. Khi một framework đi kèm một lựa chọn được chọn sẵn, nhiều nhóm xem đó như lựa chọn “đúng”, ngay cả khi nó chỉ là lựa chọn dễ chấp nhận nhất. Điều đó không phải là lười biếng; đó là hành vi con người.
Con người có xu hướng gắn bó với những gì đã được thiết lập. Một mặc định tạo ra đường cơ sở cảm thấy an toàn và được ủng hộ: “Nếu tác giả framework chọn thế này, chắc cũng hợp lý.” Thay đổi nó mang đến rủi ro (“Nếu chúng ta làm hỏng gì thì sao?”) và chi phí (“Ai sẽ duy trì cấu hình tùy chỉnh?”). Vì vậy mặc định thường thắng—ngay cả khi lựa chọn khác có thể phù hợp hơn.
Dự án thực tế bao gồm hàng nghìn quyết định nhỏ: cấu trúc thư mục, quy ước đặt tên, mẫu xác thực, cách đặt test, xử lý lỗi, tooling build, v.v. Mặc định giảm mệt mỏi vì quyết định bằng cách gộp các hạng mục tranh luận thành một con đường sẵn sàng dùng.
Tốc độ đó có giá trị. Nhóm có thể giao hàng sớm hơn, đồng bộ nhanh hơn, và tránh được tranh luận vặt. Đổi lại là sự tiện lợi có thể cứng lại thành thói quen trước khi ai đó hỏi xem mặc định đó có phù hợp với nhu cầu sản phẩm hay không.
Hầu hết lập trình viên học framework qua docs chính thức, tutorial và starter template. Những ví dụ đó bị copy-paste vào codebase thật và trở thành chuẩn:
Theo thời gian, các pattern sao chép này được củng cố bởi code review và onboarding: người mới bắt chước những gì họ thấy, và đường đi mặc định lan rộng.
Mặc định cũng tạo ra tính nhất quán. Một khi nhóm chấp nhận đường đi mặc định, nó trở thành kỳ vọng chung: đặt dịch vụ ở đâu, viết route thế nào, xử lý lỗi ra sao, sinh component như thế nào. Nhất quán giúp cộng tác, nhưng cũng có thể khiến các phương án khác trông “không chuẩn” hoặc “quá tùy chỉnh,” làm nản lòng việc suy nghĩ khác biệt.
Mặc định ảnh hưởng hành vi vì chúng kết hợp sự thoải mái tâm lý, giảm tải nhận thức và củng cố xã hội—khiến lựa chọn dễ nhất trông giống lựa chọn chính xác nhất.
Framework không chỉ cho bạn một điểm khởi đầu—chúng vẽ ra biên kiến trúc ban đầu. Ngay khi bạn chạy lệnh “new project”, template quyết định mã nằm ở đâu, nhóm như thế nào, và điều gì được coi là dependency “bình thường”.
Hầu hết starter template đi kèm cấu trúc thư mục mặc định (ví dụ: routes/controllers, models, views, services, repositories, config, middleware). Dù bạn sau này đổi tên thư mục hay thêm lớp mới, những thư mục ban đầu trở thành mô hình tinh thần chung: “logic nghiệp vụ đặt ở đây, HTTP ở kia.”
Điều đó hữu ích vì giảm tranh luận và tăng tốc onboarding. Nhưng cũng có thể giới hạn tùy chọn: nếu cấu trúc mặc định khiến khó để tạo một domain layer riêng, nhóm thường trì hoãn cho đến khi dự án trở nên đông đúc.
Generator scaffold đặc biệt có ảnh hưởng. Khi framework tạo controller, model, migration và file test cùng lúc, nó gợi ý một cách phân chia hệ thống ưa thích. Theo thời gian, dev sao chép hình dạng được sinh ra thay vì suy nghĩ lại:
Mẫu sinh tự động có thể đưa vào coupling không hiển nhiên—như truy cập trực tiếp cấu hình global, singleton của framework, hay session DB ngầm. Những mặc định đó tiện lợi, nhưng làm unit test khó hơn và đẩy nhóm sang kiểu test tích hợp chậm hơn.
Một khi quy ước lặp lại ở hàng chục file, refactor trở thành việc phối hợp một “phong cách nhà” mới hơn là thay đổi code đơn thuần. Mặc định có thể tiết kiệm hàng tuần ở giai đoạn đầu—nhưng mất hàng tháng nếu nó khăm ngầm trước khi bạn xác nhận phù hợp với hình dạng dài hạn của sản phẩm.
Framework không chỉ cung cấp công cụ—chúng dạy bạn mã “bình thường” trông thế nào. Cách nhanh nhất để ra sản phẩm là theo con đường mặc định, và con đường đó lát bằng các pattern ưa thích: controller MVC, container dependency injection, composition dựa trên hook, service object, hoặc bất cứ điều gì framework nâng thành tính năng hạng nhất.
Khi API mặc định làm một cách tiếp cận đơn giản hơn các lựa chọn khác, nhóm sẽ chuẩn hóa nó mà không cần quyết định chính thức. Nếu framework khiến việc fetch data trong controller/component trở nên dễ dàng, đó sẽ là chuẩn—dù một domain layer riêng có thể sạch hơn.
Các abstraction tích hợp quan trọng ở đây. Một lớp routing + controller mạnh khuyến khích tách bạch trách nhiệm, trong khi helper tiện lợi có thể làm mờ ranh giới và chuẩn hóa các module lớn, chặt coupling.
Hầu hết dev sao chép ví dụ chạy được đầu tiên họ thấy. Nếu docs cho thấy:
…thì những ví dụ đó trở thành mẫu cho PR và code review. Theo thời gian, giọng điệu của tài liệu (hàm chức năng vs hướng đối tượng, tường minh vs “phép thuật”) trở thành giọng điệu mặc định trong mã của nhóm.
Mặc định xử lý lỗi dạy dev cách phản ứng khi áp lực. Nếu lỗi bị nuốt, chuyển thành phản hồi chung chung, hoặc log không nhất quán theo mặc định, nhóm có thể xây thói quen “debug sau”. Nếu framework đẩy lỗi có cấu trúc và ranh giới rõ (ví dụ xử lý exception tập trung), nhóm được thúc đẩy đến chế độ thất bại có thể dự đoán và chẩn đoán nhanh.
Kết luận chính: phong cách mã không chỉ là sở thích—nó thường là cái bóng của những mặc định bạn chọn ngày đầu.
Mặc định bảo mật là một trong những tính năng “vô hình” giá trị—cho đến khi nhóm nghĩ rằng chúng là đủ. Mặc định tốt giảm số quyết định bạn phải đúng khi bị áp lực. Mặc định tồi (hoặc bị hiểu sai) có thể tạo cảm giác an toàn giả.
Nhiều framework bảo vệ bạn tự động chống các vấn đề phổ biến như CSRF, nhưng chỉ trong một số cấu hình (ví dụ forms server-rendered so với API thuần). CORS là bất ngờ phổ biến: một số dự án bắt đầu “mở cho chạy được” và quên khóa lại sau. Mặc định cookie và header cũng quan trọng—cookie an toàn, SameSite, và header bảo mật có thể được bật, bật một phần, hoặc để bạn tự lo.
Thói quen hữu ích: coi mặc định như bộ khởi đầu, không phải là kết quả audit.
Auth thường đi kèm mặc định happy-path: luồng login nhanh, xử lý session cơ bản, và cài đặt cục bộ dễ dãi. Bẫy thường xuất hiện ở các trường hợp cạnh:
Nếu framework cung cấp middleware hay authorization theo chính sách, hãy làm cho đường dẫn mặc định là “được bảo vệ trừ khi ghi rõ công khai.”
Starter template và mã mẫu có thể nhúng các pattern lỗi thời: quy tắc mật khẩu yếu, upload file không an toàn, ví dụ CORS quá rộng, hoặc xử lý secret bị copy-paste. Dependency cũng có thể kéo vào các gói transitive rủi ro.
Trước khi dùng một template, rà soát nó như mã production: cấu hình, thứ tự middleware, header, cài đặt cookie, và bất kỳ comment nào ghi là “tạm thời.”
Thực hiện một audit mặc định nhẹ trong tuần một:
SECURITY.md ngắn\n4. Thêm kiểm tra tự động nếu có thể (scan dependency, luật lint, cổng CI)Mặc định nên tiết kiệm thời gian—nhưng chỉ sau khi bạn xác minh chúng phù hợp với mô hình mối đe dọa của mình.
Framework không chỉ giúp ra tính năng dễ hơn—chúng xác định “đủ tốt” về hiệu năng ngay từ đầu. Những lựa chọn ban đầu đó có xu hướng gắn chặt, nên mặc định có thể ngăn chặn đau đầu sau này hoặc tạo ra nó.
Nhiều framework mặc định theo hướng thân thiện với dev: cache ít, source map bật, bundler cấu hình cho rebuild nhanh. Điều đó hoàn hảo cho lặp cục bộ, nhưng nếu cấu hình production không được xem lại, nhóm có thể phục vụ tài sản chưa minify, gửi bundle quá lớn, hoặc thiếu header cache dài hạn.
Một mô hình thường gặp: app nhanh với dataset nhỏ và vài trang, rồi dần tích tụ bundle client nặng, quá nhiều script bên thứ ba, và không có ngân sách rõ cho kích thước tài sản. Mặc định giúp bắt đầu dễ, nhưng không ép kỷ luật.
Các mặc định xung quanh migration và hành vi ORM ảnh hưởng hiệu năng hơn bạn nghĩ. Generator migration thường tạo bảng mà ít suy nghĩ về index, và ORM có thể khuyến khích pattern gây N+1 query trừ khi bạn preload quan hệ.
Connection pooling là một mặc định lặng lẽ khác. Nếu pooling tắt hoặc kích thước cho dev, bạn có thể thấy timeout dưới tải. Nếu quá lớn, bạn có thể làm ngập DB. Dù thế nào, mặc định trở thành baseline cho đến khi production chứng minh ngược lại.
Nếu mặc định là log console đơn giản, nhóm thường trì hoãn logs có cấu trúc, trace và metrics hữu ích. Điều đó ổn—cho đến khi latency tăng và không ai trả lời được “đã thay đổi gì?” nhanh chóng.
Hãy coi các mặc định hiệu năng như giàn giáo tạm thời. Thực hiện một lượt điều chỉnh có chủ ý trước khi ra mắt (và khi đạt mốc tăng trưởng) để tinh chỉnh caching, bundle, pattern truy cập DB và observability—khi hệ thống còn dễ thay đổi.
Framework không chỉ ảnh hưởng cách viết code—chúng thiết lập kỳ vọng về cách nhóm làm việc. Khi generator dự án đi kèm testing, linting, formatting và CI đã nối sẵn, nó thúc mọi người hướng tới một baseline chung.
Nhiều framework/starter giờ bật một stack workflow từ phút đầu: test runner, linter, formatter, và đôi khi pipeline CI cấu hình sẵn.
Gói này quan trọng vì thay đổi đường ít cản trở. Nếu test chạy tự động và format tự động, nhóm tự nhiên tạo mã qua các kiểm tra mà không tranh luận từng sở thích. Ngược lại, nếu không có gì được thiết lập, mặc định trở thành “xuất bản trước, chuẩn hóa sau”, thường dẫn tới “không bao giờ chuẩn hóa.”
Khi framework cưỡng chế tiêu chuẩn cơ học (luật lint, format, kiểm tra type), review PR chuyển từ tranh luận style sang nội dung:
Nó cũng giảm mệt mỏi cho reviewer. Cùng một kiểm tra chạy cho mọi đóng góp, nên nhóm không phụ thuộc vào người tỉ mỉ nhất để bắt lỗi style.
Người mới hưởng lợi ngay từ các lệnh và file dự đoán được: chạy test, chạy lint, mở PR, và để CI báo lỗi rõ ràng nếu có vấn đề. Điều đó loại bỏ nhiều ma sát ban đầu—nhất là khi repo có script sẵn và config CI khó bỏ qua.
Tooling mang quan điểm mạnh có thể chặn prototype nhanh: linter nghiêm ngặt, test quá nhiều, hoặc bước CI nặng có thể là rào cản. Cách thực tế là giữ mặc định bật, nhưng cho phép đường tắt nhẹ cho spike (ví dụ nhánh riêng hoặc thư mục experimental rõ ràng) để khám phá không phải chống lại toolchain.
Framework nằm trên một phổ: có cái quyết định nhiều cho bạn (có quan điểm), có cái cho bạn bộ công cụ và chờ bạn quyết định (linh hoạt). Không có cái nào hoàn toàn “tốt hơn”—mặc định đơn giản đẩy nhóm đi theo những hành vi nhất định.
Framework có quan điểm thường chuẩn hóa cấu trúc thư mục, routing, quản lý state, format và testing. Điều đó giảm mệt mỏi phối hợp và giúp nhóm cùng hướng ngay ngày đầu.
Ưu điểm là tốc độ và nhất quán: review tập trung vào đúng sai thay vì style, onboarding mượt vì có một cách rõ ràng để làm việc. Đổi lại là bạn mua luôn tầm nhìn của framework. Nếu domain cần kiến trúc đặc thù (hoặc tích hợp với hệ thống legacy), mặc định có thể cảm thấy bó buộc và vá sửa chồng chất.
Framework linh hoạt thưởng cho các nhóm đã có định hướng kỹ thuật mạnh. Bạn có thể tùy chỉnh kiến trúc, chọn thư viện, và điều chỉnh quy ước cho khớp domain.
Giá phải trả là biến thể. Hai dự án dùng cùng framework linh hoạt có thể trông hoàn toàn khác nhau, khiến chuyển engineer giữa đội, tái sử dụng tooling nội bộ, hoặc duy trì chất lượng khó hơn. Linh hoạt cũng tăng khả năng lựa chọn “tạm thời” thành nợ kỹ thuật lâu dài.
Mặc định nghiêm ngặt có thể đơn giản hóa tuyển dụng bằng cách thu hẹp kiến thức cần thiết, và làm cho hợp tác giữa đội dễ hơn vì pattern dự đoán được. Mặc định thoáng hơn có thể mở rộng nguồn ứng viên (mọi người mang theo công cụ quen thuộc), nhưng hợp tác thành công phụ thuộc nhiều hơn vào tiêu chuẩn văn bản và review kỷ luật.
Quy tắc tham khảo: đội nhỏ thường hưởng lợi từ mặc định có quan điểm vì giảm overhead phối hợp. Tổ chức lớn cũng có thể chọn framework có quan điểm để nhất quán, trừ khi độ phức tạp domain đòi hỏi linh hoạt. Nếu thất bại có chi phí lớn (bảo mật, tuân thủ, an toàn), nghiêng về framework có mặc định hướng nhóm đến thực hành an toàn và lặp lại được.
Mặc định framework được tối ưu cho app “điển hình”. Sản phẩm thực tế hiếm khi điển hình lâu. Bạn càng sớm nhận ra sự không khớp, bạn càng ít tốn thời gian vá vá.
Mặc định thường xung đột với ràng buộc sản phẩm mà tutorial không nhìn thấy:
Nhìn vào thói quen phát triển hàng ngày:
Đó không chỉ là phiền toái. Chúng tạo chi phí ẩn: debug khó hơn (vì hành vi không còn dự đoán được), onboarding chậm, và nợ kỹ thuật tích tụ rải rác trong config thay vì quyết định rõ ràng.
Khi mặc định không phù hợp, bạn có hai lựa chọn lành mạnh:
Chìa khóa là xem “mặc định” như đề xuất khởi đầu—không phải hợp đồng vĩnh viễn.
Mặc định tiết kiệm thời gian, nhưng thay đổi chúng tuỳ tiện có thể tạo ra sự không nhất quán giữa môi trường và đội. Cách an toàn là coi việc ghi đè như các quyết định thiết kế nhỏ: có lý do, được ghi lại, và có thể lặp lại.
Trước khi viết nhiều mã, rà soát nhanh cấu hình khởi tạo và hỏi: “Điều gì sẽ gây hại nếu giả định này sai?” Giữ nhẹ—làm trong 15 phút.
Checklist thực tế cho dự án mới:
Khi bạn thay đổi mặc định, ghi lại “tại sao” gần chỗ thay đổi (comment cấu hình, ADR, hoặc note ngắn trong /docs). Mục tiêu không phải quan liêu—mà là làm cho bảo trì tương lai có thể dự đoán.
Nếu bạn ghi đè, cũng lưu lại:
Tránh các bước thiết lập dựa trên kiến thức truyền miệng. Nạp quyết định vào template, generator hoặc starter repo để dịch vụ mới không trôi dạt.
Nếu bạn duy trì nhiều app, một repo baseline chung (có CI, linting và config an toàn) thường đáng đầu tư. Liên kết nó từ /docs/getting-started.
Một vài mặc định xứng đáng có checkpoint rõ ràng trong review—đặc biệt auth, CORS, và lưu trữ dữ liệu nhạy cảm. Checklist PR đơn giản hoặc label “yêu cầu review bảo mật” ngăn các suy giảm vô tình mà không làm chậm mọi thay đổi.
Mặc định giờ không chỉ đến từ framework—chúng còn đến từ công cụ tạo điểm khởi đầu.
Nếu bạn dùng nền tảng tạo app bằng chat như Koder.ai để sinh app từ prompt (web React, backend Go + PostgreSQL, mobile Flutter), xử lý dự án sinh ra như template framework:
Nguyên tắc cốt lõi vẫn vậy: tiện lợi là tốt, nhưng chỉ sau khi bạn xác nhận mặc định tối ưu cho điều gì—và đánh đổi ngầm là gì.
Mặc định dễ sống cùng nhất khi nhóm coi chúng là điểm khởi đầu—không phải quy tắc vô hình. Thói quen lành mạnh biến “framework tự làm” thành quyết định có chủ ý và chia sẻ, để dự án vẫn dễ duy trì khi lớn lên.
Mỗi lần lệch khỏi mặc định là thứ nhóm phải nhớ, ghi chép và giữ tương thích theo thời gian. Quy tắc thực tế: chỉ ghi đè khi rõ ràng hỗ trợ mục tiêu nhóm (tư thế bảo mật, yêu cầu truy cập, tốc độ phát hành, nhất quán), và viết mục tiêu đó ra.
Một mẫu nhẹ là note ngắn “Mặc định chúng ta đã thay đổi” trong repo (ví dụ /docs/decisions/defaults.md) ghi:
Khi mặc định không phù hợp, trước tiên tìm cài đặt cấu hình hoặc extension được hỗ trợ. Fork (framework, template hoặc scaffold nội bộ) có thể đóng bạn vào hành vi cũ và làm upgrade đau đớn.
Nếu phải khác biệt, hướng tới lớp nhỏ nhất phía trên: plugin, wrapper, hoặc module tùy chỉnh—gì đó có thể xóa sau này.
Mặc định tiến hóa. Một mặc định “an toàn” hai năm trước có thể giờ yếu hơn, và mặc định hiệu năng có thể khác trong version lớn mới. Thêm checklist nhỏ vào công việc nâng cấp: quét release notes tìm thay đổi mặc định, chạy lại baseline bảo mật và hiệu năng, xác nhận ghi đè vẫn hợp lý.
Người mới sao chép những gì họ thấy. Nếu họ chỉ học làm gì, họ sẽ cargo-cult các pattern không còn phù hợp. Trong onboarding, giải thích:
Hiểu biết chung đó giữ cho mặc định hữu ích—và ngăn codebase tích tụ các quy tắc vô ý.
Mặc định framework không vô tư. Chúng hướng cách bạn cấu trúc app, viết mã, test (hoặc không), triển khai, và cách nhóm cộng tác. Theo thời gian, những quyết định khởi đầu đó định hình kết quả: tốc độ giao hàng, nhất quán, tư thế bảo mật, không gian hiệu năng, và loại nợ kỹ thuật bạn tích tụ.
Điểm chính đơn giản: mặc định là các quyết định thiết kế—chỉ là đã được chọn trước. Xem chúng như các lựa chọn có chủ đích (thay vì tiếng ồn nền) là một trong những cách dễ nhất để cải thiện trải nghiệm nhà phát triển và sức khỏe dự án.
Chọn một dự án đang hoạt động và audit các mặc định bạn tin là hiển nhiên. Mục tiêu không phải viết lại mọi thứ; mà là xác nhận bạn thực sự nhận được lợi ích bạn nghĩ.
Mặc định framework nào đã giúp bạn nhiều nhất trong dự án thực tế—và mặc định nào gây đau sau đó (bất ngờ bảo mật, nút thắt hiệu năng, quy ước gây nhầm lẫn, hay ma sát đội)? Nếu bạn có một “bẫy mặc định” đáng nhớ, đó có thể là bài học người khác tránh được.
Các mặc định của framework là những lựa chọn đã được thiết lập sẵn khi bạn tạo một dự án mới: template, file được sinh tự động, cấu hình khởi tạo, các tính năng bật mặc định và các mẫu trong tài liệu chính thức.
Chúng quan trọng vì chúng trở thành nền tảng mà nhóm bạn coi là “bình thường”, thường lâu trước khi ai đó cân nhắc các phương án thay thế.
Các mặc định kết hợp một vài lực tác động:
Tất cả cùng nhau khiến lựa chọn dễ nhất trông giống như lựa chọn đúng nhất.
Hướng dẫn là tùy chọn khi gặp áp lực; mặc định thì đã có sẵn trong repo.
Một cấu trúc thư mục mặc định, output của generator hay chuỗi middleware ảnh hưởng trực tiếp đến thứ được commit trong ngày đầu tiên và điều mà code review xem là “idiomatic”, nên đường đi mặc định thường tồn tại mà không cần quyết định rõ ràng.
Kiến trúc bị hình thành ngay lập tức bởi template và generator:
Khi các mẫu này lặp lại ở hàng chục file, thay đổi sẽ trở nên tốn kém.
Ví dụ trong tài liệu thường trở thành style guide thực tế vì đó là những mẫu chạy được đầu tiên mà dev nhìn thấy.
Nếu tài liệu cho thấy logic đặt trong controller/component, điều đó có xu hướng trở thành bình thường. Nếu cho thấy xử lý lỗi tập trung và phản hồi có cấu trúc, nhóm sẽ dễ áp dụng cách làm có thể dự đoán khi có lỗi và giúp debug rõ ràng hơn.
Hãy xem các mặc định bảo mật như một bộ khởi đầu, không phải bằng chứng an toàn.
Thực hiện rà soát nhanh trong tuần đầu của dự án về:
Secure, SameSite) và cấu hình session\n- Đầu ra lỗi (trang debug, stack trace chi tiết)\n- Việc thi hành authorization (dễ bị quên trên endpoint mới)Sau đó hãy ghi lại những gì bạn phụ thuộc vào và những gì bạn đã thay đổi.
Các vấn đề phổ biến bao gồm:
Một cách thực tế là lên lịch rà soát trước khi ra mắt để tinh chỉnh caching, bundle, pattern truy cập DB và observability.
Khi test runner, linter, formatter và CI đã được cấu hình sẵn, con đường ít cản trở nhất là “viết code cho qua các kiểm tra”. Điều đó cải thiện nhất quán và chuyển trọng tâm của review sang nội dung chứ không phải phong cách.
Nếu các công cụ này thiếu mặc định, dự án thường trôi vào “chuẩn hóa sau”, và điều đó dễ thành sự không nhất quán lâu dài.
Dùng ma sát làm tín hiệu, đặc biệt khi bạn thấy:
Khi đó, hãy hoặc là tập trung và ghi chép các ghi đè có chủ ý—hoặc cân nhắc xem framework còn phù hợp không.
Một cách an toàn là coi việc ghi đè như các quyết định thiết kế nhỏ:
Giữ các ghi đè nhỏ, và kiểm tra lại sau khi nâng cấp framework.