паттрны надо изучать примерно в тот момент

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

когда по колено в говне стоишь

и рефакторишь

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

так себе мнение.

и смотришь такой на паттерн ухты у меня такая же ситуация я вот так вот делал

ООП = декомпозиция

оказывается вот так это называется

хорошая декомпозиция = легко поддерживать

а еще - тесты

ой тесты тоже холиварная тема

unit tests, accept tests, functional tests, etc

ой тесты тоже холиварная тема

холиварная тема когда их писать, а так это как если бы холиварили "плохи ли бэкапы"

тут скорее процесс разработки

хорошая декомпозиция = легко поддерживать

легко поддерживать это же относительно; вот я написал например класс для работы с api телеги для своего ботика, мне его легко поддерживать, а другому нет ?

смотрел хайлоад, доклад снесите это немедленно, грят вроде как идеального кода нет, есть просто хороший

тут скорее процесс разработки

да нифига подобного. Опять же пример с бэкапами

легко поддерживать это же относительно; вот я написал например класс для работы с api телеги для своего ботика, мне его легко поддерживать, а другому нет ?

проблемы крупных проектов, в том что их полностью в голову одному человеку сложно уместить

ты их делаешь?

проблемы крупных проектов, в том что их полностью в голову одному человеку сложно уместить

потому мы придумали митинги)

декомпозиция позволяет как раз тебе одному в голове держать ровно то что нужно сейчас

ты их делаешь?

на проекте админы написали штуку для авто бэков

и вроде даже проверяют и разворачивают иногда

на проекте админы написали штуку для авто бэков

ну ок, а если бы небыло админов например, ты бы делал бэкапы?

ну то есть вещь нужная или нет?)

ну смотри код мой в гите

можно ли "неправильно" сделать бэкапы? (намек на gitlab)

на удаленном репе

если что случится я от туда востановлюсь

ну смотри код мой в гите

база данных на проде упала

клиенту класть на код

есть ли бэкап, ну смотря что считать бэкапом

у него все стоит

я сейчас не на аутсорсе, мы развиваем свой проект

есть ли бэкап, ну смотря что считать бэкапом

вот ненадо ненужных филосовств. Недавно вон у гитлаба прод лег на сутки и данные за 6 часов похерились

адын

я сейчас не на аутсорсе, мы развиваем свой проект

это тип "у меня нет прода и не будет"?)

вот ненадо ненужных филосовств. Недавно вон у гитлаба прод лег на сутки и данные за 6 часов похерились

бэкапы были

у них

но похерили они в бд запросом

так то человеческий фактор

у них

угу, и если бы ты почитал их переписки которые они опубликовали - там так вышло что все бэкапы писались но толку от них ноль, все относительно норм было просто потому что за 6 часов до случайно сделать дамп

это тип "у меня нет прода и не будет"?)

тут вопрос не про то что моя шконка скраю

а скорее про то что функционал должен быть тот которым пользуются

тут вопрос не про то что моя шконка скраю

не увиливай

и тесты и бэкапы из разряда если это необходимо

у тебя будут пользователи, довольные такие твоим продуктом

и тут бац и все упало

если ты говоришь про мой pc, бэкапов нет на нем

бэкапы мыбли бы неплохи?

но тут я не храню данные, фотки и что то ценное храню на своем домашнем серваке

но тут я не храню данные, фотки и что то ценное храню на своем домашнем серваке

....да плевать на тебя, мы о твоих пользователях говорим

бэкапы мыбли бы неплохи?

иногда наличие бэкапа недостаточно

нужно еще умение его разворачивать

и гарантия того что бэкап корректен

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

у нас они есть конечно, на проекте

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

звучит как то стремно ?

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

бэкапы они ведь тоже разные бывают

и тут опять же холиварно, смотря что считать бэкапом

подытожу мысль. Бэкапы - это хорошо, как говорится есть люди которые делают бэкапы и которые еще не делают. Это способ управления рисками.

и тут опять же холиварно, смотря что считать бэкапом

да нет никакого холивара. Хоть дамп базы в файл хоть реплика в другом датацентре

я продолжу твою фразу, что есть люди которые делают бэкапы и проверяют бэкапы

то что позволит тебе восстановить данные в случае падения системы, стратегия для такой ситуации

я продолжу твою фразу, что есть люди которые делают бэкапы и проверяют бэкапы

мысль вообще не в том)

то что позволит тебе восстановить данные в случае падения системы, стратегия для такой ситуации

не многие бэкапы позволят востановить все данные без потерь

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

ERROR: S client not available

не многие бэкапы позволят востановить все данные без потерь

базу можно без потерь

базу можно без потерь

базу на лету можно согласен

нет есть там логи

которые можно накатывать

нет есть там логи

ты с моим утвержденим согласен?

у нас когда я в банке работал, были всякие dba люди которые гарантировали

ты с моим утвержденим согласен?

да

а теперь заменяем слова "бэкапы" на "тесты".

тут я согласен, так как я разработчик, но вот доказать менеджерам сложней

делаешь ты юнит тесты, только интеграционные... не важно. Их надо уметь готовить, их нужно проверять кодом, их нужно поддерживать... но они приносят пользу

хотя тоже можно

делаешь ты юнит тесты, только интеграционные... не важно. Их надо уметь готовить, их нужно проверять кодом, их нужно поддерживать... но они приносят пользу

еще один очень хороший плюс от тестов, когда начинаешь их писать, код получается лучше

потому что начинаешь понимать что такое зависимость и как их лучше передавать

тут я согласен, так как я разработчик, но вот доказать менеджерам сложней

просто посчитай в деньгах: - сколько стоит проверить все руками на каждое изменение - сколько стоит регрессии в твоем проекте

просто посчитай в деньгах: - сколько стоит проверить все руками на каждое изменение - сколько стоит регрессии в твоем проекте

да это доказательство для менеджеров

ну и еще есть очень хорошая мысль - если ты не будешь продавать тесты мнеджерам они и не смогу тебе их запретить делать

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

в целом оверхэд на написание тестов где-то %10-%20 от общего времени разработки

и этот оверхэд окупается очень быстро. У меня вот ручные QA бернят 40%-50% времени разработки

Ну тесты тоже нужно уметь продать, не все понимают что это несет в себе сэкономленные средства на рефакторинг и тд

их заменит тест сюита на phpunit в большинстве случаев. UI им придется конечно проверять но это уже экономия порядка 300 часов в месяц

тут скорее не продавать тесты

а просто писать сразу с тестами и оценивать с тестами

и рефакторинг это постоянный процесс

Ну тесты тоже нужно уметь продать, не все понимают что это несет в себе сэкономленные средства на рефакторинг и тд

не надо их продавать. Они либо нужны (есть профит в денежном выражении или во времени) или нет.

увидел говно код по возможности подправил или сделал таску чтобы исправили потом

а просто писать сразу с тестами и оценивать с тестами

именно

как мне кажеться проблема в том, что очень часто подходят к разработке в плане, делаем рабочую модель потом все пофиксим/поправим

именно

я заметил что у нас мнения во многом совпадают )))

как мне кажеться проблема в том, что очень часто подходят к разработке в плане, делаем рабочую модель потом все пофиксим/поправим

сегодня прототип - завтра продакшен

нет ничего более постоянного, чем временное

отличная фраза тут)