언어 / 프레임 워크 / 기술이 '미래에 맞는지'확인

저는 PHP 개발자이며 최근에 CodeIgniter와 함께 일하기 시작했습니다. CodeIgniter와 관련된 것을 검색 할 때마다 블로그 게시물과 일반적으로 '09 또는 '10의 내용이 아니기 때문에 CodeIgniter는 여전히 관련성이 있으며 향후에있을 예정입니까? 다른 프레임 워크가 있습니까?

다른 언어와 프레임 워크도 마찬가지입니다. 어떤 시점에서 특정 언어 나 프레임 워크를 배우지 않습니까? 떠오르는 가치가있는 물건을 찾는 쉬운 방법이 있습니까?

정확한 과학은 아니므로 확실하게 5 년 이상 기술 환경의 미래 동향을 예측할 수있을 것으로 기대하지 마십시오.

그러나 나는 다음을 모두 찾겠다.

• 설치 기반 -더 큰 설치 기반은 많은 회사가 기술 및 유지 관리에 투자하는 것을 계속 의미하므로 개발자는 기술을 사용하여 작업해야합니다. 긍정적 인 순환이 뒤 따릅니다. 예를 들어 자바를 들어, COBOL처럼하기 전에 멀리 않을 것입니다 매우 긴 시간입니다.
• 광범위한 산업 지원 -이 기술을 뒷받침하는 여러 유명 기업이 있습니까? 단 하나의 커밋 된 후원자 만 경고 신호입니다. 단 한 번의 전략 변경으로 언제든 중단되거나 부수적 일 수 있습니다.
• 오픈 소스 -주요 오픈 소스 제품은 장기적으로 좋은 베팅으로 입증되었습니다 (예 : Linux, Apache, Red Hat, JBoss, Eclipse 등). 반면 독점 제품은 중단 될 위험이 있거나 가격이 급등하거나 "다음 큰 것"으로 이동하려는 시도가있는 단일 공급 업체에 달려 있습니다.
• 품질 -고품질 제품은 사람들이 다른 제품으로 바꾸지 않고 제품 을 사용하기 를 원 하기 때문에 수명이 길어집니다 . 반대로, 품질이 좋은 제품은 더 좋은 제품이 나 오자마자 포기됩니다.
• 혁신 -기술이 혁신의 최첨단을 향해 있습니까? 그렇다면 더 혁신적인 회사와 사용자 사이에서 채택과 지원을받을 가능성이 높습니다. 이것은 궁극적으로 주류가되기 시작합니다 (예를 들어 Scala 및 Clojure와 같은 새로운 언어 가이 범주에 있다고 말하고 싶습니다)
• 커뮤니티 – 기술에 대해 긍정적이고 개방적이며 실용적이고 헌신적이며 도움이되는 커뮤니티가 있습니까? 이들은 궁극적으로 미래를 보장 할 사람들입니다 .....

미래의 증거가 될지 알 수있는 방법은 없습니다. 기술에 초점을 맞춰 오늘날의 문제를 해결하는 데 도움이됩니다. 문제를 해결하기 위해 더 이상 작동하지 않을 때 특정 언어 나 프레임 워크를 배우지 않아도됩니다.

당신이하고있는 일을 대표하는 커뮤니티에 참여하고 당신이오고있는 일에 대해 잘 이해할 수는 있지만 더운 일이 아니거나 내가 더운 일이 아닌 직업을위한 최고의 도구로 시간을 보내고 싶습니다. 지금부터 1 년 또는 2 년.

미래의 증거인지 확실하게 판단 할 방법이 없습니다. 가장 가까운 것은 특정 언어 또는 프레임 워크와 관련된 활동 수준을 결정하는 것입니다. 개발자 활동이 많을 경우 일반적으로 언어 / 프레임 워크가 인기를 얻고 있으며 잠시 동안 실행 가능하다는 것은 좋은 신호입니다. . 그 반대는 흥분이 적고 (개발자 포럼을 통한) 지원이 더 어려울 수 있음을 나타냅니다.

선택한 언어 / 프레임 워크가 해결하려는 문제를 해결하는 한, 죽어가는 기술로 명확하게 작업하지 않는 한 미래 보장에 대해 걱정할 필요가 없습니다. 기술은 계속 변화하고 있습니다. 할 수있는 한 가지는 산업 트렌드를 추적하는 것입니다. 이 글 에서 언급 한 바와 같이 새로운 프로그래밍 언어 / 프레임 워크를 학습 하면 트렌드를 파악하고 지속적으로 새로운 툴을 평가할 수 있습니다.

"미래에 대한 내성"은 실용적 관심사에 대한 것만 큼 의지력과 완고함에 관한 것입니다.

극단적 인 예는 이것 입니다. 스파클 필터는 40 대 후반부터 회계 시스템으로 IBM 402 컴퓨터를 아직 실행하고 있습니다. 이것은 "파일"대신 전기 플러그 보드를 사용하여 프로그래밍 된 기계입니다.

개인적으로 MS-DOS 기반 컴퓨터를 수십 년 동안 작동하도록 설계된 특수 계측기 내에서 유지 관리하는 회사에 대한 경험이 있습니다. 1997 년 말까지 운영 PDP를 폐기했습니다.

회사에서 스파클 필터와 같이 컴퓨터 역사 박물관을 방문하면 귀하 (또는 귀하의 조상)가 시스템을 "미래 방지"했음을 나타내는 표시 일 것입니다.

특정 기술이 미래에 대한 증거인지 여부에 대해 답변 할 수 있습니다. 이에 대한 시간 척도를 설정하지 않았기 때문에 대답은 거의 아니오입니다.

이 질문에 대답하려면 요구 사항에 더 자세한 내용을 추가해야합니다. 예를 들면 다음과 같습니다.

• 우리는 1 년, 3 년, 5 년 이상 어떤 시간 척도에 대해 이야기하고 있습니까?
• 5 년 안에없는 물건을 고르는 데 드는 비용은 얼마입니까?
• 덜 "안전한"옵션을 선택하면 어떤 이점이 있습니까?

언어 / 프레임 워크 / 기술의 선택은 실제로 프로젝트에서 위험 관리의 일부입니다. 모든 위험과 마찬가지로 여러 가지 요소를 고려한 다음 (이를 짧게 유지하려고합니다) 상황에 적합한 수준으로 줄이기 위해 조치를 취해야합니다.

인생의 대부분의 것들과 마찬가지로, 가장 낮은 위험을 수반하는 활동은 실제로 최선의 선택이 아닐 수도 있습니다.

요컨대, 프로젝트의 예상 수명 시간 동안 사용함으로써 얻을 수있는 이점과 비교하여 살 준비가 된 불확실성이 얼마나됩니까?

미래를 더 오래보고 싶어할수록 확실성이 떨어집니다. 예를 들어, 향후 2 년 동안 만 걱정한다면, 향후 10 년 동안 필요한 것을 선택하는 것보다 선택하기가 훨씬 쉬워 질 것입니다.

이것에는 불가능하다고 말할 많은 요소가 있습니다. 잘못 될 수있는 것들은 :-

• 패션. 사람들은 관심을 잃고 새로운 더 예쁜 플랫폼으로 관심을 돌립니다. Perl은 2000 년경 웹 응용 프로그램의 거의 독점권을 가졌습니다.
• 공급 업체 시장 점유율. 2000 년경 C ++ / Sun Solaris가 3000 년까지는 좋았지 만
• 기업 스 나니 건. 몇 년 전에 저는 Java를 미래의 증거 플랫폼으로 선택했을 것입니다. ORACLE이 API 등을 저작권으로하여 다른 언어 프레임 워크로 옮겨 갈 것이라고 생각합니다.
• 도로의 끝. Visual Basic과 같은 것들을 생각하고 있습니다. 길고 명예로운 역사 후에는 소프트웨어 개발의 최신 사고를 수용하기 위해 더 이상 확장 될 수 없습니다.
• 패자가 이깁니다. PHP (내가 좋아하는)는 개발자들 사이에서 미인 대회에서 우승하지는 않았지만 결코 웹의 왕이 아닙니다. 2004 년에 PHP를 처음 썼을 때, 나는 웹 개발의 링거 프란카로서 그것을지지하지 않았을 것입니다.
• 못생긴 오리. 단일 구문을 변경하거나 단일 API를 추가하지 않고 Javascript는 갑자기 애니메이션 성가신 배너가 WEB 2.0의 중심 부분에 추가되는 Hokey 스크립팅 언어에서 나왔습니다.

결국 그것은 중요하지 않습니다. CodeIgniter는 귀하를 위해 일하며 원하는 것을 제공합니다. 블로그 게시물이 오래되었거나 릴리스 속도가 느려서 작업을 중단 할 수 없습니다. 그래서 저의 조언은 현재 작동하는 것을 사용하고 미래에 대처하는 것입니다.

PHP 프레임 워크 인 Symfony는이를 사이트 에서 완벽하게 설명했습니다 .

올바른 프레임 워크를 선택하기위한 10 가지 기준

당신은 진보하고 있으며 좋은 일입니다! 이미 프레임 워크를 사용하여 사이트 또는 응용 프로그램을 개발할 것임을 알고 있습니다. 그러나 어느 것? 실수를 피하기 위해 사용할 수있는 점검 목록은 다음과 같습니다.

1. 인기와 커뮤니티 규모

프레임 워크가 더 잘 알려지고 인식 될수록 새로운 아이디어, 플러그인의 수 및 품질 등과 같은 "생존"이 발전하고 완성 될 것입니다.

2. 철학

이것이 프레임 워크의 본질입니다. 요구 사항을 충족시킬 수있는 기본 기준입니다. 전문가가 자체 요구에 맞게 개발 한 도구는 분명히 다른 전문가의 요구를 충족시킵니다.

3. 지속 가능성

프레임 워크를 선택하기 전에 해당 기간 동안 프레임 워크를 유지할 수 있는지 확인하십시오. 따라서 응용 프로그램의 유지 관리 및 업그레이드가 간단 해집니다.

4. 지원

간과해서는 안되는 또 다른 기준은 질문에 대한 답변을 쉽게 찾고 도움을받는 것입니다. 게시자로부터 제공되는 지원을 확인하십시오. 커뮤니티 (메일 링리스트, IRC 등)에서? 서비스 회사 (개발, 지원, 교육)로부터?

5. 기술

미로에 갇히지 않도록 항상 상호 운용 가능한 솔루션을 선택하는 것이 좋습니다. 개발 측면에서 모범 사례를 존중하는 것 (디자인 패턴)

6. 보안

모든 응용 프로그램은 잠재적으로 취약합니다. 위험을 최소화하려면 항상 보안 기능을 보장 할 수있는 프레임 워크를 선택하는 것이 좋습니다 (예 : XSS 관리).

7. 문서

프레임 워크에 대한 기존 문헌의 특성, 양 및 품질을 평가하는 것이 절대적으로 필요합니다. 잘 문서화 된 도구는 사용하기 쉽고 업그레이드 가능합니다.

8. 라이센스

라이센스는 단순히 응용 프로그램에 큰 영향을 줄 수 있기 때문에 중요합니다. 예를 들어 GPL 라이센스 프레임 워크를 사용하여 개발 된 응용 프로그램은 반드시 GPL의 적용을받습니다. 반면에 MIT 라이센스 프레임 워크의 경우에는 그렇지 않습니다.

시장에 자원의 9.Availability

아마도 유지 관리 및 업그레이드 모두를 위해 개발 단계 나 장기적으로 기술 팀이 당신을 둘러싸고 싶어 할 것입니다. 다시 말해, 사용중인 도구에 필요한 기술이 공개 시장에서 제공되는지 확인하십시오.

10. 사용해보십시오!

그게 열쇠 야! 인터넷에서 리뷰, 댓글 및 소문을 읽거나 만족하지 마십시오. 그것을 테스트함으로써, 당신은 당신의 자신의 마음을 구성하고 당신이 도구에 완전히 편안하게 할 수 있습니다.

열쇠는 인내심입니다. 인내, 인내, 인내. 미래를 확실하게 예측할 방법이 없습니다. (나도 써야 했습니까?)하지만 신기술에 몇 년을 주었고 그 기술이 어떻게 채택되는지를 보면, 뿌리를 내릴 것인지 장기 프로젝트 / 시간 투자에 적합한 지에 대한 좋은 아이디어를 얻게 될 것입니다 .

따라서 NextNewThing (tm)이 등장 할 때, 처음 몇 년 동안 중요한 것은 아니지만 밴드 웨건을 뛰어 넘어보십시오.

Mikeras의 대답은 꽤 좋습니다. 미래 보장은 일종의 보안 또는 위험 관리라고 덧붙입니다. 그것은 종종 특정 편의 및 비용 / 생산성 혜택을 포기하는 데 필요한 지금 피하기 문제에 이상이 필요합니다. 나는 거의 미래에 대비 한 기술을 꽤 오랫동안 만들고 있습니다. 도움이 될 수있는 특정 패턴이 있습니다. 몇 가지 있습니다.

1. 데이터는 나중에 추출하거나 변환하기 쉬운 개방형 형식으로 저장해야합니다. 홀수 파일 형식은 일반적으로 큰 잠금 기술 및 트랩 영역입니다. 또한 XML, Word 97 형식과 같은 복잡한 쓰레기보다 CSV, ASN.1 또는 JSON과 같은 간단한 접근 방식을 선호합니다. 아이디어는 파서를 함께 던질 수있을 정도로 간단하고 앱에서 로우 레벨 형식 파서를 재사용 할 수 있다는 것입니다.

2. 응용 프로그램은 이상적으로 벤더 -이 있어야 및 기술 중립적 인 인터페이스는 그들에 내장 플러스의 정확한 설명을 어떻게 그들이. 구현을 변경하거나 중단하지 않고 구현할 수있는 것을 설계해야합니다. 또한 프로 시저 호출 또는 데이터 처리 방법이 여러 플랫폼에서 작동하는 경우 새 플랫폼으로 쉽게 전환 할 수 있습니다. 따라서 인터페이스가 가장 중요합니다. 더 간단하고 빠르며 개방형 인터페이스 구현 방법이 더 좋습니다.

3. 스택은 완전히 오픈 소스 여야하며 자유롭게 수정할 수 있어야합니다. GPL, LGPL, BSD, MIT 등 라이센스는이 각도에서 괜찮습니다. 커뮤니티가 죽기 시작하면 스택을 새로운 [hardware / OS / protocol / etc]로 옮겨야 할 수도 있습니다. 그리고 그렇게하려면 코드가 필요합니다.

4. 스택의 디자인은 한 사람이 이해할 수 있도록 각 모듈마다 매우 모듈화되어야합니다. 이를 통해 새로운 그룹이 쉽게 픽업하고 유지 관리 할 수 ​​있습니다. 런타임 수준이 가장 낮더라도 라이브러리와 컴파일러는 포팅해야 할 경우 큰 보상을 줄 수 있습니다. 종종 한 부분 만 이식 할 수 있으며 모든 이전 코드가 작동합니다.

5. 앱은 플랫폼 세부 정보를 고려하여 해당 영역의 재 작업을 최소화하는 모듈 방식으로 만들어야합니다. 가능하면 함수를 입력 / 처리 / 출력 블록으로 구성하는 데 도움이됩니다. 이것은 포트에 의해 영향을받는 것의 분석 (및 일반적으로 라 클린 룸 방법론의 정확성 분석)을 도울 수 있습니다. 현명하게 가장 낮은 리스크 접근 방식 플랫폼은 하나의 인터페이스를 통해 보편적으로 지원되는 최저 공통 분모 기능을 사용하여 포팅을 더욱 줄이는 것입니다. (나는 당신이 무언가를 잃어 버릴 것이라고 말했다 ...)

6. 동적 타이핑, 타이핑 유추 또는 기타 유연한 타이핑 방식이 도움이됩니다. 새 플랫폼으로의 포트는 기본 유형의 정의를 변경할 수 있습니다. 내부적으로 강력한 타이핑을하는 언어는이 문제에 대한 걱정이 줄어 듭니다.

7. 동시성 모델을 단순하게 유지하십시오. 명확한 인터페이스를 통과하는 이벤트 중심의 메시지는 기본적으로 모든 것에 이식 가능합니다. 코 루틴도 있습니다. 오류와 이식성 문제가 발생하기 쉬운 경로를 피하려고합니다.

8. Mozilla와 Apache의 휴대용 런타임을 살펴보십시오. 특정 인터페이스 및 구현 선택과 관련된 많은 플랫폼 별 문제를 고려합니다. 그들은 많은 문제에 대한 좋은 해결책을 제공함과 동시에 걱정할 사항에 대한 힌트를 얻을 수 있습니다.

완벽한 예 : Tcl. 나는 많은 사람들이 그것을 싫어하고 그것을 거의 사용하지 않는다는 것을 알고 있습니다. 그러나 Tcl은 이해하기 쉽고 구현이 쉽고 (12 가지 주요 규칙) 코드를 작성 하는 데 매우 쉬운 언어입니다. 작고 빠르며 웹 서버와 통합되며 기본 앱에 포함되어 있으며 수많은 항목으로 이식되었으며 특정 안전 기능이 있습니다. , 80 년대 이후 정기적으로 업데이트되었습니다. 핵심 언어를 위해 TCL 런타임 전체를 즉시 구현할 수 있습니다. 경우 우리가 포트에 표준 라이브러리를 가지고, 그것은 .NET이나 자바를 이식하는 것보다 쉬울 것이다. 그리고 그것을 위해 작성된 약간의 유용한 코드가 있습니다. 그리고 Java 애플릿이 목표로 한 "모바일 에이전트"열풍까지 웹 기술에서 사용되었습니다. 예를 들어 OpenACS 웹 프레임 워크는 이전 서버보다 1998 년으로 거슬러 올라갑니다.

다른 예 : 기본, 코볼 및 LISP (스키마 또는 CL). 이 언어들은 모두 50 년대 나 60 년대로 거슬러 올라갑니다. 이해, 구현 및 기계적 번역을 쉽게 수행 할 수있을 정도로 간단합니다. 그러나 유용한 자료를 만들 수 있습니다. COBOL은 여전히 ​​전 세계 대부분의 트랜잭션 처리를 강화하고 몇 번 업데이트되었으며 .NET에서도 실행됩니다. 기존 QBasic / QuickBASIC 앱은 오늘날 현대 플랫폼의 개방형 / 무료 도구와 함께 GAMBAS 또는 RealBASIC과 같은 더 나은 도구로 이식 할 수 있습니다. LISP 코더는 자연스럽게 시스템을 모듈화하고 기능적으로 만들어 포팅을 용이하게합니다. 수십 년 동안 개방적이고 상업적인 구현을위한 꾸준한 구현 흐름이있었습니다.

따라서 인터페이스, 개방성, 단순성, 모듈성 및 플랫폼 중립적 아키텍처 / 디자인 / 코딩. 이것이 당신에게 필요한 미래를 보장해 줄 것입니다. 어쨌든 대부분.