Legacy PHP로 개발할 때의 안 좋은 습관들
다음은 내가 Legacy PHP로 개발할 때 쓰던 안 좋은 습관들이다.
register_globals 설정을 켜거나 extract() 함수를 사용한다.
PHP에서 사용자로부터 입력 받은 값은 $_GET, $_POST, $_REQUEST, $_COOKIE 변수에 저장된다. 매번 $_GET['parameter']와 같은 형태로 사용하기 귀찮기 때문에 register_globals를 On으로 설정하거나 extract() 함수로 일반 변수로 변환해서 사용했다.
개발하기에는 편리하지만, 다른 변수를 덮어쓸 수 있는 심각한 보안 문제가 있어서 좋지 않은 습관이다.
SQL문을 Raw Query로 작성한다.
프레임워크를 사용하지 않으면 어쩔 수 없는 부분이긴 하다. 사실 나는 아직도 Eloquent ORM이나 Query Builder를 사용하는 것 보다 Raw Query를 사용하는게 더 편하다. 간단한 쿼리는 상관없지만, JOIN이나 Sub Query같은 복잡한 구문의 쿼리는 Raw Query가 작성하기에 더 편리하기 때문이다.
하지만, Raw Query를 사용하게 되면 데이터베이스 엔진을 교체하거나 하는 Issue가 발생할 경우 모든 쿼리를 수정해야 한다는 치명적인 단점이 있다.
비즈니스 로직에서 HTML, CSS 문자열을 출력한다.
MVC 프레임워크를 사용하는 가장 큰 이유이기도 하다. 비즈니스 로직에서 화면 단에 출력되는 HTML 태그나 CSS 스타일 구문을 아무 생각 없이 문자열로 출력하는 경우가 대표적이다. 당연히 개발 결과물의 일관성이 없어지고 유지보수하기가 까다로워진다. 협업이 힘들어지는 것은 두말할 필요도 없다.
Controller 함수와 Helper 함수를 한 파일에 몰아넣는다.
나는 globals.php 같은 파일을 만들어서 거기에 Helper 함수와 Controller 함수를 구분없이 몽땅 집어넣고 모든 PHP 파일에서 include하는 형식으로 개발했다. 구 버전의 제로보드와 Tattertools에서 이런 방식을 활용했다. 당연히 안티패턴에 해당되며 모든 변수와 함수가 공유되기 때문에 보안에 취약한 개발 방법이다.
더 있을지도 모르지만, 대충 생각해서 정리해 본 것이 이 정도 되는 것 같다.
지난날을 반성하고 디자인 패턴과 소프트웨어 공학을 열심히 공부 해야겠다.
Develop Framework Legacy PHP Software Engineering Anti Pattern Design Pattern
프레임워크를 활용한 개발의 장점
나는 약 10년 간 Legacy PHP 개발자였다.
개인 홈페이지(제로보드)와 블로그(Tattertools)를 운영하며 해당 솔루션의 코드를 보고 프로그래밍을 독학하였기 때문에 프로그래밍의 기초를 모른 상태에서 프로그래밍을 했다.
당연히 소프트웨어 공학, 디자인 패턴 등 고급 기술에 대한 지식이 전무하였고, 이는 점차 개발 경력이 쌓일 수록 나를 붙잡는 족쇄가 되었다.
Legacy PHP로도 충분히 개발은 가능하다. 전 회사에서도 Legacy PHP로 개발을 잘 했다. 그리고 잘 동작하게 만들 수 있다. 보안 취약성도 Parameter를 필터링하고 특수문자를 필터링해서 잘 해결 했다.
하지만, 가장 큰 문제는 직장인 개발자에게 요구되는 핵심 역량인 "협업"이 불가능하다는 것이다.
객체지향 프로그래밍을 하고 프레임워크를 도입하는 이유가 여기에 있다. 회사는 나 혼자 일하는 곳이 아니기 때문에 반드시 협업을 해야 한다. 하지만 "나만의 세상에 갇힌" 코드로 개발을 하게 되면 동료나 후임자가 그 코드를 이해하는데 "비용"이 크게 발생한다. 남이 작성한 코드를 봐야하는 일 자체가 달갑지 않은 일인데 듣도 보도 못한 스타일의 코드를 해석하자면 고문이 따로 없을 것이다.
이것을 해결하는 것이 "프레임워크"이다. 프레임워크는 개발자에게 코드 스타일, 설계의 표준을 어느 정도 강제하고 이를 따르도록 만든다. 해당 프레임워크를 학습하는데 초기 비용이 발생하지만, 그 프레임워크가 어느 정도 인지도가 있고 생태계에서 영향력이 있다면, 그 프레임워크를 사용하는 개발자를 쉽게 채용할 수 있을 것이고 해당 프레임워크 개발자만 채용한다면 쉽게 업무 인수인계를 할 수 있다는 장점이 있다.
물론 프레임워크에서 강제하는 코드 스타일과 표준은 개발자 개인에게도 역량 개발의 기회가 될 수 있으며, 프레임워크가 제공해주는 편의 기능과 Helper 등은 개발 생산성을 향상시켜준다.
어떤 프로그래밍 언어를 배우고자 한다면 해당 언어에서 가장 널리 쓰이는 프레임워크를 공부하는 것이 좋은 학습법이라고 할 수 있겠다.
블로그를 직접 개발하게 된 이유
개인 블로그를 만들기 위해 다음 두 가지 방안을 고려하였다.
- 솔루션 활용
- TextCube, Wordpress ... etc
- 자체 개발
처음에는 솔루션을 활용하고자 하였다. 고작 블로그 하나를 개발하는데 너무 많은 시간을 뺏기기 싫었고, 특히 Wordpress의 경우 다양한 플러그인과 테마를 활용 수 있다는 점이 눈길을 끌었다. 이를 잘만 활용하면 다채롭고 확장성있는 블로그를 만들수 있다는 판단에 1순위 고려 대상이 되었다.
하지만, 나는 개발자다. 지금은 잠깐 일을 쉬고 있지만, 특히 웹 개발을 주 업무로 삼고 있는 개발자로서 "그래도 블로그 하나 정도는 내 손으로 직접 만드는 것이 낫지 않을까?" 라는 생각이 들었다.
특히 다음과 같은 측면을 고려하지 않을 수 없었다.
- 언제까지 남이 차려주는 밥상만 받아 먹을 것인가?
- 내 기술이 특정 vendor(=wordpress)에 종속되지 않을까?
따라서, 다소 귀찮지만 직접 블로그를 개발하는 것이 좀 더 가치가 있다고 생각하고 자체 개발하기로 결정을 내렸다.
"바퀴의 재발명"이라는 측면에서 남이 만들어 준 솔루션을 가져다 쓰는 것은 부끄러운 일은 아니지만, 블로그를 꾸준히 관리하고, 기능을 덧붙히고, 버그를 수정하면서 얻게 되는 경험은 무시 못할 것이라고 생각한다.
특히, 직장인이라면 회사 업무 외에는 개발을 접할 기회가 없는 것이 사실인데, 개인 블로그를 갖게 되면 회사 업무 이외에도 개인 블로그를 관리하기 위해 꾸준한 개발 역량이 투입되어야 하기 때문에 개인의 실력 관리에도 큰 도움이 되리라고 생각한다.
다음에는 블로그를 개발하고 기획하면서 있었던 이야기를 포스팅하고자 한다.
Recent Comments