Messieurs les programmeurs, aidez-moi à créer un simple EA - page 5
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
+10 !
Bien sûr, lorsque vous parlez à un client, vous pouvez faire semblant d'être un hostile, mais ce n'est pas professionnel.
>> Je suis d'accord !
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
Vous pouvez prétendre être un tuyau ou autre chose, mais le client doit également comprendre que le proger n'est pas un télépathe et qu'il doit donc rédiger les TdR plus correctement (au moins mentionner que les erreurs d'exécution doivent être traitées). Bien entendu, la gestion des erreurs grossières doit être codée par le programmeur sans les mentionner.
Можно и шлангом прикинуться, и еще чем-то, но заказчик тоже должен понимать, что прогер не телепат и поэтому должен более корректно писать ТЗ (хотя бы упомянуть что должны обрабатываться ошибки исполнения). Конечно обработку грубых ошибок программист должен кодить без упоминания.
Dans ma pratique, je n'ai jamais vu un client qui comprenait ce qu'est le MQL et ce qu'il faut faire pour qu'il n'y ait pas d'erreurs. Le client ne veut qu'une chose : l'exécution correcte de son algorithme d'entrée/sortie, etc., et la gestion des erreurs est le travail du programmeur.
Ou la même question - pour réinitialiser le terminal. Le programmeur doit tout prévoir lui-même, sans le stipuler explicitement dans les RPT.
я за свою практику не разу не видел заказчика, который понимал что такое MQL и что надо предусматривать чтоб не было ошибок. Заказчик хочет одного - правильного исполнения его алгоритма входа/выхода и т.д. а обработка ошибок это и есть работа программиста.
Devons-nous supposer que, si le client ne se plaint pas du code et de l'algorithme d'exécution de ce code, alors le code a été exécuté conformément aux termes de référence du client ? Et si oui, le proger a fait tout ce que le client voulait. Nous avons également rencontré de tels TDR, qui précisent ce que l'EA doit faire après le redémarrage du terminal.
Vous pouvez faire semblant d'être un tuyau ou autre chose.
Eh bien, c'est une question de goût.
N'oubliez pas que cette attitude à l'égard du client finit par faire en sorte qu'un client non avare refuse les services d'un tel programmeur. Vous devrez donc écrire "as if software" pour "as if payment".
стоит ли полагать, что, если у заказчика нет претензий к коду и к алгоритму выполнения этого кода, то код выполнен согласно ТЗ заказчика? А если так, то прогер сделал все как хотел заказчик. Встречались и такие ТЗ в которых указывалось что должен делать советник после перезапуска терминала.
Nous avons.
Mais si cela n'est pas précisé dans les TDR, j'évalue toujours la nécessité de le faire et les conséquences d'un redémarrage, et je discute toujours de ces points avec le client. Vous comprenez que la pratique du programmeur n'est pas comparable à la pratique du recours à des experts par le client. Le programmeur doit toujours avoir une longueur d'avance sur ce qui est possible et ce qui se passera dans l'environnement de l'EA. Et informer le client.
Ну, это на любителя.
Только имейте ввиду, что подобное отношение к заказчику приводит в конечном счете к тому, что не скупой клиент откажется от услуг такого программиста. Так и придется писать "как бы программы" за "как бы оплату".
Ne t'attarde pas sur les mots, regarde le contexte dans lequel ils ont été prononcés.
втсречались.
но если в ТЗ это не прописано я обязательно оцениваю необходимость такого и последствия при перезапуске и обязательно обсуждаю эти моменты с заказчиком. Вы же сами понимаете, что практика программиста не сравнится с практикой использования экспертов заказчиком. Программер всегда должен видеть на шаг впереди что может быть и что будет со средой эксперта. И поставить в известность клиента.
Négocier avec le client, oui, mais si le client ne sait pas ce dont il a besoin, que doit faire le programmeur ? La seule option est de tout faire comme d'habitude (selon la norme, mais selon les TdR), en tenant compte de toutes les situations exceptionnelles standard possibles