Dealing with busy situation of finalizing development

About last 5 days were dedicated to prepare newly developed iOS app to be submitted to the App Store. During those days, unknown but high priority errors were found and prevented other issues to be solved in time. It was extremely stressful to find the causes and solutions, especially if every line of code compiled and worked just fine. As expected, the main causes were architecture related, run-time issues, which are usually considered to be more difficult than anything else.

What made me more frustrated was that, the architecture was working just fine until new feature were added for the requests that were made so late as when we were just ready to submit the product to the App Store. As we were adding new feature, processes were changed and other components were affected without our knowledge. To those who request, it’s just one more feature. However, to those who develop, it’s one more variable affecting entire system.

Also, I have realized how inexperienced I am, especially if I am under time constraining situation. If newly added feature is not working right at first, I easily lost confidence in my own design of software, and attempted to modify it to accommodate the new feature. And because this modification on the currently working design was made hastily, I often overlooked how important components were affected by recent change.

I should have more training on staying calm and keeping the confidence in finely working software design in the midst the frantic development.

Re-organizing once unclear iOS project

For about three weeks working for the company, I have been dealing with the project that has been developed by other programmers before. Looking through the lines of code, I could observe how lack of solid architecture made the project to be extremely difficult to manage and discouraging for a newly added member like me to understand the flow and make meaningful contribution for significant progress of the project.

After a week of struggling with the unclear organization of the project, I rearranged some part of the code. Though it wasn’t done for the whole project, re-structuring classes and flow of method calling based on MVC convention did bring some sense to the project and allowed me to get on the track quite earlier than how I worried it to be.

Probably, it was because iOS development is usually done by only Xcode and only one kind of SDK, and the most of recommended practices are already established firmly and shared to the public. They are clear enough for an intermediate programmer like me to apply on the project.

With this experience of re-organizing the project and being benefited by it, I am so much motivated than ever to master software architecture, design patterns, and other important practices. For a software development project to succeed, help of an architect is necessary and I wish to be the one who is truly helpful.

One week has passed working for new company

One week has passed working for new company. Testing my skills in iOS development has commenced.

Unfortunately, what I have feared did happen. I got involved to the project which is struggling to be finished for some reason. It was impossible to avoid being the newly added member to the project in the midst of development. This is really daunting for me, since I have to do cramming to learn the whole plan and history of successes and failures, in limited time before the due date. And I must meet their expectation for me to actually contribute something helpful to increase the chance to finish the project successfully.

Above all, it’s really frustrating when the solutions I want to implement are not working for this project, when they are the similar ones I had done successfully in other places. Being a new comer to the project is really hard for me to trace the causes of problems, without having enough time to understand whole lines of codes and their intentions. It scares me how bad it will be if the project is much larger than current one.

I just want to save precious time, without being troubled by failed tests of implementations. It could be much better if I could get involved from the beginning of a project.

[Korean] Explaining How I developed PopToo service

This is written in Korean, introducing myself for the development job application. However, actually this describes how I developed PopToo, what I thought and what decisions I made, rather than who I am in general. Though it’s unconventional, telling the story about what I have done for my project can tell more about who I am, since I am applying for a technical job requiring to solve to problems. I don’t know when it will be, but perhaps I may rewrite this in English to be shared, or to be used for applying for other development jobs.

[아이폰 개발]
전세계 많은 개발자들과 마찬가지로, 독학으로 직접 개발을 해보면서 학습을 했습니다. 이전부터 MacBook 제품을 사용해 왔으며, iPhone 3GS, iPad, iPhone 4 모두를 경험해보면서, 최종적으로 현재 PopToo iOS App 을 완성하여 App Store 에서 서비스 하고 있습니다.

개발을 진행하면서, Objective-C 의 장단점을 충분히 경험할 수 있었으며, 성능 향상을 위해서 iOS Framework 의 전반적인 특징과 Multi-Threading 의 기초를 습득, 구현하였으며, iOS 가 제공하는 객체형 데이터베이스 Core Data 의 장점을 최대한 활용하여, 유지 보수에 탁월한 소스를 효율적으로 완성할 수 있었습니다. 충분한 검토와 고민을 하여 탄탄하고 버그 없는 Version 1.0.0 이 설계되었고, 데이터베이스 Migration 등을 포함한 업그레이드를 설계상의 큰 변형없이 무리없이 진행하면서, 현재 버젼 1.2.x 를 서비스 하고 있습니다.

아이폰 및 다른 프레임워크에서도 공통적으로 추구되는 객체지향과 MVC 방법론을 최대로 응용하여 장기적으로 유지 보수에 탁월한 설계를 완성하였습니다. 물론, 동료 개발자들과 소스가 실제로 공유될 시에는 여러가지 다른 사항들을 보완해야겠지만, 개인적으로 객체지향의 최대 장점이라 여기는 Inheritance 와 Polymorphism 의 혜택을 받으면서 수정과 개선에 필요한 작업을 최대 코드 몇줄 수준까지 줄일 수 있었습니다. 설계상 시작부터 DRY 원칙을 지키면서 Model – View – Control 을 서로 분리하였기에, 한쪽의 변경이 어떻게 다른 부분에 영향을 미치는지 확인이 무척 용이하였고, 단순반복 작업을 피하면서, 이후 업그레이드 까지 준비할 수 있었습니다.

소스코드 작업을 할 때에는 객체의 상태와 변수 값을 구동 중에도 테스트합니다. 데이터베이스 모델이 수시로 변경되고 객체의 클래스 자체가 변경될 지라도, 기본적인 구동에는 문제가 없게 할 수 있기 때문입니다. 거기에 더불어, Xcode 의 기능들을 최대한 활용하여 수시로 Build 상황을 점검하면서, 버그 없는 결과물을 만들기 위해서 테스트에 충분한 시간을 할애하고 있습니다. 물론 시간이라는 중요한 자원을 소비해야 하지만, 훌륭한 결과물이 만들어지면, 사후 관리에 필요한 시간을 별도로 할애해야 하는 상황을 방지할 수 있기 때문에, 궁극적으로는 오히려 시간을 더 아낄 수 있다고 여깁니다. 특히 PopToo 의 경우에는 버그 제거에 국한되지 않은 지속적인 업그레이드를 사용자들에게 제공해야 하기 때문에 꼭 필요한 설계 및 작업 방식이었습니다.

훌륭한 개발자 분들이 거듭 강조하시는대로, Comment 설명이 굳이 필요하지 않을 만큼 사람이 읽기 편하고, 설계의 의도와 당위성이 보이는 코드를 작성하고자 최선을 다했습니다. 목적과 용법을 쉽게 파악할 수 있는 변수, 클래스 및 메소드 명을 사용하였으며, 성능을 최대한 헤치지 않으면서 개발자가 쉽게 작업 순서도를 파악할 수 있게 한줄 한줄 신경을 썼습니다. 물론, 공동 작업자가 없이 혼자만 보게된다면 그리 심각하게 여기지 않아도 되지만, 불필요한 반복과 실수를 방지하는데 가장 좋은 방법이라고 여깁니다. 소스코드 자체가 개발 설계도가 될 수 있게 하면, 최대의 결과물이 나올 수 있기 때문입니다.

[웹 애플리케이션 개발]
PopToo 는 위치기반의 음악 정보 공유 서비스로서, 독자적인 앱으로서만이 아니라, RESTful 웹 애플리케이션과 함께 연동되는 Social Network Service 입니다. 각각의 아이폰 앱에서 데이터를 중앙 서버에 업로드하고 다른 사용자들이 공유한 데이터를 다운로드할 수 있어야 합니다. 결국, 아이폰 앱 개발 만으로는 해결할 수 없는 부분이라서 추가적인 학습이 필요한 주제였습니다.

이전부터 WordPress 기반의 블로그를 운영하면서, PHP 와 MySQL 를 활용해 보았습니다. 개발 초기에는 간단하게 PHP 를 활용한 RESTful 기반의 애플리케이션을 이용하였습니다. 웹 개발에는 초보였던 제게는 단순히 아이폰 앱에서 데이터를 업로드하고 MySQL 에 저장하고, 다운로드 받을 수 있는 것에 만족을 했었습니다. 블로그 용의 일반적인 PHP 호스팅을 사용한 무척이나 단순한 초보 수준의 작업이었습니다.

하지만, 점점 더 RESTful 기반의 웹 애플리케이션 개발에 대해 학습을 하면서, 블로그용 호스팅을 사용하는 것은 좋은 선택이 아니며, 성능과 확장성을 위해서는 PHP 보다는 Ruby 또는 Python 이 훨씬 더 용이하다는 것을 알게 되었습니다. 더군다나 자료를 검색해보아도 Ruby 또는 Python 을 이용한 자료가 훨씬 더 많고 선호됨을 알 수 있었습니다. 바쁘게 진행되는 아이폰 앱 개발에 비해서, 웹 개발은 지식과 경험의 부족함으로 어떻게 설계해야 하고 작업해야 할 지 확실한 결정을 내리기 힘들었습니다.

다행이도, Google, Amazon, Heroku, Engine Yard 등에서 개발자들을 위해서 웹 애플리케이션 전용 클라우드 호스팅을 제공하고 있습니다. 처음에는 작은 규모에서 무료로 서비스를 이용하고, 성장 규모와 트래픽에 따라서 추가 비용을 지불하게 하는 방식이어서, 본인과 같은 소규모 개발자에게, 막 새롭게 웹 개발을 배우기 시작한 사람에게는 무척이나 유용한 서비스입니다.

Ruby 기반의 Heroku 와 Python 과 Google App Engine 중에서 선택을 하려는데, 막상 두가지의 장점과 단점을 비교하기 보다는 제가 가진 한계를 어떻게 보완해 줄 수 있느냐에 더 큰 비중을 두었습니다. 개인적으로는 Ruby 언어에 대한 관심이 무척이나 크고, 학습자료의 방대함과 커뮤니티에 매료되었기에 Heroku 서비스를 이용하고 싶었으나, 웹 애플리케이션은 개발자의 역량뿐만 아니라 서버의 성능과 확장력에 대한 의존도가 무척이나 높기 때문에, 별도의 관리대응능력을 갖추지 않으면 상당히 어렵거나, 추가 비용이 많이 필요할 것으로 판단되었습니다. 반면, Google App Engine 은 이용방식에 제약이 많고, 자료가 상대적으로 많지 않지만, 자동적으로 일정 규모까지 서버의 성능을 애플리케이션에 맞게 조절을 해줄 수 있고, 일정 Quota 까지는 무료로 이용할 수 있기때문에, 저와 같은 비전문 웹 개발자에게는 상당히 유용하고 경제적인 선택이었습니다.

현재 웹 애플리케이션은, 학습자료에서 가르쳐 주는 소스들을 활용한 가장 기본적인 데이터 저장과 전송을 맡고 있습니다. 분명 PopToo 가 어떻게 성장하느냐에 따라, 웹 애플리케이션의 중요도가 커질 터인데, 시간을 내어서 웹 애플리케이션 개발능력을 더 키워보고 싶습니다. 아무리 아이폰 앱 개발에 집중을 하고 싶을 지라도, 웹 개발의 기초 정도는 분명 파악을 하고 Prototype 수준으로라도 개발을 할 수 있어야, 공동 작업시 웹 개발 담당자와의 의사소통과 작업 효율을 높일 수 있을 거라 생각합니다.

%d bloggers like this: