#заметка #soft_skills

История одной задачи + софт скиллы в деле с QA и Backend

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

Давечне мне надо было починить баг - отсутствие переводов для некоторых языков. Этот баг выглядит просто:"Наверное затерялась локализация для необходимы языков, сейчас пойду поправлю. Делов на 5 минут."

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

Иду смотреть в задачу, и нигде не вижу об этом ни слова. И тут я хотел-бы добавить, что не во всех компаниях или проектах тестировщики должны собирать логи. Или собирать логи прям везде и до 3-его колена. Нет, всё как всегда просто - как договорились, так и будете работать.

Так вот, оказывается тестер не написал этот факт, что текст приходит с бекенда, и что iOS тут особо ничего и не сделает, а задча должна БЫЛА БЫ содержать лейбл [backend], а не [iOS], но что поделать...

Иду до тестера и кумекаю, что так и так, что задача так-то не про iOS, а про backend, но тестеру не нужно волноваться, я сейчас схожу и уточню.

Иду в нужное место, тегаю PM, Backend и пишу, что текст, который багает, он приходит бекенда, и что лучше править на бекенде в одном месте, чем на iOS и Android отдельно - в двух местах. И аргументирую это тем, что если править на 2-ух платформах сразу, то это придётся:

- Делать небольшую логику в 2-ух местах
- Заводить локализацию
- Маппить нужное место с нужной локализацией

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

Cверху накинул, что можно взять текущую ручку, добавить к ней параметр языка, чтобы backend'у было проще, при реализации фикса, принимать параметр языка и с ним уже идти за переводом и отдавать нужный текст, а не стучаться в микросервис локализации, смотреть текущую локаль и только после этого отдавать нужный текст.

Какой вывод можно сделать из этой истории?

Не стоит идти к тестировщику и как-то язвить или сетовать на то, что он оказался где-то неправ. Потому-что напомню:
- Как договорились в команде так и будет.
- Опыт коллеги, кума, зятя, соседа не всегда релевантный к тебе, т.к ты не всегда знаешь всех под-капотных вещей.

Если - бы я отправил тестера вместо себя изучать, ибо проблема backend'a, то мог - бы получиться сломанный телефон из 3-ёх человек + к этому долго бы обсуждали. А лично я не люблю тягомотину эту, когда понимаешь, что с буксом + хрустом можно за 5 минут обговорить и сделать, чем 30 минут выяснять кто прав, а кто виноват и придти к такому-же результату.

Возможность для выноса на ретроспективу, чтобы тестировщики проверяли чуть глубже, если они этого не делают. А если должен делать, но конкретно тут [по какой-то причине забыл сделать], то в мягкой форме донести:"Что мне бы помогло, если-бы в результате заведения бага были логи".

Все мы люди, разные бывают обстоятельства и зачем токсичить или язвить, если можно этого не делать? - Если - вдруг ты считаешь, что токсичишь, то всегда можно:
- После написания текста не отправлять его, взять пауза на 5 минут. Спустя паузу перечитать.
- Закинуть ИИ на оценку токсичности, и в случае её обнаружения попросить поправить. А что нет то, мы ж не пишем рассказ, а доносим мысль.

Ну и последнее, чтобы backend'у было легче, я сразу же заострил внимание, что можно сделать легче и без проблем - прокинуть дополнительный параметр и по нему получать перевод. Потому-что для backend'a пойти в другой микросервис, узнать там локаль, с этими знаниями придти обратно - это лишние сложности.

А мы бы их создали, если бы могли упереться, не согласиться, дескать вот пусть backend разруливает сам ибо мы просто получаем и показываем... Разные ветви пути могли-бы быть...

Какой вывод можно сделать?

1. Понимание, хоть и небольшое, backend части может улучшить всем жизнь.
2. Задачки на фиксы багов с репортами - это гуд, так как не нужно будет тратить время на поиск причины бага. Если тестер уже на этом пути, иногда лишиние 5-10 минут сэкономят твои 30-60 минут.
3. Если хочется ткнуть носом в промах человека, то лучше вспомнить, что не все и всегда и во все периоды времени работают на полную мощнь.
4. Видишь место для улучшения работы? Запиши, ибо забудешь, а на ретро можно обсудить
5. Если человек человеку волк, то почему зомби зомби зомби?

Если понравилось, жду голубя, буду софтовыми вещами по-чаще делиться, если нужна reels version, то голубя ставь.

Полный экскурс по разработке + день iOS Разработчика

Почти 1 год прошел с публикации этого видео, где я полностью и по полочкам раскидал важное и необходиоме для тех, кто хочет понимать:"А что же там происходит, внутри этой разработки?". Вот небольшой список тем:
- Кто состоит в команде и чем занимается
- Какие задачи и откуда они берутся
- Feature / Core team, а что это вообще?
- Мобильный девопс и что он делает? Кстати подробный воркшоп и про него есть, он здесь
- Про каждый процесс подробно + дополнительные активности, опционально.

И это лишь малая часть того, что есть внутри видео. Из этого видео можно понять, и очень даже неплохо, про внутренню кухню внутри разработки ПО.

Как - всегда, все подробные таймкоды ждут внутри. Презентация и пояснение = результат 🙂

#middle #задачка

Старая добрая задача на print + работа с замыканием. Самые разные вариации с ДАНО: value / ref type и тоже самое с замыканием - implicit capture vs explicit capture.

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

final class Person {
    var name: String
    
    init(name: String) {
        self.name = name
    }
}

var person = Person(name: "Alice")

let closure1 = {
    print(person.name)
}

let closure2 = { [person] in
    print(person.name)
}

person.name = "Bob"
closure1() // Что выведет тут? [1]
closure2() // Что выведет тут? [2]

person = Person(name: "Charlie")
closure1() // Что выведет тут? [3]
closure2() // Что выведет тут? [4]

#swiftui #собеседование #jun

Доброй ночи! Такая задача на подумать. Сколько раз выведется принт:"evaluate body", если сделать два действия:
1. Запустить код, чтобы отобразить VIew
2. Нажать на кнопку

import SwiftUI
import PlaygroundSupport

struct ContentView: View {
    @State var value = 0
    
    var body: some View {
        let _ = print("evaluate body")
        
        Button("Изменить") {
            value += 1
        }
    }
}

PlaygroundPage.current.setLiveView(ContentView())

Варианты ответа будут ниже!

Ой ой ой ой.....

#swiftui #собеседование #middle

Мы поменяли @State var value = 0 на @StateObject var viewModel и дёргаем increment. Так же сделаю 2 действия: запущу это код, чтобы отобразить view и нажму на кнопку. За два этих действия сколько раз вызовется принт “re-evaluate body”? И почему?

import SwiftUI
import PlaygroundSupport

final class ViewModel: ObservableObject {
    @Published var age: Int = 0
    
    func increment() {
        age += 1
    }
}

struct ContentView: View {
    @StateObject var viewModel = ViewModel()
    
    var body: some View {
        let _ = print("evaluate body")
        
        Button("Изменить") {
            viewModel.increment()
        }
    }
}

PlaygroundPage.current.setLiveView(ContentView())

Опрос будет ниже, перед выбором нужного ответа постарайся обосновать свой ответ, почему именно ЭТА цифра.

#swiftui #собеседование #middle

Окей с двумя премерами выше мы разобрались. У нас есть правильный ответ и обоснование его. Если-вдруг есть сомнения в корректности, всегда можно проверить в Playground.

И чтобы продолжить ветку этого вопроса дальше, давай теперь ответим на следующий вопрос. Ответы выбирай тот, который считаешь НАИБОЛЕЕ корректным.

"В чём разница между re-evaluate и re-draw? Что происходит в предыдущем примере: re-evaluate и / или re-draw?"

#swiftui #собеседование #middle+

Есть такой код и при нажатии на кнопку “Увеличить возраст на 1 ед.” счётчик counter не увеличивается и не показывает числа, он всегда показывает 0.

Задача - понять почему, пофиксить и объяснить в чём была проблема. Код при этом, концептуально, должен остаться таким же, какой он изначально, не считая исправления.

import SwiftUI
import PlaygroundSupport

final class ViewModel: ObservableObject {
    @Published var age: Int = 0
    
    func increment() {
        age += 1
    }
}

struct ChildView: View {
    @ObservedObject var viewModel = ViewModel()
    @Binding var value: Int
    
    var body: some View {
        Button("Увеличить возраст на 1 ед.") {
            viewModel.increment()
        }
        .onChange(of: viewModel.age) { _, newValue in
            value = newValue
        }
    }
}

struct ContentView: View {
    @State private var counter: Int = 0
    
    var body: some View {
        VStack(alignment: .center, spacing: 0) {
            Text("Каунтер равен:\(counter)")
                .font(.title)
                .foregroundStyle(.teal)
            
            ChildView(value: $counter)
        }
        .frame(width: 300, height: 500)
    }
}

PlaygroundPage.current.setLiveView(ContentView())

#structured_concurrency #собеседование #middle

Нужно сказать на каком thread будет выполняться операция в контексте background или main thread, учитывая что Playground по-умолчанию равен background thread.

Task {
    showCurrentThread()  // 1 ?
    await asyncOperation // 2 ?
    showCurrentThread    // 3 ?
}

Task { @MainActor in
    showCurrentThread()  // 4 ?
    await asyncOperation // 5 ?
    showCurrentThread    // 6 ?
}


func asyncOperation(line: Int = #line) async {
    showCurrentThread(line: line)
    try? await Task.sleep(for: .seconds(1))
}

func showCurrentThread(line: Int = #line) {
    print("Current line is: \(line) and thread is: \(Thread.current)")
}

#полезное #глаза

Доброго вечера, кому интересно прочитать чужой - личный опыт по-поводу операций на глаза, лишним не будет, советую на 10-15 минут чтиво: https://www.drive2.ru/b/710618764151889778/

Берегите своё зрение, найдите на ютубе гимнастику / спросите у докторов. Даже текущие -1 и около него, если правильно поступать - то не будет ухудшения.

Зрение ухудшается на минус - если напрягать глаза. Лучше уделить этому вопросу, чтобы потом не пришлось: носить очки / линзы или делать операцию.

В чатике можете тегнуть и спросить лично у автора статьи - @gmalyukov

#заметка

Добрейший вечерочек, завтра будем изучать дженерики начинать, глянул в ноушен, а там в этом разделе ничего нет. Уровень джюн, уверенный джюн, мидл и уверенный мидл надо будет точно закрывать.

Начну с простого, от 0 до уверенного джюна - крепыша, скрепыша.
Цель - понимание.
Результат - умени(е)я.

Презентация готова, сценарий на первые несколько видео есть, Xcode для первого занятия тоже есть.

Помню в своё время дженерики были одной из самых сложных для ПОНИМАНИЯ и ПРИМЕНЕНИЯ вещью.

Вот сидишь ты и думаешь, а тут надо? А тут надо? А вот протоколы тоже могут быть, а тут их надо или где надо? Етить колотить...

В общем будем струячить. Это не означает, что другие вещи останавливаются - нет, нисколько.

Всё идёт своим чередом. Если у кого-то есть желание стать гуру дженериков и прокачаться так, чтобы просто смотреть и улыбать как тот кот с гифки - то пробуйте Compiling Swift Generics от Slava Pestov