1. 11

Simon Whitaker examines the exorbitantly large code base of Facebook’s iOS app and makes some justifications.


  2. 4

    memorializeUser(687406370, 499891768)

    So in case you haven’t guessed what I got wrong yet, I managed to get the arguments the wrong way round. Instead of me memorialising my test user, my test user memorialised me.

    I hated it at first, but now I’ve really come to appreciate Objective C’s expressive method names with embedded arguments. It’s nearly impossible to screw up the order of things, and you know just from reading code that calls the method what the arguments being passed are for.

    A lot of ruby projects seem to emulate this by passing in a hash of argument keys and values, but it’s error-prone and adds a lot of code for parsing arguments. I just make long method names that tell you the order of the arguments so it’s ban_by_user_for_reason!(banner, reason) instead of just ban!(banner, reason).

    I would expect memorializeUser with two arguments in an Objective C project to be called something like memorializeUser:withLegacyUser:.

    1. 1

      The long method names in Objective-C are, along with the bottom propagation, my favorite thing about it. The further I get into using C++, the more I miss Objective-C.

    2. 2

      I think some of these things can be regarded as rationalizations (e.g. we don’t use $X because we’re too big!) but one particular idea rings pretty true: Simon says there are a lot of developers from different feature teams working on the app, and that comes along with a high volume of code duplication. That seems like it makes sense because in order to have many developers committing, you must either introduce communication bottlenecks (where developers working on X can’t make progress because they need to update Y which is also used by numerous other developers) or you remove dependency sharing. And, it sounds plausible that in order to allow feature development to proceed at pace you must let many independent feature teams work on it. So, if there was only one team that committed to the app then you could eliminate code duplication but you would introduce a bottleneck.

      Another thing mentioned that I found interesting was the in-house layout engine. I don’t use the FB app regularly, so I’m not sure what sort of crazy layout they’re doing in their feed browser, but I wonder why they couldn’t inflate view hierarchies from xibs, or whatever. Maybe the layout engine was motivated by bad experiences with the Android layout engine that lead the company to decide to bring that dependency in house for all platforms.