앱 개발의 다음 단계: 리엔지니어링 or 마이그레이션?

[RAD]

• 원문: https://blogs.embarcadero.com/how-to-make-the-next-app-development-step-reengineering-or-migration/
• 작성자: Softacom Information  (2022.4)

 

Inevitably, during any the lifecycle of any app development there can be a lot of projects that were written or maintained during the period of the Delphi 5/6/7 popularity or even earlier. Many of them have been already migrated to newer versions of the programming language. But some of them are still being developed in old IDEs. Usually, they use a huge range of external components. Some of them have been already abandoned as a modern version of the programming language supports the analogical “out-of-the-box” capacities. Some others are still being actively developed.

앱 개발의 라이프사이클을 진행하다보면 델파이 5/6/7 또는 그 이전에 개발되거나 유지 관리된 프로젝트들이 많이 있을 수 있다는 건 예상 가능하다. 이러한 프로젝트들 대부분은 이미 최신 버전의 프로그래밍 언어로 마이그레이션이 진행되고 있다. 하지만 여전히 일부는 오래된 IDE에서 개발 되고 있다. 이 경우 일반적으로 광범위한 외부 컴포넌트들을 사용하게 된다. 그리고 그 중 일부는 최신 버전의 프로그래밍 언어에서 제공하는 유사한 "즉시 사용 가능한" 기능들로 인해 이미 폐기되기도 했다. 나머지 일부는 여전히 활발하게 개발이 진행되고 있다.

But here we have a question on the necessity to conduct app migration for ensuring modern capacities like cross-platforming or 64-bit app versions. And a huge number of external components can have a negative impact on the time and quality of migration.

여기서 우리는 의문이 하나 든다. 크로스 플랫폼 또는 64비트 앱 버전 등 최신 기능을 보장하기 위해 앱 마이그레이션을 진행해야 하는지 그 필요성에 고민하게 되는 것이다. 또한 엄청난 수의 외부 컴포넌트가 마이그레이션 시간이나 품질에 부정적인 영향을 미칠 수도 있을 것이다.

 

---

목차

첫 번째 단계에서 해야하는 일: 리엔지니어링 or 마이그레이션?

애플리케이션 개발에 있어 마이그레이션이 의미하는 것은?

엔지니어링: 무엇을 위한 것인가?

예제를 통해 살펴보기

 

첫 번째 단계에서 해야하는 일: 리엔지니어링 or 마이그레이션?
(What should be done in the first turn: reengineering or migration?)

애플리케이션 개발에 있어 마이그레이션이 의미하는 것은? (What do we mean by migration for app development?)

If we take that migration is just code actualization for the requirements of the modern IDE, we can move to this stage without any doubt. But if it’s not enough for you just to update the language version, IDE and some components and you need to introduce some more serious changes to provide new capacities like cross-platforming or to fully update the existing UI, do not make a decision too quickly. In such a case, it’s worth considering such a migration stage as reengineering.

마이그레이션이 단지 최신 IDE 요구사항에 대해 코드로 실현하는 것 정도라고 생각한다면, 의심할 것없이 이 단계를 넘어가면 된다. 하지만 언어 버전, IDE, 일부 컴포넌트 업데이트로 충분하지 않고, 크로스 플랫폼과 같은 새로운 기능을 제공한다거나 기존 UI를 완전히 업데이트하기 위해 더욱 중요한 변경사항을 도입할 필요가 있다면 너무 서둘러 결정해서는 안 된다. 이 경우 리엔지니어링과 같은 마이그레이션 단계를 고려할 가치가 있다.

 

앱 개발 리엔지니어링이란? (What is app development reengineering?)

Very often, apps that were built in the early 2000s and that have been seriously expanded since then, do not have any particular architecture. Many of them were inspired by the desire to automate just one process. A developer just wrote an app without any serious preparations or vision. The logic was closely tied with the user interface.

2000년대 초반에 구축되고, 그 이후로는 확장을 계속해 온 앱들은 특별한 아키텍처가 없는 경우가 많다. 그 중 상당수는 하나의 프로세스만 자동화하려는 목적만 가지고 시작하려 할 수 있다. 개발자는 진지한 준비나 비전없이 앱을 금방 만들어낸다. 로직은 UI와 밀접하게 연결되어 있다. 

Then there appeared a necessity to add some additional functionality. The same actions were repeated. Some code for similar functions was just copied from one module and pasted into another one. The app was growing. The maintenance of such apps is becoming more and more challenging.

그러고 나면 다음 추가해야 할 기능이 필요하게 된다. 같은 행동이 반복된다면, 유사한 기능에 대한 일부 코드를 한 모듈에서 복사해 다른 모듈로 붙여넣는다. 앱이 커지게 된다. 이런 앱의 유지관리는 점점 더 어려워진다.

Later, to change any similar functionality in different modules of the program, it was necessary to introduce changes to every unit. And if a developer didn’t have the possibility to break the vicious circle timely, it is required to re-process the existing code and conduct the re-engineering before migrating the app.

이후에는 프로그램의 다른 모듈에 있는 비슷한 기능을 변경하기 위해 모든 유닛에 변경사항을 적용해야 하는 상황이 온다. 개발자가 악순환의 고리를 제때 바로 잡을 가능성이 없다면, 앱 마이그레이션 전에 기존 코드를 재처리하고 리엔지니어링을 수행해야 한다.

 

엔지니어링: 무엇을 위한 것인가? (Engineering: what for?)

• First of all, it will facilitate app support in the future.
  우선, 앱 지원이 향후 더 원활해질 것이다.
• Secondly, it will facilitate migration.
  둘째, 마이그레이션이 용이해질 것이다.

 

예제를 통해 살펴보기 (Let’s consider an app from our practice as an example.)

The app was being developed for nearly 20 years and gradually it was being migrated to a newer Delphi version. But then a client decided to change the design. The task doesn’t seem to be too complicated, does it? We should have just taken the app and updated its design.

이 앱은 거의 20년간 계속해서 개발해 온 것이고, 더 새로운 델파이 버전으로 옮겨가고 있다. 그런데 고객이 디자인을 변경하기로 결정했다. 여기까지는 그닥 복잡해보이지는 않는다, 그렇지 않은가? 그냥 앱을 가지고 디자인을 업데이트하기만 하면 된다.

But within the process of app migration to a new GUI, the client decided to keep not the entire functionality but just a part of it as some features became outdated and some others had to be simplified. It means that there was a necessity not just to move the code to a newer GUI but to change the logic. And it still seems to be rather simple, doesn’t it? But here we face the first pitfalls. Some parts of the business logic were linked to the entire app. Deleting the obsolete logic became a little bit more difficult task.

그러나 새로운 GUI로 앱 마이그레이션 과정에서, 고객이 일부 기능만 유지하기로 결정했다. 오래된 기능들 중 일부는 없애고, 또 일부 다른 기능들은 단순화하기로 한 것이다. 즉 단순히 더 새로운 GUI로 코드를 옮기는 것으로 끝나는 것이 아니라, 로직이 바뀌어야 한다는 것이다. 아직은 간단해 보인다. 하지만 여기서 우리는 첫 번째 함정에 직면하게 된다. 비즈니스 로직의 일부와 앱 전체를 연동하는 것이다. 구식의 로직을 삭제하는 것은 조금 더 어려운 일이다.

But at the same time, the old app continued working and growing. It still had the same functionality. We had to track the changes in the old code and combine them with ours. Moreover, we couldn’t forget that a new app wouldn’t have some part of the logic and we didn’t have to migrate it. It was the first challenge.

이 과정에서도 오래된 앱은 계속해서 작동하고 성장해왔다. 그리고 여전히 동일한 기능을 제공한다. 오래된 코드에서 변경된 부분들을 추적하고 우리의 코드와 결합해야만 했다. 거기다가 새로운 앱에는 해당 로직의 일부가 없으며, 이를 마이그레이션할 필요가 없다는 점을 기억해야 했다. 첫번째 과제였다.

The second issue was related to the fact that the legacy code had some errors. We had to correct them and provide the team behind the old app with our feedback and then move the code to our app again.

두 번째 이슈는 레거시 코드에 있는 일부 오류와 관련된 것이었다. 해당 오류들을 수정하고 앱 담당 팀에게 피드백을 제공한 후 다시 우리의 앱에 코드를 옮겨야 했다.

All this increased the complexity of the migration.

이 모든 작업이 마이그레이션을 더욱 복잡하게 만들었다.

Another important thing was the time that was spent on migration. Due to requirement changes, it increased as well.

또 다른 중요한 점은 마이그레이션 소요 시간이었다. 요구 사항이 변경되면서, 시간이 더 많이 소요되었다.

And of course, within this process of migration, it was impossible to avoid mistakes that were related to changes in functionality. And once again we needed additional time to correct them.

물론 마이그레이션 과정에서 기능의 변화와 관련된 실수를 피할 수는 없다. 그러나 이를 수정하기 위해서 우리는 시간을 투자해야 했다.

 

이 모든 어려움을 어떻게 피할 수 있을까? (How could we avoid all these difficulties?)

First of all, we should have worked with a legacy code and conducted its reengineering. The simplest thing that we could do was to separate the logic from the UI. It would have allowed us to work with a single code base for our old app and a new one but to have different designs.

우리는 레거시 코드로 작업하고 리엔제니어링을 해야만 한다. 우리가 할 수 있는 가장 간단한 방법은 UI에서 로직을 분리하는 것이었다. 기존 앱과 새 앱의 단일 코드베이스를 가지고 작업은 할 수 있었지만, 각각 다른 디자인을 가지고 있었다.

Yes, in such a form, it won’t be fully correct to call it reengineering but we could have moved further. After separating logic we could have continued improving the existing code. Similar functionality that was contained in different forms of the app could have been combined in separate re-usable classes. The functionality spread across the app could have been united.

이런 형태라면, 리엔지니어링이라고 부르는 것이 맞겠지만 여기서 더 나아가기로 했다. 로직을 분리하고나서 기존 코드를 계속해서 개선할 수 있었던 것이다. 다른 형태의 앱에 있는 비슷한 기능을 별도의 재사용 가능한 클래스와 결합할 수 있었다. 앱에 있는 기능을 하나로 통합할 수 있었다.

We could have not only avoided errors in a new app but also increased the code quality in the old one that is still in use. The introduction of new functionality in one of the apps would have allowed us to introduce the same functionality in the second app.

이로써 새로운 앱에 오류가 발생하는 걸 방지할 수 있을 뿐 아니라, 여전히 구동중인 오래된 앱의 코드 품질도 향상시킬 수 있었다. 이러한 앱들 중 하나에 새로운 기능을 도입하면 두 번째 앱에도 동일한 기능을 적용할 수 있다.

At the current moment, the functionality of the updated app has been realized, implemented and continues to be enriched with new features. The code r-engineering is being executed. And it already has very little in common with what we had initially. The old app is also being developed and used. But what if we need to introduce some functionality from the old app again? I think that it will definitely bring new challenges as both apps are following very different paths in their development.

지금도 업데이트된 앱의 기능은 실현되고 구현되어 새로운 기능들과 함께 계속해서 강화되고 있다. 코드 r-엔지니어링이 실행되고 있는 것이다. 이미 여기에는 초반에 있던 것과 공통점이 거의 없다. 오래된 앱도 개발되어 사용된다. 하지만 오래된 앱에서 일부 기능을 다시 도입해야 한다면? 두 앱 모두 개발 과정에서 매우 다른 길을 걷고 있기 때문에 분명 새로운 과제가 생길 것이라고 생각한다.

There isn’t any universal solution for all problems. But in the case of dealing with legacy code, Softacom would like to recommend starting with analyzing the existing project and requirements. First of all, you should evaluate possible risks and requirement changes. And only after that, you can make a decision on how to work with the code.

모든 문제를 해결할 수 있는 보편적인 해결책은 없다. 그러나 레거시 코드를 다루는 경우, 기존 프로젝트와 요구사항 분석부터 시작할 것을 권장한다. 우선 발생 가능한 위험과 요구사항 변경 사항을 평가해야 한다. 그 후에 코드를 어떻게 사용할 지 결정할 수 있다.

In the considered example, the best decision should have been to conduct re-engineering before migrating the app.

위의 예에서, 최고의 선택은 앱 마이그레이션에 앞서 리엔지니어링을 수행해야 한다는 것이다.

 

데브기어에서는 마이그레이션 무상 컨설팅 서비스를 제공하고 있다. 마이그레이션이 필요한 프로젝트의 규모나 상세 내용을 제출하면, 담당팀에서 검토 후 마이그레이션 과정에서 발생할 수 있는 이슈들을 미리 안내해주는 서비스이다.

유상 컨설팅 서비스도 제공된다. 데브기어 마이그레이션 담당자가 직접 프로젝트를 진행하는 서비스이다. 자세한 내용은 다음 링크를 참고하기 바란다.

• 마이그레이션 컨설팅 서비스: https://devgear.co.kr/consulting#upgrade_migration
• 마이그레이션 센터 (기술자료들): https://devgear.co.kr/archives/products/migration-upgrade-center