Insights into Google’s Development Practices: Code Management, Front‑end/Back‑end Collaboration, and Workflow

The author, who has worked at a large tech company (referred to as B), shares observations gathered from public sources, the book *In The Plex*, and informal discussions about the internal development practices of another major company (referred to as G). The purpose is to provide technical insight and possible references for future improvements.

Note: The information is collected from the internet, the book *In The Plex*, and casual conversations. It reflects personal opinions and may contain unverified details.

Division and Collaboration

Most product lines at G do not separate front‑end and back‑end engineers; a single engineer often handles the full stack. Recently, dedicated Front End positions have appeared but remain rare.

Interviewees report that G requires candidates to know at least one of C++ or Java; Python/PHP alone is insufficient, and pure JavaScript knowledge is even less valued.

The author argues that front‑end engineers should understand basic back‑end concepts. In some companies, front‑end engineers only develop templates (e.g., Smarty), leading to dependency on back‑end engineers for environments and data, which hurts productivity.

Some domestic companies further split front‑end work into HTML/CSS and JavaScript roles, a practice the author disagrees with because HTML and JS are tightly coupled.

Code Management Methods

Key observations include:

All internal code is visible to everyone. Submissions require review, enabling engineers to switch projects easily.

Only a trunk (latest) version exists. No separate release branches or version numbers. New interfaces are added freely; modifying existing ones requires notifying all users.

Code search engine. Engineers rely on searching existing code rather than writing extensive documentation.

Global dependency management. Similar to Chromium’s GYP or npm, but multi‑language.

Minimal use of third‑party libraries. Internal versions are preferred; new third‑party libraries undergo lengthy approval.

Perforce as the version‑control system. Used for over 17 years, handling millions of changelists and hundreds of thousands of files. Review tool is Mondrian (the predecessor of Rietveld).

The lack of versioned releases is a double‑edged sword: it encourages openness and collaboration but can also create coordination challenges.

Feature Flag

Because there are no branches, new functionality is toggled via feature flags managed by the online Borg system. Flags can target specific user groups for A/B testing. Removing a feature that does not ship requires manual code deletion, and the flag system itself can become a critical point of failure.

Strict Code Checks

Engineers write extensive unit tests; UI testing is limited to Selenium or custom screenshot diffs. Submissions go through three stages: style checks (very strict, even naming conventions), unit‑test verification, and owner review. Mistakes can affect many projects due to the shared trunk.

Front‑end Development

Most pages are generated by back‑end templates (Java or C++), with very little pure JavaScript. G uses Closure Templates and CTemplate for server‑side rendering. Front‑end engineers often write both Java and JavaScript, while back‑end services are primarily C++ (with some Go adoption).

Because many engineers come from a Java background, GWT (Google Web Toolkit) is widely used to generate cross‑browser JavaScript, enforce structure, and leverage powerful IDE features. However, JavaScript‑only developers often dislike GWT.

Example: the author analyzed the open‑source Wave project (formerly a G product) and found only one 56‑line JavaScript file, illustrating the minimal front‑end code footprint.

Later, Dart was introduced to replace GWT, offering similar benefits. Some products (e.g., Plus) use Closure directly instead of GWT.

Historical data from Gmail shows rapid growth of JavaScript code and the introduction of the Closure compiler, type‑checking, and extensive comments.

While GWT has limited relevance for the author’s team, the author prefers TypeScript for its gradual typing and compatibility with existing JavaScript.

Internal Workflow

The typical project flow includes idea proposal, UX mockup, low‑traffic online experiment, data‑driven analysis, and staged rollout, with many approval gates. Projects often have long cycles (at least a quarter) and many never reach full production.

A Day in the Life (Example: Matt Welsh)

The author outlines a typical day of an engineer at G, covering email checks, coding, code reviews, MapReduce tasks, meetings across locations, and even leisure activities. This illustrates the structured nature of work and the emphasis on data analysis.

Internal Tools

Tools include Sites for internal sites, Docs for collaborative documentation, Chromium’s code review system, Groups for discussions, issue tracking, Buildbots for CI, and various quality‑assurance tools.

Takeaways ("可用的石头")

Open source code without versioned releases, accessible to all engineers.

Strict code style and mandatory unit‑test enforcement (e.g., Travis CI integration).

Demo‑driven examples rather than minimal "hello world" samples.

Co‑location of documentation and code.

Internal use of external products (e.g., Docs) to gather feedback.

Static checking mechanisms (e.g., GWT, TypeScript).

console.dir and Type-checking is important and possible are cited as examples of debugging and type‑checking emphasis.

Overall, the author suggests that many of G’s practices—open code, rigorous review, extensive testing, and data‑driven decision making—are valuable for other organizations, though some aspects (like lack of versioned releases) may need careful consideration.