I was on Facebook yesterday when I saw a job posting for a company’s iOS team. Usually, job postings only stand out with a few keywords such as welfare, technology stacks, etc. but the contents of this job posting were very easily read just like a tech blog. Many of the things I wanted to introduce when I was in my old team were already built here. I tried introducing these things one by one alone as I persuaded my teammates, so I knew that it would have taken a lot of time, effort, and trial and error to build this mobile development environment. As I was nodding my head and reading the post, I thought, ‘what if I read this when I was still a rookie?’ I don’t think I would have understood what’s good or how it’d affect me because I’ve had no experience and knowledge. Now I know because I’ve experienced both a development environment like this and when there wasn’t any. All these big and small things come together to determine the quality of time I spend at work. There need to be only a few things that cut off the flow during development, as well as simple, repetitive tasks.
Quality time of work means a lot of time to focus on development and this time connects to a developer’s growth.

Deployment Automation

“All codes are tested each commit, and builds under development are being shared to the team members dozens of times in a day.”

Automated deployment means an environment where an app is built with a single(or 0) click and is delivered directly to the internal user or external stores. Deployment is simple, repetitive, and time-consuming. When I went to the previous time for the first time, only half of it was automated. An app version or a build number was required to deploy an app. But someone had to commit it manually, create a PR, pass all the tests according to the policy, and lastly, another developer had to approve the PR before uploading the version. Since this was the process, whenever I tried to deliver the app to the team members, two developers’ workflow was cut off. I felt a problem with this method, so I constantly tried to improve it, and in the end, it was automated enough for Siri to deploy the app, and the time and effort spent for deployment were greatly reduced.

To get immersed in development, continuous time without interruption is very important. Two sessions of 30 minutes are not the same as one hour. Sharing builds for dozens of times in a day means the deployment is completely automated, so the developer does not have to worry about it at work, and the team members can install the latest version without having to interrupt other teammates. A good environment has CI/CD in place, so interruptions like these are reduced as much as possible.

Feature Flags

“Introduced feature flags to create an environment where deployment can be done for users every week”

Feature flags are devices that use Boolean values from the back end that can turn features of an app on and off. If there are no feature flags, codes cannot be pushed into the master branch so a feature branch should be managed separately. The larger the feature and the longer it takes to develop, the master and feature branches become further away from each other, and it becomes difficult to merge them together later. I’ve seen cases where the codes get lost and features break because merge conflicts were wrongly modified.
After experiencing something like this, merging code into the master branch becomes a serious task, causing anxiety and fear. Working hard in development and finishing tests well, but facing problems in the last step while merging codes will discourage developers.

If you can develop one feature at a time due to the small number of developers, and you won’t have to deploy the app during that time, you may not feel the necessity of this environment. But if a feature flag is built in, several developers can maintain only one master branch as each of them is developing a different feature, branch management is much easier, and actual deployment can also take place without any problems. Even if there are underdeveloped codes, the incomplete features can be hidden from the users using back-end values. This way, developers can pay less attention to branch management or merge conflicts, and focus more on development. Another advantage of a feature flag is that it can reduce the impact on users by turning off the feature as a temporary measure when problems are found with the released feature.

Code Review and Pair Programming

“Code review is a core feature of an iOS team. (…) Pair programming is often used.”

Minseok Lee, dean of the Innovation Academy, said that ‘a code made without review is like a private loan.’ I couldn’t agree more with it. There’s a term called technical debt in the industry, and it means that a code created by a single developer generates a lot of technical debt like high-interest debt. It’s really unhealthy to identify yourself with your code and try to protect it from change due to excessive attachment. A code should be treated with the idea that it is a common asset owned by the whole team. If you do a code review, techniques are shared and the whole team grows together. As you’re in development, sometimes you might feel proud and think, ‘this is really perfect. I don’t think there’s going to be a particular opinion from the review as well.’ But still, your colleagues will find room for improvement, suggest new ideas, and you can learn new techniques. If you don’t look at each other’s codes and point out room for improvement, you can’t grow as an individual or as a team.

Pair programming is a higher version of code review. It’s more effective for two people with asymmetric skills than for two people with a similar level of skills to do it. Google considers codes created out of pair programming as approved for a code review. I can’t call this pair programming, but I’ve mentioned before in the previous article an experience when I was a rookie, my senior made me sit beside him and see his code and debug, and that helped me greatly and I still remember it until now. Recently, I engaged in pair programming with a rookie developer with me as the teacher. His response was good and it was a good opportunity for me to organize my thoughts and create a more solid design. Pair programming with a senior developer is a very valuable time for a junior developer. You can’t buy this opportunity to learn the techniques and know-how from someone that’s better than you and ask questions as much as you want one-on-one.

A good environment needs to have only a few simple, repetitive tasks, and a lot of time to focus only on development.

To do so, repetitive tasks need to be automated. In addition, an individual, as well as the whole team, can grow together if a code review culture is established. I hope the above standards and examples can help junior developers who are worried about which company or team to go to, or how to improve their surroundings to grow further.

Some of the most useful “Power Xcode Tricks” from the try! Swift World online workshop by @ericasadun

Search Scope

Create custom scopes

You can create custom search scope to limit your search within a subset of your code. For instance, create a scope to search only within your small team's scope.

Exclude certain files ⭐️

Xcode doesn't provide out-of-the-box filter functionality for this. But you can use regex to exclude certain files to create useful search scopes. For example, you can exclude test files from your search.

Other handy search scopes

Tests Only, Swift Only, Objective-C Only, headers, etc.

Search history

Related items

Navigation Pane

Find files with keyword

Find files with keyword X or Y

Wildcard

Recenty opened files

Modified file

Open sibling folders ⭐️

This functionality applies to everywhere with the similar triangle (e.g. Find tab in Navigator Pane, etc)

Open subfolders ⭐️

This functionality applies to everywhere with the similar triangle (e.g. Find tab in Navigator Pane, etc)

Others

File history

Reveal in Project Navigator ⭐️

Edit all in scope

페북 포스팅에서 복사해옴.

모바일 개발자에게 scalability란 뭘까.. 란 궁금증을 오래전부터 지니고 있었습니다. 커리어를 라인에서 시작했는데, 글로벌 수천만의 유저를 감당하는 경험을 해보고 싶었거든요. 그러나 알고보니 수 천만 명의 트래픽은 서버 개발자가 감당할 일이었던거죠. 약간 실망했어요.

서버 개발자는 얼만큼의 트래픽을 감당해봤느냐가 기술력의 척도가 되는데 모바일 개발자는 100명이 쓰는 앱을 개발하든, 100만 명의 유저가 쓰는 앱을 개발하든 큰 기술력의 차이도 없고 코드의 차이도 없다고 느꼈어요. 그럼 대체 모바일 앱에서 scalable한 코드나 시스템을 만든다는게 어떤걸까 싶었어요.

개발자의 기술력이 집약되는 부분은 병목이 발생하는 구간이겠죠. 서버는 사용자들이 동시에 한 곳으로 몰리기 때문에 그 곳에 부하가 발생하고, 이 부하를 해결하는 기술력이 값진 것이고요. 그런데 앱은 사용자가 많다고 앱에 부하가 걸리지 않아요. 사용자가 앱에 몰리는게 아니라 앱이 사용자의 문앞까지 배달되기 때문에요.👇

그럼 대체 모바일 개발자가 해결해야할 병목은 어디일까요. 역설적이게도 모바일 앱의 병목은 사용자가 아니라 개발자로 인해 발생한다는 생각이 들었습니다. 단일 프로그램으로 배포되는 앱에 수많은 개발자들이 코드를 밀어넣는 지점을 병목이라고 볼 수 있지 않을까 싶었어요.👇

유저가 천명일 때와 수천만 명일 때 서버의 구조와 코드가 달라야하듯이, 앱은 개발자가 3명일 때와 100명일 때 코드의 구조와 개발 환경이 완전히 달라야 하더라고요. 그렇지 않으면 병목의 폐해가 개발자 자신에게는 물론이고 사용자에게도 전가되기 시작해요. 앱 최초 실행 시간(startup time)이 증가하고 앱 용량이 계속 커지기만 하고요. 뿐만 아니라 크래시가 증가해서 사용자의 만족도가 줄어들거나, 계속해서 터지는 사이드이펙트 때문에 핫픽스를 밥 먹듯이 해야할 수도 있습니다. 또 빌드 시간이 늘어나서 개발자의 생산성이 저하되고 스트레스 때문에 삶의 만족도가 줄어듭니다. 게다가 100명이 마스터 브랜치에 푸시를 하는 상황에서는 QA를 하고 버그를 잡고 앱을 배포하는 것조차 간단한 일이 아닙니다. 누구는 버그를 고쳐서 체리픽을 할 때 누구는 기능 개발한 코드를 계속해서 푸시하고 있거든요. 100명까지 가지 않더라도 10명만 넘어가도 위같은 문제들이 스멀스멀 발생하지 않나 싶어요.

그래서 최근에 제 궁금증에 대한 실마리를 찾은거 같아요. 모바일 개발자에게 scalability란 회사가 성장하면서 모바일 팀이 점점 커져도 사용자 경험과 개발자 경험 둘다 악화되지 않게 하면서 앱은 계속해서 빠르고 자신있게 배포하는 것이 아닐까라는 생각을 해봤습니다.