Архив недели @funbox_team
Понедельник
Всем привет! Меня зовут Сергей Нагаев, и я разрабатываю бэкенд на Python в компании FunBox. А еще руковожу командой таких же разработчиков, как и я сам. В треде традиционно немного про то, о чем будем говорить на этой неделе. Ну и немного о себе)
План недели:
День 1. IT-попаданцы: как стать и что делать дальше.
День 2. Тестовое, собес и все-все-все.
День 3. Особенности (интер)национального фриланса.
День 4. Рефакторинг: когда, кому, зачем?
День 5. Так ли плохи галеры?
День 6. Python: аннотация типов против динамической типизации. Или не против?
День 7. Тестирование.
С программированием я впервые познакомился, когда мне было 9 лет. Набрел в школьной библиотеке на "Энциклопедию профессора Фортрана" и... мир больше никогда не был прежним. Перечитал про компьютеры всю литературу, до которой только смог дотянуться (и которую смог понять).
Уже через несколько месяцев писал программки на QBASIC в... тетрадке) Да, компьютера не было, но была тетрадка) И учебники по QBASIC. Свой комп у меня появится только через 5 лет. По окончании школы мне "пришлось" разделить взгляды родителей на мое будущее и поступить на юрфак :)
Далее 5 лет университета (специальность "Гражданское право и процесс", 3 года аспирантуры и 9 лет работы помощником судьи в областном суде. Да, я из тех, кто ушел в IT после тридцати и вот-это-вот-все :) Уходил долго и плавно.
Во-первых, потому, что я ленивая попа и много боялся. Во-вторых... да и во-вторых, наверное, тоже. Как и в-третьих, и в-десятых. Давайте вот прямо сегодня об этом и поговорим!
Тред (Сергей Нагаев)
IT-попаданцы.
На одном из подкастов, куда меня как-то приглашали ребята из IT Way (найти бы их твиттер, прастити, я не местный 😜) как-то стихийно возник этот термин. Мне кажется, он очень точно отражает людей, которые идут (и входят) в IT из других сфер и профессий.
А давайте слегка проголосуем? Вот конкретно у вас IT'шное образование?
🤔
48.7% Да, и я в IT🤔
31.0% Нет, и я в IT🤔
14.2% Нет, но я собираюсь в IT.🤔
6.1% Что такое образование?Ого! Результаты пока огонь! Почти каждый третий однажды взял себя за... в руки!) И это очень круто!
Казалось бы, что вообще можно рассказать об IT-попаданцах в мире, где из-за каждого угла орут о том, как это можно легко сделать, а каждое второе объявление обещает этому научить, сделав из каждого крутого мила?
Ну... в первую очередь то, что это ровно такие же разработчики, админы, тестировщики, как и их коллеги с профильным образованием. Они не лучше, не хуже. И даже не другие. Мне кажется, есть сферы, где таких даже большинство. Все, кого я знаю - классные специалисты.
Твиттер - не самое лучшее место, где можно описать сколь-либо подробный roadmap того, как идти в IT. И я, наверное не буду. Всякие визуализации успешных успехов никогда не работали, и тут не будут. Ачивки с курсов - всего лишь ачивки, до которых никому нет дела.
А единственный применимый совет: "пахать как не в себя, изучая не магию, но как все это работает под капотом" - слишком банальный.
По опыту моему и моих коллег после старательного изучения основ пути ровно два.
Первый: как можно раньше попасть в компанию, где вас обучат всему остальному. Второй: пойти на фриланс, набить ру... шишек, убедиться, что вы способны зарабатывать этим, что вы ловите с этого кайф, драйв и... добро пожаловать на путь №1! :)
Тред (Сергей Нагаев)
Как перетащить в IT друга/подругу/родственника?
Никак. Никакие уговоры, рассказы, обещания и зарплаты не сгенерируют в человеке настоящей мотивации. Помочь можно лишь тому, кто замотивирован сам по себе. Хотите кого-то замотивировать? Не тратьте время: ни свое, ни чужое.
Вторник
Собесы и тестовые задания.
Новый день, и мы продолжаем! Давайте я для разминки накину... небольшое голосование?
Как вы считаете, нужны ли вообще тестовые задания?
🤔
21.3% Обязательно🤔
61.3% Только в особых случаях🤔
17.4% Нет, это абсолютное злоИтак, тестовые задания.
Решил поговорить на эту тему, т.к. периодически их проверяю, и принимаю участие в собеседованиях питонистов.
Собесы и тестовые задания. Новый день, и мы продолжаем! Давайте я для разминки накину... небольшое голосование? Как вы считаете, нужны ли вообще тестовые задания?
В одном из комментов к опросу (twitter.com/itunderhood/st…) была высказана мысль о том, что тестовое задание имеет смысл исключительно для кандидатов с минимальным опытом. И, на самом деле, я сам очень долгое время придерживался именно такой же позиции.
И тут такое: "но однажды все изменилось" 🤓 Со временем я пришел к выводу, что давать тестовое человеку без опыта (м.б. не вообще, но в конкретном языке) или джуну бессмысленно. Т.е. зачем давать тестовое тому, кого все равно надо либо учить с нуля, либо очень сильно доучивать?
А вот опыт человека со стажем в 3-5 лет может быть очень и очень разный. Очень далеко не во всех компаниях есть код-ревью, сколь-либо соблюдаемые процессы, стандарты качества кода и пр. Нанимая людей с опытом, компании, очевидно, не рассчитывают тратить много времени на обучение.
Но ситуация, когда в резюме у кандидата заявлено 3 года опыта, а в тестовое, при этом, являет собой образец того, как писать нельзя - это, блин, вообще не редкость. И для меня такое было открытием. Возможно, всему виноват низкий порог входа в Python. Возможно - что-то еще.
И да, я совершенно не хочу сказать, что такие кандидаты безнадежны или что-то в этом роде. Их тоже можно и, нередко, нужно брать, просто надо хорошо понимать, что выпустить такого разработчика в бой ни сегодня, ни через неделю не получится. А это возможно далеко не всегда.
Тред (Сергей Нагаев)
Ошибочно думать, что тестовые задания - это вещь, которая способна рассказать что-то только о вас. Уже по нему часто можно судить о компании, хоть и поверхностно.
Тестовое задание здорового человека: небольшая задача из расчета на 2-3 часа работы, не больше.
Без какого-либо потенциала коммерческого применения результатов. Возможны и более сложные варианты на бОльшее время работы, но такое тестовое должно оплачиваться. И да, договор на оплату такого рода задания должен быть заключен ДО того, как вы к нему приступите.
Так, среди моих знакомых бывали случаи, когда не слишком хорошие конторы пытались использовать такие задания, чтобы делать свою работу чужими руками. И, вроде бы, все мы не глупые, все все понимают, но почему-то люди до сих пор попадаются.
Получили тестовое задание с непонятным, нечетким описанием, допускающим разное толкование? Связаться с HR'ом лишний раз, конечно, не грех, но есть шанс, что после трудоустройства задачи вам будут ставить как-то так же)
К вопросу о попытках делать свою работу чужими руками: не раз и не два слышал от знакомых тестировщиков о предложения в рамках таких заданий потестировать боевые сервисы работодателей. Уже само по себе звучит странно, согласитесь.
Лично знаю компании, часто нанимающие QA-спецов и содержащие для этого отдельные специально забагованные сайты/приложения.
Тред (Сергей Нагаев)
А вы готовитесь к собеседованиям?
🤔
58.5% Обычно да🤔
30.2% Обычно нет🤔
11.2% У меня их не былоЕсть мнение, что специально готовиться к собеседованиям не стоит. Поясню, почему. Задача здоровой компании на собесе в том, чтобы выяснить границы знаний кандидата и оценить их с т.з. релевантности своим задачам. Ну или оценить трудозатраты на (до/пере)подготовку человека.
Как обычно готовятся? Берут все непонятные слова из вакансии и начинают судорожно тоннами об этом читать. Стряхивают пыль с книг по алгоритмам, еще по чему-нибудь на всякий случай (вдруг спросят). И вдруг... спрашивают. И (о чудо) человек уверенно отвечает.
Интервьювер, нащупав знание человека на этой границе, переходит к следующему пункту, кандидат - просто счастлив, все хорошо. На самом деле не всегда. Ни у кого в универе не было такого: все, что прочитано в день/ночь перед экзаменом, забывается через день/ночь после экзамена?
При подготовке к собесу та же беда. И беда для обеих сторон. Если про экзамен мы забываем, выходя из аудитории, то у интервьюера фиксируется ошибочная оценка. И оно потом может быть положено в основу того пула задач, который на вчерашнего кандидата ляжет.
Справится ли он? Ну... шанс есть всегда. Стоит ли оно того? Я считаю, нет. Работая, в свое время, в аутсорсинговой компании, я готовил людей к собесам. И не помню толком случаев, когда такого рода "оверподготовка" играла потом на пользу людям на проектах.
Ваше незнание чего-то - это не ваш недостаток. Это просто такой же факт, как и... длина ваших волос, например). И он может быть при необходимости исправлен в будущем. Стесняться этого не надо и иногда даже опасно. Нет, сам я к собесам никогда не готовился)
Тред (Сергей Нагаев)
@itunderhood Работодатель ищет идеального кандидата завышая требования к позиции в вакансии, соискатель представляет на собеседовании лучшую версию себя, вроде бы все честно)
Собес здорового человека.
Один из ответов в предыдущем треде (twitter.com/I7PAKTuKAHT/st…) сам по себе - отличная тема для нового треда :) Так, вообще, многие считают. Но есть большая разница между собесом, как я написал, здорового человека (компании) и собесом нездоровым.
Здоровое собеседование - это когда интервьюер "прощупывает" опыт и знания кандидата на предмет их релевантности задачам компании.
Нездоровый собес - это когда работодатель ищет пробелы в знаниях, чтобы выделить их и максимально обесценить опыт кандидата. Тем самым, сбить цену.
Да, это МОГУТ быть (но не обязательно, вдруг просто интервьюер был неопытный) ровно те самые кейсы, когда на собесе надо было повернуть бинарное дерево, а в работе приходится сутками менять цвета кнопочек. Нездоровый собес часто можно выявить в процессе самого собеса.
Достаточно не забывать, что собеседование - вещь обоюдная, и вы вправе собеседовать компанию не меньше, чем она вас. Не стесняйтесь задавать вопросы относительно предполагаемого проекта, технологий, типичных задач и пр. Это очень помогает.
Тред (Сергей Нагаев)
Среда
Новый день и новая тема!
А вы пробовали себя во фрилансе?
🤔
11.5% Да, понравилось🤔
27.0% Да, не понравилось🤔
20.2% Нет, но хочу🤔
41.3% Нет и не хочуФриланс - тема почти бесконечная. Даже для обсуждения в формате, скажем, Хабра. С одной стороны, у меня достаточно большой опыт фриланса. Я и в IT зашел, по сути, именно через него. С другой стороны, я до сих пор не могу определиться с пониманием: для кого он хорош.
Казалось бы, настолько свободное плавание должно быть под силу только крутым опытным кодерам. Но там немало ниш как технологических, так и ценовых, где новички без какого-либо промышленного опыта чувствуют себя, как минимум, неплохо.
Назвать же фриланс темой для новичков язык не поворачивается. Тут уже в комментах понабрасывали типичных фрилансерских болячек: отсутствие нормального ТЗ, нестабильные заказчики и пр. Фриланс требует жесткой самодисциплины, прокачанных софт-скилов, продвинутых навыков оценки и..
И еще кучу всего, чего у новичка быть не может по определению. И все же, я уверен, - это идеальный способ макнуть самого себя в эдакую рафинированную айтишную реальность, когда тебя не прикрывают ни менеджер, ни лид, ни команда.
Когда ты максимально чувствуешь ценность каждого затраченного часа. И по-настоящему больно всякий раз, когда грубо ошибаешься с оценкой. А еще поддержка. Ничто так здорово не учит документировать и покрывать тестами собственный код, как возвращение прошлогоднего заказчика!
А еще мы в ответе за тех, кого приручили) И если вы написали заказчику сервис или приложение, готовьтесь его поддерживать. Иногда диву даешься, сколько могут жить и использоваться плоды твоих трудов.
Так, пару месяцев назад мне на email написал один из заказчиков, которому я что-то наваял на VBA (VBA, Карл!!!) году так в 2014-м. Я даже не сразу вспомнил его. В то время я брал все заказы подряд. Написал ему скрипт часа за два, а он им пользуется уже 7 лет!
Тред (Сергей Нагаев)
Самая большая проблема фриланса, как мне кажется, в отсутствии развития. Возможно, это была только моя проблема. Неизвестная технология == нет адекватной оценки == не беремся. В итоге часто брались однотипные или очень похожие заказы.
Чему я по-настоящему научился на фрилансе - это сразу же говорить заказчику неприятную правду о сроках-стоимости. Да и учиться этому довольно легко, когда любая попытка выглядеть в оценках лучше, чем ты есть - за твой счет :)
Многие отмечают боль работы без ТЗ. Ибо и ТЗ, и аналитика - все на тебе. Да, это так. Но после такого, работая в компании, смотришь на работу менеджеров совсем другими глазами.
Есть интереснейшая зависимость между потребностью на рынке и ценой. Так, когда я только начал фрилансить, я, осознавая свой опыт (точнее, его отсутствие), скромничал с расценками. Фрилансил я на Upwork, рейт у меня был невысокий: сначала $5, потом $7/час.
Было непросто: с такой ставкой я был вынужден конкурировать с фрилансерами из Индии и Пакистана. Новые клиенты добывались с трудом: я каждый день подавал десятки заявок, и очень редко заказчики мне писали сами.
В какой-то момент я психанул и выставил себе рейт в $25/час. Блин... такого наплыва приглашений поработать я до этого не видел никогда! И это не были какие-то особо сложные задачи: не сложнее тех, что я делал за $7. Только теперь это были $25 при в разы меньшей конкуренции.
Четверг
Давайте по-честному: как часто вы сталкиваетесь с задачами на рефакторинг?
🤔
33.0% Почти каждый спринт/релиз🤔
38.8% Только когда припрет🤔
19.1% Реф.. что? Работать надо!🤔
9.1% Ко мне неприменимоСколько вы видели откровенно упоротых по состоянию кода проектов? Сколько из них разрабатывалось такими специально? Сколько из них сейчас проще переписать с нуля? А был в истории этих проектов момент, когда такой проблемы можно было бы избежать, начав рефакторить код?
А где располагается эта точна на временном отрезке жизни проекта, когда "стало нужно рефакторить"? Смогли ответить на предыдущий вопрос?) Если да, тогда я спрошу еще: а рефакторинг действительно стал нужен именно с конкретной даты? Неделей ранее он еще нужен не был?
Момент, когда для добавления новой фичи нужно пошлифовать старые или что-то, хотябы минорно, переделать, настает на каждом проекте рано или поздно. И это, по сути, не проблема - это нормальная часть рабочего процесса. Часть жизненного цикла продукта.
Проблемой оно становится тогда, когда на добавление условной кнопки начинает уходить не час, а день. Или три дня. Или неделя. Когда достаточно простые, на первый взгляд внедрения в код начинают тащить за собой лавину доделок, допилов и костылей.
Которые, в свою очередь, уже через неделю начнут мешать внедрению новой очередной фичи. И команда начинает вылезать за оценки, менеджмент и заказчики - откровенно агриться. Начинают приниматься решения типа "так, сроки горят, ща бегом сдадим, а потом видно будет".
Но все, что видно потом - это растерянное лицо менеджера, и гневное лицо заказчика, искренне негодующего: "Вы же профессионалы! Какого фига я жду эту фичу уже неделю?!" Проект начинает обрастать дурной славой среди коллег. Попасть на него - фуфуфу! Лучше вон на тот, новый!
Знакомо? Флешбеки пошли?) Тогда нам есть о чем поговорить)
Тред (Сергей Нагаев)
Есть мнение (весьма радикальное), что абсолютно любой проект рано или поздно скатится в г (если, конечно, не закроется раньше). И полностью избежать такого финала невозможно. Но можно максимально его оттянуть. Для этого не нужно писать без багов - это из области фантастики.
Можно провести аналогию между рефакторингом и уборкой квартиры. Вот когда надо начать убираться? Когда станет трудно зайти в дом? Или когда будут заносить новую мебель?) А давайте каждый, живущий в ней, будет убираться только там, где считает нужным и как считает нужным?
Я сейчас привел два самых распространенных, на мой взгляд, заблуждения относительно рефакторинга. Первое - рефракторим только по факту добавления фичи. Выглядит очень соблазнительно. Особенно тем, что пахнет избежание преждевременной оптимизации.
"Да, есть плохой код. Но что сейчас его трогать, если он пока никому не мешает? Вот затронет он фичу, зарефакторим." Это такой себе ad hoc-рефакторинг под конкретные кейсы.
Второе заблуждение: глобальный рефакторинг не нужен, разработчики должны самостоятельно прибираться везде, где увидят. Соблазнительно снятием ответственности с лида и менеджера. Такая себе приятная иллюзия анархии, в которой должен рождаться порядок.
Только вот он не родится. Где два программиста, там, нередко, три архитектурных видения. А когда программистов 5 или 10? И каждый будет рефакторить в своем видении. При этом разработчики часто могут быть не вовлечены в глобальные планы по развитию проекта.
И могут не иметь представления о том, что в ближайшем или не очень будущем в проект планируется добавить, а что будет гарантированно убрано. Но рефакторят, как видят. Благое начинание, но оно только ускорит приход состояния "Г."
Ad hoc рефакторинг опасен ровно таким же ситуативным и бессистемным внедрением в код, который никем, по сути, не управляется. В итоге порядок и способ внедрения фич начинают диктовать архитектуру. А не наоборот. Итог предсказуем.
Тред (Сергей Нагаев)
Пятница
Продолжим немного по рефакторингу. Я глубоко убежден, что, рефакторинг, как и любое другое внедрение в код, должен быть управляемым. А "чтобы управлять, нужно, как-никак, иметь точный план" (с) Воланд.
Поэтому я большой противник стихийного и случайного рефакторинга.
Важность рефакторинга должна осознаваться не только разработчиками, но и лидом (да, такое не всегда и не везде), и, что очень важно, менеджментом. Как менеджеры будут продавать этот рефакторинг (никак) - тема совершенно отдельная.
Важно, чтобы (тим/дев)лид осозновал весь скоуп задач на рефакторинг. Особенно, если он по каким-то причинам сам в данном проекте не кодит. Должно быть четкое представление о том, что плохо сейчас, и о том, что, когда и как мы будем делать лучше.
Должен быть бэклог на рефакторинг, а сами задачи на него - добавляться в спринт уже на этапе планирования и быть неотъемлемой частью спринта/релиза. И да, разумеется, инициатива на рефакторинг может и должна исходить от самих разработчиков. Это нормально.
Иными словами, рефакторинг в моих глазах - это полноценная, постоянная, согласованная командная работа. Отдавать ее на откуп только разработчикам (или отдельным из них) неправильно.
Тред (Сергей Нагаев)
Так когда надо начинать рефакторить? Кмк, с первого дня работы над проектом. Не надо дожидаться, когда проекту и разработчикам станет больно. Пусть с первого же дня будет история или эпик, куда и разработчики, и девлид начнут складывать свои задачи-заявки на причесывание кода.
И откуда эти задачи будут заноситься на стадии планирования в спринты. Это позволит с самого начала держать рефакторинг в уме, а потребности - на виду, не доводя до ситуации, когда "надо бросить все и срочно переделать вот эту вот фичу".
Доводилось ли вам работать в компаниях, занимающихся аутсорсингом/аутстаффингом?
🤔
30.1% Да, понравилось🤔
24.9% Да, не понравилось🤔
37.3% Нет🤔
7.7% Что?! Это?! За слова?!Суббота
Доводилось ли вам работать в компаниях, занимающихся аутсорсингом/аутстаффингом?
Очень интересные получились результаты опроса: twitter.com/itunderhood/st…. Практически половина из тех, кто прошел через аутсорс, остались довольны. Это, мягко говоря, не совпадает с отзывами из моего окружения. Да, лучшее подтверждение, насколько все субъективно.
Мне вот в такой компании, я считаю, очень везло и с проектами, и с тиммейтами, и с лидами. Очень немногие из моих знакомых могут похвастаться тем же. Но вот, вижу, что далеко не все так плохо! :)
В то же время я на примерно 146% согласен с @Wolf_Musing, что аутсорс - лучший способ понюхать пороху для желающих войти в IT. Более того, это, возможно, один из самых реальных способов это сделать, если вы вчерашний выпускник курсов или просто самоучка без коммерческого опыта.
Аутсорс-компании, как правило, одни из немногих, готовых брать людей без опыта с прицелом на "выучить и выпустить в бой под чутким присмотром ментора". Правда, качество "выучивания" и присмотра очень сильно зависят от компании и конкретного ментора. Да, лотерея.
Но каким бы ни был исход такой лотереи, вы все равно с очень высокой вероятностью получите свой первый (а, может, и второй, и третий) боевой опыт, который будет вполне себе котироваться на рынке.
Тред (Сергей Нагаев)
А много среди нас питонистов?!
🤔
38.4% Я! Я питонист!🤔
61.6% Ха! Мое кунг-фу лучше!А что вы думаете насчет явного указания типов в языках с динамической типизацией?
🤔
7.9% Полный бред. Не нужно🤔
65.6% За! Полезно🤔
16.8% Не определился пока🤔
9.7% Не в курсе, о чем речьЛень vs Аннотация типов в Python
3:1
По плану сегодня хотел немного порассуждать на тему аннотации типов (type hints) в Python. Питонистов среди нас немало, но, все-таки, не все. Так что, возможно, сдвинем фокус на вообще языки с динамической типизацией. Посмотрим)
Сама идея использования аннотации типов в Python поначалу многими была встречена не очень однозначно: язык с динамической типизацией, к чему ему это? Да и вообще, у нас и так очень простой синтаксис, нечего его загромождать всяким капитанством.
Некоторые мои коллеги на полном серьезе так и думали. А кое-кто делает это до сих пор) Кстати, прямо сейчас пишу эти строки, смотрю на голосование и вижу, что из 50, пока, проголосовавших ни один не выбрал пункт "Не нужно", и откровенно радуюсь :)
Основной довод противников был в том, что явное указание типов посягает на святую святых - динамическую типизацию. Чтобы убедить всех в обратном авторы PEP 484 пошли на достаточно интересный шаг.
Так, документ получил своего рода преамбулу, гласяющую, что Python останется языком с динамической типизацией, и авторы не планируют придавать обязательный характер аннотации типов. Даже в рамках соглашений. Думаю, это многих успокоило)
И вот, аннотация типов у нас присутствует. Но, даже если мы ее и используем, проверка согласования типов интерпретатором не осуществляется. Для этого надо использовать сторонние инструменты. Тот же Mypy, к примеру. Однако и он работает для нас, а не для интерпретатора.
Можно абсолютно смело объявлять типы, писать там всякую фигню, и это ни на что не повлияет. Свобода...
Тред (Сергей Нагаев)
Лень vs Аннотация типов в Python
3:1
Проблема с аннотацией типов не в том, что ее кто-то не признает ее пользу или что-то в этом роде. Просто это, блин, еще одна вещь, про которую все знают, что она есть, что она полезна... но мало кто ее внедряет всерьез.
Ну практически как у нас с пандемией и масочным режимом. Да, внедренная аннотация типов с проверкой, включенной в Quality Gate на уровне CI, по первости будет генерировать дополнительные трудозатраты на причесывание кода. Но в дальнейшем эти самые трудозатраты окупаются.
Понятно, что полноценно завести аннотацию типов в легаси-проект, это долго, дорого и больно. Но есть же новые проекты, есть проекты, которые еще не успели обрасти тоннами функционала.
Когда я спрашивал коллег, почему они не хотят полноценного внедрения type hints на таких проектах, самым частым ответом было "геморно". Т.е. лень. И это грустно.
Тред (Сергей Нагаев)
Воскресенье
Аннотация типов: это диверсия!!!
В завершение тредов по Type Hints в Python у меня есть небольшое признание. Мы используем ее на всех своих проектах, и я очень к ней привык. И, как пользователь языка, я давно не чувствую никакого профита от динамической типизации.
И аннотация типов здесь не единственный виновник, но ключевой. И я не вижу ничего плохого в том, что она заставляет кодера явным образом продумывать и указывать типы до того, как этой же работой займется интерпретатор. В конечном счете, "явное лучше неявного" (c) Zen of Python
Получается, что мне комфортнее жить мире, где типизация явная. И Python с его Type Hints, предлагает не лучшую, на мой взгляд, реализацию такого подхода. В том же Rust это... кхм. Ну это уже совсем другая история :)
Не пренебрегайте тестированием.
Тестирование - тема, которая незаслуженно отодвигается на второй план как многими действующими разработчиками, так и теми, кто только собирается войти в IT. Почему-то принято считать, что это "просто", "понятно", и говорить тут особо не о чем.
Применительно к разработчикам - это вопрос умения писать тесты. И вопрос умения тестировать свой же продукт руками. Практически все практически всегда убеждены, что умеют это делать. Но на деле это, к сожалению, далеко не всегда так.
Будущих же IT-попаданцев тестирование может заинтересовать как точка входа в индустрию. Это крайне интересное направление, о котором многие даже не задумываются. Возможно, для кого-то данный тред - это шанс исправить это упущение :)
Войти в тестирование проще и быстрее, нежели в разработку. Что, в общем-то не означает, что данная сфера менее значима или чем-то там обделена. Да, есть кодеры, смотрящие на тестирование сверху вниз, и это абсолютно несправедливая позиция.
Хорошими тестировщиками может стать куда меньше людей, чем хорошими разработчиками. Что бы там ни говорили злые языки, но мыслить конструктивно в нашей природе. Особенно если это мысли о своем продукте. Мыслить деструктивно намного сложнее. Хоть по началу так и не кажется.
А мыслить деструктивно по отношению к своему продукту или фиче - сложнее на порядок. И в этом уникальность работы тестировщика. Поверьте, без их навыков наш с вами мир был бы намного, намного хуже.
Тред (Сергей Нагаев)
Учитесть тестировать.
Думаю, не буду глубоко погружаться сейчас в вопросы становления тестировщиков и важности этих навыков для разработчиков (хоть поначалу и планировал). Но я хочу призвать вас узнать об этой сфере немного больше.
Во-первых, почти невозможно написать надежное приложение, не имея четкого понимания, как оно должно тестироваться.
Во-вторых, если вы только планируете свое будущее в IT, тестирование вполне может стать его частью. Возможно, весомой, а возможно - промежуточной. Лично знаю тех, кто зашел через тестирование и, потом, ушел в разработку. Знаю и тех, кто там остался, ибо нравится.
Вокруг сотни книг по тестированию и тонны курсов. Просто ознакомьтесь :)
С чего начать? Ну, хотябы, с книги "Как тестируют в Google" :)
Тред (Сергей Нагаев)
Вместо итога.
Вести аккаунт оказалось не так-то просто. Надо больше времени, чем я думал. А еще я не привык к такому формату, не мыслил в нем, и мои заготовки оказались почти бесполезны: все приходилось писать с нуля. И это очень интересный опыт! :)
Если у вас есть вопросы - самое время их задавать! Потом тоже можно, но уже в личку на Facebook'e :) Если я пропустил где-то ваш вопрос - подсветите в личку, пожалуйста - обязательно постараюсь ответить)
Большое спасибо всем, что были со мной всю эту неделю! Надеюсь, было интересно)
Всем удачи!)