Холиварофорум
Вы не вошли.
Объявление
#1 2014-04-18 11:36:50
- Анон
Тема айти
Каталог полезных советов и ссылок, принесенных разными it-анонами, c 1-й по 332-ю страницы:
Пока, вроде, полет нормальный, ттт. #8151 2021-08-05 07:09:49
- Анон
Re: Тема айти
#8152 2021-08-05 09:16:54
- Анон
Re: Тема айти
Вот так прямо и ставится задача разрабам (менеджеру)
Ты знаешь, мы изначально договорились. UI тех лид был только за и активно это драйвил как лучшую практику.
У тебя сложные отношения с разработчиками? Почему ты мыслишь в рамках «мне выдадут человека», а не «мы договоримся с человеком»? Я сомневаюсь, что тебе дадут таску на переработку сразу всего, она слишком большая, а вот договориться и ввести правило, чтобы впредь в новых фичах писали эти уникальные айди - реально. А со старыми можно постепенно фоном разобраться.
Тебя пускают в код? Попроси научить и сама поучаствуй.
#8153 2021-08-05 09:56:24
- Анон
Re: Тема айти
У тебя сложные отношения с разработчиками? Почему ты мыслишь в рамках «мне выдадут человека», а не «мы договоримся с человеком»? Я сомневаюсь, что тебе дадут таску на переработку сразу всего
У нас всего несколько разработчиков и большой легаси корпоративный продукт, написанный лет 7 назад, который в основном поддерживается и фрагментарно изменяется по запросу, но не переписывается глобально.
Менеджер мыслит категориями бизнеса: "Оплатит ли заказчик вот эти трудочасы разработчика? А кто оплатит трудочасы разработки, которая нужна не напрямую заказчику, а для удобства, комфорта, облегчения жизни тестер? Или тестер перетерпит, а за эти трудочасы мы сделаем что-нибудь платное..."
Поэтому любая вещь для автотестов или АПИ, которая требует привлечения разработчиков, выпрашивается буквально обиванием порогов и протянутой рукой ((
В код меня не пускают. Но, положим, пустят. А что так можно было. Какого рода идентификаторы лучше расставлять - ID, name (которые хорошо видит Селениум), или изобрести что-то уникальное типа SachaId ? ))
#8154 2021-08-05 10:02:49
- Анон
Re: Тема айти
А кто оплатит трудочасы разработки, которая нужна не напрямую заказчику, а для удобства, комфорта, облегчения жизни тестер? Или тестер перетерпит, а за эти трудочасы мы сделаем что-нибудь платное..."
Ну это нормальная позиция. Посчитай, сколько вы сэкономите в тех же трудочасах, и иди разговаривать с ПМ. Если вы сэкономите меньше и дело только в твоей боли, а ты можешь найти на рынке проект получше - увольняйся. Вариантов-то...
#8155 2021-08-05 10:19:11
- Анон
Re: Тема айти
Какого рода идентификаторы лучше расставлять - ID, name (которые хорошо видит Селениум), или изобрести что-то уникальное типа SachaId ? ))
На существующие и используемые по функциональному назначению лучше не надо. Что-нибудь в духе data-testId. Погугли лучшие практики.
Обосновывать QA задачи и тех долги (вот как анон выше говорит) - тоже полезный навык, как впрочем и обосновывать любые тех долги и мейнтейнанс системы. Если не менеджеру, то бизнесу, который далёк от разработки и не понимает, зачем тратить три дня на рефакторинг, если можно разработать новую фичу. И начинается: бла-бла-бла, качество приложения, количество багов на проде, бла-бла-бла, скорость доставки, бла-бла-бла, тестовое покрытие, бла-бла-бла, ну вы же ТО автомобиля делаете, вот тут то же самое.
Можно попробовать исходить из скорости разработки: если ты не будешь глобально переписывать каждый раз тесты, то это сократит тестирование новых фич, а значит ускорит выдачу заказчику. Это ускорит скорость регрешна, а значит ускорит выдачу заказчику. И цифры в трудочасах.
Можно вообще постепенно делать и обосновывать менеджеру проще: вот ты работаешь над новой порцией упавших локаторов, взяли и с разрабами точечно заменили их. Это не должно сильно замедлить разработку.
#8156 2021-08-05 14:13:54
- Анон
Re: Тема айти
Извините, если этот вопрос раньше задавали. Как в айти с поиском работы после 30-35 лет? При условии, что опыт работы имеется, пусть и не уровня синьор.
#8157 2021-08-05 15:07:04
- Анон
Re: Тема айти
Отлично, 10/10 - начинают звать на позиции вроде CTO или VP of Engineering.
#8158 2021-08-05 17:24:36
- Анон
Re: Тема айти
Извините, если этот вопрос раньше задавали. Как в айти с поиском работы после 30-35 лет? При условии, что опыт работы имеется, пусть и не уровня синьор.
Да вообще без проблем. Может в мелкие конторы, где "мы за модно-молодежно и стартап" будут набирать молодняк, но в остальных 30-35 это не возраст
#8159 2021-08-08 01:01:58
- Анон
Re: Тема айти
ПС. а еще интересно про стресс. Все знакомые САПеры очень жалуются на расстроенную психику, дескать жесть прессуют и атмосфера отвратительная. Правда они консультанты. Их спрашиваю тоже, но интересно еще и мнение анонов собрать.
я SAP SD бизнес-аналитик инхаус, у нас зависит от команды и менеджера.
особо стресс бывает - если ПМ неадекватный или менеджер ебанашка и хочет все за час и вчера и с вовлечением экстернал. или если вендор тянет с дедлайнами, а закупки проебались и не добавили сроки в контракт (хаха).
чем я занимаюсь в основном - копание в багах, сбор требований внутренних заказчиков, написание ТЗ техкомандам, поддержка и координация тестов, иногда участие в них, консалтинг по небольшим изменениям.
#8160 2021-08-08 15:35:00
- Анон
Re: Тема айти
Аноны, а кто-то курсами тестирования Andersen занимался?
#8161 2021-08-08 23:40:26
- Анон
Re: Тема айти
Посоветуйте, пожалуйста, наиболее доходчивую и не сложную книгу по JS с нуля, как первый ЯП. Бумажная, на подарок. На русском.
Слышал хорошие отзывы на Эрика Фримена, стоит ее искать?
#8162 2021-08-09 15:01:01
- Анон
Re: Тема айти
Неторопливо отвечу анону из заебавших айтишников, про комменты к коду. Тема старая, поэтому я хз, стоило отвечать или нет 
Ну, не соглашайся. Но коммент - это доп источник инфы. Т.е. у тебя, помимо кода, появляется второй источник правды. И когда изменяешь код, надо еще и следить, чтобы коммент этому коду сответствовал. И рано или поздно эти два источника разойдутся (это тот же DRY, только применимый не только к коду). Что должен делать код, должны отражать тесты, н-р. Потому что автоматически, если код начинает делать что-то другое, они посыпятся. Если же код непонятнет без комментов (за некоторыми исключениями), то скорее всего - это не слишком хороший код.
Конечно, все, что написано для внешнего использвания (библиотеки, апи и т.д.), должно быть обвязано комментами, с этим я не спорю
Абсолютно согласен с первой половиной комментария. А дальше расхождения. Не весь код покрыт тестами (да, я знаю, что это неидеально, но). Кроме того, есть масса случаев, когда код пишется в режиме залипухи, или в режиме "давай вот здесь быстренько подправим". И когда ты на это смотришь спустя год, ты не узнаёшь свой собственный код и нахуя ты это сделал. А когда на это смотрит другой человек — это вообще пиздец. Я не к тому, конечно, что нужно комментировать каждую x = x + 1, я к тому, что многие мои коллеги сэкономили бы годы жизни моей и других коллег, если хотя бы подписывали, НАХУЯ ОНИ ЭТО НАПИСАЛИ!!
#8163 2021-08-09 15:46:24
- Анон
Re: Тема айти
Кроме того, есть масса случаев, когда код пишется в режиме залипухи, или в режиме "давай вот здесь быстренько подправим". И когда ты на это смотришь спустя год, ты не узнаёшь свой собственный код и нахуя ты это сделал.
Во-первых, git blame. Во-вторых, это какой говнокод ты там пишешь, что спустя год не можешь понять, зачем это и как работает?
другой анон
#8164 2021-08-09 15:59:08
- Анон
Re: Тема айти
Во-первых, git blame.
Хаха. Избалованные гитом люди Куча старого говнолегаси, часть из которого написана на ебучем древнем языке. Лежит в репозитории, который сто раз переезжал вместе с конторой и в который коммитили разработчики, десять лет назад ушедшие. И вот если бы все эти люди пятнадцать лет назад подписывали, зачем они изменили высоту объекта на 1.58 м, мне было бы намного, намного проще работать.
Во-вторых, это какой говнокод ты там пишешь, что спустя год не можешь понять, зачем это и как работает?
С говнокодом я согласен, анон (см.выше), но ты удивишься: куча людей спустя год не может понять, нахуя это было сделано. Особенно если в авральном режиме. Проверялось не только на нашем говнолегаси, на нормально выстроенной разработке и с нормальным человекочитаемым языком.
#8165 2021-08-09 16:14:49
- Анон
Re: Тема айти
Куча старого говнолегаси, часть из которого написана на ебучем древнем языке.
Самый обычный код, написанный нормально, и через 10 лет можно будет понять, если писать его не через жопу. Если 10 лет назад какие-то твои коллеги написали говнокод, а вы продолжаете вокруг него наводить новый говнокод, прикрываясь комментариями, то это проблема конкретно вашего говнокода, а не норма в индустрии.
но ты удивишься: куча людей спустя год не может понять, нахуя это было сделано. Особенно если в авральном режиме. Проверялось не только на нашем говнолегаси, на нормально выстроенной разработке и с нормальным человекочитаемым языком.
Верю, что такое бывает. Не верю, что таких случаев в проекте так много, что весь код нужно накрепко комментировать. Я ж не говорю, что вообще ничего не надо комментировать - анон, с которым ты спорил, то же самое тебе писал. Если в вашем проекте нужно комментировать каждый метод или строчку, то это не просто легаси - это говнолегаси. Таких проектов, к счастью, не так много осталось.
#8166 2021-08-09 16:17:35
- Анон
Re: Тема айти
Самый обычный код, написанный нормально, и через 10 лет можно будет понять, если писать его не через жопу.
Код-то да, а вот зачем он был сделан? Окей, ты прекрасно понял, что вот этот кусок, допустим, ограничивает размер передаваемых пакетов до 2047 строк. Это нормальным языком написано, у тебя всё хорошо с мозгами, кусок понятен. Но нахуя? В какой части сборки это используется? Можно ли это выпилить? Что посыпется, если ты это выпилишь?
#8167 2021-08-09 16:28:23
- Анон
Re: Тема айти
Код-то да, а вот зачем он был сделан? Окей, ты прекрасно понял, что вот этот кусок, допустим, ограничивает размер передаваемых пакетов до 2047 строк. Это нормальным языком написано, у тебя всё хорошо с мозгами, кусок понятен. Но нахуя? В какой части сборки это используется? Можно ли это выпилить? Что посыпется, если ты это выпилишь?
У тебя весь проект из таких кусков что ли? Конкретно этот можно и откомментировать, но нахрена комментировать все подряд? Если у вас такой сложный проект, где так много нюансов на каждом шагу, то проще уже написать вики, а не захламлять код кучей комментов.
Отредактировано (2021-08-09 16:28:40)
#8168 2021-08-09 16:47:14
- Анон
Re: Тема айти
Хаха. Избалованные гитом люди Куча старого говнолегаси, часть из которого написана на ебучем древнем языке.
Какая разница, на каком языке написан код? Или он написан еще до появления какой-бы то ни было системы сорс контродля?
НАХУЯ ОНИ ЭТО НАПИСАЛИ!!
В каком смысле? Если на выскомо уровне - то "нахуя" должно быть описано не в коде, а там, где описываются требования к продукту. Если на уровне кода, то название метода и наименование переменных должно показывать, что делает код.
Если зачесались руки написать комментарий, значит уже появился кусок, который делает отдельную логику, и он должен быть выделен в отдельный метод. Если код не читаем через год после написания, то это проблемный код. И надо работать с его качеством. Иначе возникают вопросы: почему время написать комменты есть, а время удобоваримо назвать метод и переменные - нет?
#8169 2021-08-09 16:50:54
- Анон
Re: Тема айти
Но нахуя? В какой части сборки это используется? Можно ли это выпилить?
Стори и его номер в коммите. Н-р, баг коммуникации с сервером, если размер пакета меньше чем... Ты поправляешь этот баг и в коммите пишешь - баг номер xxl - поправка коммуникации с сервером. А так ты пытаешься что ли фнукцию сорс контроля и документации переложить на комменты?
#8170 2021-08-09 16:52:15
- Анон
Re: Тема айти
У тебя весь проект из таких кусков что ли? Конкретно этот можно и откомментировать, но нахрена комментировать все подряд? Если у вас такой сложный проект, где так много нюансов на каждом шагу, то проще уже написать вики, а не захламлять код кучей комментов.
Окей, я расскажу вкратце. Есть много кусков кода на разных языках, которые делают разное. Условно один считает статистику на R, второй моделирует физику на матлабе, третий генерирует пакеты в сеть на C++. Есть интерфейс и множество отладочных гуёв к нему, которые то самое ебучее говнолегаси, которому уже лет пятнадцать и которое поддерживают как могут. Это всё делают разные разработчики, поскольку семируких восьмихуев, которые и на матлабе, и на плюсах, и на древнем наречии говнолегаси, мало. Есть отдельная команда, которая пытается переписать интерфейс на чём-то приличном, условно на джаве. Есть отдельная команда, которая интегрирует разработку и тестирование, они вообще не разработчики, в более приличной конторе они назывались бы девопсами.
И вот один из девопсов обнаруживает, что у него режутся пакеты до 2047 строк. Он быстро понимает, что дело в говнолегаси, а не в остальных кусках. Он лезет в древнее наречие и читает там
то вот этот кусок, допустим, ограничивает размер передаваемых пакетов до 2047 строк. Это нормальным языком написано, у тебя всё хорошо с мозгами, кусок понятен.
с некоторым трудом, потому что он не разработчик на древнем наречии, но тем не менее. Он лезет в репозиторий (предположим, что он работает нормально, а не как у нас) и видит коммент:
12.05.2011 ivan petrov #12345 fixed bug
или
12.05.2011 ivan petrov some changes from installation
(мы же помним, что разработчики часто работают в дедлайне и на местах инсталляции?)
или даже
12.05.2011 ivan petrov finally the packets work!
(а зачем комментировать код подробно, он же свой, всё же и так понятно!)
Дальше девопс лезет в трекер в баг #12345 (снова предположим, что трекер работает нормально и не переезжал шесть раз за десять лет, как у нас) и среди переписки с тестерами и менеджерами пытается понять, что произошло. Или лезет к Ивану Петрову и пытается спросить, что же такое тот писал десять лет назад, нахуя и что поломается, если увеличить размер пакетов. Или (поскольку Иван Петров уже семь лет как уволился, дураков нет в шарашке работать) лезет в говнолегаси сам или просит команду разработки говнолегаси. И на всё это уходит время, силы и иные ресурсы девопса. И всего этого можно было бы избежать, если написать в коде, в репозитории, а лучше там и там
Уменьшил размер пакетов до 2047, только для мурманской инсталляции (т.к. %железканейм% в Мурманске принимает UDP только такого размера)
#8171 2021-08-09 16:54:10
- Анон
Re: Тема айти
Или он написан еще до появления какой-бы то ни было системы сорс контродля?
Да. Системы контроля и репозитории с тех пор менялись много раз.
а там, где описываются требования к продукту.
Хаха *звуки зависти к нормальному процессу разработки *
А так ты пытаешься что ли фнукцию сорс контроля и документации переложить на комменты?
Именно.
#8172 2021-08-09 16:56:49
- Анон
Re: Тема айти
Хаха *звуки зависти к нормальному процессу разработки *
Ну так, анон, у тебя было
они выше этого, они даже код не комментируют!
Типа, отсутсвие комментариев - это признак плохого кода/процесса.
Так вот ты сам в своих постах проиллюстрировал, что _наличие_ комментариев - это симптом того, что с кодом и/или процессом что-то не так (без комментов невозможно разобраться, что и нахуя написано)
#8173 2021-08-09 16:59:32
- Анон
Re: Тема айти
Дальше девопс лезет в трекер в баг #12345 (снова предположим, что трекер работает нормально и не переезжал шесть раз за десять лет, как у нас) и среди переписки с тестерами и менеджерами пытается понять, что произошло. Или лезет к Ивану Петрову и пытается спросить, что же такое тот писал десять лет назад, нахуя и что поломается, если увеличить размер пакетов. Или (поскольку Иван Петров уже семь лет как уволился, дураков нет в шарашке работать) лезет в говнолегаси сам или просит команду разработки говнолегаси. И на всё это уходит время, силы и иные ресурсы девопса. И всего этого можно было бы избежать, если написать в коде, в репозитории, а лучше там и там
Так если иванов-петров в коммитах т в документации не может написать, что и нахуя он сделал, что тебя заставляет думать, что его комменты будут лучше? Все, что ты описал, это не проблема отсутсвия комментов.
#8174 2021-08-09 16:59:50
- Анон
Re: Тема айти
Или он написан еще до появления какой-бы то ни было системы сорс контродля?
Да. Системы контроля и репозитории с тех пор менялись много раз.
а там, где описываются требования к продукту.
Хаха *звуки зависти к нормальному процессу разработки *
А так ты пытаешься что ли фнукцию сорс контроля и документации переложить на комменты?
Именно. Хотя бы потому, что а) код пишется разными людьми на куче разных языков, и о централизованных процессах типа непрерывного контроля речи вообще не идёт; б) в силу специфики работы (много мелких проектов, которыек сдаются в разных городах разными командами) очень много работы делается на местах и в режиме затычки; в) документация, по убеждению коллег, вообще дело техписов, ведь код-то и так понятен!
что _наличие_ комментариев - это симптом того, что с кодом и/или процессом что-то не так (без комментов невозможно разобраться, что и нахуя написано)
Нет, наличие комментариев — это симптом того, что разработчики комментируют код. Может быть, что с процессом что-то не так, как в нашем случае. Может быть, нет. И нет, я не говорил "что", я говорил "нахуя".
#8175 2021-08-09 17:01:31
- Анон
Re: Тема айти
Нет, наличие комментариев — это симптом того, что разработчики комментируют код.
Я уже писала, какая проблема с комментированием кода: нужно обновлять одновременно и код, и комменты. Читать надо не только код, но и комменты ( а нахуя, если код понятный?). Комменты нужны только тогда, когда это неочевидное решение. Не надо засирать код комментами. Это мусор в коде.