옵션 1: 정적 메뉴 생성 전용으로 우리가 연결하는 버튼으로 코드를 생성하기만 하면 됩니다.
옵션 2: 우리는 버튼 자체에 코드를 동적으로 삽입하는 지원을 도입했습니다. 우리는 무엇을 언제 어디서 호출하는지 .... 그래서 구현하기가 어렵지 않아야 합니다. 터미널에서 즉시 도망쳐서 외부 환경에서 무언가를 조각할 수도 있습니다.
옵션 3: 저자가 아닌 다른 모든 사람들과 마찬가지로 내가 저자가 아닌 한 분명히 상상할 수 없는 것. 그러나 이것은 위에 쓰여진 모든 것보다 훨씬 더 복잡해야 합니다.
모든 변형에서 메뉴 자체를 만드는 전체 기능을 의미합니다.
어쨌든 경험은 연습으로 매우 중요합니다.
귀하의 프로젝트는 프로그래밍 기술이 그다지 높지 않기 때문에 대규모로 보입니다. 따라서 코드는 10배 미만이 될 것입니다. 실제로는 10배입니다. . 20,000 - 40,000줄은 몇 줄입니까? 2000-4000일 것입니다. 그리고 그는 더 이상 괴물처럼 보이지 않을 것입니다. 그냥 프로그램.
게다가 창의성은 그것과 아무 관련이 없습니다. 단지 적은 코드가 더 읽기 쉬울 뿐이며, 프로그래머는 일반적으로 한 번 작성하기 전에 코드를 20번 읽습니다.
추신: 예를 들어, 포럼 중재자 중 한 명이 작성한 기사를 생각해 보십시오(전문 프로그래머도 아님) ... 기사 디자인은 결과적으로 1000라인 미만의 코드에서 불필요하게 훌륭합니다. 40줄을 작성해야 했고 훨씬 더 명확할 것입니다.
그러나 열정과 헌신은 분명히 부러워 할 수 있습니다.
실수: 유사한 문제를 해결하기 위한 다른 사람들의 접근 방식을 연구하기를 원하지 않고 이를 구현하는 방법을 이해합니다.
여기에서 말하자면, 이 포럼의 많은 참가자들이 MT의 라이브러리에 동의하지 않고 다시 작성한다는 점을 이해해야 합니다. 저것들. 그들은 평가하고, 그들의 코드를 이해하고, 그들이 동의하지 않는 것을 보고, 다시 작성합니다. 하지만 작품을 충분히 이해한 후
여기 아무도 한 가지를 이해하지 못합니다. 이 경우 교육은 관련이 없습니다. 요점은 다른 것입니다. 교육은 그 반대가 아니라 아이디어를 따릅니다. 사람들은 먼저 무언가를 발명한 다음 그 발명품을 보기 좋게 만듭니다. 지식을 조직하십시오. 씹은 정보의 배열을 흡수한 후, 그들은 원래 발명품을 "만졌을" 뿐이지, 아직 그 깊은 본질을 모두 이해하지 못했습니다. 그리고 그들은 스스로 발명가가 되지 않았습니다. 물론 의사나 조종사는 체계화된 지식이 필요하고 그 질이 중요하지만 이러한 직업에는 창의적인 요소가 없습니다. 프로그래밍은 수술과 달리 창의성에 자유를 줍니다. 특히 여기, 가까운 틈새 시장에서. 여기에서 발명할 수 있으며 모든 것을 알 필요는 없습니다.
본 발명은 독립적인 속성을 가지고 있습니다. 발명하고 구현을 시작하고 우리는 갑니다. 폭발처럼 어떤 아이디어를 실행에 옮기는 과정은 멈출 수 없고, '구식으로 돌아가기' 위해 그 아이디어에서 벗어나려는 시도는 어리석고 무의미하다.
아직 프로젝트에 대해 알아볼 시간이 없었습니다. 설명하겠습니다. 본격적인 그래픽 인터페이스 작동에 필요한 모든 솔루션이 이미 존재합니다. 마크업 언어와 API 파일을 통해 작성된 GUI를 사용자 애플리케이션에 연결하는 기능이 있습니다. 모든 것이 확인되고 테스트됩니다. 이제 비주얼 에디터로의 전환 단계가 왔습니다. 작업의 특정 기능을 추가하는 것이 남아 있습니다. 다른 모든 기본 솔루션이 포함되어 있습니다.
아인슈타인이 거기에서 말했듯이 가장 중요한 것은 교육이 아니라 열정의 깊이입니다.
그리고 예가 있습니까? 나는 멘델레예프의 시대에 대해 말하는 것이 아닙니다 ...
그리고 예가 있습니까? 나는 멘델레예프의 시대에 대해 말하는 것이 아닙니다 ...
아인슈타인 자신, 그는 교육을받지 못했습니다)
나도 그의 이론에 동의한다
의사는 물론 교육을 받아야 함))
아인슈타인 자신, 그는 교육을받지 못했습니다)
답변이 예상됩니다 :) 우리는 더 많은 옵션을 기다리고 있습니다 ...
교육에 물든 사람들에게 독학은 아인슈타인을 비롯한 삶의 원동력이 됩니다...
일찍. 3일에는 구체적인 결과에 대해 말할 수 있다. 물론 '괴물'을 두려워하는 사람도 있겠지만, 누가 더 용감한가가 객관적인 평가를 내릴 것이다. (얼마나 냄새나고 "옆으로 넘어지는지"). 여기서 우리는 볼 것입니다.
프로젝트 자체는 결코 냄새가 나지 않습니다. 오류는 다른 곳에 있으며,
제품 구현 유형:
최종 버전
옵션 1: 정적 메뉴 생성 전용으로 우리가 연결하는 버튼으로 코드를 생성하기만 하면 됩니다.
옵션 2: 우리는 버튼 자체에 코드를 동적으로 삽입하는 지원을 도입했습니다. 우리는 무엇을 언제 어디서 호출하는지 .... 그래서 구현하기가 어렵지 않아야 합니다. 터미널에서 즉시 도망쳐서 외부 환경에서 무언가를 조각할 수도 있습니다.
옵션 3: 저자가 아닌 다른 모든 사람들과 마찬가지로 내가 저자가 아닌 한 분명히 상상할 수 없는 것. 그러나 이것은 위에 쓰여진 모든 것보다 훨씬 더 복잡해야 합니다.
모든 변형에서 메뉴 자체를 만드는 전체 기능을 의미합니다.
어쨌든 경험은 연습으로 매우 중요합니다.
귀하의 프로젝트는 프로그래밍 기술이 그다지 높지 않기 때문에 대규모로 보입니다. 따라서 코드는 10배 미만이 될 것입니다. 실제로는 10배입니다. . 20,000 - 40,000줄은 몇 줄입니까? 2000-4000일 것입니다. 그리고 그는 더 이상 괴물처럼 보이지 않을 것입니다. 그냥 프로그램.
게다가 창의성은 그것과 아무 관련이 없습니다. 단지 적은 코드가 더 읽기 쉬울 뿐이며, 프로그래머는 일반적으로 한 번 작성하기 전에 코드를 20번 읽습니다.
추신: 예를 들어, 포럼 중재자 중 한 명이 작성한 기사를 생각해 보십시오(전문 프로그래머도 아님) ... 기사 디자인은 결과적으로 1000라인 미만의 코드에서 불필요하게 훌륭합니다. 40줄을 작성해야 했고 훨씬 더 명확할 것입니다.
그러나 열정과 헌신은 분명히 부러워 할 수 있습니다.
실수: 유사한 문제를 해결하기 위한 다른 사람들의 접근 방식을 연구하기를 원하지 않고 이를 구현하는 방법을 이해합니다.
여기에서 말하자면, 이 포럼의 많은 참가자들이 MT의 라이브러리에 동의하지 않고 다시 작성한다는 점을 이해해야 합니다. 저것들. 그들은 평가하고, 그들의 코드를 이해하고, 그들이 동의하지 않는 것을 보고, 다시 작성합니다. 하지만 작품을 충분히 이해한 후))) 친숙한 문구 chtol?)))
미안, 내 머리 속 깊이 생각을 발전 시켰어))
아니요, 낯익은 얼굴입니다(사실이 아닙니다. 완전히 확신할 수 있습니다. 묻지 않을 것입니다). 그러나 베드로가 나의 이 질문을 일관되게 무시했다는 사실로 판단하면 그가 그랬을 가능성이 매우 높습니다. 그리고 피터?
답변이 예상됩니다 :) 우리는 더 많은 옵션을 기다리고 있습니다 ...
교육에 물든 사람들에게 독학은 아인슈타인을 비롯한 삶의 원동력이 됩니다...
프로젝트 자체는 냄새가 나지 않습니다
Реter Konow :
Здесь никто не понимает одной штуки. ....
... 여기에서 발명할 수 있으며 모든 것을 알 필요는 없습니다.
여기 교육받지 못한 사람들이 있습니까? 그래서?...
... 즉, 교육을받지 못한 "발명품"을 문지르 수 있습니까?
여기 교육받지 못한 사람들이 있습니까? 그래서?...
... 즉, 교육을받지 못한 "발명품"을 문지르 수 있습니까?
왜 조작을...
조작은 어디에?