Выборка данных через AOS vs SQL Server

[mazzy]

Цитата:

Сообщение от fed

Мы с тобой о разных вещах говорим. Как тестирование организовыватся:
1. Запускается некий скрипт на C#, который пишет в БД тестовые данные.
2. Запускается другой скрипт на C#, который вызывает один или несколько классов X++ (через .net bc), которые эти данные обрабатывает.
3. Запускается третий скрипт на C#, который сравнивает получевшиеся по результатам работы классов на X++ в аксаптовской базе данные с эталонными.
4. Запускается четвертый скрипт, который подчишает результируюшие и тестовые данные. (Шаг не обязательный).

Дык вот для шагов 3,4 и (вероятно) 1 - .net bc и непрямой SQL не нужен совсем, если Ваньку начальство заставляет .net bc использовать для чтения базы на шагах 3 и 4 - это верх изврата.

Цитата:

Сообщение от kashperuk

На мой взгляд (я не претендую на эксперта в данной области), ближе всех к истине fed.

вот интересно, как тестируется алгоритм резервирования при вставке той же строки заказа. аксапта по-разному вставляет строки в зависимости от параметров.

т.е. я еще могу представить как таким образом можно тестировать вставку цен из прайс-листов. То же сводное планирование или закрытие склада.

но я с трудом представляю как тестируется авторезервирование указанным способом при вставке строки в заказ. Ведь там куча мест, которые несколько раз апдейтят запись и сильно зависят от orig().

также с трудом представляю как можно тестировать не из самой аксапты функцию создания строк, которая сильно завязана на внутриаксаптовские временные таблицы (может быть, конечно, в ax6 временные таблицы находятся на уровне SQL). И вообще все алгоритмы, в которых маркируются строки (через map, временные таблицы или еще как).
axaptapedia: Tutorial Form MultiSelectCheckBox

Цитата:

Сообщение от fed

А раскажи, в общих чертах, как вы более сложную функциональность тестируете ? Как юнит-тест для Аксапты написать - я примерно понимаю. А вот как написать и запустить тест, который не custVendVoucher тестирует, а иммитирует, ну скажем сессию сводного планирования, я пока не особенно понимаю...

а вот это - более-менее понятно и принципиальных сложностей не вызывает.
просто число первоанчальных и финальных данных велико.

[kashperuk]

Цитата:

Сообщение от mazzy

вот интересно, как тестируется алгоритм резервирования при вставке той же строки заказа. аксапта по-разному вставляет строки в зависимости от параметров.

Итак, два отступления:

При тестировании какого-либо нетривиального продукта, невозможно протестировать все сценарии. Думаю, этот момент понятен. Но он важен и не стоит о нем забывать. Над тестированием логистики в АХ работает около 30 человек. Соответственно, есть предел тому, что эти 30 человек могут успеть за отведенное время, учитывая чрезвычайную зау-сложность нашего процесса.

По причинам, описанным выше, большинство тестеров в MDCC занимается так называемым "black-box testing" (в отличии от "white-box testing"). То бишь, никто в код не заглядывает, и им не важно, сколько там раз использовался orig(), и являлась ли таблица временной или постоянной.

Соответственно, выполняя комплексное тестирование они по сути прогоняют различные сценарии, как это делал бы обычный пользователь Аксапты в посведневной работе. Резервирование - ну вот и создают строки, проверяя проводки и т.д. с различными настройками системы.
Обратите внимание, что в большинстве случаев о правильности работы функциональности принимает решение именно тестер в ходе выполнения сценария. Поэтому очень важно, чтобы они понимали, что именно происходит в реальной жизни, и см. пост выше

[Logger]

Цитата:

Сообщение от kashperuk

А про то, что тестируют и разрабатывают приложение люди без знания АХ - я считаю, что это проблема. Но, к сожалению, практически всех кандидатов с опытом АХ и Х++, о которых я знаю, не взяли на работу за недостаточные technical skills. То бишь, простите, программисты АХ недостаточно квалифицированы для того, чтобы писать качественный код.

Неужели все настолько плохо ?
Если не секрет, на чем люди срезались ? Очень интересно, чего же, как правило, не хватает среднему X++ программисту.

Кстати, в некоторых местах встречал код (как правило это относилось к взаимодействию с БД), который явно был написан не X++ программистом, т.е. никакой бест практис не соблюдался. Жутковато выглядело. Походу разработчики ядра взяли и после си наваяли что-то на X++

[Lemming]

Цитата:

Сообщение от Logger

Если не секрет, на чем люди срезались ? Очень интересно, чего же, как правило, не хватает среднему X++ программисту.

Присоединяюсь к вопросу. Понятно что NDA и все такое, но если как-то можно своими словами сформулировать более четкие требования. Что-то вроде: уметь реализовать на бумаге красно-черное дерево на чистом С или там сортировку пузырьком Возможно что-то более фундаментальное: расход памяти при использовании той или иной структуры, понимание каких-либо алгоритмов, параллельность, может что-то еще? В общем, гадать не хочется, так что если кто из приближенных к теме поделится, было бы здорово!

[MikeR]

Цитата:

Сообщение от Logger

Неужели все настолько плохо ?
Если не секрет, на чем люди срезались ? Очень интересно, чего же, как правило, не хватает среднему X++ программисту.

Эх, если бы ты знал что спрашивают на собеседовании, то погрузился бы в дипрессию.
Я знаю места, где надо отвечать, что такое виртульаный диструктор или чем отличается делегат от события. + еще надо иметь пятилетний стаж работы у партнера не понятно зачем. Получается как в армии, где надо и кросс пробежать и подтянуться после этого больше двадцати раз. Думается ну все такие крутые парни в армии служат...
А потом смотришь на допустим взятие заложников, где эти чудо богатыри палят друг в дружку и никакой согласованности действий.
Так и здесь. Но это глубочайшее имхо.

[Vadik]

Цитата:

Сообщение от kashperuk

То бишь, простите, программисты АХ недостаточно квалифицированы для того, чтобы писать качественный код

А если посмотреть на код, который в SSRS отчетах используется, это как - качественный код? По мне, так нечитабельное кровавое месиво Хотя готов допустить, что глаз немного "замылился" - сказывается привычка к аксаптовскому оформлению

[kashperuk]

Цитата:

Сообщение от Vadik

А если посмотреть на код, который в SSRS отчетах используется, это как - качественный код? По мне, так нечитабельное кровавое месиво Хотя готов допустить, что глаз немного "замылился" - сказывается привычка к аксаптовскому оформлению

Нет, с глазами у тебя все ОК.
Практически весь этот код написан вендорами, и хотя мы тратим кучу времени на то, чтобы следить за тем, что они делают, они все равно делают то, что ты написал вышел.

[Logger]

Ну просто интересно знать что считают нормой в Майкрософте. И в чем, например, я могу не соответствовать.
По крайней мере, мне кажется что их требования к соискателям как-то коррелируют с планами развития продукта.

[MikeR]

Мое жизненое кредо - развиваться и еще раз развиваться. А то, что я не прошел в гугл/яндекс/компаниию рога и копыта меня не волнует честно тебе скажу.
Я бы не стал себя подгонять под какие-то стандарты, бо стандарты придумываются людьми и ими же отменяются. Есть еще такая хрень, как личная приязнь/неприязнь, случайность выборки и так далее. Но это опять же мое личное мнение.

[kashperuk]

(Если есть) интервью с HR, то ожидать нужно туповатых вопросов по C++/C#, чаще из области формальных знаний Computer Science.

Техническое телефонное интервью обычно сфокусировано на понимании базовых алгоритмов, ООП, design patters и умении решать более-менее простые задачи программирования (а-ля сортировка, поиск, т.д., но не тривиальные задачи, а чуть посложнее).
Важным является умение объяснять по ходу интервью свое решение, умение показать ход своих мыслей.

При успешном прохождении есть еще интервью "лицом-к-лицу", которое проводится либо у нас на кампусе, либо (в случае выездных рекрутинг мероприятий) в Москве/Киеве/Польше/т.д.
Интервью у нас на кампусе состоит из 5 частей, с пятью разными интервьюерами, каждый - по 1 часу. Здесь вопросы разнятся. Обычно, каждый из интервьюеров задает несколько общих вопросов - про бывшый опыт, про задачи, которые вам приходилось решать, а также те, которые вы не смогли решить, тд. - примеров в интернете куча. После этого обычно необходимо решить какую-то задачу с написанием кода. Задачи, ессно, чуть сложнее, чем на телефонном интервью, но при этом не супер-сложные.

Опять же, важен подход к решению задачи, применение ООП/design patterns, стиль мышления и написания кода. К примеру, вы сразу бросаетесь писать код, или сперва задаете уточняющие вопросы, чтобы более полно понять суть задачи, рисуете ли какие-то обобщенные диаграммы или что-то подобное. Примеров таких задач тоже полно в интернете. Здесь никто не требует четких знаний того или иного языка программирования, поэтому можно писать хоть на псевдо-коде.

Большинство Х++ разработчиков сыпятся еще на интервью с HR, или же на телефонном интервью, в основном из-за отсутствия четкого понимания ООП/шаблонов программирования, или же полном неумении писать код (это основной бич консультантов).

Ключевым моментов является то, что "We hire for Microsoft", то есть недостаточно просто хорошо подходить на какую-то конкретную позицию, надо иметь достаточные технические знания для того, чтобы продолжить карьеру в Майкрософт.

Мое личное мнение - продукт в целом довольно сильно страдает от нехватки у людей, над ним работающих, понимания ERP, бизнеса и потребностей партнеров/клиентов. Но пока мне не удалось изменить то, каких людей мы нанимаем. Но я в этом направлении продолжаю работать

[George Nordic]

А ведь можно было пойти по совсем другому пути: возложить тестирование на партнеров и клиентов, но быстро реагировать, исправлять недочеты (а не отмазываться), уведомлять всех прочих клиентов (а не прятать от них поддержку) и предлагать им хот-фиксы (ноты).

С Уважением,
Георгий

[Logger]

Цитата:

Сообщение от George Nordic

А ведь можно было пойти по совсем другому пути: возложить тестирование на партнеров и клиентов, но быстро реагировать, исправлять недочеты (а не отмазываться), уведомлять всех прочих клиентов (а не прятать от них поддержку) и предлагать им хот-фиксы (ноты).

Похоже это политика такая. Отгородиться от клиента партнерами и сидеть там как за забором.
Не вчера это все возникло.

[Maximin]

Кстати желающим устроиться в MS - советую налечь именно на шаблоны. Полёт воображения там не приветствуется. Насколько я понял, я засыпался именно на этом - несколько нешаблонно реализовал класс в тестовом задании на C++. Т.е. заучить и тупо лепить шаблоны (желательно со ссылками на MS P&P). Нужны, по сути, кодеры. Полезно еще попрыгать на простых заданиях типа чисел Фибоначчи с разными вывертами - словом, на том, что давно и прочно забыто. Олимпиадные задания трогать не стоит - это удел уже тех, кто внутри продвинулся повыше. Помните - не будьте умнее среднего индуса, прикиньтесь туповатым, но исполнительным, и простые задания должны отскакивать от зубов.

Цитата:

Сообщение от kashperuk

Опять же, важен подход к решению задачи, применение ООП/design patterns, стиль мышления и написания кода. К примеру, вы сразу бросаетесь писать код, или сперва задаете уточняющие вопросы, чтобы более полно понять суть задачи, рисуете ли какие-то обобщенные диаграммы или что-то подобное. Примеров таких задач тоже полно в интернете. Здесь никто не требует четких знаний того или иного языка программирования, поэтому можно писать хоть на псевдо-коде.

Большинство Х++ разработчиков сыпятся еще на интервью с HR, или же на телефонном интервью, в основном из-за отсутствия четкого понимания ООП/шаблонов программирования, или же полном неумении писать код (это основной бич консультантов).

[kashperuk]

Цитата:

Сообщение от Maximin

Олимпиадные задания трогать не стоит - это удел уже тех, кто внутри продвинулся повыше. Помните - не будьте умнее среднего индуса, прикиньтесь туповатым, но исполнительным, и простые задания должны отскакивать от зубов.

Не совсем. Все зависит от того, на какой уровень вас нанимают. На более высокие уровни требуется соответственно и намного больше опыта, и простые задачки уже никто не задает.