2004. 3. 27. 16:11
기술문서창고/asp
한빛네트워크에 있는 기사.
...한빛이 개편하면서 페이지 보이는게 이상해졌다 =-=
by 스콧 미첼, 『ASP 설계하기』의 저자 이 팁은 견고하고 재사용 가능한 ASP 페이지를 개발하기 위한 설계 방법에 초점을 두어 여러분이 ASP를 설계하고 구축할 때 큰 개념을 이해하도록 한다. 자, 스콧의 제안을 한 번 들어보자.
1. 생각 먼저 해라. 코딩은 그 다음이다.
ASP 개발자들은 보통 프로그래밍 개발에 대해 충분히 생각을 하지도 않고 먼저 코딩을 시작하는 경향이 있다. 예를 들어 특정 데이터베이스 테이블의 내용을 특정 형식으로 나열하는 웹 페이지가 필요하다고 하자. 아마도 대부분의 개발자는 당장 소매를 걷어 올리고 필요한 코드를 바로 작성할 것이다. 모든 코드를 일사천리로 작성하기 전에 우선 한 발 뒤로 물러서서 이 작업에 대해서 더 생각해보고 현재 코드가 앞으로 수행할 어떤 작업과 유사할 것인지를 생각해보는 것이 좋은 방법이다. 분명히 다른 데이터베이스 테이블 안의 내용을 또 다른 형식으로 표시되어야 할 경우가 생길 것이다. 이런 가능성에도 불구하고 여러분은 개발자가 왜 설계에 시간을 투자해야 하는지 의아해 할 것이다. 결국 각각의 단일 작업에서, 코드의 첫 행부터 마지막까지 작성할 때 15분에서 한 시간까지 시간이 걸릴지도 모른다. 왜 스크립트는 변경될 수 있고, 코드를 재사용 가능하게 만들 수 있다는 것에 대해 좀더 신중하게 생각하지 않는가? 또 언젠가 코드를 변경하게 될 때 더 많은 유연성을 제공할 다른 대안을 생각하지 않는가? 코드가 변경될 가능성을 고려하고 설계하는데 투자한 시간은 앞으로 스크립트를 수정해야 할 때 개발 시간을 절약함으로써 결국에는 나중에 보상되는 것이다. 포괄적이고 강력한 스크립트를 생성한다면 쿼리스트링 매개변수로 모든 데이터베이스 테이블을 쉽게 표시할 수 있다. 또 데이터를 어떤 스타일이나 모양으로도 보여줄 수 있다. 이렇게 미래의 수정 과정이나 유사한 스크립트를 새로 생성하기 위한 많은 시간을 절약할 수 있다. 이런 강력한 스크립트는 그저 단순히 데이터베이스 표시 스크립트를 작성하는 것보다 분명히 더 많은 설계 시간(초기 개발 단계에서)을 필요로 한다. 그렇지만 새로운 데이터베이스를 새로운 스타일로 표시하기 위해 강력한 스크립트가 사용될 때마다 항상 개발 시간을 절약할 수 있다. 게다가 두 번째 팁에서 언급하겠지만 강력한 데이터베이스 스크립트는 확실히 버그가 적다. 이 두 요인만으로도 개발 시간과 디버깅 시간을 엄청나게 줄일 수 있다.
2. 코드는 가능한 조금만 작성해라.
이것은 대규모 웹 응용 프로그램을 생성하는데 꼭 필요한 팁이고 저자가 프로그래밍을 할 때 유념하는 첫번째 공리이기도 하다(두 번째 공리는 세 번째 팁에 있다). 이 공리의 이론은 아주 간단하다. 분명히 버그는 코드를 작성하기 때문에 생기는 것이고 따라서 코드를 많이 작성할수록 더 많은 버그가 생기는 것이다. 그리고 응용 프로그램에 오류가 많을수록 더 많은 디버깅 시간이 소요되는 것이다. 물론 이 말은 간단한 기능만을 가지고 있는 소프트웨어를 만들어야 한다거나 옵션이 적어서 코드를 조금만 생성해야 한다는 의미가 아니다. 저자가 말하고 싶은 것은 재사용 할 수 있는 코드를 만들어야 한다는 것이다. 예를 들어 HTML 페이지에서 특정 폼에 대한 서버측 폼 유효성 검사를 수행할 루틴을 만들어야 한다고 하자. 여러분은 단지 이 특정 폼만을 처리하는 클래스가 아니라 여러 다른 HTML 페이지에서 다양한 폼 유효성 검사에도 사용할 수 있는 포괄적인 서버측 폼 유효성 검사 클래스를 구축하기로 마음먹을 것이다. 이 강력한 폼 유효성 검사 코드는 특정 폼과 HTML 페이지에 국한된 폼 유효성 검사기보다 분명히 훨씬 많은 코드를 포함한다. 비록 개발에 많은 시간이 들었지만 이 서버측 폼 유효성 검사 루틴이 다른 HTML 페이지에 있는 다른 폼에서 사용될 때는 루틴을 다시 생성할 필요가 없다. 왜냐하면 이미 포괄적인 폼 유효성 검사 루틴을 작성해놓았지 않은가! 이것이 바로 개발 시간과 디버깅 시간을 절약하는 것이다. 자, 이제 세 번째 팁을 보자.
3. 첫째도 재사용, 둘째도 재사용, 셋째도 재사용.
코드 한 조각이 더 자주 사용될 때 발생하는 버그는 적어진다. 코드 블록은 일련의 입력을 받아서 출력을 생성해내는 블랙박스로 간주될 수 있다. 주어진 입력에 대해 출력은 정확할 수도(버그가 없을 수도) 있고 그렇지 않을 수도(버그가 있을 수도) 있다. 모든 코드 조각을 디버깅 할 때의 어려운 점은 모든 가능한 입력을 계속해서 테스트해야 한다는 것이다. 코드 한 조각을 생성해낼 때 100 퍼센트 버그 없이 완벽하다는 보장은 없다. 실제로도 버그가 없는 코드는 거의 없다. 버그 없이 결과 코드가 완벽하다는 것은 테스트한 사람이 게을러서다. 왜냐하면 훨씬 많은 입력값을 테스트해보아야 하기 때문이다. 코드가 백명, 천명, 그 이상의 사용자에 의해 사용되기 시작할 때 광범위한 입력은 바로 테스트되어야 한다. 완벽하게 사용되어 왔고 어떤 숨겨진 버그도 발견되지 않은 코드 조각은 자주 사용되지 않았다는 의미가 아니라 버그가 없다는 말이다. 코드 블록이 최종 제품으로 배포되면 코드를 테스트하고 디버깅했던 개발자가 아닌 다른 상황에서 많은 테스트에 직면하게 된다. 이것을 차에 비유해보면, "어떤 차가 운전하기에 더 안전한가?"라는 질문에 몇 년 동안의 증거 자료에서 어떤 차의 사고 발생률이 낮은지를 관찰하는 것과 같다. 여러분의 ASP 응용 프로그램에서 버그의 수를 줄이기 위해서는 재사용 가능한 코드를 만들어서 재사용해라. 이전에 재사용 가능한 코드 블록에서 버그를 발견하면 버그를 수정하고 계속 재사용해라. 그러면 앞으로 이 코드를 버그가 없고 100 퍼센트 완벽하다는 자신감을 가지고 다시 사용할 수 있다.
4. 재사용을 위한 방법을 알고 있어라.
재사용에 가장 유용한 두 가지 방법은 클래스와 SSI다. 이 내용에 대해서는 『ASP 설계하기』에서 간략하게 설명하였다. SSI(Server-side includes)는 개발자로 하여금 재사용 가능한 코드(HTML, 서브루틴, 함수나 클래스 집합)를 생성하고 연관된 재사용 가능한 코드를 별개의 파일로 그룹화 할 수 있게 한다. 그런 다음, 이런 함수나 클래스의 서비스가 필요할 때 개발자는 그저 SSI를 사용하여 함수나 클래스를 가져오면 된다. SSI는 이런 코드를 사용하는 ASP 페이지로부터 재사용 가능한 코드를 별도로 유지하도록 지원한다. 재사용 가능한 코드가 변경되었을 때는 SSI를 사용하여 자동으로 변경 사항을 SSI를 사용하는 모든 ASP 페이지로 반영해주기 때문에 이 방법은 유용하다. SSI에 대한 자세한 설명은 저자가 운영하는 사이트의 The Low-Down on #includes를 참고해라. 지금까지 VBScript 클래스는 코드 재사용을 위한 가장 괜찮은 방법이었다. 클래스는 복잡한 작업을 단순하고 사용하기 쉬운 인터페이스로 캡슐화하기 때문에 당연히 사용자에게 설계를 위한 강력한 솔루션을 제공한다. VBScript 클래스가 여러분에게 새로운 것이라면 'Using Classes VBScript classes' 부분을 읽어보자. VBScript5.0이 나오기 이전까지는 클래스가 지원되지 않았다. 5.0 이전의 버전을 사용하고 있다면 최신 버전을 다운로드 할 수 있다. 여러분의 웹 서버에 어떤 버전이 설치되어 있는지를 잘 모르겠으면 'Determining the Scripting Language and Version'을 참고하자.
5. 클래스를 사용해서 복잡한 작업을 캡슐화해라.
ASP 개발자들은 많은 비슷한 작업을 처리하기 위해 단순한 코딩을 반복하고 있다는 것을 스스로 알고 있을 것이다. 예를 들어 데이터베이스 테이블에 대한 웹 기반 관리 페이지를 생성하는 것은 공통적으로 사용되는 ASP 작업으로 그다지 복잡하지 않다. 많은 개발자가 데이터베이스 테이블로부터 레코드를 추가, 갱신, 삭제하기 위한 웹 기반 도구를 생성해야 한다. 여러분이 완전한 웹 기반 관리 도구를 원한다면 이런 다양한 폼을 추가하는 것은 데이터베이스에 있는 모든 테이블에 대해 각각 반복되어야 하는 작업이다. 엄청난 양의 데이터베이스 테이블이 있다면 그만큼 많은 ASP 페이지와 코드가 필요할 것이다. 그리고 이런 코드는 프로그래밍의 첫 번째 공리인 두 번째 팁을 무시하고 있기 때문에 버그가 있다. 분명히 포괄적인 단일 ASP 페이지를 생성해놓으면 현재 데이터베이스 테이블에서 뿐만 아니라 미래의 데이터베이스 테이블에서도 사용할 수 있다. 그렇지만 각 데이터베이스 테이블의 관리 페이지에는 복잡한 매개변수가 필요하기 때문에 이런 강력한 단일 스크립트를 생성하는 데에는 어려움이 있다. 그러나 이런 복잡한 입력 매개변수가 클래스로 포함된다면 최종 개발자의 관점에서 주어진 모든 데이터베이스 테이블에 대한 관리 페이지를 생성하는 것은 클래스의 인스턴스를 생성하고, 프로퍼티를 설정하거나 메소드를 호출하는것 만큼이나 쉬워질 것이다. 클래스를 사용함으로써 복잡한 필수 사양이나 매개변수 혹은 작업 등을 클래스를 사용하는 다른 개발자로부터 숨길 수 있다. 따라서 클래스를 사용하는 개발자의 프로그래밍은 훨씬 쉬워지고, 간단해지며, 가독성이 높아진다. 이 모든 사항은 버그를 줄이는 역할을 한다. 이 주제에 대한 자세한 정보는 'Use Classes to Encapsulate Implementation Complexity'를 참고하자.
스콧 미첼은 넷에서 지도적인 ASP 리소스 중의 하나인 4GuysFromRolla.com의 창시자이자 웹 마스터이다. 스콧은 마이크로소프트의 오피스 그룹을 위한 인트라넷 툴을 제작했고 액티브 서버 페이지를 이용하여 많은 웹사이트를 구축한 경험도 갖고 있다.
...한빛이 개편하면서 페이지 보이는게 이상해졌다 =-=
by 스콧 미첼, 『ASP 설계하기』의 저자 이 팁은 견고하고 재사용 가능한 ASP 페이지를 개발하기 위한 설계 방법에 초점을 두어 여러분이 ASP를 설계하고 구축할 때 큰 개념을 이해하도록 한다. 자, 스콧의 제안을 한 번 들어보자.
1. 생각 먼저 해라. 코딩은 그 다음이다.
ASP 개발자들은 보통 프로그래밍 개발에 대해 충분히 생각을 하지도 않고 먼저 코딩을 시작하는 경향이 있다. 예를 들어 특정 데이터베이스 테이블의 내용을 특정 형식으로 나열하는 웹 페이지가 필요하다고 하자. 아마도 대부분의 개발자는 당장 소매를 걷어 올리고 필요한 코드를 바로 작성할 것이다. 모든 코드를 일사천리로 작성하기 전에 우선 한 발 뒤로 물러서서 이 작업에 대해서 더 생각해보고 현재 코드가 앞으로 수행할 어떤 작업과 유사할 것인지를 생각해보는 것이 좋은 방법이다. 분명히 다른 데이터베이스 테이블 안의 내용을 또 다른 형식으로 표시되어야 할 경우가 생길 것이다. 이런 가능성에도 불구하고 여러분은 개발자가 왜 설계에 시간을 투자해야 하는지 의아해 할 것이다. 결국 각각의 단일 작업에서, 코드의 첫 행부터 마지막까지 작성할 때 15분에서 한 시간까지 시간이 걸릴지도 모른다. 왜 스크립트는 변경될 수 있고, 코드를 재사용 가능하게 만들 수 있다는 것에 대해 좀더 신중하게 생각하지 않는가? 또 언젠가 코드를 변경하게 될 때 더 많은 유연성을 제공할 다른 대안을 생각하지 않는가? 코드가 변경될 가능성을 고려하고 설계하는데 투자한 시간은 앞으로 스크립트를 수정해야 할 때 개발 시간을 절약함으로써 결국에는 나중에 보상되는 것이다. 포괄적이고 강력한 스크립트를 생성한다면 쿼리스트링 매개변수로 모든 데이터베이스 테이블을 쉽게 표시할 수 있다. 또 데이터를 어떤 스타일이나 모양으로도 보여줄 수 있다. 이렇게 미래의 수정 과정이나 유사한 스크립트를 새로 생성하기 위한 많은 시간을 절약할 수 있다. 이런 강력한 스크립트는 그저 단순히 데이터베이스 표시 스크립트를 작성하는 것보다 분명히 더 많은 설계 시간(초기 개발 단계에서)을 필요로 한다. 그렇지만 새로운 데이터베이스를 새로운 스타일로 표시하기 위해 강력한 스크립트가 사용될 때마다 항상 개발 시간을 절약할 수 있다. 게다가 두 번째 팁에서 언급하겠지만 강력한 데이터베이스 스크립트는 확실히 버그가 적다. 이 두 요인만으로도 개발 시간과 디버깅 시간을 엄청나게 줄일 수 있다.
2. 코드는 가능한 조금만 작성해라.
이것은 대규모 웹 응용 프로그램을 생성하는데 꼭 필요한 팁이고 저자가 프로그래밍을 할 때 유념하는 첫번째 공리이기도 하다(두 번째 공리는 세 번째 팁에 있다). 이 공리의 이론은 아주 간단하다. 분명히 버그는 코드를 작성하기 때문에 생기는 것이고 따라서 코드를 많이 작성할수록 더 많은 버그가 생기는 것이다. 그리고 응용 프로그램에 오류가 많을수록 더 많은 디버깅 시간이 소요되는 것이다. 물론 이 말은 간단한 기능만을 가지고 있는 소프트웨어를 만들어야 한다거나 옵션이 적어서 코드를 조금만 생성해야 한다는 의미가 아니다. 저자가 말하고 싶은 것은 재사용 할 수 있는 코드를 만들어야 한다는 것이다. 예를 들어 HTML 페이지에서 특정 폼에 대한 서버측 폼 유효성 검사를 수행할 루틴을 만들어야 한다고 하자. 여러분은 단지 이 특정 폼만을 처리하는 클래스가 아니라 여러 다른 HTML 페이지에서 다양한 폼 유효성 검사에도 사용할 수 있는 포괄적인 서버측 폼 유효성 검사 클래스를 구축하기로 마음먹을 것이다. 이 강력한 폼 유효성 검사 코드는 특정 폼과 HTML 페이지에 국한된 폼 유효성 검사기보다 분명히 훨씬 많은 코드를 포함한다. 비록 개발에 많은 시간이 들었지만 이 서버측 폼 유효성 검사 루틴이 다른 HTML 페이지에 있는 다른 폼에서 사용될 때는 루틴을 다시 생성할 필요가 없다. 왜냐하면 이미 포괄적인 폼 유효성 검사 루틴을 작성해놓았지 않은가! 이것이 바로 개발 시간과 디버깅 시간을 절약하는 것이다. 자, 이제 세 번째 팁을 보자.
3. 첫째도 재사용, 둘째도 재사용, 셋째도 재사용.
코드 한 조각이 더 자주 사용될 때 발생하는 버그는 적어진다. 코드 블록은 일련의 입력을 받아서 출력을 생성해내는 블랙박스로 간주될 수 있다. 주어진 입력에 대해 출력은 정확할 수도(버그가 없을 수도) 있고 그렇지 않을 수도(버그가 있을 수도) 있다. 모든 코드 조각을 디버깅 할 때의 어려운 점은 모든 가능한 입력을 계속해서 테스트해야 한다는 것이다. 코드 한 조각을 생성해낼 때 100 퍼센트 버그 없이 완벽하다는 보장은 없다. 실제로도 버그가 없는 코드는 거의 없다. 버그 없이 결과 코드가 완벽하다는 것은 테스트한 사람이 게을러서다. 왜냐하면 훨씬 많은 입력값을 테스트해보아야 하기 때문이다. 코드가 백명, 천명, 그 이상의 사용자에 의해 사용되기 시작할 때 광범위한 입력은 바로 테스트되어야 한다. 완벽하게 사용되어 왔고 어떤 숨겨진 버그도 발견되지 않은 코드 조각은 자주 사용되지 않았다는 의미가 아니라 버그가 없다는 말이다. 코드 블록이 최종 제품으로 배포되면 코드를 테스트하고 디버깅했던 개발자가 아닌 다른 상황에서 많은 테스트에 직면하게 된다. 이것을 차에 비유해보면, "어떤 차가 운전하기에 더 안전한가?"라는 질문에 몇 년 동안의 증거 자료에서 어떤 차의 사고 발생률이 낮은지를 관찰하는 것과 같다. 여러분의 ASP 응용 프로그램에서 버그의 수를 줄이기 위해서는 재사용 가능한 코드를 만들어서 재사용해라. 이전에 재사용 가능한 코드 블록에서 버그를 발견하면 버그를 수정하고 계속 재사용해라. 그러면 앞으로 이 코드를 버그가 없고 100 퍼센트 완벽하다는 자신감을 가지고 다시 사용할 수 있다.
4. 재사용을 위한 방법을 알고 있어라.
재사용에 가장 유용한 두 가지 방법은 클래스와 SSI다. 이 내용에 대해서는 『ASP 설계하기』에서 간략하게 설명하였다. SSI(Server-side includes)는 개발자로 하여금 재사용 가능한 코드(HTML, 서브루틴, 함수나 클래스 집합)를 생성하고 연관된 재사용 가능한 코드를 별개의 파일로 그룹화 할 수 있게 한다. 그런 다음, 이런 함수나 클래스의 서비스가 필요할 때 개발자는 그저 SSI를 사용하여 함수나 클래스를 가져오면 된다. SSI는 이런 코드를 사용하는 ASP 페이지로부터 재사용 가능한 코드를 별도로 유지하도록 지원한다. 재사용 가능한 코드가 변경되었을 때는 SSI를 사용하여 자동으로 변경 사항을 SSI를 사용하는 모든 ASP 페이지로 반영해주기 때문에 이 방법은 유용하다. SSI에 대한 자세한 설명은 저자가 운영하는 사이트의 The Low-Down on #includes를 참고해라. 지금까지 VBScript 클래스는 코드 재사용을 위한 가장 괜찮은 방법이었다. 클래스는 복잡한 작업을 단순하고 사용하기 쉬운 인터페이스로 캡슐화하기 때문에 당연히 사용자에게 설계를 위한 강력한 솔루션을 제공한다. VBScript 클래스가 여러분에게 새로운 것이라면 'Using Classes VBScript classes' 부분을 읽어보자. VBScript5.0이 나오기 이전까지는 클래스가 지원되지 않았다. 5.0 이전의 버전을 사용하고 있다면 최신 버전을 다운로드 할 수 있다. 여러분의 웹 서버에 어떤 버전이 설치되어 있는지를 잘 모르겠으면 'Determining the Scripting Language and Version'을 참고하자.
5. 클래스를 사용해서 복잡한 작업을 캡슐화해라.
ASP 개발자들은 많은 비슷한 작업을 처리하기 위해 단순한 코딩을 반복하고 있다는 것을 스스로 알고 있을 것이다. 예를 들어 데이터베이스 테이블에 대한 웹 기반 관리 페이지를 생성하는 것은 공통적으로 사용되는 ASP 작업으로 그다지 복잡하지 않다. 많은 개발자가 데이터베이스 테이블로부터 레코드를 추가, 갱신, 삭제하기 위한 웹 기반 도구를 생성해야 한다. 여러분이 완전한 웹 기반 관리 도구를 원한다면 이런 다양한 폼을 추가하는 것은 데이터베이스에 있는 모든 테이블에 대해 각각 반복되어야 하는 작업이다. 엄청난 양의 데이터베이스 테이블이 있다면 그만큼 많은 ASP 페이지와 코드가 필요할 것이다. 그리고 이런 코드는 프로그래밍의 첫 번째 공리인 두 번째 팁을 무시하고 있기 때문에 버그가 있다. 분명히 포괄적인 단일 ASP 페이지를 생성해놓으면 현재 데이터베이스 테이블에서 뿐만 아니라 미래의 데이터베이스 테이블에서도 사용할 수 있다. 그렇지만 각 데이터베이스 테이블의 관리 페이지에는 복잡한 매개변수가 필요하기 때문에 이런 강력한 단일 스크립트를 생성하는 데에는 어려움이 있다. 그러나 이런 복잡한 입력 매개변수가 클래스로 포함된다면 최종 개발자의 관점에서 주어진 모든 데이터베이스 테이블에 대한 관리 페이지를 생성하는 것은 클래스의 인스턴스를 생성하고, 프로퍼티를 설정하거나 메소드를 호출하는것 만큼이나 쉬워질 것이다. 클래스를 사용함으로써 복잡한 필수 사양이나 매개변수 혹은 작업 등을 클래스를 사용하는 다른 개발자로부터 숨길 수 있다. 따라서 클래스를 사용하는 개발자의 프로그래밍은 훨씬 쉬워지고, 간단해지며, 가독성이 높아진다. 이 모든 사항은 버그를 줄이는 역할을 한다. 이 주제에 대한 자세한 정보는 'Use Classes to Encapsulate Implementation Complexity'를 참고하자.
스콧 미첼은 넷에서 지도적인 ASP 리소스 중의 하나인 4GuysFromRolla.com의 창시자이자 웹 마스터이다. 스콧은 마이크로소프트의 오피스 그룹을 위한 인트라넷 툴을 제작했고 액티브 서버 페이지를 이용하여 많은 웹사이트를 구축한 경험도 갖고 있다.
posted by
progh2