Facebook created a tool which detect and repair bugs automatically
The recent document by Facebook engineers explains how they wrote a tool that can automatically fix bugs. In the paper, they introduced SAPFIX, an automated tool designed to detect and repair bugs in software. The tool has suggested fixes for six essential Android apps in the Facebook App Family: Facebook, Messenger, Instagram, FBLite, Workplace, and Workchat.
How Does It Work?
Step 1: Detect a Crash - Another tool, Sapienz, finds app crashes. When Sapienz identifies a crash, it is logged into a database.
Step 2: Identify the Problem—SAPFIX pinpoints the exact line of code causing the issue. It first checks if the crash is reproducible. If it's not, the crash is discarded. It uses a technique called "spectrum-based fault localization" to identify the most likely lines of code responsible for the crash.
Step 3: Suggest a Fix - Using predefined templates or code mutations, SAPFIX proposes a solution. After identifying the fault location, SAPFIX attempts to generate a patch. It employs two strategies:
Template-based Fixing: SAPFIX suggests fixes for common bugs using predefined templates designed based on standard developer practices.
Mutation-based Fixing: If the template-based approach fails, SAPFIX resorts to a mutation-based system. It systematically applies a series of code mutations to the fault location to generate potential fixes.
Step 4: Test the Fix—The proposed solution is tested to ensure its validity. It uses the test cases from Sapienz to check the patch's validity. If the patch passes all tests, it's considered a good fix. After patch validation, SAPFIX uses Infer (a static analysis tool) to analyze the proposed fix further. Infer checks if the patch introduces any new potential issues.
Step 5: Review - Developers get the final say, reviewing and approving the fix.
To learn more about it, check the entire document.
What is the Twelve-Factor App?
It describes many well-tested architectural patterns and best practices for software-as-a-service (SaaS) applications. Thanks to these best practices, apps can be created with portability and resilience when deployed to the web.
It was created by engineers at Heroku, a cloud platform-as-a-service company, around 2011. Adam Wiggins, a co-founder of Heroku, played a significant role in articulating and promoting these principles. This framework continues to be influential, aiding in designing and deploying scalable and maintainable software applications.
The Twelve Factors:
Codebase - One codebase tracked in revision control, many deploys
Dependencies - Explicitly declare and isolate dependencies
Config - Store config in the environment
Backing services - Treat backing services as attached resources
Build, release, run - Strictly separate build and run stages
Processes - Execute the app as one or more stateless processes
Port binding - Export services via port binding
Concurrency - Scale out via the process model
Disposability - Maximize robustness with fast startup and graceful shutdown
Dev/prod parity - Keep development, staging, and production as similar as possible
Logs - Treat logs as event streams
Admin process - Run admin/management tasks as one-off processes
Beyond the twelve-factor application
Also, in the book "Beyond the 12 Factor App", Kevin Hoffman presents new guidelines that build on the original 12 factors but include elements such as telemetry and security:
One codebase, one application - Applications and repositories should be one-to-one.
API first - Make your API a first-class citizen in your development process.
Dependency management - Define dependency for each application.
Design, build, release, and run - We must define our development process in these four steps and execute them independently.
Configuration, credentials, and code - Manage configuration, credentials, and code separately.
Logs - We want to treat logs as event streams and use tools to analyze them.
Disposability - Make the possibility to restart your apps quickly.
Backing services - Define backend services and connect them via Cloud functions.
Environment parity - All environments should be the same.
Administrative processes—Such as DB migrations or batched jobs—should be run as a separate function from the application.
Port binding - Mapping application ports to actual ports on the Cloud infrastructure.
Stateless processes - We want the possibility to restart the server quickly at any time.
Concurrency - Design your applications so they can handle multiple processes.
Telemetry - Create a way to measure the application's performance (logs, domain telemetry, APM, etc.).
Authentication and authorization - Implement security from the beginning of your project.
Also, check IBM's view on this topic: “Beyond the 12 factors: 15-factor cloud-native Java applications”.
Bonus: The Startup CTO’s Handbook
Check this useful (free) handbook, created by Zach Goldberg, which covers some essential topics for all tech leaders, such as:
Leadership
Engineering management
Different tech topics (architecture, Testing, DevOps, etc.)
More ways I can help you
1:1 Coaching: Book a working session with me. 1:1 coaching is available for personal and organizational/team growth topics. I help you become a high-performing leader 🚀.
Promote yourself to 18,000+ subscribers by sponsoring this newsletter.
