Нужен ли Арбитраж качества кодинга? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Сертификация :) можно уже заходить на следующий круг.
Это смотря кто сколько кушает :) Профессионал напишет программу быстрей новечка, а значит потенциально она может стоить дешевле, особенно учитывая отсутствие сложных проектов.
Вот с этим позвольте не согласиться. Профессионал - он ценит свои знания, умения, опыт, накапливаемые годами. Пусть у него и есть своя наработанная качественная библиотека кода и потому он сможет быстрее новичка составить и оптимизированный алгоритм (что не зависит от имеющегося кода), и саму программу из имеющегося в наличии кода (естественно, логику всё-равно кодировать с нуля под ТЗ)... Так вот я о чём - качество, надёжность и устойчивость к сбоям стоят немало. Скорость выполнения заказа тут ни при чём. В основном заказчики согласны подождать чуть дольше, лишь бы было учтено гораздо больше моментов, возникающих при работе на реале, нежели поскорее код получить. А моменты, не учтённые при обсуждении ТЗ, всё-равно возникают при тестировании и отладке - мы не боги и сразу охватить всё возможное не в состоянии. Зато, когда сообщаешь о некоей проблеме заказчику и спрашиваешь его о том, как бы он желал обрабатывать данную возникшую ситуацию, человек видит серьёзность отношения кодера как к своей работе, так и к нему лично.
Да и вообще - сложно говорить о каких-то критериях оценки. Дайте сотне прекрасных, опытных кодеров одно и то же задание и получите сотню различных вариантов его выполнения. И тут уже сложно будет судить кому из них отдать предпочтение.
Этом абзац особо умиляет. Нужно выбирать новечков, они хоть и потенциально дороже, но стараться будут больше..)))
Стараться им придется больше, чтоб закодить ранее неведанное им, и поэтому они оценят свою работу дороже, так как потратят времени больше. Учитывая Вашу озабоченность ошибками, надеюсь вы проголосовали "Да".
В 1с тоже предусмотрена сертификация ))) Однако, на деле часто встречаются тааакие художники...
Однозначно "да", но часто проблема в непонимании задачи, программисты не бухгалтера, могут менять одно и не понимать, что поедет другое...
Вот с этим позвольте не согласиться. Профессионал - он ценит свои знания, умения, опыт, накапливаемые годами. Пусть у него и есть своя наработанная качественная библиотека кода и потому он сможет быстрее новичка составить и оптимизированный алгоритм (что не зависит от имеющегося кода), и саму программу из имеющегося в наличии кода (естественно, логику всё-равно кодировать с нуля под ТЗ)... Так вот я о чём - качество, надёжность и устойчивость к сбоям стоят немало. Скорость выполнения заказа тут ни при чём. В основном заказчики согласны подождать чуть дольше, лишь бы было учтено гораздо больше моментов, возникающих при работе на реале, нежели поскорее код получить. А моменты, не учтённые при обсуждении ТЗ, всё-равно возникают при тестировании и отладке - мы не боги и сразу охватить всё возможное не в состоянии. Зато, когда сообщаешь о некоей проблеме заказчику и спрашиваешь его о том, как бы он желал обрабатывать данную возникшую ситуацию, человек видит серьёзность отношения кодера как к своей работе, так и к нему лично.
Да и вообще - сложно говорить о каких-то критериях оценки. Дайте сотне прекрасных, опытных кодеров одно и то же задание и получите сотню различных вариантов его выполнения. И тут уже сложно будет судить кому из них отдать предпочтение.
Я с Вами согласен, что тестирование должно входить в стоимость работ, но по факту... по факту надо давать, и возможно порталом, гарантию на работу и устранение недочетов в случае их выявления. А то получается принял работу, и только спустя месяц увидел ошибку - человеческий фактор. И есть программисты которые говорят "Да, без проблем поправлю!", а есть "Вы уже приняли работу".
А что касается проработки ТЗ, тут все в равных условиях, но я уверен, что чем больше опыта, тем быстрей решается задача. Поэтому это нормально, что начинающие программисты работают за идею - они учатся и получают опыт. И тогда логично что затраченное время на получение одного у.е. у опытного программиста будет меньше, а рентабельность больше.
Говорить о критериях оценки можно, если привязывать её к математической плоскости измерения, не обращая внимания на стиль, красоту кода, использованные логические выражения, а обратить внимание на скорость работы советника, его устойчивость на сбой в сети, проверку ожидания другого советника, и иные "мелочи", без которых работать с советником (иным кодом) становиться невозможным. Иначе говоря нужны стандарты, на соблюдение которых может рассчитывать заказчик.
Говорить о критериях оценки можно, если привязывать её к математической плоскости измерения, не обращая внимания на стиль, красоту кода, использованные логические выражения, а обратить внимание на скорость работы советника, его устойчивость на сбой в сети, проверку ожидания другого советника, и иные "мелочи", без которых работать с советником (иным кодом) становиться невозможным. Иначе говоря нужны стандарты, на соблюдение которых может рассчитывать заказчик.
Иначе говоря нужны стандарты, на соблюдение которых может рассчитывать заказчик.
вот. но их нет. Так как нет школы, конвеера и методологии.
без этого ни о каком арбитраже речи не может быть.
Придумали же такое - арбитраж качества MQL кода. У вас лекала или линейка завалялась где-то на это измерение?
ааа. вспомнил, теоретик :)Иначе говоря нужны стандарты, на соблюдение которых может рассчитывать заказчик.
Вы даже не представляете , как программистам хотелось бы , что бы к ним с заказами приходили тоже сертифицированные Заказчики . Проверенные и с гарантией что не дурак и время на обсуждение ТЗ не будет выкинуто на помойку.
Но такого нет и не будет и они идут на риск
Так вот , любой Заказчик, приняв решение о заказе , тоже должен понимать , что идет на риск. Это он должен тщательно , потратив время , выбрать себе исполнителя . Это его работа.
Не сделал свою часть работы - попал. Ныть про гарантии ресурса бесполезно.
Говорить о критериях оценки можно, если привязывать её к математической плоскости измерения, не обращая внимания на стиль, красоту кода, использованные логические выражения, а обратить внимание на скорость работы советника, его устойчивость на сбой в сети, проверку ожидания другого советника, и иные "мелочи", без которых работать с советником (иным кодом) становиться невозможным. Иначе говоря нужны стандарты, на соблюдение которых может рассчитывать заказчик.
Вот вы всё о скорости печётесь. Вам не кажется, что советник, сделанный только для тестера, будет работать гораздо быстрее советника, сделанного под реал. И программист тут ни при чём. Вы должны понимать, что для тестера не критична потеря данных - при сбое тестер всё-равно перезапускать. А вот на реале советник не имеет права терять важные данные, и обязан без потерь качества своей работы уметь их восстановить из окружения, не зависимого от вашего компьютера. А это - лишние циклы и проверки, которых в тестерном варианте в помине нет.
Так вот, вы, для проверки своей идеи и оптимизации параметров за триста лет, сначала закажите программисту тестерный вариант советника, а уж потом, при положительных результатах тестов и оптимизации, закажите его же, но для реала. Денег жаль? Или вам подискутировать о квалификации кодеров интереснее?
Вы даже не представляете , как программистам хотелось бы , что бы к ним с заказами приходили тоже сертифицированные Заказчики . Проверенные и с гарантией что не дурак и время на обсуждение ТЗ не будет выкинуто на помойку.
Конечно очевидно, что дополнительная ответственность воспринимается людьми как негатив. К сожалению тут слышно мнение только исполнителей, которые не думают о заказчиках.
А Вы поймите, что заказчик не может знать всех нюансов программирования, и именно Вы должны у него спросить "Вам проверку на каждый тик, что ордер не закрылся и надпись в лог "ещё не закрылись" или вы ещё и оптимизировать советник намерены?". "Вы даже не представляете , как программистам хотелось бы , что бы к ним с заказами приходили тоже сертифицированные Заказчики ." - для этих целей ТЗ Вам должен писать программист.
В подтверждении вышеизложенного, про работу за еду, я приведу таблицу, из которой видно, что успеха можно добиться делая много/дешева/качественно