그누보드5, 영카트5 이후
SIR의 앞으로 행보는 어떻게 될까요?
외산 소프트웨어를 보면 기능이나 프레임워크 등이 신기한 것도 많던데...
그누에도 적용될만한 부분들은 어떤 것이 있을까요...
SIR 법인의 공개된 재무 정보 보면, 생각보다 급성장(?) 하고 있는 회사인 것 같네요..
2014년? 이전보다?
이런저런 이야기 늘어놓고 갑니다..~~ ㅋ..;;
댓글 12개
베스트 댓글
@임종필 객체지향이 정답은 아니죠.
다만, 현대의 프로그램들은 그냥 동작만하면 된다가 아니라 테스트가 가능하고 기능의 대체가 쉽고 미들웨어, 서비스 주입 등 확장성을 확보해 개발 편의를 위한 목적을 함께하기 때문에 이러한 형태로 발전해온 것입니다. 사회적 합의로 이루어진 것이죠.
지금의 그누보드는 싱글턴이라고 부르는 것은 맞지 않고 절차지향 방식이라고 부르는게 맞고 절차지향이 틀리거나 잘못된 개발방법론은 아니죠.
코드를 함수로 묶는다고 함수형 프로그래밍이 아닌 것처럼, 함수를 클래스로 묶는다고 객체지향도 아닐 뿐더러 필요나 추구하는 목적에 따라 선택하거나 뒤섞여 사용될 수도 있죠.
개발방법론을 바꿀 필요는 없지만 비즈니스 로직과 뷰의 결합도를 낮출 필요가 있고 기능과 목적에 따라 적절한 분리도 필요합니다.
말씀하신 마이크로 서비스는 절차지향이나 객체지향과는 궤를 달리합니다.
다만, 현대의 프로그램들은 그냥 동작만하면 된다가 아니라 테스트가 가능하고 기능의 대체가 쉽고 미들웨어, 서비스 주입 등 확장성을 확보해 개발 편의를 위한 목적을 함께하기 때문에 이러한 형태로 발전해온 것입니다. 사회적 합의로 이루어진 것이죠.
지금의 그누보드는 싱글턴이라고 부르는 것은 맞지 않고 절차지향 방식이라고 부르는게 맞고 절차지향이 틀리거나 잘못된 개발방법론은 아니죠.
코드를 함수로 묶는다고 함수형 프로그래밍이 아닌 것처럼, 함수를 클래스로 묶는다고 객체지향도 아닐 뿐더러 필요나 추구하는 목적에 따라 선택하거나 뒤섞여 사용될 수도 있죠.
개발방법론을 바꿀 필요는 없지만 비즈니스 로직과 뷰의 결합도를 낮출 필요가 있고 기능과 목적에 따라 적절한 분리도 필요합니다.
말씀하신 마이크로 서비스는 절차지향이나 객체지향과는 궤를 달리합니다.
저는 그누보드 하시는 분들이 메타버스, 블록체인, iot 견인할 거라고 봅니다.
그리고 현재 처럼 싱글턴으로 계속 갈거라고 봅니다.
객체지향을 그누보드 사용자 분들이 안하는 이유가 다 있을 겁니다.
라라벨이나 ci 등등 여러 시도를 해보았으나 결국 그누보드 이용자가 젤 많습니다.
쉽게 해야합니다. 최대한 쉽게 그게 그누보드의 매력 아니겠습니까?
그리고 마이크로 서비스 방식만 살짝 도입한다면, 오히려 다시 싱글턴으로도
충분히 경쟁력을 갖출 수 있습니다.
객체 지향을 굳이 따라갈 필요 없다고 봅니다.
그리고 현재 처럼 싱글턴으로 계속 갈거라고 봅니다.
객체지향을 그누보드 사용자 분들이 안하는 이유가 다 있을 겁니다.
라라벨이나 ci 등등 여러 시도를 해보았으나 결국 그누보드 이용자가 젤 많습니다.
쉽게 해야합니다. 최대한 쉽게 그게 그누보드의 매력 아니겠습니까?
그리고 마이크로 서비스 방식만 살짝 도입한다면, 오히려 다시 싱글턴으로도
충분히 경쟁력을 갖출 수 있습니다.
객체 지향을 굳이 따라갈 필요 없다고 봅니다.
저는 그누보드 하시는 분들이 메타버스, 블록체인, iot 견인할 거라고 봅니다.
그리고 현재 처럼 싱글턴으로 계속 갈거라고 봅니다.
객체지향을 그누보드 사용자 분들이 안하는 이유가 다 있을 겁니다.
라라벨이나 ci 등등 여러 시도를 해보았으나 결국 그누보드 이용자가 젤 많습니다.
쉽게 해야합니다. 최대한 쉽게 그게 그누보드의 매력 아니겠습니까?
그리고 마이크로 서비스 방식만 살짝 도입한다면, 오히려 다시 싱글턴으로도
충분히 경쟁력을 갖출 수 있습니다.
객체 지향을 굳이 따라갈 필요 없다고 봅니다.
그리고 현재 처럼 싱글턴으로 계속 갈거라고 봅니다.
객체지향을 그누보드 사용자 분들이 안하는 이유가 다 있을 겁니다.
라라벨이나 ci 등등 여러 시도를 해보았으나 결국 그누보드 이용자가 젤 많습니다.
쉽게 해야합니다. 최대한 쉽게 그게 그누보드의 매력 아니겠습니까?
그리고 마이크로 서비스 방식만 살짝 도입한다면, 오히려 다시 싱글턴으로도
충분히 경쟁력을 갖출 수 있습니다.
객체 지향을 굳이 따라갈 필요 없다고 봅니다.
@임종필 객체지향이 정답은 아니죠.
다만, 현대의 프로그램들은 그냥 동작만하면 된다가 아니라 테스트가 가능하고 기능의 대체가 쉽고 미들웨어, 서비스 주입 등 확장성을 확보해 개발 편의를 위한 목적을 함께하기 때문에 이러한 형태로 발전해온 것입니다. 사회적 합의로 이루어진 것이죠.
지금의 그누보드는 싱글턴이라고 부르는 것은 맞지 않고 절차지향 방식이라고 부르는게 맞고 절차지향이 틀리거나 잘못된 개발방법론은 아니죠.
코드를 함수로 묶는다고 함수형 프로그래밍이 아닌 것처럼, 함수를 클래스로 묶는다고 객체지향도 아닐 뿐더러 필요나 추구하는 목적에 따라 선택하거나 뒤섞여 사용될 수도 있죠.
개발방법론을 바꿀 필요는 없지만 비즈니스 로직과 뷰의 결합도를 낮출 필요가 있고 기능과 목적에 따라 적절한 분리도 필요합니다.
말씀하신 마이크로 서비스는 절차지향이나 객체지향과는 궤를 달리합니다.
다만, 현대의 프로그램들은 그냥 동작만하면 된다가 아니라 테스트가 가능하고 기능의 대체가 쉽고 미들웨어, 서비스 주입 등 확장성을 확보해 개발 편의를 위한 목적을 함께하기 때문에 이러한 형태로 발전해온 것입니다. 사회적 합의로 이루어진 것이죠.
지금의 그누보드는 싱글턴이라고 부르는 것은 맞지 않고 절차지향 방식이라고 부르는게 맞고 절차지향이 틀리거나 잘못된 개발방법론은 아니죠.
코드를 함수로 묶는다고 함수형 프로그래밍이 아닌 것처럼, 함수를 클래스로 묶는다고 객체지향도 아닐 뿐더러 필요나 추구하는 목적에 따라 선택하거나 뒤섞여 사용될 수도 있죠.
개발방법론을 바꿀 필요는 없지만 비즈니스 로직과 뷰의 결합도를 낮출 필요가 있고 기능과 목적에 따라 적절한 분리도 필요합니다.
말씀하신 마이크로 서비스는 절차지향이나 객체지향과는 궤를 달리합니다.
게시글 목록
| 번호 | 제목 |
|---|---|
| 1717629 | |
| 1717626 | |
| 1717625 | |
| 1717621 | |
| 1717619 | |
| 1717611 | |
| 1717610 | |
| 1717609 | |
| 1717607 | |
| 1717601 | |
| 1717598 | |
| 1717591 | |
| 1717590 | |
| 1717583 | |
| 1717575 | |
| 1717572 | |
| 1717568 | |
| 1717566 | |
| 1717549 | |
| 1717545 | |
| 1717533 | |
| 1717512 | |
| 1717511 | |
| 1717508 | |
| 1717495 | |
| 1717479 | |
| 1717473 | |
| 1717470 | |
| 1717463 | |
| 1717452 |
댓글 작성
댓글을 작성하시려면 로그인이 필요합니다.
로그인하기