나는 소스가 그에게서 만든 하나의 주문을 버릴 수 있습니다. 누가 그가 질적으로했는지 여부를 이해하는지 볼 수 있습니다. 나는 그것이 질적으로인지 여부를 이해하지 못합니다. 가장 중요한 것은 알고리즘에 따라 작동한다는 것입니다. 그러나 나는 내부 방법을 모릅니다) 0
대부분의 코드는 그가 당신에게 보낸 것으로 생각되는 Trades.mqh 라이브러리에 있습니다. 부착하여 품질을 평가합니다. 이 파일에서 할 말이 별로 없습니다. 검사 및 정규화가 있어야 할 위치에 없는 것처럼 보이지만 포함된 Trades.mqh 파일에도 있을 수 있습니다. 예, 대부분의 코드는 같은 위치에 있습니다.
그러나 신호 블록에 대해 할 말이 있습니다. 1) 정규화 없이 두 배를 서로 비교합니다. 2) 양초 종가 가 MA 가격과 동일한 상황을 고려하지 않고 MA 가격이 교차했습니다. 드물지만 가능합니다.
나는 그것이 어렵다고 주장하지 않고 그렇습니다. 거기에서 많은 오류가 표면화되었습니다. 그러나 2개월 전에 오류가 알려지고 제거되었으며 가장 어려운 것은 모두 뒤에 있다고 말했습니다. 불행히도 저는 이 일을 하지 않습니다. 그러나 전략의 모든 세부 사항을 자세히 알고 있고 그는 시간당 요금에 동의했고 작업에 대한 보고서만 있었고 이것이 나쁘고 틀렸다는 것을 그에게 증명할 수 없었습니다.
프리랜서에 시간당 급여가 있습니까?
중재를 통해 문제를 해결할 수 있다는 사실, 그런 것이 있기 때문에 그들은 거기에서 판단합니다.
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리에서 이동하는 경우 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 돌아가서 이미 차트의 가장자리에 오도록 해야 합니다. 일부 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 일이 안 돼서 쪼개서 고객들에게 개발비를 올려야 한다고 편지를 썼는데, 컴퓨터를 놓고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 구성에 오류가 있는 화면을 보내주는 원리로 작업중인데 수정합니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리에서 이동하는 경우 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 돌아가서 이미 차트의 가장자리에 오도록 해야 합니다. 일부 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 실패를 해서 개발비를 올려야 한다고 쪼개서 고객들에게 편지를 썼는데, 컴퓨터를 놔두고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 시공에 오류가 있는 화면을 보내주신다는 원칙에 따라 작업을 진행하고 있으며 수정하고 있습니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
일반적으로 이전보다 훨씬 더 혼란스러워졌습니다.
내가 이해한 바에 따르면, 상급반에서 조건의 일치 여부를 확인해야 하고, 일치하지 않으면 ...
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리로 이동하면 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 전환하고 일부를 가지고 차트의 가장자리에 오도록 해야 합니다. 이미 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 실패를 해서 개발비를 올려야 한다고 쪼개서 고객들에게 편지를 썼는데, 컴퓨터를 놔두고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 구성에 오류가 있는 화면을 보내주는 원리로 작업중인데 수정합니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
설명을 보면 잘 개발된 기술 사양이 없었고 작업은 다음과 같습니다. 이 전략을 설정하고 그렇게 작동해야 합니다. 이 모든 것을 구현하는 방법을 알아내는 과정에서 알고리즘이 없습니다. .
이 경우 이것은 노동 집약적 인 작업입니다. 위에서 쓴 것처럼 프로그래머는 생각하기 시작하고 모든 사람은 생각에 대한 자신의 대가가 있습니다. 따라서 가격이 정당화될 수 있습니다.
분업은 헛되이 발명된 것이 아닙니다. 고객의 이해에서 프로그래머는 어떤 아이디어라도 코드로 전달할 수 있는 마법사입니다. 사실 인간의 자질과 능력은 항상 한계가 있고, 대기업에서는 알고리즘을 만드는 사람, 아키텍트, 이미 프로그래머로 나누어져 있고, 누구나 각자의 전문 분야가 있습니다. 상황이 이렇게 되었습니다.
익숙한 상황. 코드 작성을 시작하기 전에 미리 구조와 논리를 계획하지만, 알고리즘이 준비되고 완전히 작동한 후 몇 가지 다른 조건과 새로운 기능을 코드에 추가하기 시작하면 결국 다음과 같은 상황이 발생합니다. 전체 구조를 수정하고 모든 논리를 완전히 다시 작성하는 것이 더 쉬울수록 이전 알고리즘에 몇 가지 새로운 개념을 계속 집어넣으려는 시도가 계속됩니다. 새로운 기능과 조건을 고려하여 모든 것을 다시 생각하고 알고리즘을 다시 작성하는 것이 더 쉬운 것으로 나타났지만 이것은 많은 시간이 걸립니다.
나는 소스가 그에게서 만든 하나의 주문을 버릴 수 있습니다. 누가 그가 질적으로했는지 여부를 이해하는지 볼 수 있습니다. 나는 그것이 질적으로인지 여부를 이해하지 못합니다. 가장 중요한 것은 알고리즘에 따라 작동한다는 것입니다. 그러나 나는 내부 방법을 모릅니다) 0
대부분의 코드는 그가 당신에게 보낸 것으로 생각되는 Trades.mqh 라이브러리에 있습니다. 부착하여 품질을 평가합니다.
이 파일에서 할 말이 별로 없습니다. 검사 및 정규화가 있어야 할 위치에 없는 것처럼 보이지만 포함된 Trades.mqh 파일에도 있을 수 있습니다.
예, 대부분의 코드는 같은 위치에 있습니다.
그러나 신호 블록에 대해 할 말이 있습니다.
1) 정규화 없이 두 배를 서로 비교합니다.
2) 양초 종가 가 MA 가격과 동일한 상황을 고려하지 않고 MA 가격이 교차했습니다. 드물지만 가능합니다.
나는 그것이 어렵다고 주장하지 않고 그렇습니다. 거기에서 많은 오류가 표면화되었습니다. 그러나 2개월 전에 오류가 알려지고 제거되었으며 가장 어려운 것은 모두 뒤에 있다고 말했습니다. 불행히도 저는 이 일을 하지 않습니다. 그러나 전략의 모든 세부 사항을 자세히 알고 있고 그는 시간당 요금에 동의했고 작업에 대한 보고서만 있었고 이것이 나쁘고 틀렸다는 것을 그에게 증명할 수 없었습니다.
프리랜서에 시간당 급여가 있습니까?
중재를 통해 문제를 해결할 수 있다는 사실, 그런 것이 있기 때문에 그들은 거기에서 판단합니다.
그런 술이 사라졌으므로 토론에 참여하겠습니다.)))
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리에서 이동하는 경우 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 돌아가서 이미 차트의 가장자리에 오도록 해야 합니다. 일부 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 일이 안 돼서 쪼개서 고객들에게 개발비를 올려야 한다고 편지를 썼는데, 컴퓨터를 놓고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 구성에 오류가 있는 화면을 보내주는 원리로 작업중인데 수정합니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
그런 술이 사라졌으므로 토론에 참여하겠습니다.)))
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리에서 이동하는 경우 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 돌아가서 이미 차트의 가장자리에 오도록 해야 합니다. 일부 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 실패를 해서 개발비를 올려야 한다고 쪼개서 고객들에게 편지를 썼는데, 컴퓨터를 놔두고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 시공에 오류가 있는 화면을 보내주신다는 원칙에 따라 작업을 진행하고 있으며 수정하고 있습니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
일반적으로 이전보다 훨씬 더 혼란스러워졌습니다.
내가 이해한 바에 따르면, 상급반에서 조건의 일치 여부를 확인해야 하고, 일치하지 않으면 ...
알고리즘을 올바르게 이해했다면 그리 어렵지 않습니다(최대 2-3일).
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
그건 그렇고, 1000줄은 모든 Expert Advisor가 단순하지 않은 평균 크기입니다. 문제는 나타난 문제를 해결하는 방법에 대해 생각할 때 잘못된 방향으로 갔다는 것입니다. 성공의 90%는 작업을 올바르게 공식화하는 것이며 구현은 이미 열 번째입니다.
.
.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
내가 당신을 지원하자.
나는 정확히 똑같은 것은 아니지만 비슷한 전략을 가지고 있습니다. 외부(사용자 정의) 지표를 사용하지 않고 지지/저항 수준, 추세, 반전, 후퇴 및 기타 여러 사항을 고려합니다.
나는 3년 동안 이 전략을 사용하여 손을 교환했습니다. 그동안 어떻게 구현할까 고민하다가 1년 만에 프로그래밍을 했다. 2000줄도 안 되는 줄 알았다.
손을 거래하는 방법을 알고 있는 모든 개발자는 일부 막대를 분석의 기초로 삼을 때 더 쉽게 찾을 수 있습니다.
하지만 바, 그것이 M1이라고 해도 이것은 이미 과거 다. 막대(특히 오래된 막대에서)에 어떤 종류의 전략을 세우는 것은 무의미합니다.
각 틱 을 처리하는 모든 작업이 완료되어야 합니다.
여기 내 프로그램에는 단일 배열(절대적인 의미에서)이 없으며 과거에 발생한 일을 분석하지 않습니다. 하지만 물론 (배열이 아닌) 실시간으로 필요한 제어점 을 기억합니다.
요컨대: 손으로 하는 일과 차트에 그토록 쉽고 아름답게 그려진 것이 항상 프로그래밍할 수 있는 것은 아닙니다.
그런 술이 사라졌으므로 토론에 참여하겠습니다.)))
우선, 물론 개발이 지연된 데 대해 82Dmitry82와 그의 나머지 팀원들에게 사과드립니다. 개발을 맡게 된 점을 유감스럽게 생각한다고 이미 대표님께 말씀드린바와 같이 어려운 일임을 인정합니다. 작업을 여러 부분으로 나누었지만 2단계에서 TOR의 강력한 컴플리케이션이 드러났고, 사실 일단 시작하면 완성하기로 마음먹었지만 생각보다 간단하지 않은 것으로 밝혀졌다.
이제 전략을 공개하지 않고 동료 프로그래머가 이 사실이 개발을 얼마나 복잡하게 하는지를 정말로 이해할 수 있도록 TK의 복잡성에 대한 사실을 설명하려고 합니다.
이것은 주문을 열어야 하는 레벨의 그래픽 구성 을 기반으로 합니다. 히스토리를 참조하지 않고 차트의 가장자리로 이동하면 이러한 레벨을 구축할 수 없으며 히스토리가 누적될 때까지 기다려야 하거나 단순히 어드바이저가 히스토리 자체로 전환하고 일부를 가지고 차트의 가장자리에 오도록 해야 합니다. 이미 데이터. 그래서 그렇게 하기로 결정했습니다.
처음에는 촛대를 사용하여 4개의 매개변수(Open,Close,High,Low)를 평가하고 조건에 따라 구성하는 것처럼 보였습니다. 이것이 첫 번째 부분이 시니어 TF에서 수행된 방식입니다(TOR는 3개의 부분으로 나뉘며, 각 부분에 대한 3개의 TF는 이러한 구성에 대한 다른 구성 및 조건입니다). 두 번째 TF로 이동하여 기본적으로 준비된 두 번째 부분을 테스트하기 시작했을 때 오류가 드러났고, 이에 대한 일반적인 토론 중에 기록의 촛불을 온라인으로 추적해야 함(즉, 차트 가장자리에서 0인 것처럼) 촛불이 아직 닫히지 않은 상태에서 재구축합니다. 이는 히스토리를 실행할 때 현실적이지 않습니다. 왜냐하면 실제로 Open, Close, Low, High 4개의 매개변수가 있기 때문입니다.
일반 토론 중에 양초의 구성을 온라인에서 최대한 추적하기 위해 양초가 깊어지고 m1까지 분할되어야 한다고 결정했습니다(차트 가장자리에서 0인 것처럼). 히스토리의 구성을 4포인트 그대로 두자는 제안과 차트의 가장자리(Close[0]이 플로팅일 때)에서 이미 추적하는 올바른 논리는 거부되었습니다. 고객 스스로는 개발 과정에서 드러난 이 사실이 TOR를 상당히 복잡하게 만든다는 사실을 이해했습니다. 이미 그 단계에서 개발을 포기하고 싶었지만 이미 1단계가 완료되었고 개발을 중앙에 두는 것이 전적으로 제 원칙이 아니기 때문에 계속하기로 결정했습니다. 기존 알고리즘을 M1을 따라 달리고 기존 TF를 추적해야 한다는 사실에 적응하는 과정에서 이 과정에서 엄청난 시간을 허비했다는 사실에서 정신병이 나기 시작했습니다. 실패를 해서 개발비를 올려야 한다고 쪼개서 고객들에게 편지를 썼는데, 컴퓨터를 놔두고 작동하지 않는다는 사실을 조금 식히자 계속해서 편집을 했다.
그는 더 이상 합의된 금액만큼 프로젝트를 추진할 힘이 없다는 이유로 시간 기반 지불을 제안했습니다. 비록 그가 그 출처를 밝히겠다고 제안했지만, 그것은 그들이 그것을 마음에 가져다 줄 누군가를 찾을 수 있도록 하기 위함이었습니다.
사실, 내가 이전 TF 내부에서 m1을 추적해야 한다는 것을 처음에 알았다면 EA 로직을 다르게 구축했을 것입니다.
지금은 구성에 오류가 있는 화면을 보내주는 원리로 작업중인데 수정합니다. 전략에 수많은 조건이 있기 때문에 모든 가능성을 직접 확인할 수 있는 방법은 없습니다. 사실 기억조차 나지 않습니다. 서로 충돌하지 않도록 모두 조정하는 것이 주요 문제입니다. 모든 것이 점진적으로 이루어졌고 고객 자신도 전략이 이해하기 어렵다는 것을 인정했지만 일반적으로 이제는 거의 모든 것이 이미 철자되어 있지만 작동 방식을보고 나면 올바르게 이해할 수조차 없습니다)))))
우리가 마지막으로 멈춘 것은 고려되지 않은 경우였습니다(고객 대표에 따르면조차도). 이제 우리는 작성하고, 쐐기를 박고, 12개의 다른 조건에 하나 더 동의해야 합니다. 따라서 시급으로의 전환이 정당하다고 생각합니다.
82Dmitry82, 원하는 경우 고문과 개인적으로 대화할 수 있습니다. 연락처가 있습니다. 나는 당신을 위해 다른 고문을 만들었습니다. 나는 그들이 효율성과 지원을 높이 평가했다고 생각하지만, 이것으로 나는 인내심을 요구할 것입니다. 때로는 다른 쪽을 수정하기 시작하기 위해 접근해야 할 측면에 대한 이해가 없기 때문에 때때로 작업을 연기합니다. 잘못된 레벨 빌딩.
현재 어드바이저는 1000줄 이상의 코드를 가지고 있으며, 이것은 아름다운 혼란과 아직 도달하지 못한 명령도 없이 단지 레벨을 구축하는 것입니다.
설명을 보면 잘 개발된 기술 사양이 없었고 작업은 다음과 같습니다. 이 전략을 설정하고 그렇게 작동해야 합니다. 이 모든 것을 구현하는 방법을 알아내는 과정에서 알고리즘이 없습니다. .
이 경우 이것은 노동 집약적 인 작업입니다. 위에서 쓴 것처럼 프로그래머는 생각하기 시작하고 모든 사람은 생각에 대한 자신의 대가가 있습니다. 따라서 가격이 정당화될 수 있습니다.
분업은 헛되이 발명된 것이 아닙니다. 고객의 이해에서 프로그래머는 어떤 아이디어라도 코드로 전달할 수 있는 마법사입니다. 사실 인간의 자질과 능력은 항상 한계가 있고, 대기업에서는 알고리즘을 만드는 사람, 아키텍트, 이미 프로그래머로 나누어져 있고, 누구나 각자의 전문 분야가 있습니다. 상황이 이렇게 되었습니다.
내가 당신을 지원하자.
나는 정확히 똑같은 것은 아니지만 비슷한 전략을 가지고 있습니다. 외부(사용자 정의) 지표를 사용하지 않고 지지/저항 수준, 추세, 반전, 후퇴 및 기타 여러 사항을 고려합니다.
나는 3년 동안 이 전략을 사용하여 손을 교환했습니다. 그동안 어떻게 구현할까 고민하고 1년 동안 프로그래밍했다. 2000줄도 안 되는 줄 알았다.
손을 거래하는 방법을 알고 있는 모든 개발자는 일부 막대를 분석의 기초로 삼을 때 더 쉽게 찾을 수 있습니다.
하지만 바, 그것이 M1이라고 해도 이것은 이미 과거 다. 막대(특히 오래된 막대에서)에 어떤 종류의 전략을 세우는 것은 무의미합니다.
각 틱 을 처리하는 모든 작업이 완료되어야 합니다.
여기 내 프로그램에는 단일 배열(절대적인 의미에서)이 없으며 과거에 발생한 일을 분석하지 않습니다. 하지만 물론 (배열이 아닌) 실시간으로 필요한 제어점 을 기억합니다.
요컨대: 손으로 하는 일과 차트에 그토록 쉽고 아름답게 그리는 것이 항상 프로그래밍할 수 있는 것은 아닙니다.
무엇이든 프로그래밍할 수 있지만 이를 위해서는 먼저 알고리즘을 개발해야 하며 이것이 작업의 큰 부분입니다. 사실, 먼저 눈에 보이는 것을 공식과 논리로 변환한 다음 프로그래밍해야 합니다. 그리고 첫 번째 것은 종종 과소 평가됩니다.
그런 술이 사라졌으므로 토론에 참여하겠습니다.)))
....
사실 진작에 알았다면 ..... 고문의 논리를 다르게 구축했을 텐데.
....
익숙한 상황. 코드 작성을 시작하기 전에 미리 구조와 논리를 계획하지만, 알고리즘이 준비되고 완전히 작동한 후 몇 가지 다른 조건과 새로운 기능을 코드에 추가하기 시작하면 결국 다음과 같은 상황이 발생합니다. 전체 구조를 수정하고 모든 논리를 완전히 다시 작성하는 것이 더 쉬울수록 이전 알고리즘에 몇 가지 새로운 개념을 계속 집어넣으려는 시도가 계속됩니다. 새로운 기능과 조건을 고려하여 모든 것을 다시 생각하고 알고리즘을 다시 작성하는 것이 더 쉬운 것으로 나타났지만 이것은 많은 시간이 걸립니다.
" 프로젝트 가 없는 작업의 결과"에 대한 좋은 그림
모두 서로 불만 제로 배기 ..