В данном случае имелись ввиду не стандарты кодирования, для контроля которых, кстати говоря, и инспектирование не нужно, так как с этим отлично справляются автоматизированные средства в момент сборки.
Имелась ввиду вкусовщина в плане способа решения задачи (архитектура, разбиение ответственности, использованный алгоритмы, паттерны и пр.). Тут могут быть очень важные дефекты, которые обязательно нужно править, но должны быть аргументы «за» это кроме «мне декоратор нравится больше, чем стратегия»
> Но определение того, выполняет ли код поставленную задачу, это прерогатива отдела тестирования, а не инспектирования.
Во-первых тестирование и инспектирование решают одну и туже задачу: ищут дефекты. При этом инспектирование позволяет обнаружить такие дефекты, которые тестирование не факт, что и найдет.
Во-вторых, задачи бывают в том числе технические (например, рефакторинг). Тестировщикам тут вообще делать нечего.
У меня, например, водонепроницаемый Motorola Defy. Чтобы его зарядить приходится каждый раз резиновую заглушку выковыривать. А тут бы не пришлось — бросил и все.
Такой подход понятен только в контексте марксистско-гегелевского мышления, которое предполагает, что исторические события развиваются определенным и заранее известным образом. Поэтому любой подход, который не соответствует истории, в равной степени и не соответствует истине; он столь же неверен, сколь неверно решение математической задачи. А наши представления, напротив, обычно поддерживают компромиссы… мысль, что у каждого вопроса есть две стороны, трудно воспринимается теми, кто не знаком с этой концепцией и ее влиянием»
Ага, этот подход отлично отрекламирован в знаменитой «марксистско-гегелевской» книге «Атлант расправил плечи», которая, по утревждению самих американцев, находится на втором месте после библии по влиянию на их умы :)
Какая разница между циферками в базе данных и бумажками? Так что понять этого люди не могут уже много тысяч лет: с момента изобретения денег и использования их вместо бартера.
Рантайм .Net используется только для классов, объявленных специальным образом, весь код написанный на синтаксисе классического С++ компилируется так же, как и в обычном С++ компиляторе, и все плюшки для него недоступны.
Да. Но речь в данном случае идет о managed части C++\CLI
Создание «рантайм для C++, в котором могли бы существовать перечисленные фичи» для обычных С++ классов, с обеспечением обратной совместимости, по моему скромному мнению — задача очень сложно решаемая.
Конечно, обратной совместимостью придется пожертвовать. Но и хрен с ней, было бы о чем жалеть ;)
Этот пример показывает, всего лишь, что c помощью определенного вмешательства в язык, можно сделать для него компилятор в .Net
То есть на выходе мы имеем компилятор С++ с поддержкой всех фич, в качестве рантайма у которого в данном случае используется .NET
Неужели только MS под силу создать рантайм для C++, в котором могли бы существовать перечисленные фичи?
Да, часть фич относятся скорее к рантайму (Reflection например). Но пример C++\CLI показывает, что и для C++ можно сделать рантайм, в котором будут работать такие фичи
Тут надо объяснить, что Reflection, сборка мусора и остальные плюшки доступны только для managed классов (для тех, кто не знает в C++ CLI есть два типа классов — первый, который компилируется в MSIL и второй — который компилируется в нативный код) и традиционные возможности C++ расширяют слабо. Если вы пишете неуправляемый класс, то получаете не больше, чем в любом другом компиляторе С++.
Это не важно. Важно то, что все эти фишки в языке реализованы. А что получается после компиляции: MSIL или native к непосредственно языку отношения имеет слабое. Это скорее имеет отношение к рантайму.
Тут надо объяснить, что Reflection, сборка мусора и остальные плюшки доступны только для managed классов (для тех, кто не знает в C++ CLI есть два типа классов — первый, который компилируется в MSIL и второй — который компилируется в нативный код) и традиционные возможности C++ расширяют слабо. Если вы пишете неуправляемый класс, то получаете не больше, чем в любом другом компиляторе С++.
Это не важно. Важно то, что все эти фишки в языке реализованы. А что получается после компиляции: MSIL или native к непосредственно языку отношения имеет слабое.
>Автомобили более безопасны, чем мотоциклы, это факт.
>А от попадания ядерной бомбы автомобиль защитит? Или от падения со 100 метрового обрыва? Нет! Значит автомобили не безпаснее мотоциклов! От всего вышеперечисленного спасет только радио «Радонеж»
Кроме оплаты первоначальных лицензий, необходимо оплачивать постоянные апгрейды системы, обучение сотрудников, устранение неполадок.
А что, в случае с SaaS не надо обучать сотрудников?
Одним из огромных преимуществ облачных SaaS-решений в любой области является как раз легкость их обновления и совершенствования. Ядро системы, расположенное на удаленном сервере, постоянно обновляется разработчиками, и все пользователи мгновенно получают доступ ко всем новым возможностям.
… и пользователи в самый неподходящий момент (за две недели до Нового Года) получают новую неоттестированную ими версию софта с новыми багами
Не нужно устанавливать патчи и обновления на свой компьютер, ждать выхода новых версий программ — пользователи SaaS-платформы всегда пользуются самой последней версией продукта.
Многие (как бы не все) крупные компании предпочитают крайне консервативно относиться к новым версиям софта. Сомневаюсь, что в случае с SaaS их консерватизм куда-то денется.
В то же время SaaS-решение размещается на удаленном защищенном сервере, и доступа к исходным кодам нет ни у кого из пользователей, поэтому вероятность взлома на порядок ниже. Пользователи имеют доступ только к терминалу, и им нет необходимости размещать какой бы то ни было код на своем компьютере.
Имелась ввиду вкусовщина в плане способа решения задачи (архитектура, разбиение ответственности, использованный алгоритмы, паттерны и пр.). Тут могут быть очень важные дефекты, которые обязательно нужно править, но должны быть аргументы «за» это кроме «мне декоратор нравится больше, чем стратегия»
Во-первых тестирование и инспектирование решают одну и туже задачу: ищут дефекты. При этом инспектирование позволяет обнаружить такие дефекты, которые тестирование не факт, что и найдет.
Во-вторых, задачи бывают в том числе технические (например, рефакторинг). Тестировщикам тут вообще делать нечего.
Ага, этот подход отлично отрекламирован в знаменитой «марксистско-гегелевской» книге «Атлант расправил плечи», которая, по утревждению самих американцев, находится на втором месте после библии по влиянию на их умы :)
Главное, что руль с педалями покупать не надо будет.
Да. Но речь в данном случае идет о managed части C++\CLI
Конечно, обратной совместимостью придется пожертвовать. Но и хрен с ней, было бы о чем жалеть ;)
То есть на выходе мы имеем компилятор С++ с поддержкой всех фич, в качестве рантайма у которого в данном случае используется .NET
Неужели только MS под силу создать рантайм для C++, в котором могли бы существовать перечисленные фичи?
Это не важно. Важно то, что все эти фишки в языке реализованы. А что получается после компиляции: MSIL или native к непосредственно языку отношения имеет слабое. Это скорее имеет отношение к рантайму.
Это не важно. Важно то, что все эти фишки в языке реализованы. А что получается после компиляции: MSIL или native к непосредственно языку отношения имеет слабое.
>Автомобили более безопасны, чем мотоциклы, это факт.
>А от попадания ядерной бомбы автомобиль защитит? Или от падения со 100 метрового обрыва? Нет! Значит автомобили не безпаснее мотоциклов! От всего вышеперечисленного спасет только радио «Радонеж»
А что, в случае с SaaS не надо обучать сотрудников?
… и пользователи в самый неподходящий момент (за две недели до Нового Года) получают новую неоттестированную ими версию софта с новыми багами
Многие (как бы не все) крупные компании предпочитают крайне консервативно относиться к новым версиям софта. Сомневаюсь, что в случае с SaaS их консерватизм куда-то денется.
Расскажите это пользователям сервисов Sony