Более чем. «Здравый смысл» у каждого свой. Вон у того парня проехать на красный свет — здравый смысл. А чо, никого ж нет.
Такие ситуации, когда что-то делается опционально, должны вносится в инструкцию. Да, любой «здравый смысл» должен быть описан. В данном конкретном случае — если репликация бага простая, не нужно, например, вставлять ролик с записью. Это все оговаривается инструкцией. Что не оговаривается — делается обязательно.
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее
В чем проблема прочитать? Доводим то тимлидов, они делают в тот же день пятиминутную летучку и объясняют остальным, что поменялось.
Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Это забота начальника отдела тестирования, начальника разработки, ну и может, крупнейших тимлидов.
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
О, какой знакомый разговор. Прям как в жизни, право слово. Вон тот закон нам кажется дурацким — исполнять не будем.
Не, почему ж прослыть недисциплинированным? Наоборот — нашел косяк, хоть в коде, хоть в инструкции, проявил инициативу — молодец.
Принцип простой:
1)Инструкция выполняется. Точно.
2)ВСЕГДА
3)Да, даже если она дурацкая
4)Если она дурацкая — добиваемся внесения изменений, а не сидим на попе ровно, обсуждая в курилке «начальник — дурак».
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
Я вас умоляю. Пол-страницы текста обновить несложно.
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Извините, но то, что вы описываете, называется «разгильдяйство». Т.е. в коллективе нет дисциплины. Это проблема совсем иного плана.
У нас, например, решение об упомянутой инструкции принималось коллективно начальником отдела тестирования и самыми крупными тимлидами, которые довели инструкцию до нас, разработчиков попроще. Естественно, ВСЕ поля заполняются только если процесс тестирования сложен. Есть обязательные поля, есть «для сложных случаев». Такая разбивка как раз и сделана исходя «из здравого смысла». Но раз и навсегда, а не так, что каждый сам делает, как хочет. Никому в голову не придет нарушать, просто потому что это не культурно — все равно, извините, что накидать окурков посреди чистого опен-спейса.
А, ну это просто разные инструменты используются.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
читаем символ, если он А и стейт «начало», идем в стейт «ждем С». Читаем символ, если он С — идем в стейт «ждем D», иначе откатываемся в начало
Ну так, блин, это и есть конечный автомат. Автор описал универсальное, короткое решение.
Таблица легко строится по графу, методы минимизации автомата известны. Соответственно, решение топикстартера лекго поменять. А вот править стену кода…
В этом случае полезным может быть комментарий типа «Дайте информацию, как верифаить, или поверифайте, пожалуйста, сами». Такая фраза, в сочетании с назначением бага на разработчика, работает лучше, чем просто «Дайте информацию, как верифаить».
Почему не разработать обязательную к исполнению внутреннюю инструкцию, которая требует при передаче «дела» разработчиком тестировщику описывать конкретные пункты (как у нас сделали)
1) в чем была проблема
2) как пофикшено
3) изменения с внутренней точки зрения
4) изменения с пользовательской т.з.
5) возможные риски
6) видеозапись-демка, которая показывает, что фикс есть, и все работает, как надо
7) описание в деталях, как проверять (дополнительное тестирование по необычным usecase'ам тестировщики разработают сами).
Можете мне пожалуйста рассказать, как живут студенты на 50€? Без сарказма, мне очень интересно.
В 2006 году у меня была стипендия в 650 рублей (СПБ). Это в те годы примерно 20 евро. У круглых отличников была повышенная — 900р.
Хватало на:
1) Проездной — 300 р для студента
2) Общагу — 300р для бюджетника
3) Ручку и карандаш с линейкой — 50р.
Жил я тогда на 3800-4000р (117 евро), присылаемых родителями. Хватало на нормальную еду и книги.
Было бы интересно узнать, чем он ограничен (шаблоны не в счет — во-первых, они и в дельфи уже давно есть, а во-вторых, у него большая встроенная библиотека — «контейнеры» и прочее присутствует).
В штатах одна из крупных страховых компаний до 2005 года примерно использоваля при обработке мэйнфрйм с 7 битной кодировкой родом из 70-80х.
Незачем менять работающую вещь, если она делает то, что нужно (и если при этом производительности и надежности хватает).
Во всех перечисленных ВУЗах учатся как местные, так и приезжие. Посмотрите на процент иногородних. Если бы в городе, откуда приехал студент в МГУ/МФТИ были бы нормальные условия труда, была бы больше вероятность того, что он не останется в столицах. Получается замкнутый круг.
Связь понятна (хотя мнение не разделяю) — если человек задерживается на одном месте, то есть риск, что его знания устаревают (прогресс обгоняет). В итоге он привязывается к месту и становится неконкурентоспособным на глобальном рынке труда. Если рабочее место/должность меняется (с повышением, освоением новых, более продвинутых технологий и т.д.), значит, человек 1)умеет учиться 2)учится, значит он как специалист _потенциально_ более ценен.
Значит, потенциально его ЗП и моральные потребности выше. Спутница жизни мужчине соответствует.
Да не, просто годами никто не может ответить на простой вопрос «почему?». И смешно и грустно одновременно.
Полная аллюзия на «если тебе не нравится стиль живописи XYZ, то ты просто тупое быдло и не дорос».
Более чем. «Здравый смысл» у каждого свой. Вон у того парня проехать на красный свет — здравый смысл. А чо, никого ж нет.
Такие ситуации, когда что-то делается опционально, должны вносится в инструкцию. Да, любой «здравый смысл» должен быть описан. В данном конкретном случае — если репликация бага простая, не нужно, например, вставлять ролик с записью. Это все оговаривается инструкцией. Что не оговаривается — делается обязательно.
В чем проблема прочитать? Доводим то тимлидов, они делают в тот же день пятиминутную летучку и объясняют остальным, что поменялось.
Это забота начальника отдела тестирования, начальника разработки, ну и может, крупнейших тимлидов.
О, какой знакомый разговор. Прям как в жизни, право слово. Вон тот закон нам кажется дурацким — исполнять не будем.
Не, почему ж прослыть недисциплинированным? Наоборот — нашел косяк, хоть в коде, хоть в инструкции, проявил инициативу — молодец.
Принцип простой:
1)Инструкция выполняется. Точно.
2)ВСЕГДА
3)Да, даже если она дурацкая
4)Если она дурацкая — добиваемся внесения изменений, а не сидим на попе ровно, обсуждая в курилке «начальник — дурак».
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
{$APPTYPE CONSOLE} и все дела.
Ну, как. Если версия от 5 (1999 г) и новее — New -> Application -> Console application.
По сравнению с чем?
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
Я вас умоляю. Пол-страницы текста обновить несложно.
Извините, но то, что вы описываете, называется «разгильдяйство». Т.е. в коллективе нет дисциплины. Это проблема совсем иного плана.
У нас, например, решение об упомянутой инструкции принималось коллективно начальником отдела тестирования и самыми крупными тимлидами, которые довели инструкцию до нас, разработчиков попроще. Естественно, ВСЕ поля заполняются только если процесс тестирования сложен. Есть обязательные поля, есть «для сложных случаев». Такая разбивка как раз и сделана исходя «из здравого смысла». Но раз и навсегда, а не так, что каждый сам делает, как хочет. Никому в голову не придет нарушать, просто потому что это не культурно — все равно, извините, что накидать окурков посреди чистого опен-спейса.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
Насколько ж по-разному головы работают… Мне бы в голову ничего, кроме двухмерного массива не пришло бы.
Извините, без подкола, — а как еще можно представить-то?
Ну так, блин, это и есть конечный автомат. Автор описал универсальное, короткое решение.
Таблица легко строится по графу, методы минимизации автомата известны. Соответственно, решение топикстартера лекго поменять. А вот править стену кода…
Почему не разработать обязательную к исполнению внутреннюю инструкцию, которая требует при передаче «дела» разработчиком тестировщику описывать конкретные пункты (как у нас сделали)
1) в чем была проблема
2) как пофикшено
3) изменения с внутренней точки зрения
4) изменения с пользовательской т.з.
5) возможные риски
6) видеозапись-демка, которая показывает, что фикс есть, и все работает, как надо
7) описание в деталях, как проверять (дополнительное тестирование по необычным usecase'ам тестировщики разработают сами).
«На машине нет колес» — «пофикшено, поставили 2 колеса». Какой же тут фикс? Колес (комплекта) как не было, так и нет.
Тем более, закрываться же баг должен тестером?
В 2006 году у меня была стипендия в 650 рублей (СПБ). Это в те годы примерно 20 евро. У круглых отличников была повышенная — 900р.
Хватало на:
1) Проездной — 300 р для студента
2) Общагу — 300р для бюджетника
3) Ручку и карандаш с линейкой — 50р.
Жил я тогда на 3800-4000р (117 евро), присылаемых родителями. Хватало на нормальную еду и книги.
Незачем менять работающую вещь, если она делает то, что нужно (и если при этом производительности и надежности хватает).
Или токарем. Или электриком. Или сварщиком. Почему-то в сторону средне-специального не думают.
Можно. Давайте прикинем, сколько людей работют на месте, сколько — по удаленке. Мне кажется, соотношение не в пользу вторых.
Это смотря, что считать культурой и каков критерий ценности специалиста.
Значит, потенциально его ЗП и моральные потребности выше. Спутница жизни мужчине соответствует.
Полная аллюзия на «если тебе не нравится стиль живописи XYZ, то ты просто тупое быдло и не дорос».