Можно и шлангом прикинуться, и еще чем-то, но заказчик тоже должен понимать, что прогер не телепат и поэтому должен более корректно писать ТЗ (хотя бы упомянуть что должны обрабатываться ошибки исполнения). Конечно обработку грубых ошибок программист должен кодить без упоминания.
я за свою практику не разу не видел заказчика, который понимал что такое MQL и что надо предусматривать чтоб не было ошибок. Заказчик хочет одного - правильного исполнения его алгоритма входа/выхода и т.д. а обработка ошибок это и есть работа программиста.
стоит ли полагать, что, если у заказчика нет претензий к коду и к алгоритму выполнения этого кода, то код выполнен согласно ТЗ заказчика? А если так, то прогер сделал все как хотел заказчик. Встречались и такие ТЗ в которых указывалось что должен делать советник после перезапуска терминала.
Только имейте ввиду, что подобное отношение к заказчику приводит в конечном счете к тому, что не скупой клиент откажется от услуг такого программиста. Так и придется писать "как бы программы" за "как бы оплату".
но если в ТЗ это не прописано я обязательно оцениваю необходимость такого и последствия при перезапуске и обязательно обсуждаю эти моменты с заказчиком. Вы же сами понимаете, что практика программиста не сравнится с практикой использования экспертов заказчиком. Программер всегда должен видеть на шаг впереди что может быть и что будет со средой эксперта. И поставить в известность клиента.
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
+10!
もちろん、お客さまとのコミュニケーションでハズレを引くこともありますが、それはプロとして失格です。
>> 同感です!
Конечно, общаясь с заказчиком можно прикинуться шлангом, но это - проявление непрофессионализма.
ホースなどを装うのもいいが、顧客もプロジェクターがテレパスではないことを理解し、そのためToRをより正しく書くべき（少なくとも実行エラーは処理すべきと言及すべき）であろう。もちろん、重大なエラーの処理は、プログラマが言及せずにコーディングすべきです。
Можно и шлангом прикинуться, и еще чем-то, но заказчик тоже должен понимать, что прогер не телепат и поэтому должен более корректно писать ТЗ (хотя бы упомянуть что должны обрабатываться ошибки исполнения). Конечно обработку грубых ошибок программист должен кодить без упоминания.
私の実務では、MQLとは何か、間違いがないようにするにはどうすればよいかを理解しているお客様を見たことがありません。顧客が求めるものはただ一つ、入出力アルゴリズムなどが正しく実行されることであり、エラー処理はプログラマの仕事である。
あるいは、同じ質問ですが、端末をリセットすることです。TORで明示的に規定しなくても、プログラマーが自分ですべてを用意しなければならない。
я за свою практику не разу не видел заказчика, который понимал что такое MQL и что надо предусматривать чтоб не было ошибок. Заказчик хочет одного - правильного исполнения его алгоритма входа/выхода и т.д. а обработка ошибок это и есть работа программиста.
顧客がコードやこのコードを実行するためのアルゴリズムに不満がなければ、そのコードは顧客の条件に従って実行されたと考えるべきでしょうか。そして、もしそうなら、プロジェクターはすべてお客さまの希望通りにしたのです。また、端末を再起動した後にEAが何をしなければならないかを指定した、そのようなTORにも出会いました。
ホースのふりとかでもいいんですよ。
まあ、これは好みの問題なんですけどね。
ただ、顧客へのこのような態度は、最終的にはケチな顧客がそのようなプログラマーのサービスを拒否するという事実につながることを心に留めておいてください。そのため、"as if software "を "as if payment "と書く必要があります。
стоит ли полагать, что, если у заказчика нет претензий к коду и к алгоритму выполнения этого кода, то код выполнен согласно ТЗ заказчика? А если так, то прогер сделал все как хотел заказчик. Встречались и такие ТЗ в которых указывалось что должен делать советник после перезапуска терминала.
持っています。
しかし、TORに明記されていない場合は、その必要性と再開した場合の影響を常に評価し、その点を必ずクライアントと協議します。お客様は、プログラマーの実務が、お客様による専門家の活用の実務と比較できないことを理解します。プログラマーは、EAの環境で何が可能か、何が起こるか、常に一歩先を見なければならない。そして、お客様にお知らせすること。
Ну, это на любителя.
Только имейте ввиду, что подобное отношение к заказчику приводит в конечном счете к тому, что не скупой клиент откажется от услуг такого программиста. Так и придется писать "как бы программы" за "как бы оплату".
わざわざ言葉を選ぶ必要はない、その言葉の背景を見よう
втсречались.
но если в ТЗ это не прописано я обязательно оцениваю необходимость такого и последствия при перезапуске и обязательно обсуждаю эти моменты с заказчиком. Вы же сами понимаете, что практика программиста не сравнится с практикой использования экспертов заказчиком. Программер всегда должен видеть на шаг впереди что может быть и что будет со средой эксперта. И поставить в известность клиента.
クライアントと交渉することはそうですが、クライアントが何を必要としているのかわからない場合、プログラマはどうすればいいのでしょうか？ 唯一の選択肢は、標準的な例外的状況をすべて考慮して、いつも通り（標準に従って、しかしToRに従って）すべてを実行することです。