А они не хотят. От слова совсем, ну или почти совсем. 98%. Второй курс, ООП... Не идет. Начинаю разбираться почему, выяснилось, что с трудом применяют базовые конструкции языка. Ну то есть они их знают, но прошлый семестр посчитали слишком простым, опять циклы, опять условия и т.д., лабы сдали в лоб, тренироваться поленились. Чего то перечитал, чего то заставил переделать, что то усложнил. Уткнулись в полное неумение в базовые алгоритмы: перебрать массив тяжело, сделать по нему поиск какое то запредельное сложное задание. Оказалось, что предмет, где это давали, сдавали копипастой. Отстаем уже на месяц. Какое там ООП. И все из под палки. Лишь бы сдать. С ужасом думаю, что им в следующем семестре мне им паттерны читать. Потом придут на хабр, будут плакать как их плохо учили. З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?
Или не было. Осуждать кого-то можно только зная все обстоятельства принятия такого решения.
Хорошей практикой
Немного видоизменю ваше утверждение: мы живем не в идеальном мире, и хорошей практикой является писать настолько хороший код, насколько это возможно в данных обстоятельствах. Код и был хорош для той задачи которую он решал. Но код не является конечной точкой, по крайне мере моей работы. Для "хорошо" нужна как можно более полная информация, время и ресурсы. ПМ и начальство то же не из прихоти такие решения принимает. Если фича нужна к 28 числу, а если к 29 то можно и не делать, в рефакторинг не успеваем, значит делаем как успеваем. Хорошей практикой является писать тесты - аксиома, но не успеваем - практика, значит не пишем, запишем в долг. Если на долг не дали время, так в долгу и останется.
/но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки.
По тому, что это классно когда тебе дали время на подумать и архитектуру, и дали это воплотить. Но бывает и так: «а давайте попробуем!», а потом этот «попробуем» по желанию начальства улетает в прод и на твои возражения, что задача изначально была другой, внимания не обращают, что ПМ приходить со сроком и описанием того, что надо сделать "на пальцах", начинать писать надо сейчас, а требования уточняется уже потом, или под конец выясняется, что надо туда вкрутить что-то, что ломает все твою стройную архитектуру, или подвели соседи/подрядчики и тебя надо сделать то, что изначально планировалось на другой стороне... Да мало ли...
Ознакомьтесь пожалуйста с нормализацией базы данных.
Вот и поговорили, я получил отказ и стандартный фидбек «иди учи».
Вот ты сидишь с той стороны и гадаешь, что «экзаменатор» знает, что нет, а самое главное, что примет близко к сердцу. Вот, например, вам надо говорить, что в поле 'model', у вас еще, наверное, через пробел, намешана марка, еще кое где модификация, кое где исполнение, а где-то нет? Или вы это то же близко к сердцу воспримите? И как ваше хистори со всем этим строить.
И этот коварный вопрос про апи, поди угадай, какой вариант «экзаменатор» считает единственно верный? CRUD, добавить туда patch, сделать все на get – post, ошибки как возвращать, стандартные или предусмотреть какой то isError. Я разные варианты видел единственно верными, с иди учи, если не угадаешь. Но мне в общем все равно, я по любому могу. Вот сидишь в недоумении, что сказать, а где лучше помолчать.
И в общем мало вероятно, если от тебя требуют объект, вернуть массив, это как минимум надо заново согласовывать доку/спеку или хотя бы принимающую сторону извещать. И вы от меня ждете, что я начну разруливать не однозначности, а где то, другой экзаменатор, что предложу поменять ФИО на уникальный uid. Иди догадайся, что вы ждете…
И какое решение именно вы считаете если не идеальным, то близким к правильному.
Даже не знаю, что бы я подумал после такого интервью.
«мы нарушаем одну из форм нормализации БД» - по теории баз данных форма нормальная, а нормализацию нельзя нарушить, поскольку это процесс… приведения к одной из нормальных форм. Интервьюер не владеет теорией и терминологией? Или проверяет? В вопросе вы говорите об автомобилях, то есть объектах, тогда вводим user_id, и первую нормальную форму не нарушаем, поскольку в ней говориться о уникальных кортежах, user_id и автомобиль(объект) будет уникальных кортежем и связь один к многим. Но на рисунке у вас в таблице не автомобили, а модели, тогда связь будет многие ко многим, поскольку объект автомобиль урезается до объекта модель автомобиля, которая является только одной из характеристик автомобиля. Что думать?
А еще есть теория информационных процессов и систем или просто ООП. И все становиться еще не однозначнее.
Просили вернуть адрес – в единственном числе (first скажем), а оказалось, что вернуть надо массив. Вы уже там решите, какая у вас задача…
А чего у них в конторе с БД в которой нет уникальных идентификаторов, а ищется по ФИО, вообще не понятно, да еще они при этом хотят безопасность.
Если бы другой инфы не было, поставил бы конторе большой минус и не стал бы связываться.
А они не хотят. От слова совсем, ну или почти совсем. 98%. Второй курс, ООП... Не идет. Начинаю разбираться почему, выяснилось, что с трудом применяют базовые конструкции языка. Ну то есть они их знают, но прошлый семестр посчитали слишком простым, опять циклы, опять условия и т.д., лабы сдали в лоб, тренироваться поленились.
Чего то перечитал, чего то заставил переделать, что то усложнил. Уткнулись в полное неумение в базовые алгоритмы: перебрать массив тяжело, сделать по нему поиск какое то запредельное сложное задание. Оказалось, что предмет, где это давали, сдавали копипастой. Отстаем уже на месяц. Какое там ООП. И все из под палки. Лишь бы сдать.
С ужасом думаю, что им в следующем семестре мне им паттерны читать.
Потом придут на хабр, будут плакать как их плохо учили.
З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?
Надо угадать ответ который вас устроит?
Или не было. Осуждать кого-то можно только зная все обстоятельства принятия такого решения.
Немного видоизменю ваше утверждение: мы живем не в идеальном мире, и хорошей практикой является писать настолько хороший код, насколько это возможно в данных обстоятельствах. Код и был хорош для той задачи которую он решал. Но код не является конечной точкой, по крайне мере моей работы. Для "хорошо" нужна как можно более полная информация, время и ресурсы. ПМ и начальство то же не из прихоти такие решения принимает. Если фича нужна к 28 числу, а если к 29 то можно и не делать, в рефакторинг не успеваем, значит делаем как успеваем. Хорошей практикой является писать тесты - аксиома, но не успеваем - практика, значит не пишем, запишем в долг. Если на долг не дали время, так в долгу и останется.
bisnes online
/но с точки зрения архитектуры всей кодовой базы, написанный код бывает, как выброшенный мусор в окно во время поездки.
По тому, что это классно когда тебе дали время на подумать и архитектуру, и дали это воплотить.
Но бывает и так: «а давайте попробуем!», а потом этот «попробуем» по желанию начальства улетает в прод и на твои возражения, что задача изначально была другой, внимания не обращают, что ПМ приходить со сроком и описанием того, что надо сделать "на пальцах", начинать писать надо сейчас, а требования уточняется уже потом, или под конец выясняется, что надо туда вкрутить что-то, что ломает все твою стройную архитектуру, или подвели соседи/подрядчики и тебя надо сделать то, что изначально планировалось на другой стороне...
Да мало ли...
То есть устроить тот же экзамен, только сделать его область еще более расплывчатой и еще более приближенной к опыту экзаменатора?
Вот и поговорили, я получил отказ и стандартный фидбек «иди учи».
Вот ты сидишь с той стороны и гадаешь, что «экзаменатор» знает, что нет, а самое главное, что примет близко к сердцу. Вот, например, вам надо говорить, что в поле 'model', у вас еще, наверное, через пробел, намешана марка, еще кое где модификация, кое где исполнение, а где-то нет? Или вы это то же близко к сердцу воспримите? И как ваше хистори со всем этим строить.
И этот коварный вопрос про апи, поди угадай, какой вариант «экзаменатор» считает единственно верный? CRUD, добавить туда patch, сделать все на get – post, ошибки как возвращать, стандартные или предусмотреть какой то isError. Я разные варианты видел единственно верными, с иди учи, если не угадаешь. Но мне в общем все равно, я по любому могу. Вот сидишь в недоумении, что сказать, а где лучше помолчать.
И в общем мало вероятно, если от тебя требуют объект, вернуть массив, это как минимум надо заново согласовывать доку/спеку или хотя бы принимающую сторону извещать. И вы от меня ждете, что я начну разруливать не однозначности, а где то, другой экзаменатор, что предложу поменять ФИО на уникальный uid. Иди догадайся, что вы ждете…
И какое решение именно вы считаете если не идеальным, то близким к правильному.
Даже не знаю, что бы я подумал после такого интервью.
«мы нарушаем одну из форм нормализации БД» - по теории баз данных форма нормальная, а нормализацию нельзя нарушить, поскольку это процесс… приведения к одной из нормальных форм. Интервьюер не владеет теорией и терминологией? Или проверяет? В вопросе вы говорите об автомобилях, то есть объектах, тогда вводим user_id, и первую нормальную форму не нарушаем, поскольку в ней говориться о уникальных кортежах, user_id и автомобиль(объект) будет уникальных кортежем и связь один к многим. Но на рисунке у вас в таблице не автомобили, а модели, тогда связь будет многие ко многим, поскольку объект автомобиль урезается до объекта модель автомобиля, которая является только одной из характеристик автомобиля. Что думать?
А еще есть теория информационных процессов и систем или просто ООП. И все становиться еще не однозначнее.
Просили вернуть адрес – в единственном числе (first скажем), а оказалось, что вернуть надо массив. Вы уже там решите, какая у вас задача…
А чего у них в конторе с БД в которой нет уникальных идентификаторов, а ищется по ФИО, вообще не понятно, да еще они при этом хотят безопасность.
Если бы другой инфы не было, поставил бы конторе большой минус и не стал бы связываться.