Как вы думаете, насколько конечный программист должен быть осведомлен о задачах проекта в котором он участвует ?

На каком этапе "гениальный кодер" может стать программером понимающим бизнес логику реализумой задачи?





Исправлено 1 раз(а). Последнее : Vedmak, 26.08.17 21:27

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

Я бы хотел заранее дитстанцироваться от "масштабов и замеров".

Когда "кодер" способен понять цель проекта?





Исправлено 2 раз(а). Последнее : Vedmak, 26.08.17 22:14

Vedmak
Когда "кодер" способен понять цель проекта?

"Тесту место у печи".

Vedmak
Как вы думаете, насколько конечный программист должен быть осведомлен о задачах проекта в котором он участвует ?
На каком этапе "гениальный кодер" может стать программером понимающим бизнес логику реализумой задачи?

имхо слишком абстрактно
когда я писал локал. армы - сам себе режиссер - все одном флаконе
а в больших проектах все по РАЗНОМУ
а уж если пришел на суппорт - так сиди фикси баги а на понимание времени не останется


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

Немного приземлим. Должен ли программист заботиться о вменяемости текстов сообщений показываемых пользователю его изделием?

Упростим еще чуть чуть. Ошибки возникающие в процессе исполнения кода. Кто должен заботится о текстах сообщении о ошибках ?

Должен.

Ну и давай так - ты спросил, я ОТВЕТИЛ. Если в ТВОЮ ЛИЧНУЮ концепцию не уписывается - друг - тогда ЗАЧЕМ нужно все это? Объясни !

Ну и пожелание - будь ХОЗЯИНОМ темы, сам общайся, комментируй. Или ты думаешь мы тут все хотим угадать ПРАВИЛЬНЫЙ вариант? Боюсь, что нет.

Вероятно, следует поступать так. Сообщения об ошибках пишет программер, после чего демонстрирует эти сообщения (можно искусственно вызвать сообщения, разумеется) постановщику. Если постановщика что-то не устраивает, он или предлагает свой вариант, или предлагает программеру иначе сформулировать сообщение.

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

Например, ответка SQL-сервера о попытке вставить дубликат уникального ключа. Стоит ли сначала проверить наличие вставляемого значения в таблице или пытаемся пропихнуть и потом мучаемся с разбором ошибки ?

Vedmak
Например, ответка SQL-сервера о попытке вставить дубликат уникального ключа. Стоит ли сначала проверить наличие вставляемого значения в таблице или пытаемся пропихнуть и потом мучаемся с разбором ошибки ?

Как ни крути дубликат будет зло.Сначала проверить, это ЛОГИЧНО и ПОСЛЕДОВАТЕЛЬНО.

sphinx
..Сначала проверить, это ЛОГИЧНО и ПОСЛЕДОВАТЕЛЬНО.

Будем считать это мнением А и голос засчитаем как +1.

Итого:

*A* Проверять перед вставкой: 1

У меня сейчас задача по разбору адресной строки тоже сложная штука (да сам попробуй, я тоже шашкой махал).. Конечно проверять. Но и критерии/ключи вылизывать (ну или триггеры на вставку). У меня проще (и еще сложнее по сути) - уже все и все ЗАПИСАЛИ. Все молодцы. А теперь из это й КРИВОЙ базы надо получить ФИАС-коды. Думаешь там критерии поиска просто сформулировать? Ну можно, да. А нужны ХОРОШИЕ. И с этим что-то и по моим идеям не густо, и возможно, из наших мало кто прочитал..

Сообщения об ошибках будет читать юзер. Сообщение должно быть лаконичным, однозначным и содержать инструкцию для юзера. По "менталитету" постановщик ближе к юзеру, нежели программер (кодер). Поэтому постановщик должен проверить сообщения об ошибках на предмет их соответствия вышеперечисленным требованиям.

Simple777
Сообщения об ошибках будет читать юзер. Сообщение должно быть лаконичным, однозначным и содержать инструкцию для юзера. По "менталитету" постановщик ближе к юзеру, нежели программер (кодер). Поэтому постановщик должен проверить сообщения об ошибках на предмет их соответствия вышеперечисленным требованиям.

Суть верная, хотя форма подачи мне показалась перенагруженной, Но это мое ЛИЧНОЕ мнение. Разумеется, это давно пора считать неправильным.

Simple777
Сообщения об ошибках будет читать юзер. Сообщение должно быть лаконичным, однозначным и содержать инструкцию для юзера. По "менталитету" постановщик ближе к юзеру, нежели программер (кодер). Поэтому постановщик должен проверить сообщения об ошибках на предмет их соответствия вышеперечисленным требованиям.

Также думаю. Сообщение в GUI должно сообщать пользователю о неправельности ЕГО действий, а не о том что "восьмая шестеренка в третьем ряду слева" не смогла выполнить.

Vedmak
Сообщение в GUI должно сообщать пользователю о неправельности ЕГО действий

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

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





Исправлено 1 раз(а). Последнее : Божья_коровка, 02.09.17 00:15

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

Прям райские песни.... А когда уже продали то, что еще не начали писать, то служба поддержки огребает все задачи которые "пропустили" и постановщики и кодеры....

Тут и рождается вопрос... что старше, яйцо или курица?

Vedmak
Прям райские песни....

Нормальные песни ;)

Vedmak
А когда уже продали то, что еще не начали писать, то служба поддержки огребает все задачи которые "пропустили" и постановщики и кодеры..

Разъясни этот момент, что в твоем понимании, продали то что еще не начали писать? В таких случаях продается не само физически ПО, а документация "первого уровня" на него.

Vedmak
Тут и рождается вопрос... что старше, яйцо или курица?

Расскажу байку На прошлой работе у нас все сообщения были стандартизированы. Была некая таблица в оракле содержащая код сообщения, самое сообщение и небольшое его описание. И никто "отсебятину" при разработке\доработке юзерам на экран не выдавал.
Так кто старше, яйцо или курица? Постановка с аналитикой или разработка?