Да, монотонность работы часто наблюдается пока идет описание грамматики и начальное её покрытие реализацией парсера\компилятора\интерпретатора\генератора\….
Типа, как в этом дневнике — скукотища: вот первая 1000 строк, вот вторая… ага, вот свет в конце тоннеля уже виден… и, наконец, 100% покрытие спецификации языка.
Но, когда такая рутинная работа завершена и наступает фаза полномасштабных испытаний, неожиданно начинают выявляться «чудеса-чудесные».
И вроде грамматику описал в точном соответствии со спецификацией языка и кусочки реализации четко подгонял, чтобы они правильно отрабатывали в любом порядке для любого исходного текста на входе…
но, нет… и в описании грамматики и в реализации начинают проявляться самые неожиданные блохи…
и вот тут начинается настоящее творчество…
А, реализация хорошей обработки некорректного исходного текста это вообще всегда очень нетривиальная задача.
Разработчику попроще, если разрабатывается реализация для какго-нибудь «известного и стабильного» языка, а если ещё и язык новый, то точно о монотонности и не вспомните даже на начальном этапе. Особенно на фоне «живой» спецификации языка.
Подобные попытки предпринимались неоднократно и многими. Особенно на ранних стадиях развития виртуальных сред исполнения. Вот только один пример для Java среды: https://gcc.gnu.org/java/
Однако приоритет развития был всё-таки отдан «компиляции на лету» (англ. Just-in-time (JIT) compilation).
Статья — хороший бочонок меда начинающим для вхождения в тему.
Ложка дёгтя — слова «линковщик»\«линковка» вместо более традиционных «компоновщик»\«компоновка».
Такое особенно вредно для начинающих — в комментариях уже цитируют…
FYI Критерии качества, связанные с Section 508 [1], могут оказаться весьма полезными даже, если к Веб-сайту и не предъявляются повышенные требования для обеспечения возможности взаимодействия с людьми с ограниченными возможностями. Например, отдельные критерии из этого списка [2] могут весьма положительно повлиять на качество большинства Веб-сайтов.
Цветочки на рубашке звёздного ученого мужа не интересны — они никак не влияют на производительность систем. Константа завернута в класс для получения дополнительных методов работы с ней. Ссылка в переменной на инстанцию такого класса также будет также иметь характер константы. Создание\удаление инстанций классов это дорогостоящая операция. Сборщик мусора потратит дополнительно и время и память на такую инстанцию, что однозначно снизит производительность. Метод класса, где происходит создание, может вызываться очень многократно. Для большой развивающейся системы на этапе проектирования класса мы чаще всего даже не знаем сколько раз такой метод будет вызван и сколько временных инстанций будет создаваться. Конечно, можно пользоваться только вкусом и о проблеме с производительностью, связанной с порождением кучи временных инстанций, «вдруг» узнать перед сдачей проекта в процессе профилирования. Но, можно попробовать и избегать подобных неожиданностей, выбирая несколько иной вкус и стиль.
Естественно, все эти вкусы и стили обязаны выбираться не из личных предпочтений, а исключительно на основе технической целесообразности.
Всех с Новым годом и желаю Вам делать системы с достаточной производительностью, чтобы ваши пользователи никогда не вспоминали про тормоза!
Конечно, моя претензия к примеру будет некорректной, если найдется хотя бы один случай, когда переменные в коде всё-таки изменят свои значения на отличные от инициализированных. Моей фантазии сейчас не хватило, что бы изобрести такой корректный случай.
Кроме того, если эти «переменные» будут признаны константами, то правильно их объявление делать на уровне класса, добавляя модификаторы final static.
Вряд ли истинные мотивы автора будут нам известны. Диапазон мотивов велик от бездумного творчества со скуки, или от бесшабашного бахвальства и до выверенного прагматизма. Не удивлюсь, если через несколько лет он и сам не сможет объяснить почему он именно в таком виде опубликовал, когда его будут награждать юбилейной медалью за участие в той кампании… А после, от избытка чувств, он напишет очередной перл.
Может главный посыл статьи не в том, что он что-то написал, а в том, что он награжден начальниками, чьи инструкции он нарушил?
И это первая статья из цикла по карьерному росту — дальше: «Как я стал начальником», «Как я награждал...»,…?
Увольнение принимаю. Вы не первый, кто говорит мне, что я своими словами заставляю работать.
У вас сейчас есть всё, что бы самому получить ответы на свои вопросы. Уверяю, это не сложно. Надо только абстрагироваться от имеющихся у вас в голове догм и шаблонов (не важно даже какие они!). Открываете главу «4. Considerations for producing a good SRS» и формально\пунктуально примеряете эти положения на свои утверждения\требования к Системе.
Какая дуэль?
Утром на рассвете… как обычно. :-)
Для подготовки схем целая ночь впереди — достаточно же :-)
взаимоувязанной картины профессий из этих стандартов нет.
И Вы ещё спрашиваете про мою тоску-печаль?
А у вас-то у самих — экспертов — разработчиков стандарта какое впечатление после такой работы?
Неужели в Вашей команде не нашлось ни одной значимой фигуры, которая объяснила бы министрам «какая хрень у них творится»?
«Мыши кололись плакали, но продолжали есть кактусы»?
мы не успели потестировать стандарт
Потестировать стандарты в каких-то приёмочных сценариях
«Ну, Вы, блин даёте!» — сказал генерал из особенностей разработки национальных стандартов.
Можно и дальше обсуждать QA процессы для разработки стандартов, ответственность руководителей за качество в рамках мультисерийного стандарта ISO 90XаXа…
Нет уж, увольте. Вы сами назвались профессионалом в этом. Так что, сами, сами, сами, пожалуйста.
«Главная задача высшей школы это научить студентов (от лат. studens — усердно работающий, занимающийся, интересующийся) к самостоятельному обучению и обретению новых навыков»
из материалов XVI съезда КПСС.
Зачем Вам пользоваться опытом неизвестно Виктора.
Возьмите лучше авторитетный источник, ну, хотя бы какой-нибудь IEEE Recommended Practice for Software Requirements Specifications. Он старый и добрый — он поможет. Примените его положения к своим требованиям и поймите почему оба(!) ваших варианта не «good».
А если интересно моё мнение, то у меня не хватило пальцев на руках, считая «недочеты» к этим двум требованиям.
Уточню, у меня на руках 10 пальцев.
Разумеется я это взял на основе сакрального знания о потребности государства иметь систему стандартизации, разработка которой без использования системных подходов… дает наглядный результат.
И печаль моя от этого результата.
У Вас есть шанс немного развеять эту печаль, если сможете представить на суд публики всего две диаграммы:
Эталонную иерархическую организационную диаграмму, в которой присутствуют позиции всех(!) без исключения вариаций «стандартных» ИТ менеджеров.
Эталонный технологический IT процесс, в который вовлечены эти менеджеры
И строго, как на дуэле: «Выбор достойных графических языков для описания за вами...»
С такой «линейкой» можно будет тогда поговорить и о качестве стандарта, и о его применимости в быту…
И не хай, что сейчас висит этот стандарт в вакууме… промеряем, взвесим и оценим…
Не думаю, что это должно вызвать серьёзное напряжение… Ведь, во «внутренних отчётных документах МинТруда» наверняка есть какой-нибудь «Отчет об испытаниях стандарта». Так же-ж?
Однако, если применения этого стандарта «в быту» не предусматривается, то не надо тратить на это время…
Десятилетиями на сотнях примерах убеждаюсь в справедливости фразы, которую говорил выдающийся человек — профессор Петр Петрович Гель своим студентам на первой же лекции по конструированию:
«К сожалению, научить разрабатывать нельзя! Это либо дано, либо...».
Либо жизнь заставляет Вас готовить специалистов по разработке требований из того, что есть.
Попытка использовать шаблоны, которые заранее разработаны «людьми со способностями» это хорошая попытка.
Но, на примере Макета для вашего стандарта и Методических рекомендаций к нему, мы видим совсем иную ситуацию.
Надеюсь ваши шаблоны содержат раздел «Область применения» или там так же, как со «Списком литературы» в стандарте?
И ваша первая тема на тренинге это «Шаблоны и правила выбора подходящего», а вторая тема «Что делать, если подходящего шаблона нет?»
Эх, жаль Peter Coad «забил» на свой бизнес — у него и его команды изумительно получалось жонглировать всякими шаблонами. Мир много потерял от этого. Надеюсь, по роду своей деятельности Вы отслеживаете все современные достижения в этой области… Судя по Вашим словам выше, свято место пока пусто. Или нет?
К стати, Вы своими словами только что подтвердили обязательность наличия в стандартах, учебных пособиях и т.д. раздела «Определения».
Попробуйте дать определение для термина «Качество продукта» (или найдите готовое в стандартах — только не в учебниках и популярных книжках — я там такой бред встречал — ужас, наши стандарты, к стати, тоже очень «хромают» в части терминологии) для лучшего собственного понимания, сравните несколько различных определений для приближения к «математическому ожиданию и уменьшения дисперсии». Далее определите коэффициенты корреляции для каждого требования при вычислении целевой функции качества.
При этом ужаснитесь: «Ой, все(!) > 0. Что же делать!?».
Я доходчиво объяснил?
Все те определения, которые известны мне, а также мой личный скромный опыт, позволяют заявить, что ваша методика, обособляющая требования к качеству, ошибочна. Причем, цена этой ошибки будет очень-очень высока — Вы её распространяете, обучая людей и разрабатывая стандарты.
Но, это так, замечание в сторону. Я буду рад, если это замечание принесет пользу. Но, мне совершенно не хочется разворачивать на поле Хабрахабр «Битву Водогреев» по данному вопросу — не тот формат. К тому же, моё имя уже по любому определяет победителя :-)
Давайте, добьемся вставки в стандарт одной ссылки… на эту переписку в Хабрахабр и вопрос будет решён —
Хабрахабр войдет в федеральную систему стандартизации :-)
Да, монотонность работы часто наблюдается пока идет описание грамматики и начальное её покрытие реализацией парсера\компилятора\интерпретатора\генератора\….
Типа, как в этом дневнике — скукотища: вот первая 1000 строк, вот вторая… ага, вот свет в конце тоннеля уже виден… и, наконец, 100% покрытие спецификации языка.
Но, когда такая рутинная работа завершена и наступает фаза полномасштабных испытаний, неожиданно начинают выявляться «чудеса-чудесные».
И вроде грамматику описал в точном соответствии со спецификацией языка и кусочки реализации четко подгонял, чтобы они правильно отрабатывали в любом порядке для любого исходного текста на входе…
но, нет… и в описании грамматики и в реализации начинают проявляться самые неожиданные блохи…
и вот тут начинается настоящее творчество…
А, реализация хорошей обработки некорректного исходного текста это вообще всегда очень нетривиальная задача.
Разработчику попроще, если разрабатывается реализация для какго-нибудь «известного и стабильного» языка, а если ещё и язык новый, то точно о монотонности и не вспомните даже на начальном этапе. Особенно на фоне «живой» спецификации языка.
Подобные попытки предпринимались неоднократно и многими. Особенно на ранних стадиях развития виртуальных сред исполнения. Вот только один пример для Java среды: https://gcc.gnu.org/java/
Однако приоритет развития был всё-таки отдан «компиляции на лету» (англ. Just-in-time (JIT) compilation).
Ложка дёгтя — слова «линковщик»\«линковка» вместо более традиционных «компоновщик»\«компоновка».
Такое особенно вредно для начинающих — в комментариях уже цитируют…
[1] en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973
[2] webaim.org/standards/508/checklist
«Рисунок 7. На корте появился хоккеист.»
это же идея новой игры «Теннис на льду»)
Естественно, все эти вкусы и стили обязаны выбираться не из личных предпочтений, а исключительно на основе технической целесообразности.
Всех с Новым годом и желаю Вам делать системы с достаточной производительностью, чтобы ваши пользователи никогда не вспоминали про тормоза!
У меня возникло подозрение, что не соблюдается выполнение соглашения Java для имен в примере со строками
DoubleHolder nan = new DoubleHolder(Double.NaN);
DoubleHolder zero = new DoubleHolder(0.0);
Ведь «переменные» nan и zero в левых частях обоих выражений это на самом деле константы, а, следовательно, их имена должны быть написаны буквами в верхнем регистре.
См. www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099.html#367
Конечно, моя претензия к примеру будет некорректной, если найдется хотя бы один случай, когда переменные в коде всё-таки изменят свои значения на отличные от инициализированных. Моей фантазии сейчас не хватило, что бы изобрести такой корректный случай.
Кроме того, если эти «переменные» будут признаны константами, то правильно их объявление делать на уровне класса, добавляя модификаторы final static.
И это первая статья из цикла по карьерному росту — дальше: «Как я стал начальником», «Как я награждал...»,…?
У вас сейчас есть всё, что бы самому получить ответы на свои вопросы. Уверяю, это не сложно. Надо только абстрагироваться от имеющихся у вас в голове догм и шаблонов (не важно даже какие они!). Открываете главу «4. Considerations for producing a good SRS» и формально\пунктуально примеряете эти положения на свои утверждения\требования к Системе.
Утром на рассвете… как обычно. :-)
Для подготовки схем целая ночь впереди — достаточно же :-)
взаимоувязанной картины профессий из этих стандартов нет.
И Вы ещё спрашиваете про мою тоску-печаль?
А у вас-то у самих — экспертов — разработчиков стандарта какое впечатление после такой работы?
Неужели в Вашей команде не нашлось ни одной значимой фигуры, которая объяснила бы министрам «какая хрень у них творится»?
«Мыши кололись плакали, но продолжали есть кактусы»?
мы не успели потестировать стандарт
Потестировать стандарты в каких-то приёмочных сценариях
«Ну, Вы, блин даёте!» — сказал генерал из особенностей разработки национальных стандартов.
Можно и дальше обсуждать QA процессы для разработки стандартов, ответственность руководителей за качество в рамках мультисерийного стандарта ISO 90XаXа…
«Главная задача высшей школы это научить студентов (от лат. studens — усердно работающий, занимающийся, интересующийся) к самостоятельному обучению и обретению новых навыков»
из материалов XVI съезда КПСС.
Возьмите лучше авторитетный источник, ну, хотя бы какой-нибудь IEEE Recommended Practice for Software Requirements Specifications. Он старый и добрый — он поможет. Примените его положения к своим требованиям и поймите почему оба(!) ваших варианта не «good».
А если интересно моё мнение, то у меня не хватило пальцев на руках, считая «недочеты» к этим двум требованиям.
Уточню, у меня на руках 10 пальцев.
И печаль моя от этого результата.
У Вас есть шанс немного развеять эту печаль, если сможете представить на суд публики всего две диаграммы:
Эталонную иерархическую организационную диаграмму, в которой присутствуют позиции всех(!) без исключения вариаций «стандартных» ИТ менеджеров.
Эталонный технологический IT процесс, в который вовлечены эти менеджеры
И строго, как на дуэле: «Выбор достойных графических языков для описания за вами...»
С такой «линейкой» можно будет тогда поговорить и о качестве стандарта, и о его применимости в быту…
И не хай, что сейчас висит этот стандарт в вакууме… промеряем, взвесим и оценим…
Не думаю, что это должно вызвать серьёзное напряжение… Ведь, во «внутренних отчётных документах МинТруда» наверняка есть какой-нибудь «Отчет об испытаниях стандарта». Так же-ж?
Однако, если применения этого стандарта «в быту» не предусматривается, то не надо тратить на это время…
«К сожалению, научить разрабатывать нельзя! Это либо дано, либо...».
Либо жизнь заставляет Вас готовить специалистов по разработке требований из того, что есть.
Попытка использовать шаблоны, которые заранее разработаны «людьми со способностями» это хорошая попытка.
Но, на примере Макета для вашего стандарта и Методических рекомендаций к нему, мы видим совсем иную ситуацию.
Надеюсь ваши шаблоны содержат раздел «Область применения» или там так же, как со «Списком литературы» в стандарте?
И ваша первая тема на тренинге это «Шаблоны и правила выбора подходящего», а вторая тема «Что делать, если подходящего шаблона нет?»
Эх, жаль Peter Coad «забил» на свой бизнес — у него и его команды изумительно получалось жонглировать всякими шаблонами. Мир много потерял от этого. Надеюсь, по роду своей деятельности Вы отслеживаете все современные достижения в этой области… Судя по Вашим словам выше, свято место пока пусто. Или нет?
К стати, Вы своими словами только что подтвердили обязательность наличия в стандартах, учебных пособиях и т.д. раздела «Определения».
Попробуйте дать определение для термина «Качество продукта» (или найдите готовое в стандартах — только не в учебниках и популярных книжках — я там такой бред встречал — ужас, наши стандарты, к стати, тоже очень «хромают» в части терминологии) для лучшего собственного понимания, сравните несколько различных определений для приближения к «математическому ожиданию и уменьшения дисперсии». Далее определите коэффициенты корреляции для каждого требования при вычислении целевой функции качества.
При этом ужаснитесь: «Ой, все(!) > 0. Что же делать!?».
Я доходчиво объяснил?
Все те определения, которые известны мне, а также мой личный скромный опыт, позволяют заявить, что ваша методика, обособляющая требования к качеству, ошибочна. Причем, цена этой ошибки будет очень-очень высока — Вы её распространяете, обучая людей и разрабатывая стандарты.
Но, это так, замечание в сторону. Я буду рад, если это замечание принесет пользу. Но, мне совершенно не хочется разворачивать на поле Хабрахабр «Битву Водогреев» по данному вопросу — не тот формат. К тому же, моё имя уже по любому определяет победителя :-)
Хабрахабр войдет в федеральную систему стандартизации :-)