![]() As noted above, we like the structure of the app to be trendless and aim to never bind the app to any given tool or library in a way that compromises our ability to change it. ![]() ![]() We use a lot of open source tools in our Android apps. 100% of new code is written in Kotlin and we strongly encourage team members to refactor/rewrite older Java classes in Kotlin wherever possible. Now that Google has made it generally clear that they intend to standardize more on Kotlin we've started enforcing its use. As of the writing of this blog post it's about 67/33 according to GitHub. Large portions of the app are still written in both Java and Kotlin so over time any developer on our team ends up being fluent in both. Up until recently, we had a strong and growing preference for Kotlin, but we didn't force its use and allowed using Java if a team member felt strongly about it. We'll have separate blog posts where we discuss our approach to common functionality and code. To help keep things focused we've intentionally excluded any further discussions about common code from this post and put the emphasis on just the app. We maintain a separate repository of common components that are shared between the apps to provide functionality that we want to be identical like feature flags, authentication/login, mapping controls, etc. The approach should not be bound or dependent on a particular technology, tool, or trend.Ĭurrently the apps do share quite a bit of common, platform level code. Be trend-less and expect that we have to replace everything - It should be easy to incorporate new tools/libraries.Don't reinvent the wheel - We shouldn't waste time solving problems that already have solutions.You should be able to just pull and compile without any fuss. KISS (Keep It Super Simple) - New people joining the team can understand it quickly.Some guidelines we use for how we build things: The information that follows is the result of that work. Starting ~18 months ago we found ourselves at a happy balance point where we had the scale to start re-architecting the app and also the business motivation to support the work. Over time that created a lot of tech debt. We developed and shipped the apps as if the business depended on it because usually it did. Like most startups, we had a scrappy beginning and spent most of our time focused on just getting apps running and shipped with minimum features needed to compete. Some background:Īs of the writing of this blog, DoorDash has been in business for over 6 years and maintaining a growth rate of at least 2-3x/year. In this post we'll be answering the above questions with regard to our Android Dasher app.īefore we begin though, we want to remind you that we are currently hiring across the board for our teams, so if you find any of this interesting and want to work in a dynamic, high-growth environment please apply to one of our open positions here. Order Manager - The app used by many of our Merchant restaurants to track orders they receive from DoorDash.Dasher - The app used by dashers to facilitate delivery.DoorDash - Food Delivery - Our consumer app for ordering food.We currently have three Android apps available to the public via the Google Play store. What architectural patterns are used in the app?.What 3rd party libraries do you use? Recently this usually boils down to interest in Retrofit, Dagger, and Rx.It's a bit different for each candidate but almost always comes down to the following questions: One of the most commonly asked questions from candidates is what our "Tech Stack" on Android looks like. We’ve been aggressively growing our Android teams and will continue to do so. Over the last 2-3 years, this was particularly true for our Android teams as the platform has become more critical to the company. DoorDash has been on a hiring binge since the company was founded, often doubling or tripling in size each year.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |