Блог

Я сотрудник фабрики, который совсем немного программировал. Я хочу предложить, чтобы наши отчеты о смене компьютеров выполняли пару вычислений за нас, чтобы мне не приходилось вбивать их в калькулятор несколько раз в день. Вместо того, чтобы просто сказать «Я хотел бы, чтобы компьютер принял вес нетто и тары, которые я ввел в другом месте, и сообщил мне вес брутто», я хотел бы отправить некоторый код или псевдокод с моим предложением:

 function calculategross () {
    int gross = fldshf_skidnet   fldshf_tare;  
    //use fldshf_skidnet, not fldshf_net in case of multiple rolls per skid.
    }
  

Поскольку я точно знаю, какие вычисления мне нужно выполнить и какие переменные доступны в таблице базы данных, псевдокод может избавить прикладного программиста от лишних размышлений. Это также должно сделать мое предложение более жизнеспособным, а написание нового кода — просто забавным. Но настоящий программист предпочел бы иметь подробную спецификацию или что-то в этом роде без моего мнения о технических особенностях. Если бы менеджер попросил вас что-то закодировать и отправил некомпилируемый «код», вы бы сказали «эй, хорошая дорожная карта» или «блин, есть подсказка»?

Справочная информация: Отчет о смене — это вид таблицы базы данных с вкладками, выполненный в Alpha V5. Итак, у вас есть интерфейс, который чем-то напоминает первый результат здесь, и если вы нажмете F8, вы увидите базовую таблицу в базе данных. (Так я узнаю все имена переменных.) Моя страница калькулятора будет находиться на отдельной вкладке. Некоторые из используемых данных будут введены пользователем на других вкладках, некоторые на самой странице.

Вот некоторые из «первого черновика кода», которые я рассматриваю. Интерфейс, в котором я больше всего сомневаюсь, находится вверху, некоторые функции калькулятора — внизу.

 Button GetDataButton = new Button();
GetDataButton.onclick() = UpdateAllUneditedVariables() {
    //Populate all fields on this tab with data entered elsewhere 
    //Don't update fields the user changed on this page.
    //I didn't actually write this function, I'm just describing it.
    }

Button CalculateAll = new Button();
CalculateAll.onclick() {
    FillEmptyFieldsWithDefaultValues();
    CallAllCalculatorFunctions();
    DisplayAllCalculationResults();
    }

sub CallAllCalculatorFunctions() {
    CalculateGross();
    CalculateAverage();
    CalculateNetPoundsPerHour();
    //I feel like this is a non-programmer way to structure this...
    }


//Here's a couple of the mathier functions -- not that hard, but complicated 
//enough that I'd rather not have the programmer have to think through them.

function SkidsPerJob () {
    //How many skids must we divide this job into based on weight limits?
    int max_by_weight = ceil (fldshf_total_lbs / max_lbs_skid);

    //How many based on height limits?
    float total_height = fldshf_gauge * fldshf_total_sheets;
    int max_by_height = ceil(total_height / max_height / stacks_per_skid);

    int total_skids = max (max_by_weight, max_by_height);
    }

function CalculateNetPoundsPerHour () {
    int netpph = sheet_weight / sheet_length * feet_per_minute * 12 * 60;
    if (number_of_webs > 1) {netpph *= number_of_webs;
    }
  

Если вы не считаете, что это хорошо, не могли бы вы порекомендовать просто обновить мои навыки программирования, обновив формы Microsoft Access? (Я делал их раньше, с выпадающими списками и всем прочим, просто не в последнее время.) Получите редактор от Scriptlance для исправления соглашений об именовании и ошибок кодирования? Или мне следует просто сосредоточиться на внешнем виде страницы и описании необходимых мне функций и не пытаться разрабатывать ее самостоятельно?

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

Однако не тратьте на это слишком много времени. Сосредоточьтесь на вещах, которые уникальны для вашего домена.

В мире agile вы бы старались избегать попыток спецификации всего заранее, признавая, что это практически невозможно, и вместо этого позволяли дизайну развиваться посредством постоянного прототипирования и взаимодействия с разработчиком (см., например, Scrum или DSDM).

Мой совет — сосредоточиться на бизнес-требованиях и позволить разработчику точно решить, как их лучше реализовать, это его работа, и он будет знать, как это сделать лучше, чем вы. Несомненно, у него также будут такие вещи, как стандарты кодирования и существующие библиотеки кода, которые он, возможно, захочет использовать повторно. В первую очередь вы должны быть заинтересованы в тесном сотрудничестве с ним, чтобы убедиться, что он понимает ваши требования (я бы посоветовал вам разбить их на небольшие, дискретные «куски»), чтобы то, что он создает, отвечало вашим потребностям, и в день доставки не было никаких сюрпризов.

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

Как программист, я предпочел бы видеть спецификацию в виде экранной диаграммы с описаниями того, что делает каждая кнопка (или другой активный элемент управления), чем псевдокод для создания экрана. Однако я не вижу ничего плохого в указании вычислений в псевдокоде, особенно если они сложные. Если порядок операций критичен (либо с точки зрения пользователя, либо «это значение зависит от этого вычисления»), я бы также приветствовал высокоуровневый псевдокод, подобный английскому, для указания ключевых битов.