Можно и шлангом прикинуться, и еще чем-то, но заказчик тоже должен понимать, что прогер не телепат и поэтому должен более корректно писать ТЗ (хотя бы упомянуть что должны обрабатываться ошибки исполнения). Конечно обработку грубых ошибок программист должен кодить без упоминания.
я за свою практику не разу не видел заказчика, который понимал что такое MQL и что надо предусматривать чтоб не было ошибок. Заказчик хочет одного - правильного исполнения его алгоритма входа/выхода и т.д. а обработка ошибок это и есть работа программиста.
стоит ли полагать, что, если у заказчика нет претензий к коду и к алгоритму выполнения этого кода, то код выполнен согласно ТЗ заказчика? А если так, то прогер сделал все как хотел заказчик. Встречались и такие ТЗ в которых указывалось что должен делать советник после перезапуска терминала.
Только имейте ввиду, что подобное отношение к заказчику приводит в конечном счете к тому, что не скупой клиент откажется от услуг такого программиста. Так и придется писать "как бы программы" за "как бы оплату".
но если в ТЗ это не прописано я обязательно оцениваю необходимость такого и последствия при перезапуске и обязательно обсуждаю эти моменты с заказчиком. Вы же сами понимаете, что практика программиста не сравнится с практикой использования экспертов заказчиком. Программер всегда должен видеть на шаг впереди что может быть и что будет со средой эксперта. И поставить в известность клиента.
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
+10!
当然，在与客户交谈时，你可以假装是一个胡闹的人，但这是不专业的。
>> 我同意!
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
你可以假装是软管或其他东西，但客户也应该明白，程序员不是心灵感应者，因此应该更正确地编写ToR（至少要提到应该处理执行错误）。当然，处理严重的错误应该由程序员进行编码，而不提它们。
Можно и шлангом прикинуться, и еще чем-то, но заказчик тоже должен понимать, что прогер не телепат и поэтому должен более корректно писать ТЗ (хотя бы упомянуть что должны обрабатываться ошибки исполнения). Конечно обработку грубых ошибок программист должен кодить без упоминания.
在我的实践中，我从未见过一个客户了解什么是MQL，以及如何确保没有错误。客户只想要一件事--正确执行他的输入/输出算法等，而错误处理是程序员的工作。
或者同样的问题--重置终端。程序员必须自己提供一切，而不是在TOR中明确规定。
я за свою практику не разу не видел заказчика, который понимал что такое MQL и что надо предусматривать чтоб не было ошибок. Заказчик хочет одного - правильного исполнения его алгоритма входа/выхода и т.д. а обработка ошибок это и есть работа программиста.
我们是否应该认为，如果客户对代码和执行这段代码的算法没有抱怨，那么这段代码就是按照客户的职权范围执行的？如果是这样的话，职业经理人就按照客户的要求做了一切。我们也遇到过这样的TOR，它规定了EA在重新启动终端后必须做什么。
你可以假装是一个水管或其他东西。
嗯，这是一个品味的问题。
只要记住，这种对客户的态度最终会导致不小气的客户会拒绝这样的程序员的服务。因此，你将不得不把 "仿佛软件 "写成 "仿佛付款"。
стоит ли полагать, что, если у заказчика нет претензий к коду и к алгоритму выполнения этого кода, то код выполнен согласно ТЗ заказчика? А если так, то прогер сделал все как хотел заказчик. Встречались и такие ТЗ в которых указывалось что должен делать советник после перезапуска терминала.
我们有。
但如果TOR中没有写明，我总是评估它的必要性和重新启动的后果，而且我总是与客户讨论这些要点。你明白，程序员的做法与客户使用专家的做法不能相提并论。程序员必须始终领先一步看到EA环境中可能发生的事情和将要发生的事情。并通知客户。
Ну, это на любителя.
Только имейте ввиду, что подобное отношение к заказчику приводит в конечном счете к тому, что не скупой клиент откажется от услуг такого программиста. Так и придется писать "как бы программы" за "как бы оплату".
不要去挑剔这些话，看看说这话的背景吧
втсречались.
но если в ТЗ это не прописано я обязательно оцениваю необходимость такого и последствия при перезапуске и обязательно обсуждаю эти моменты с заказчиком. Вы же сами понимаете, что практика программиста не сравнится с практикой использования экспертов заказчиком. Программер всегда должен видеть на шаг впереди что может быть и что будет со средой эксперта. И поставить в известность клиента.
与客户协商，是的，但如果客户不知道他需要什么，程序员应该怎么做？ 唯一的选择是照常做一切（根据标准，但根据ToR），考虑到所有可能的标准例外情况