Ну да. Мне определенно стоило начинать свои тезисы с приставки «не-»: неверность, некорректность и т.п. Как всегда спешу и не задействую мозг на полную.
За ссылку спасибо. Возможность доказать корректность программы математически давно подкупает в ФП, но разобраться детально пока не выходило. Видимо, пришла пора.
А в спеке на алгоритм написано, как именно алгоритм должен быть реализован? Чем тогда спека принципиально отличается от реализации алгоритма, кроме чуточку менее машиннопонимаемого языка?
Иногда бывает нужно реализовать не алгоритм сортировки вообще, а вполне конкретный — например, все ту же сортировку слиянием. В этом случае к спеке прикладывают описание алгоритма в виде блок-схемы, псевдо-кода, кода на другом ЯП и т.п. в качестве reference implementation, а задача программиста сводится к трансляции этого описания в код на языке, используемом в проекте. Например, потому что математик, проработавший алгоритм, знает только питон, а в проекте для подобных числодробилок повелось использовать плюсы.
Безусловно, речь идет о частном случае. В общем случае ни в какие детали реализации спека лезть не должна.
Если в спецификации будет черным по белому написано, что алгоритм состоит из цепочки «если-то», и такая спецификация каким-то чудом пройдет до этапа кодирования, то да: такая реализация будет корректным отображением документа в код и это будет подтверждено тестами.
Если же в спеке написано одно, а прогер с тестером сговорились и воткнули костыль на ифах с определением лишь тех входных значений, которые будут проверяться в тестах, то с формальной точки зрения реализация будет признана корректной и уйдет в прод. Правда, потом кто-то из пользователей обязательно столкнется с не протестированным сценарием и крайним окажется тестировщик, потому что плохо составил тест-план и пропустил ошибку, но это уже, как говорится, совсем другая история.
Ну и наконец встречный вопрос: а к чему Вы клоните? Что тесты могут быть несовершенны и иметь, например, дырявое покрытие? Так я с этим не спорю. Если я где-то был по Вашему мнению не прав — прошу указать.
«корректность реализации алгоритма сортировки» = соответствие написанного кода спецификации алгоритма. Т.е. что при одинаковом вводе и выполнении алгоритма "по бумажке" и в бинарном виде будет получен одинаковый результат. Именно это и проверяют тестами по определению, нет?
А кто сказал, что в случае по ссылке — ошибка кодирования? Не было требования, ограничивающего скорость выполнения на большом массиве данных, и/или требования, ограничивающего приоритет выполнения задачи — получите, распишитесь. Задача формально решена, проходит тесты и ревью, а то, что у кого-то из пользователей из-за этого могут возникнуть неудобства — так это в следствие незапланированного режима эксплуатации. В одном из следующих апдейтов предусмотрим работу в вашем режиме, если вы настолько важный клиент.
Верность алгоритма покажет только эксплуатация. (Ну или тестирование модели, но на этом этапе именно кода еще не написано ни строчки) Корректность реализации алгоритма покажут тесты. Корректность записи алгоритма покажет компилятор/анализатор.
Ну а лапшичность кода — это вообще не ошибка, а дело вкуса и стиля, принятого в команде. Может, там одни пастафарианцы работают, кто их знает?
JS по своей природе создан для примитивной разработки
Fixed. Выпадающие менюшки, картинки подгрузить, вызовы в апплеты прокинуть. Никакого рокет-сайнс, чисто чтобы с этой задачей могли справиться даже дизайнеры. Оттуда и решения вроде неявного приведения типов, которое иначе могло бы несчастных дизайнеров просто запугать (вы их еще вручную памятью управлять заставьте, ага!).
А для быстрой разработки подойдет абсолютно любой ЯВУ (вписывающийся в ограничения задачи, разумеется). При одном лишь условии — если он хорошо знаком. Потому что к новому инструменту, даже если он по итогу эффективнее, все равно нужно время на привыкание. А если нужно быстро — этого времени, как правило, нет.
Я не могу сравнивать TS и JS, за неимением достаточного опыта работы с обоими языками, но мои предпочтения все равно будут на стороне сильной статической типизации: тесты и ревью это хорошо, но цикл обратной связи получается уж больно длинным, да и опечатка все равно может через них прорваться и наломать дров. При этом компилятор и статический анализатор вполне могут отловить ее еще на стадии написания кода.
Грустно, когда такого рода… неприятности приключаются с кем-либо. А когда «кто-либо» — молодая девушка, почему-то становится еще грустнее.
Спасибо за статью, желаю Вашим близким терпения, а Вам — поддержки, здоровья и скорейшего восстановления. Статьи и открытые читалки — это конечно же хорошо, но и трейлы тоже скучают и очень ждут.
За ссылку спасибо. Возможность доказать корректность программы математически давно подкупает в ФП, но разобраться детально пока не выходило. Видимо, пришла пора.
Иногда бывает нужно реализовать не алгоритм сортировки вообще, а вполне конкретный — например, все ту же сортировку слиянием. В этом случае к спеке прикладывают описание алгоритма в виде блок-схемы, псевдо-кода, кода на другом ЯП и т.п. в качестве reference implementation, а задача программиста сводится к трансляции этого описания в код на языке, используемом в проекте. Например, потому что математик, проработавший алгоритм, знает только питон, а в проекте для подобных числодробилок повелось использовать плюсы.
Безусловно, речь идет о частном случае. В общем случае ни в какие детали реализации спека лезть не должна.
Если же в спеке написано одно, а прогер с тестером сговорились и воткнули костыль на ифах с определением лишь тех входных значений, которые будут проверяться в тестах, то с формальной точки зрения реализация будет признана корректной и уйдет в прод. Правда, потом кто-то из пользователей обязательно столкнется с не протестированным сценарием и крайним окажется тестировщик, потому что плохо составил тест-план и пропустил ошибку, но это уже, как говорится, совсем другая история.
Ну и наконец встречный вопрос: а к чему Вы клоните? Что тесты могут быть несовершенны и иметь, например, дырявое покрытие? Так я с этим не спорю. Если я где-то был по Вашему мнению не прав — прошу указать.
Спасибо, буду знать что выбрать, если нелегкая занесет во фронтенд :)
и если не удастся пролоббировать использование Blazor %)«корректность реализации алгоритма сортировки» = соответствие написанного кода спецификации алгоритма. Т.е. что при одинаковом вводе и выполнении алгоритма "по бумажке" и в бинарном виде будет получен одинаковый результат. Именно это и проверяют тестами по определению, нет?
Верность алгоритма покажет только эксплуатация. (Ну или тестирование модели, но на этом этапе именно кода еще не написано ни строчки)
Корректность реализации алгоритма покажут тесты.
Корректность записи алгоритма покажет компилятор/анализатор.
Ну а лапшичность кода — это вообще не ошибка, а дело вкуса и стиля, принятого в команде. Может, там одни пастафарианцы работают, кто их знает?
Fixed. Выпадающие менюшки, картинки подгрузить, вызовы в апплеты прокинуть. Никакого рокет-сайнс, чисто чтобы с этой задачей могли справиться даже дизайнеры. Оттуда и решения вроде неявного приведения типов, которое иначе могло бы несчастных дизайнеров просто запугать (вы их еще вручную памятью управлять заставьте, ага!).
А для быстрой разработки подойдет абсолютно любой ЯВУ (вписывающийся в ограничения задачи, разумеется). При одном лишь условии — если он хорошо знаком. Потому что к новому инструменту, даже если он по итогу эффективнее, все равно нужно время на привыкание. А если нужно быстро — этого времени, как правило, нет.
Я не могу сравнивать TS и JS, за неимением достаточного опыта работы с обоими языками, но мои предпочтения все равно будут на стороне сильной статической типизации: тесты и ревью это хорошо, но цикл обратной связи получается уж больно длинным, да и опечатка все равно может через них прорваться и наломать дров. При этом компилятор и статический анализатор вполне могут отловить ее еще на стадии написания кода.
Грустно, когда такого рода… неприятности приключаются с кем-либо. А когда «кто-либо» — молодая девушка, почему-то становится еще грустнее.
Спасибо за статью, желаю Вашим близким терпения, а Вам — поддержки, здоровья и скорейшего восстановления. Статьи и открытые читалки — это конечно же хорошо, но и трейлы тоже скучают и очень ждут.