Робив би все можливе, щоб зменшити Feedback Loop. Не можу без цього :)
В цілому — це допомагає трошки швидше їх шукати. У нас є .xcconfig на проекті. Вони дуже гарно себе зарекомендували у випадках, коли .xcodeproj не комітиться в репозиторій, а генерується на стороні розробника (xcodegen/tuist). В таких випадках флаги повністю визначаються тим, що є в .xcconfig. А ось якщо .xcodeproj в git’і, то .xcconfig — yet another level. тому що ніхто не заважає «випадково» змінити щось в .xcodeproj.
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) DEBUG=1
Так, мені тоді в email повідписували за таке рішення. Пропонували щось комбіноване писати з рандомними таймаутами після unlock event’у. І виходило що (system events + timers) vs (timers). Рішення з timer only має в цьому плані багато переваг через меншу складність і простоту розуміння.
Тут запитали, як подивитися, чи «в мене є така проблема на проекті». Ну, по-перше, треба Objective-C (відчуваю себе динозавром). Можна зробити Clean Derived Data, і зібрати проект. І після цього подивитися на кількість директорій в ModulesCache. Їх там має бути ±8. Якщо у вас там пару десятків — то скоріш за все, ви можете трошки підтюнити білди.
:wow: Так багато всього і в одному коменті. Пішов перевіряти, що змінилося в Bazel/Buck. Колись пробував, і не раз завести, і кількість зусиль на підтримку цього всього і ознайомлення команди займало занадто багато часу. Треба щоб хтось прийшов і показав, що і де і як. Пішов дивитися доки і відоси.
А не треба було мати відповідність 1-в-1. Взяв останню версію релізну, що була в репозиторії. Було достатньо.
Треба буде перенести з Ґабру сюди
May be it’s me, але чому патАрни, а не патерни?
Десь щось приблизно таке саме я колись чув про Automatic Reference Counting
По максимуму автоматично форматуйте код ( наприклад на post-commit hook). Так, щоб можна було писати як попало, і все одно код був би відформатований. Форматування коду (не назви змінних, а саме форматування) зараз майже для всіх мов є засоби. Це дозволяє змістити обговорення PRів з пробілів/рядків, і відступів — до семантики (назви класів, структура коду e.t.c).
Тобто навіть не linter форматування, коли тобі б’ють по рукам за те,що ти неправильно відформатував, а автоформаттер.
Лінтер може ловити вже більш складні випадки, які автоматично не можна виправити (function complexity/naming styleguide etc).
Саш, прекращай, любые высказывания от представителей Stanfy все равно будут расматриваться как попытки оправдаться/выслужиться/"навешать лапши на уши" ;). В обсуждении ты никому ничего не докажешь — не поверят, ты же заинтересованный человек. Более интересно мнение людей, которые работали в Stanfy, и кто что слышал от друзей/знакомых.
А с теми, кто сейчас работает в Stanfy есть смысл общаться только в приватной беседе, не на публичном форуме, по понятным причинам.
Без порівняння з людьми важко зрозуміти наскільки це погано. Може люди б взагалі відповіли б у 10% правильно. Може 48% це прямо дуже круто :)