Пара бізнес-логіки програмування з особою, що не є ІТ [закрито]

У вас був досвід, коли людина, яка не є ІТ, працює з програмістом під час процесу кодування?

Це як парне програмування, але одна людина - людина, яка не є ІТ, яка багато чого знає про бізнес, можливо, інженер з процесами з математичним фоном, який знає, як все обчислюється, і може зрозуміти неідіоматичний процедурний код.

Я виявив, що деякі процедурні, доменні мови, такі як PL / SQL, цілком зрозумілі інженерам, які не є ІТ. Ці особи в кінцевому підсумку є співавторами кодексу та гарантують правильність формул, факторів тощо.

Я вважаю, що подібне програмування пар є досить продуктивним, користувачі цього типу інженерного типу вважають, що вони також є "власниками" та "авторами" коду і допомагають мінімізувати непорозуміння в процесі спілкування. Вони навіть допомагають проектувати тестові випадки.

• Чи поширена така практика?
• Чи має це ім’я?
• Чи мали у вас подібний досвід?

Хоча ви описуєте це як спільний сеанс кодування (я не можу назвати це парним програмуванням, оскільки лише одна людина "керує" - при парному програмуванні обидві сторони беруть клавіатуру і пишуть код), я б назвав це збираючи критерії прийняття .

Тобто ви перевіряєте бізнес-правила (правильні розрахунки та процеси) з діловим користувачем (правда, з дуже технічною роллю, інженером).

У цьому випадку це негайно перекладається на письмовий код (SQL), але для багатьох інших заходів це не буде, хоча є автоматизовані інструменти тестування прийому для різних мов та платформ (я конкретно замислююся про мову корнішерів та пов'язані з цим інструменти).

Ця практика не настільки поширена, як повинна бути, але набирає все більше і більше послідовників, і тих, хто її дотримується (отримання критеріїв прийняття у формі, яка може бути виконана) вважають її безцінною як інструментом для спілкування з бізнесом та для управління розвиток.

Так. Де я працюю, я займаюся типом хардкорного програмування, тоді як стратеги працюють над стратегією uhm. Тобто я пишу програми, які реалізують свої торгові моделі.

Ключ до цього сидить прямо поруч з ними і зрозуміти , які саме ідеї і задавати багато запитань про речі , які можуть бути випадково до них, але важливо , щоб сторони виконання. Наприклад, я б запитав про те, як швидко здійснювати торгівлю, чи впливає це на їхню модель. Це має величезний вплив на те, як я буду писати код. Насправді я схильний розпорошувати питання в кімнату, оскільки ми сидимо там, працюючи кожен день.

Є двосторонній зворотній зв'язок. Якщо я скажу їм, що побудувати якусь схему торгівлі буде непросто, вони повернуться назад і подумають, які компроміси можна зробити на стороні прийняття рішень. Якщо вони вирішать, що їх нова стратегія потребує якоїсь нової функції, я поговорив з ними про те, скільки часу знадобиться для побудови та які потенційні підводні камені.

Вони роблять кодові модулі, які час від часу інкапсулюють деякий аспект торгової стратегії, але я масажую фрагменти разом в архітектуру, яка дозволяє нам відслідковувати всі різні стратегії, а також бекенд-операційні речі. Таким чином, їм не потрібно знати азотну крупу в системі.