Не стану переписывать и копировать уже написанные тексты и доводы, просто почитайте “Null References: The billion dollar mistake” (“Нулевые ссылки: ошибка на миллиард долларов”) и связанные статьи. Если коротко - null это только для ошибок.
А потом понадобится добавить ещё квартиру, которая тоже будет подаваться как number (а если номера дома нет?) и потом из x полей, ака отдельные столбцы в базе данных, с разным типом данных мы будем собирать одну строку, когда могли просто в самом начале определить номер дома как строку и не думать об этом. Тип number полезен только когда требуются арифметические действия, для всего остального лучше использовать строку.
Зашёл почитать интересную статью о новых методах тестирования или администрирования, которые позволили бы сократить время тестирования или покрыть большее количество кейсов, а тут обычная жалоба на некомпетентность сотрудников.
Мой совет как QA, который уже миллион раз упоминался в статьях и книгах - автоматизируйте процессы, хотя бы кейсы по регрессии. И покажите разработчикам как с ними работать.
Статья о важности налаженных процессов написанная без использования этих процессов.
Очень много воды, тема не раскрыта, выводы спорные. Рекомендация менять проект раз в полгода - из серии вредных советов. Редко когда можно поменять проект в рамках одной компании, а держать работника по пол-года никто не захочет, разве что за копейки.
Зачем нужно было упоминание про нейронки в конце? Пойти учиться когда уже припекло - это не правильная реализация процессов и очень плохой пример развития нутриент скила.
Простой совет "Следите за новостями/трендами, читайте книги и развивайтесь" был бы куда более полезным.
Что если качество строительства будут утверждать сами строители.
Так качество строительства строители и утверждают 🙄 Прочитал статью - это либо крайне кривой перевод либо поток несвязных мыслей. QA существуют давно, более 30 лет, если для автора это недавно - наверное от 1000 летний вампир. По чистому коду тоже много вопросов, например почему его должно быть легче тестировать? Проще читать? Да. Он быстрее? Иногда. Но если функционально он не отличается, то и нагрузка при тестировании не должна отличаться.
В идеальном мире, команда проектирования не только может сделать график прямой линией, но и выгнуть его, то есть завершать проект без напряжения сил.
Зачем эти примеры из идеального мира? Должен быть график в котором будет заложено время на тестирование, фикс багов и возможную регрессию. Намного легче заранее заложить чуть больше времени, чем потом гнать всю команду и оправдываться перед клиентом.
гос. служащие, кто же ещё
Остальные знать не знают про этот мессенджер и тем более про то где предварительно регистрироваться
Это все конечно хорошо, но нарочное игнорирование определенного языка не делает чести, как минимум в моих глазах.
Первая часть очень понравилась, жаль что со второй так получилось.
К сожалению не срослось с инопланетяненом - он не умеет импортировать коллекции из постмана
А меня ещё называли параноиком когда я боролся за отказ от постмана :D
90гб проект? 8к текстуры? Ты молодец, спору нет, но явно стоит почитать хоть что-то про оптимизацию
Вижу АИ картинку в статье - скипаю.
Как раз ищу работу QA JS автоматизатора)
Аминь 🤝
Так же не забываем что это простой форк аосп и называть его российской ос тоже самое что и редос инновационной ос от отечественных разработчиков
Технически - не ограничивала, а программно - да 😁
Не стану переписывать и копировать уже написанные тексты и доводы, просто почитайте “Null References: The billion dollar mistake” (“Нулевые ссылки: ошибка на миллиард долларов”) и связанные статьи. Если коротко - null это только для ошибок.
А потом понадобится добавить ещё квартиру, которая тоже будет подаваться как number (а если номера дома нет?) и потом из x полей, ака отдельные столбцы в базе данных, с разным типом данных мы будем собирать одну строку, когда могли просто в самом начале определить номер дома как строку и не думать об этом. Тип number полезен только когда требуются арифметические действия, для всего остального лучше использовать строку.
Зашёл почитать интересную статью о новых методах тестирования или администрирования, которые позволили бы сократить время тестирования или покрыть большее количество кейсов, а тут обычная жалоба на некомпетентность сотрудников.
Мой совет как QA, который уже миллион раз упоминался в статьях и книгах - автоматизируйте процессы, хотя бы кейсы по регрессии. И покажите разработчикам как с ними работать.
Жаль что крупные проекты вышедшие в этом году не читали таких статей.
Потому что судя по всему компиляция шейдеров по 40ммнут на машине пользователя уже стала нормой для них.
Если бы у меня на работе я заявил что подготовка кастомера и карты под него будет занимать час - меня бы заменили на следующий день.
Приятная статья, но есть пара вопросов касаемо финального JSON'a пользователя:
Почему вы используете null вместо пустой строки?
Для номера дома тип number будет фатальной ошибкой
Статья о важности налаженных процессов написанная без использования этих процессов.
Очень много воды, тема не раскрыта, выводы спорные. Рекомендация менять проект раз в полгода - из серии вредных советов. Редко когда можно поменять проект в рамках одной компании, а держать работника по пол-года никто не захочет, разве что за копейки.
Зачем нужно было упоминание про нейронки в конце? Пойти учиться когда уже припекло - это не правильная реализация процессов и очень плохой пример развития нутриент скила.
Простой совет "Следите за новостями/трендами, читайте книги и развивайтесь" был бы куда более полезным.
Так качество строительства строители и утверждают 🙄 Прочитал статью - это либо крайне кривой перевод либо поток несвязных мыслей. QA существуют давно, более 30 лет, если для автора это недавно - наверное от 1000 летний вампир. По чистому коду тоже много вопросов, например почему его должно быть легче тестировать? Проще читать? Да. Он быстрее? Иногда. Но если функционально он не отличается, то и нагрузка при тестировании не должна отличаться.
Зачем эти примеры из идеального мира? Должен быть график в котором будет заложено время на тестирование, фикс багов и возможную регрессию. Намного легче заранее заложить чуть больше времени, чем потом гнать всю команду и оправдываться перед клиентом.