Senior Systems Architect
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Это называется вендор локинг. Гнилой продукт будет тянуть не понимающего клиента на дно, а продавец будет жив пока не переведутся не понимающие кастомеры. У подрастающего поколения уже на уровне подкорки укоренилась ассоциация IBM = боль. Остальное вопрос времени.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Wrong.
    1. Подмена System.out — бррр. Эксепшн внутри congrats? Паралельный ран? Аутпут с других потоков?
    2. Ничего не замокано. Я могу протестировать поздравительный сценарий один день в году?
    3. И вообще — ифы в тесте? Серьезно?
    Если это был прикол, то очень тонко, снимаю шляпу.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Об этом я и говорю, это вирус которому подвержены даже весьма крупные компании.. а потом в макоси можно стать рутом без пароля, айось крашится от символа в чате, и еще вагон примеров. Качество софта дико понизилось в последние годы, глобально на всей планете.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Это не имеет смысла тестировать

    Это имеет смысл тестировать, потому что вылавливается вся мелочь типа опечаток, случайно закомменченных строк итд еще ДО пулл реквеста и код ревью, а значит дешевле пофиксить. К тому-же код ревью становится более эффективным, поскольку diff юнит тестов сразу поясняет поведенческое изменение пулл реквеста без необходимости компилировать и симулировать в голове. Опять-же, это учитывая что все делается правильно, и тогда написание юнит тестов это не экстра эффорт, это сохранение времени at no cost. Именно потому было придумано TDD, поскольку когда сначала пишешь логику, а потом начинаешь думать как теперь это все протестировать — сразу начинаешь рефакторить только что написанный код, и вот тебе экстра эффорт. Отсюда и миф.. отсюда TDD.. но если понять фишку — TDD не нужно, просто думай о тестах сразу и соблюдай баланс, решай сам когда удобно писать эти тесты. В некоторых случаях юнит тесты могут служить технической документацией (как использовать этот класс и этот метод) а так же служить защитой от дурака (ну точнее от людей которые впервые работают с этим куском кодовой базы).

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

    О, конечно стоит, абсолютно согласен. Существует 1000 и 1 заблуждение про тестирование. Много копий сломано. Просто автор наехал конкретно на юнит тесты, потому я написал ответ конкретно про юнит тесты. Я ни в коем случае не ставлю юнит тесты важнее других видов тестирования. Нет такого вида тестирования, которое важнее чем другие. У каждого вида тестирования своя цель, и все они одинаково важны. Есть хорошо известная пирамида bfy.tw/I2Oz, иллюстрирующая сказанное. Которую, к слову, многие тоже неправильно читают (мол снизу значит нужно больше — хотя это значит снизу по факту получается больше, но не цель к которой нужно стремится).

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Идеально работающая деталь вне контекста продукта не имеет смысла.

    Ну а теперь возвращаемся на несколько страниц назад, и еще раз. Юнит тесты это в первую очередь инструмент разработки а не тестирования. Если разработчик в теме, он ни у кого не будет спрашивать разрешения что-бы писать тесты. Он просто будет их использовать, что-бы облегчить себе жить, сэкономить время и нервные клетки.

    Думаю, что именно этот хайп сыграл с TDD злую шутку.

    Согласен. TDD было попыткой популяризировать подход среди своей, технической аудитории.

    Я не видел потопленных продуктов из-за плохого покрытия юнитами.

    Да ладно... куда не ткни. Самая жесть начнется, как я сказал выше, в течении лет десяти. Пока только зреет.

    Зато я видел потопленные продукты из-за непонимания, как автоматизировать комплексное тестирование.

    True.

    Потому что покрытие юнитами даёт ложное ощущение надёжности.

    Also true.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    и надавать по рукам программистам-перфекционистам

    Плиз сразу скидывай в ЛС координаты провинившихся. Когда они будут бежать с тонущего корабля, мы их с удовольствием приютим, нам такие нужны :)

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Еще раз. Написание юнит тестов не тратит время а экономит его. Когда используется правильно, а не как мантра.
    1. Имея юнит тесты, не нужно сотни раз в течении дня собирать машину, выгонять ее на трассу и проезжать поворот просто что-бы проверить что нижнее положение переключателя включает именно левый поворотник.
    2. Код пишется сразу нормально декомпозированный, с развернутыми циклами и ифами, что заранее предотвращает накопление технического долга и уменьшает необходимость и частоту рефакторинга.
    3. Рано или поздно, когда рефакторинг таки нужен, или просто мажорное изменение — оно не превращается в полугодовой проект потому что люди боятся лезть в код который никогда не видели (не знаю что сломается). Как в свое время системы контроля версий дали свободу менять что угодно и как угодно в коде (потому-что всегда можно откатить), так юнит тесты позволяют менять что угодно и как угодно при этом сохраняя рабочее состояние и упрощая поиск точек вхождения, сломанных контрактов и прочих интерфейсов.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Я где-то сказал что юнит тесты заменяют интеграционные, функциональные, e2e, adhoc и еще кучу других типов тестов? Не припомню такого.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Ну не факт и не всегда.. есть например и BDD практики, где acceptance criteria либо сразу пишется тест кейсом (и оно практически plain English, например semaphoreci.com/...​h-protractor-and-cucumber), либо генерируется из acceptance criteria (например для бекенда acceptance criteria может быть задефайненый сваггер файл или модификация к нему из которой тесты могут быть сгенерированны автоматически).

    Поддержал: anonymous
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    TDD было придумано в контексте юнит тестов, поскольку их пишут разработчики то это никакие не разные команды. Тем не менее это действительно должно быть параллельно. Написание юнит тестов по ходу написания самого кода позволяет смотреть на код сразу с двух точек зрения — автора и пользователя (кода — другого программиста использующего твой класс или метод). Самый простой пример — извечный вопрос когда метод нужно делить на два. Когда попытаешься покрыть метод тестами, так сразу само станет понятно, когда и где его делить, как лучше развернуть цикл, как избежать вложенных if итд. Когда делается все правильно, написание юнит тестов не тратит дополнительное время, а наоборот его экономит.

    С остальными видами тестирования это отдельная история, однако согласен что это должно быть сделано тоже параллельно. Пока не решил для себя как лучше — видел и две команды работающие параллельно и DoD включающее покрытие тестами самим автором кода.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Продаю. Вы задумали построить свою машину. Придя в магазин — вы можете купить только типовой инструмент, например отвертку и пассатижи. Вам явно этого не хватит, вам потребуется изготовить некоторое количество своих собственных инструментов и станков для изготовления деталей автомобиля по вашему дизайну. Так-же, вероятно, вам придется сконструировать сборочный конвеер, поскольку собирать автомобили вручную — очень трудозатратно имея только одного синьора и двух мидло/джунов, и скорее всего каждая собранная машина будет иметь погрешности поскольку ручной труд слабо воспроизводим (каждая машина это каждый билд софта).

    Поддержал: Yuriy Pitometsu
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Рабочий продукт — прежде всего

    И именно поэтому нужно писать тесты, делать рефакторинг, а иногда и начинать сначала. За примерами далеко ходить не надо. Скоро выходит iOS 12, на секундочку мажорная версия, в которой судя по аналитике нововведений не будет вообще (впервые в истории). Про количество багов в последние годы я молчу. Система достигла критической массы (и речь не только о коде и вообще не только о технологиях), где любое мельчайшее изменение это сотни и сотни человекочасов. Эта тенденция прослеживается абсолютно в любом продукте. Я предрекаю новый кризис доткомов в течении 10 лет, и его причиной послужит микс нарощенной комплексити из-за супер-эффективного менеджмента, не понимающего цену рефакторинга и тестов, девелоперов не умеющих эту цену донести, ну и общий наплыв рандомных фейсов в индустрии, которые вообще не понимают что они здесь делают.

    По поводу юнит тестов хотелось бы замолвить отдельное словечко. Юнит тесты это в первую очередь инструмент разработки. Возможность проверить работу переключателя поворотника без сборки всего автомобиля и даже без сборки самого поворотника — экономит неописуемое количество времени и нервных клеток. А порой и прозвон косы без сборки даже самого переключателя. И уже во вторую очередь юнит тесты — это инструмент тестирования, но далеко не так как его многие представляют. Юнит тесты в git diff или в PR показывают как изменился код с точки зрения поведения, избавляя необходимость проводить компиляцию и симуляцию в голове, экономя опять-же время, уменьшая вероятность ошибок и повышая эффективность код ревью. Юнит тесты ко всем остальным видам тестирования имеют очень посредственное отношение. Особенно на гигантских проектах, где больше половины людей не знакомы и с половиной кодовой базы — где без наличия юнит тестов все просто боятся делать изменения и вместо этого предпочитают плодить костыли убивающие проект в долгосрочной перспективе. Я виню разработчиков только в том, что они либо не знают этого либо не умеют донести, но зачастую они нутром чувствуют, что «так надо» — на уровне ощущений из предыдущего опыта они понимают что так работается легче. TDD был лишь способом популяризации идеи, на самом деле не особо важно пишутся тесты до или после кода... но это отдельная история.

    Конечно, в поддержку автора, все сказанное будет иметь мало смысла если без сегодняшнего костыля завтра компания обанкротится, но в отличии от автора не нужно думать что это правило действует по-дефолту. Это скорее исключение.

  • Начальство против фреймворков. Что делать?

    Предположу что это не вброс и попытаюсь разобрать кейс...
    Интеграция 1С и пыха — значит доместик ритейл (ну или на крайняк интернет магазин). В среднем такая контора имеет до 20 сотрудников всего (не считая персонал на точках если это таки ритейл), из которых айти ну может чувака три. И конкурировать приходится с галерными зарплатами на рынке. Потому единственный шанс конторы найти ребят — это зеленые студенты которые еще вчера лабы на дельфи делали. Эти ребята знакомы с базовыми структурами языка, но вряд-ли со фреймворками. Заинтродюсить фреймворк — поднять сложность и загнать себя в ловушку необходимости дальше хайрить более дорогих спецов. Твой начальник вполне умно экзекьютит стратегию.
    Совет конторе — сменить стратегию и отдать на аутсорс/купить под ключ. Ваши студенты вас рано или поздно зафакапят.
    Совет студенту — ты уже готов, теперь беги от них дальше и выше.

  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    мне нужны люди на проект с шефом, терраформом и амазоном
    Мне нужны люди в первую очередь с правильным майндсетом, с пониманием зачем нужно писать тесты, делать CD, селф-сервис и вот это все.

    Для информации описано что есть в бекграунде на проекте, но это не имеет ничего общего с реквайрментами на позицию. Хотя-бы ИЛИ шеф ИЛИ терраформ квалифай на мидла, на синьора и то и другое. Не надо перекручивать плиз..
    Еще раз, приходят вчерашние админы с каким-то базовым количеством ансибла в сиви и считают себя синьорами. Это я то быкую? :)

    Поддержал: Сергій Назаревич
  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    То есть писать кукбуки и тф модули на сегодняшний день это уже «чимало». Простите, что по вашему должен уметь среднестатистический мидл-девопс на его среднерыночную зп? Заходить по ссш на сервер?

  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    У меня все норм в JD. А еще fyi есть тут некоторые конторы, которые за 25к человек, которые вообще не выходят на рынок за кандидатами, они сначала хайрят просто «к себе» в пул, а потом из пула предлагают на конкретные проекты.

  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    Опасная статья с однобоким перегибом. Очень слабо выраженно, что речь в статье идет именно о джунах, а не в целом о проблеме хайринга. У меня сейчас кейс, мне нужны люди на проект с шефом, терраформом и амазоном. В бекграунде есть саппорт легаси с паппетом и клаудформешном. Мне нужны люди в первую очередь с правильным майндсетом, с пониманием зачем нужно писать тесты, делать CD, селф-сервис и вот это все. Но мне так-же нужно, что-бы человек пришел и сразу начал писать кукбуки и модули с тестами, коих нам нужно в большом количестве. Мне присылают толпы кандидатов, которые позавчера были админами а вчера скриптили что-то очень базовое на ансибле. И намекают, что я каких-то единорогов ищу. Такая статья мне абсолютно не помогает.

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

    А если сделать как в статье предлагается, то по факту придется бебиситить всех нанятых вместо своих прямых обязанностей. Не поймите меня не правильно, статья справедлива и работает для 90% случаев, но точно не для сеньоров и точно есть проекты где нужно поднапрячься и отхватить кусок пирога создав еще десяток рабмест в перспективе на которых уже и можно будет неспешно набрать джунов и раскочегаривать их.

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

    The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. © George Bernard Shaw

    Поддержал: Сергій Назаревич
  • Работа ночью: как высыпаться и надо ли становиться жаворонком

    У меня умная лампа симулирует рассвет за пол часа до будильника, стандартный айфоновский будильник стоит на 5ам, алярми с математикой на 5:15, алярми со сканом штрих кода находящегося в другой комнате на 5:30, сам телефон лежит в противоположном углу комнаты от кровати. Угадайте с одной попытки, остался я сегодня WFH или нет. Мой мозг спокойно проходит через все эти задачи утром не давая мне проснуться. А ночью я не могу заснуть, в полной тишине и темноте, с маской на лице, свежим притоком воздуха и 22 градуса на термометре, могу лежать часами и не могу остановить мой мозг думать о всяком. Немного помагает мелатонин, безотказно помогают снотворные, но тогда падает продуктивность, мотивация, становлюсь вялым и не способным покорять вершины. И так уже 10 лет.

  • В чому був сенс для створення Android Studio обирати IntelliJ IDEA?

    Слепцом вас делает не ИДЕ. Плохому танцору...
    Звучит так будто вы пишете много спаггетти и мало нормально декомпозированного и структурированного кода. Иначе не пришлось бы

    багато доводиться в голові, щось проектувати і тримати

    Что бы не чистить

    сміття

    нужно его не производить :)
    Я думаю именно это люди здесь вам и пытаются донести. Идея не лучше просто по набору фич. Это нельзя просто взять и описать. И вообще «лучше» это понятие ну очень относительное. Для понимания контекста и сценария использования требуется для начала повысить скилл ;) И это вам не объяснят в комменте на доу, это бывает занимает годы.
    Для примера попытайтесь дровосеку из средневековья объяснить чем же бензопила лучше, он тоже будет чертыхаться. И держать неудобно, и тяжелая, и вот это вот туда-сюда делать тоже неудобно...
    Или вот пример с машинами вам тут приводили. Я как начинающий водитель недавно ощутил это на себе. Без понимания «контекста» было сложно сделать выбор, какую купить. Кто-бы мне не давал советов по этому поводу, я их слышал, но не слушал. Моих знаний было недостаточно понять мотивацию, ведь кому-то нужно раздавать угла на парковке, кому-то заварить дифф, а кому-то безопасность.
    Аналогичные холивары постоянно происходят по поводу android vs iphone. Когда-то я был приверженцем андроида за его возможности кастомизации. Потом перешел на айфон по той же причине — за отсутствие кастомизации. Потому что пропало лишнее время и интерес разбираться во всех этих настройках, надо что-бы просто работало из коробки. Но тогда, если-бы мне кто-то попытался объяснить за айфон, я бы посмеялся им в лицо и припомнил за айтюнс.
    К чему я клоню, это к пониманию термина «лучший». Для начала определитесь со сценарием использования и потом подберите инструмент. Black/white ответов не бывает. Может вам вообще атом подойдет. Если во главе угла у вас сейчас стоит базовый автокомплит, может вам и лучше посидеть с эклипсом пока.

    перед тим як про це писати, треба мені, ще розібратись

    This. Идите разбираться :)

    Поддержал: Роман Смоляков
  • В чому був сенс для створення Android Studio обирати IntelliJ IDEA?

    Ну я, например, перестал тестировать через кнопку Build правильный ли у меня синтаксис, как вы описываете это в статье, поэтому на счет инкрементального компилятора я вас не понимаю. Мой код синтаксически правильный в 99% случаев и вместо этого я ранаю юнит тесты когда результат на мой взгляд уже готов. И тогда штуки типа Refactoring, Find Usages, etc — становятся во главу угла, когда вы их почему-то намеренно опустили (видимо как неважные/ненужные, хотя именно это правильный способ найти все вызовы метода сигнатуру которого вы меняете, а не Build, это если не вспоминать про @Deprecated и обратную совместимость, ну да ладно). Идея гораздо круче понимает контекст с которым я работаю, когда эклипс это просто текстовый редактор с автодополнением и приблудами (ну по крайней мере был лет 5 назад когда я с него ушел). Сейчас уже сложно вспомнить все детали о разнице между двумя инструментами, хорошо запомнились только эмоции. Сначала плевался (переучивание хоткеев итд), потом прозрение.

    Поддержали: Stanislav Demchenko, Alex Koshterek
← Сtrl 123456...39 Ctrl →