это правила хорошего тона

какой тут гост?

стоп! т.е. это всего лишь моральная сторона вопроса?

естно

не совсем моральная

а это сторона из разряда той по которой код делится на говнокод и неговнокод

Вообще такие вещи у вас должны быть определены внутри команды

в которой ведется данная работа

на основании чего? личных предпочтений, верно?

не личных, а опыта людей, вот мне лично, как наверное и многим другим, чрезмерное кол-во комментариев только мешает и затрудняет разбор кода

не личных, а опыта людей, вот мне лично, как наверное и многим другим, чрезмерное кол-во комментариев только мешает и затрудняет разбор кода

Егор, ключевое слово - "наверное")

Егор, ключевое слово - "наверное")

Поэтому я и сказал что вы должны писать код так как принято у вас в команде

В конце концов можете почитать книжки вроде "Совершенный код" МакКоннелла

статьи вконце концов

чтобы понять какое в среднем отношение к данному вопросу и почему

вконце концов есть же последнее китайское предупреждение

МакКоннел, он всего лишь человек, который предложил один из вариантов, не более

но если это считается хорошей практикой то зачем делать иначе?

зачем тогда еще паттерны юзать?

но если это считается хорошей практикой то зачем делать иначе?

сколько из 7 млрд человек признают это хорошей практикой?)

нафиг их кто-то придумывает, лучше всегда свое писать

сколько из 7 млрд человек признают это хорошей практикой?)

Можете провести сравнительный соц-опрос, и предоставить нам результаты)

наш разговор свёлся к тому, что "9999 разработчиков не могут заблуждаться"

именно, и как я уже сказал, что если у вас в команде принято по другому то тогда пишите как принято у вас

у нас единое мнение, мол, кто не пишет комментарии, то филипп киркоров

и так Филиппов по России - множество

Это мнение только Вашей команды) В некоторых командах считают что писать на VB это моветон)))

и, даже, не то плохо или хорошо, писать или не писать, не для себя, скажем так поступают, а поступают так - мне сказали, кто-то, что вот Вася пупкин книжку прочитал там так было написано, поэтому, вот я лучше Васю послушаю, чем сделаю как по-человечески

по нормальному

Это мнение только Вашей команды) В некоторых командах считают что писать на VB это моветон)))

vb был выбран из-за простоты написания на оном

а чем правила написания кода автотеста отличается от написания кода программы?

Ну если у тя сложная архитектура...То да

Тока сама сложность - ошибка

Тока сама сложность - ошибка

А какая разница, сложно или просто, для чего делате разделение? стесняетесь, что коллеги засмеют или?

Я нет

и, даже, не то плохо или хорошо, писать или не писать, не для себя, скажем так поступают, а поступают так - мне сказали, кто-то, что вот Вася пупкин книжку прочитал там так было написано, поэтому, вот я лучше Васю послушаю, чем сделаю как по-человечески

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

Используем, потому что наглядно, удобно и просто)

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

или мы о разных паттернах подумали...

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

и так и так попробовали, с ними удобнее

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

если в критериях приемки есть требование, типа "проверить, что в БД появилось значение" - то как его можно реализовать без ползанья в БД ? Хотя если есть UI доступ к этим значениям - то может лазить в базу и излишне... тут на вкус и цвет

согласен, всё зависит от критериев и возможностей проверить без прямого доступа в БД

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

Неправильно, но иногда приходится

http://www.testing-whiz.com/infographics/45-websites-every-software-tester-should-bookmark-in-2017

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

А какие риски могут возникнуть при создании тестовой стратегии? 0_о

Вот и у меня такой же вопрос. Меня попросили задокументировать тест стратеджи, во всех найденных шаблонах есть пункт Оценка рисков

Это какой-то пережиток прошлого, или мимо меня прошло, а все используют?

Похоже на путаницу. Оценить риски "при" создании стратегии != Оценить риски "для" создания

Что до рисков, то теперь только так и тестируют - risk based management

"только так" - это, конечно, преувеличение. Но эти самые риски и их оценка важнее всего вашего документа.

у нас есть оценка проджект рисков, этим занимаются на каком-то высоком уровне

теоретически, оттуда берутся и риски тестировочного проекта

но я таким никогда не занималась

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

я вот лично склоняюсь что лучше в БД не лазить тк это acceptance и тут все должно быть как у "людей"

тем более что разработчики могут хранить сущности долстаточно сложно, что вызовет сложности в проверке, плюс если структура БД поменяется все тесты покраснеют

хорошо, спасибо всем за ответы

Это удобно тем, кто хочет быть в контакте с коллегами. Я не понимаю, как вообще работать удаленно. Пока не придешь и лично не пнешь - у всех все занимает в 4-5 раз больше времени

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

опенспейс возможен на 2 человека

опенспейс возможен на 2 человека

так люблю эти категоричные суждения людей :)

ситуация - 3 человека, один спрашивает что-то второго, третьему нужно сосредоточиться и вы ему мешаете

если он вас не послал - это не значит, что вы ему не мешаете

а если один по скайпу говорит?

Для обсуждений есть переговорки, как и для скайпа

Нормальный опенспейс - это когда пройти мимо можно, не попадая за спину коллегам.

ох какую больную тему задели

ERROR: S client not available

ну и в целом у нас широкие столы, тумбочка незаметно в углу притулилась. И перегородки высокие, от сидящегл напротив разве что макушку видно (если специально не вытягиваться)

ситуация - 3 человека, один спрашивает что-то второго, третьему нужно сосредоточиться и вы ему мешаете

надень наушники или научись не слушать то, что тебе не нужно)

ничоси, что ещё сделать?

опенспейс же на то и опен, что все типа должны себя чувствовать комфортно в коллективе

типа видеть людей, слышать, общаться

а сидеть в наушниках меня никто обязать не может

Плюс опен спейса общение, но это и есть его самый большой минус

правильны подход - я сообщаю всем закрыть рот и они закрывают рот

при чём тут обязать? это ты отвлекаешься на всё подряд

потому что нельзя мешать другим людям

что значит "отвлекаюсь"? вы мне мешаете и отвлекаете

я уверяю, ты один из немногих, кто не может сосредоточиться настолько :)

сижу работаю и тут начинают шуметь

поэтому категоричный взгляд тут не уместен

никто не может, гугл - реакция мозга на внешние раздражители

тебе также никто не обязан обеспечивать тишину за пределами норм санпин

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

:)

тебе также никто не обязан обеспечивать тишину за пределами норм санпин

правильно - разговор рядом сидящих людей в незвукоизолированной комнате - это нарушение норм

дрель мешает меньше

дрель мешает меньше

+

правильно - разговор рядом сидящих людей в незвукоизолированной комнате - это нарушение норм

тыкни меня носом в нарушаемые нормы

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

потом глянь нормы по зашумленности офисных помещений

погоди, давай ка соблюдать бремя доказательства?

дрель мешает меньше, какроч

погоди, давай ка соблюдать бремя доказательства?

нет, так как в данном случае единственный аргумент выглядит так "ты шумишь = ты мне мешаешь"

он не требует доказательств и абсолютен

мешаешь - ок, нарушаешь нормы - ой ли?

про нормы я сказал - гугл, доказывать не буду, в контексте спора - это доп, а не основной аргумент

"гугл" означает сам не знаю, но уверен, что я прав

про нормы как бы начал ты, так что доказжи, что разговор не нарушает