Здравствуйте, Shtole, Вы писали:
S>Если уж на то пошло, ошибки если и были, то из-за того, что джаваскрипт, услужливый дурак, конкатенировал '5' + 3. Потом я открыл для себя TIS Андрея, который плевался исключениями и заставлял пользоваться форматированием, и оказалось, что такое поведение совсем не обязательно.
S>Но потом маятник качнулся в обратную сторону. Типы и компиляцию потащили туда, где от них не было выхлопа в виде производительности. Естественно, это лично для меня выглядит немного реакционно. Шея у кого-то замёрзла без ошейника. MS пролетел со своим VBScript и начал поиск в JS фатального недостатка. Нашёл в виде отсутствующей типизации, ага.
У меня есть ограниченный опыт работы на разных языках. И в том числе — опыт освоения нового языка с нуля.
В прошлом году я осваивал flow9 и clojure.
Первый — строготипизированный язык с с-подобным синтаксисом, второй — динамически типизированный язык с лисп-подобным синтаксисом.
Оба — поверх JVM. Оба — функциональные.
Освоение flow9 — лёгкая и приятная прогулка: компилятор отлавливает множество ошибок, и когда ты сделал что-то не так, то он тычет тебя носом в конкретное место.
Для интерпретации сообщений об ошибках требуется некоторая практика, но сразу после того, как она пройдена, дальнейшее освоение идёт достаточно гладко.
Освоение clojure — боль и страдания. Интерпретатор прожёвывает любой мусор. При исполнении диагностика ошибок — никакая. Не помню наизусть конкретный формат сообщения об ошибке, но в основном — про невозможность привести object к вызываемому типу.
Конечно, возможно, что это мои личные когнтиивные неспособности. Тут на форуме с полгода назад кто-то из участников рассказывал, что clojure — это лучшее, что он встретил в жизни.
Но вот показательная штука: в университетском курсе flow9 используется в рамках курса "Методы трансляции и компиляции". Студенты на нём за семестр делают 15 лабораторных работ, первая из котрых — это превратить массив интов в строку и вывести её на экран, а последняя — написать верифицирующий компилятор с недетерминированного языка в самодельную виртуальную машину.
А clojure используется в универстетском курсе "Современные методы программирования", и за один семестр студенты делают на нём 3 (три) лабораторных, самая сложная из которых — это сделать многопотоковую блочную реализацию функции filter. Ну, правда, там ещё надо сделать курсовую на выбор — типа "реализовать свою версию ООП поверх clojure".
В любом случае несопоставимость сложностей прикладных задач видна невооружённым взглядом.
На борьбу с убогостью диагностики в динамике уходит очень много ресурсов. Не, я верю, что опытный разработчик постепенно обучается просто не делать таких ошибок, которые приводят к "невозможно привести object к вызываемому типу" — в конце концов, люди же и на перфоркартах программировали. Но на мой взгляд статика всё ещё даёт сто очков вперёд любой динамике.
Особенно в тех случаях, когда опыт разработчика значительно меньше сложности системы.
То есть — для начинающих, а также для всех в крупных корпоративных проектах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
BFE>>Вооот! А если делать по умному, то можно ошибиться в хитросплетениях рассуждений C>Это — не по умному. Как это выразил один писатель — "изощренность, которой пытаются заменить мастерство".
Давайте же, покажите мастерство!
C>Это даже и близко не похоже на тот баг, про который я написал.
Если вы знаете, что баг есть, то зачем его искать? Его надо исправлять. Если вы не знаете, что баг есть — тогда что делать? Как искать?
Здравствуйте, Codealot, Вы писали:
I>>Это общие слова. Не существует ни одного способа гарантировать обнаружение всех багов.
C>И не нужно. Достаточно только самые простые, для начала.
Снова общие слова. Что конкретно ты можешь предложить?
Здравствуйте, Codealot, Вы писали:
C>Вообще да. Неплохо бы просто не делать тупые баги.
Нет способа, который дает 100% гарантии.
C>Но если тебе хочется именно про тестирование, то для данного конкретного случая, сделать автоматическую проверку мертвых тэгов — то, что доктор прописал.
Где и как ты собираешься хранить список мертвых тегов?
Кто будет отвечать за полноту этого списка?
C>Это, кстати, и вебсайту мелкомягких тоже не помешало бы, потому что там постоянно много дохлых ссылок. Казалось бы — совершенно несложно в реализации, но нет.
На самом деле это болезнь любой более-менее большой и сложной системы. Микрософт здесь ничем не выделяется.
Здравствуйте, Shtole, Вы писали:
S>Потому, что вы или прописываете его первый раз сами, а потом уже копируете, либо в первый раз копируете из документации.
Падажжите. S>Даже при наличии автокомплита я делаю именно так, поэтому мне всё одно: что ошибки компиляции, что исключения при первом запуске — я ни того, ни другого обычно не вижу. S>Почему выдумываю? Ну, вы можете не считать это проблемами. А я считаю. Если описанная вами ситуация («Все уже давно разбито, при чем с самого начала. Кроме тебя ведь есть и другие люди, они тоже вносят изменения и ты про то ни слухом ни духом — проект то большой. Каким образом ты узнаешь, что именно возвращает каждый из компонентов?») возможна, с моей точки зрения УЖЕ всё плохо. И надо разбивать монолит на куски, изолировать, осознавать контракты, и начинать относиться к контрактам, как к контрактам.
Да, вот тут вопрос. Что значит "относиться к контрактам, как контрактам"? И вот про "копирование из документации" выше — откуда вообще взялась она, эта документация?
И кто занимается поддержанием документации up to date?
Почему вам не лень описать контракт в терминах многословного и путаного человеческого языка, но лень описать его же в терминах типов?
Почему вас раздражает то, что в статике мне показывают косяки документации — например, наличие недокументированного параметра? S>Потому, что это не издержки. Это самая суть разделения труда. Применительно к программированию.
Всё верно. Описал контракт типами — и получил одновременно автоматическую проверку соответствия контракту, и документацию, которая гарантированно соответствует реальному коду.
S>Не пишите за раз кода больше, чем можете проверить при запуске. S>И, главное — не считайте, что компиляция или тесты вам заменят запуск самим разработчиком.
Тесты — и есть запуск "самим разработчиком". Кроме примитивных hello world или веб-страничек уровня "landing page".
Вот я написал, скажем, простую библиотеку.
Что именно вы предлагаете "запускать"? Какое-то приложение-пример?
Я пробовал так делать — бессмысленная штука. Потому что я на приложении-примере проверил работоспособность кода вида a+b. Потом допилил поддержку умножения — и надо переделывать приложение на проверку a*b.
Потом что-то ещё допилил — а сложение отвалилось. Но я же "проверил при запуске" то, что я "написал за раз".
В итоге, написание тестов даёт ту самую "проверку при запуске", которая умеет ещё и делать регрессию. То есть проверять не только то, что новая фича заработала, но и то, что 5000 старых всё ещё живы.
S>И получится 100% само собой. А советы выше (я считаю) стоит соблюдать даже если у вас задействована компиляция в процессе разработки. I>>А как проверить те ветки, должны были вызываться, но не вызвались? Т.е. как убедиться, что ты ничего не сломал? S>Вы же разработчик! Вы знаете, что делать с вашей программой, чтобы зайти во все уголки. И это надо делать. Ни компиляция, ни тесты, ничего это не заменит. И вот тут мы, наконец, вернулись к теме, которую начал ТС. Некоторые места в продуктах одной известной компании выглядят так, как будто их авторы сами не запускали и не смотрели, что написали.
Не. Выглядит так, что авторы бросили писать тесты. Они как-то постепенно перешли от концепции "у нас нет выделенных тестеров — есть только software development engineering and testing professional" к концепции "нам всё протестируют пользователи". В итоге они регулярно в своих public API выкатывают обновления с блокер-багами, которые нашими автотестами отлавливаются в первые же несколько минут.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shtole, Вы писали:
S>Цикл разработки ускоряется тогда, когда вам не надо ничего компилировать — написал и... всё.
А тесты тоже не надо писать?
S>Нет такой необходимости. Вы всё это делаете с собой добровольно.
S>Ну вот о каких тестах вы говорите?
Юнит тесты, функциональные тесты. Например, тесты "парсер формата ххх выдает вот такую структуру получив вот такой вход"
S>Вот такие «лишние тесты», по-вашему, я пишу, чтобы гарантировать, что bar1, bar2 и так далее действительно есть в объекте? Нет. Я их не пишу. Я не сумасшедший.
Каким образом гарантировать покрытие всех путей выполнения, включая граничные кейсы и скрытое ветвление?
> Тесты я иногда пишу...
Вот это и есть препятствие
I>>А кто тебе даст гарантию, что поле-метод реально существуют? И что ты будешь делать, если автокомплит тебя обманул? Каким чудом ты узнаешь об этом, или хотя бы заподозришь?
S>Потому, что вы или прописываете его первый раз сами, а потом уже копируете, либо в первый раз копируете из документации.
То есть, тебе нужна та самая документация. А почему бы тогда не использовать ее и для стат анализа?
S>Даже при наличии автокомплита я делаю именно так, поэтому мне всё одно: что ошибки компиляции, что исключения при первом запуске — я ни того, ни другого обычно не вижу.
И понятно почему — ты тестируешь "один запуск" + "иногда пишу тесты"
S>Почему выдумываю? Ну, вы можете не считать это проблемами. А я считаю. Если описанная вами ситуация («Все уже давно разбито, при чем с самого начала. Кроме тебя ведь есть и другие люди, они тоже вносят изменения и ты про то ни слухом ни духом — проект то большой. Каким образом ты узнаешь, что именно возвращает каждый из компонентов?») возможна, с моей точки зрения УЖЕ всё плохо. И надо разбивать монолит на куски, изолировать, осознавать контракты, и начинать относиться к контрактам, как к контрактам.
Я уже сказал — на куски побили, изолировали. Каким образом удержать в голове все детали контрактов?
Проект то конский, одной метадаты сто типов.
I>>Вот-вот. Ты предлагаешь как раз больше изолированых модулей, да еще и АПИ каждого согласовывать со всеми сторонами. И почему то эти издержки тебя не пугают.
S>Потому, что это не издержки. Это самая суть разделения труда. Применительно к программированию.
Это издержки, тк расход времени ненулевой.
I>>И это не даёт вобщем никаких существенных гарантий.
S>А вы не пишите код, который не используется.
Приложение довольно большое, его прокликать может тестер примерно за день, так понятно?
S>Не пишите за раз кода больше, чем можете проверить при запуске.
А заказчику сказать, что бы проект свернул?
S>И, главное — не считайте, что компиляция или тесты вам заменят запуск самим разработчиком.
У меня приложуха запускается раз сто во время тестов.
S>Вы же разработчик! Вы знаете, что делать с вашей программой, чтобы зайти во все уголки.
Именно. Тестер прокликает за день. А авто-тесты ща полчаса, идея понятна?
Здравствуйте, Ikemefula, Вы писали:
I>Где и как ты собираешься хранить список мертвых тегов? I>Кто будет отвечать за полноту этого списка?
Ты бредишь. Не надо его хранить, надо его показать.
I>На самом деле это болезнь любой более-менее большой и сложной системы. Микрософт здесь ничем не выделяется.
Ты на вопрос не ответил. Что мешает сделать простенький краулер, чтобы искать мертвые ссылки на вебсайте?
Здравствуйте, B0FEE664, Вы писали:
BFE>Автор, например, часто не замечает проблем приложения, которое он написал. Есть такой психологический эффект связанный, видимо, с патернами использования приложения. Поэтому и вопрос: кто тестировал?
Здравствуйте, Codealot, Вы писали:
I>>Где и как ты собираешься хранить список мертвых тегов? I>>Кто будет отвечать за полноту этого списка?
C>Ты бредишь. Не надо его хранить, надо его показать.
И как же показывать, если нигде не хранить?
Каким образом протестировать что мертвые теги нигде не используются?
I>>На самом деле это болезнь любой более-менее большой и сложной системы. Микрософт здесь ничем не выделяется. C>Ты на вопрос не ответил. Что мешает сделать простенький краулер, чтобы искать мертвые ссылки на вебсайте?
Не вижу в этом большого смысла. Намного чаще встречается проблема, когда ссылки ведут не туда, или ведут туда, но не содержат, того что надо.
Краулер здесь ничем не поможет.
Такое положение является следствием разделения документации-суппорта от разработки самой системы, разлиные подразделения, огромного размера, состоят из разных команд.
Здравствуйте, Codealot, Вы писали:
I>>Снова общие слова. Что конкретно ты можешь предложить?
C>Думать головой (если она есть). C>Ели фичу решили удалить, то проверить, что ничего не забыли подчистить — первое, чем должны были заняться тестеры.
А здесь надо вспомнить, что тесты автоматические. Тебе надо написать тест, который проверит, что каждая мертвая фича не всплывает ни в этом, ни в следующих релизах.
Здравствуйте, Sinclair, Вы писали:
S>>Потому, что вы или прописываете его первый раз сами, а потом уже копируете, либо в первый раз копируете из документации. S>Падажжите. S>>Даже при наличии автокомплита я делаю именно так, поэтому мне всё одно: что ошибки компиляции, что исключения при первом запуске — я ни того, ни другого обычно не вижу. S>>Почему выдумываю? Ну, вы можете не считать это проблемами. А я считаю. Если описанная вами ситуация («Все уже давно разбито, при чем с самого начала. Кроме тебя ведь есть и другие люди, они тоже вносят изменения и ты про то ни слухом ни духом — проект то большой. Каким образом ты узнаешь, что именно возвращает каждый из компонентов?») возможна, с моей точки зрения УЖЕ всё плохо. И надо разбивать монолит на куски, изолировать, осознавать контракты, и начинать относиться к контрактам, как к контрактам.
S>Да, вот тут вопрос. Что значит "относиться к контрактам, как контрактам"?
На этот и на следующий вопрос я отвечу в одном месте — ниже.
S>И вот про "копирование из документации" выше — откуда вообще взялась она, эта документация? S>И кто занимается поддержанием документации up to date?
А это важно? Для понимания примера? В каждом примере есть существенная для обсуждения часть и есть не относящиеся к делу детали. Я зря, конечно, написал «из документации» — сразу начались вопросы, что это за документация, да откуда она взялась и т.д. На самом деле, имелось в виду, что вы знаете — а откуда неважно. Но если для вас важно, я приведу более конкретный пример.
Допустим, вам говорят, что в такой-то ветке Вася запилил новую версию своего модуля, который используется вашим модулем. Вам предлагается в этой же ветке привести свой модуль в соответствие и смёрджить в тестировочную ветку. Вы берёте эту ветку, и собираете свой модуль. Он не собирается, а компилятор говорит, что метод Foo() не найден. Далее вы делаете одну из трёх вещей: смотрите в Васин IDL, или в tlb, которая из него скомпилировалась, или прямо в автогенерённый код wrapper'а и видите, что вместо Foo() теперь Bar(). Вы заменяете свои вызовы Foo() на Bar(). Теперь всё компилируется, но при запуске падает с исключением, что Bar() не найден.
Я написал, мол, смотрите в документацию. К чёрту документацию. Вы просто смотрите в код диспетчеризации, и видите, что там не Bar(), а Bas(). А теперь начинается самое интересное. Пока вы опираетесь на автогенерацию wrapper'а и компиляцию для проверок, компилятор вам буквально НЕ ДАСТ вызвать Bas(). Пока вы не приведёте внешнюю схему в соответствие. Или не попросите об этом Васю. Откуда может взяться рассинхрон — это отдельный вопрос. Например, у Васи есть 2 IDL, и обе правильные. Одна внутренняя, из которой он генерирует заготовки актуального кода, а вторая (с меньшим числом интерфейсов) для использования. Это не секретный API, security by obscurity, а просто способ указать, что в конкретные части лезть не надо.
Теперь, что значит «относиться к контрактам, как контрактам» — меняя Foo() на Bar()/Bas() Вася должен или обсудить это с вами (может, вы вообще скажете, что это плохая идея), или хотя бы письмо написать. Из письма вы хотя бы будете знать, как правильно — Bas() или Bar(). Но Вася совершенно не обязан обсуждать каждое своё изменение, в т.ч. детали реализации. Понимание разницы между этими двумя случаями я называю «осознавать контракты», а исполнение обязанности обсудить/проинформировать — «относиться к контрактам, как контрактам».
Теперь, возникает искушение — нахрен выкинуть IDL да и COM в целом, вернуться к монолитной схеме, пилить всё на одном языке. Тогда Вася сможет просто нажать Refactor -> Rename и заменить Foo() на Ba?() везде, в т.ч. в коде модуля, который пишете вы. Но при этом вас исключили из процесса принятия решения, а это решение могло быть важным для вашего модуля и всей программы в целом. Тем более, изменения могут быть более сильные, чем простое переименование. Если с вами обсуждали — вы могли донести своё (не)согласие до того, как код начал меняться. Если вам хотя бы письмо пришло, вы можете выразить несогласие в ответе, и все, кто в CC, включая техлида, будут это видеть. Но если нет ни того, ни другого — вы можете только одно: начать критиковать уже написанный код и требовать изменить. Или плюнуть и забить. Фактически такой проект становится неуправляемым, а решения принимаются односторонне, что снижает количество правильных решений.
Когда менежер осознаёт, какая творится жопа в результате разброда и шатаний, начинаются отчаянные попытки исправить ситуацию. Обычно они принимают форму внедрения code review. В результате проектирование с учётом интересов всех модулей (криво сформулировано, но суть вы поняли) всё-таки появляется в процессе, но происходит оно уже ПОСЛЕ написания. Хорошего в этом мало, поскольку на code review лучше находить исключительно ошибки имплементации.
S>>И, главное — не считайте, что компиляция или тесты вам заменят запуск самим разработчиком. S>Тесты — и есть запуск "самим разработчиком". Кроме примитивных hello world или веб-страничек уровня "landing page".
Ну это уже оторванная от жизни теория как раз.
Вот прям из жизни история вам. Один такой «Вася» (зовут его по-другому и в жизни мы с ним друзья, он милый коммуникабельный человек) долго писал свой модуль, тестируя его на своём тестовом клиенте. И я очень долго уговаривал его отказаться от этой практики, а перейти к запуску программы в целом и тестам через вызовы функционала его модуля моим модулем. Как только уговорил, у нас число ошибок по программе в целом резко скакнуло вниз. Это медицинский факт, извините.
Здравствуйте, Ikemefula, Вы писали:
S>>Цикл разработки ускоряется тогда, когда вам не надо ничего компилировать — написал и... всё. I>А тесты тоже не надо писать?
. Сначала вы согласились с (неким неявным) утверждением на эту тему, а теперь задаёте вопросы.
S>>Нет такой необходимости. Вы всё это делаете с собой добровольно. S>>Ну вот о каких тестах вы говорите? I>Юнит тесты, функциональные тесты. Например, тесты "парсер формата ххх выдает вот такую структуру получив вот такой вход"
Вы уже начали передёргивать и дальнейшее — пустая трата моего (и вашего) времени. Вы писали о каких-то дополнительных тестах, в которых появляется необходимость из-за отказа от компиляции. Я попросил пример — а это оказались «Юнит тесты, функциональные тесты». С наличием/отсутствием компиляции они никак не связаны, поэтому мой вопрос в силе. Хотя это, на самом деле, с моей стороны не вопрос, а утверждение, что нет никаких таких специальных тестов, необходимость в которых появляется при отказе от компиляции.
Здравствуйте, Sinclair, Вы писали:
S>На борьбу с убогостью диагностики в динамике уходит очень много ресурсов. Не, я верю, что опытный разработчик постепенно обучается просто не делать таких ошибок, которые приводят к "невозможно привести object к вызываемому типу" — в конце концов, люди же и на перфоркартах программировали. Но на мой взгляд статика всё ещё даёт сто очков вперёд любой динамике.
Я примерно так же и думаю. Только сделаю два замечания.
Во-первых, «опытный» звучит как «крутой», а мне бы не хотелось таких коннотаций. Никто не говорит: «Я настолько крут, что мне и компилятор не нужен». В реальности речь идёт о компромиссах и разменах, о разных стратегиях, и они могут быть «правильные» каждая по-своему.
Во-вторых, «сто очков» подразумевает какую-то метрику. (Весь разговор тут крутится вокруг числа багов и я подозреваю, что это она и есть). А их много разных, плюс есть вещи, которые не померить — то же удобство, например. А оно, как показало всё это обсуждение, как всегда — в высшей степени субъективно.
Здравствуйте, Sinclair, Вы писали:
S>Да, вот тут вопрос. Что значит "относиться к контрактам, как контрактам"? И вот про "копирование из документации" выше — откуда вообще взялась она, эта документация? S>И кто занимается поддержанием документации up to date?
Возможно, я не правильно понял ваш про документацию. Если вы НЕ про пример, когда компилятор + внешняя схема приводят к ошибкам — извините, пожалуйста. Уточните и я отвечу.
Здравствуйте, Ikemefula, Вы писали:
I>А здесь надо вспомнить, что тесты автоматические. Тебе надо написать тест, который проверит, что каждая мертвая фича не всплывает ни в этом, ни в следующих релизах.
А это кто сказал, что должны быть только автоматические тесты? Я — нет.
Здравствуйте, Ikemefula, Вы писали:
I> И как же показывать, если нигде не хранить?
Что-то ты уже совсем полную пургу гонишь. Какая вообще разница, что и где хранится?
I>Каким образом протестировать что мертвые теги нигде не используются?
Детали целиком зависят от реализации самого гуя, и никакой роли не играют.
I>Не вижу в этом большого смысла. Намного чаще встречается проблема, когда ссылки ведут не туда, или ведут туда, но не содержат, того что надо. I>Краулер здесь ничем не поможет.
Ты не юли. Мертвых ссылок тоже хватает. Решить проблему их обнаружения очень легко, но этого никто не делает.
I>Такое положение является следствием разделения документации-суппорта от разработки самой системы, разлиные подразделения, огромного размера, состоят из разных команд.
В переводе на инженерный язык — просто бардак. Все с выпученными глазами бегают с одного совещания на другое, и никто ни за что не отвечает. Точнее — все валят ответственность друг на друга. Музыкальные стулья в IT-варианте.
