Выполнение пункта 4 может привести к побочным эффектам для обоих сторон диалога
Если джун идёт в соседней отдел и там тоже сидит джун, который, но неопытности начинает пытаться помочь и что-то править забив на свои задачи, то джун 2 потом рискует получить выговор за то что не успел свои задачи, а то что помог кому-то из соседнего отдела, так там приоритеты ниже сильно были и вообще не в том месте проблема была
Если же в соседнем отделе сидит милорд-помидор, то к нему таких людей, которые решили проявить инициативу, ходит по 10 в день. Большинство из них оперативно шлются к тому, кто выставляет приоритеты. А если кто-то злоупотребляет, то это может ещё и ухудшить личное отношение к такому человеку, что тоже не очень хорошо.
Если в компании есть вертикальная структура, то нужно пользоваться ей и не пытаться быть "эффективным", понимая коллег через голову лидов
А что если уехал в другую страну ещё до постановки на учёт? В 16 лет и теперь регулярно приезжаю на месяц-два по работе. По идее не состою на учёте вообще поэтому и сниматься не от куда?
Мне от Atlassian приходили письма о странных логинах из Лондона и Ирландии. На всякий случай двухфакторную аутентификацию включил и перестало приходить.
В общем полезная статья, но я бы не стал слепо следовать ей во всех случаях.
* При создании (апдейте) объекта, не вижу ничего плохого чтобы вернуть этот самый созданный\обновленный объект чтобы сократить таким образом коммуникацию и избежать доп. нагрузки когда всегда следом прилетит GET на тот же объект
* Считаю что очень нужно и правильно при 4хх ошибках возвращать в JSON доп информацию по ошбке. Как то: код\константу ошибки. Сопровождающий текст. Возможно какую то информацию requestUUID и.т.д. Возвращать тело ошибки текстом когда вся остальная система работает с JSON — как минимум странно
Так же в статье деликатно обошли множество моментов, когда при формировании API сложно создать правильный URI с точки зрения операций над объектами (операции не являющиеся созданием или получением ентити и какие-то промежуточные операции).
Раньше Вы писали что курса всего два, а выходит 4 года. Но это наверное я не так понял.
По поводу математик это все же моё имхо — программа слабая. Как с этим в СНГ сейчас не знаю. Сам учился в Израиле поэтому сравниваю с израильскими вузами. У нас первый год программирования был 1 курс по-моему и я считаю это праильным.
Да. Я имел в виду что должно быть больше курсов математики (тем более не очень понятно что скрывается за предметом Математика)
Какую степень выдает этот универ после двух курсов? Для BA как-то маловато выходит.
Как по мне, для первых семестров очень мало математики. Имхо высшая математика неплохо расширяет сознание и учит мыслить абстрактно что не помешает если хочешь стать чем то больше чем просто кодером
Если вам предлагают быстрое, но архитектурно слабое решение, ваша обязанность сказать «нет»
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.
Выполнение пункта 4 может привести к побочным эффектам для обоих сторон диалога
Если джун идёт в соседней отдел и там тоже сидит джун, который, но неопытности начинает пытаться помочь и что-то править забив на свои задачи, то джун 2 потом рискует получить выговор за то что не успел свои задачи, а то что помог кому-то из соседнего отдела, так там приоритеты ниже сильно были и вообще не в том месте проблема была
Если же в соседнем отделе сидит милорд-помидор, то к нему таких людей, которые решили проявить инициативу, ходит по 10 в день. Большинство из них оперативно шлются к тому, кто выставляет приоритеты. А если кто-то злоупотребляет, то это может ещё и ухудшить личное отношение к такому человеку, что тоже не очень хорошо.
Если в компании есть вертикальная структура, то нужно пользоваться ей и не пытаться быть "эффективным", понимая коллег через голову лидов
Спасибо за подробное описание,
А что если уехал в другую страну ещё до постановки на учёт? В 16 лет и теперь регулярно приезжаю на месяц-два по работе. По идее не состою на учёте вообще поэтому и сниматься не от куда?
* При создании (апдейте) объекта, не вижу ничего плохого чтобы вернуть этот самый созданный\обновленный объект чтобы сократить таким образом коммуникацию и избежать доп. нагрузки когда всегда следом прилетит GET на тот же объект
* Считаю что очень нужно и правильно при 4хх ошибках возвращать в JSON доп информацию по ошбке. Как то: код\константу ошибки. Сопровождающий текст. Возможно какую то информацию requestUUID и.т.д. Возвращать тело ошибки текстом когда вся остальная система работает с JSON — как минимум странно
Так же в статье деликатно обошли множество моментов, когда при формировании API сложно создать правильный URI с точки зрения операций над объектами (операции не являющиеся созданием или получением ентити и какие-то промежуточные операции).
По поводу математик это все же моё имхо — программа слабая. Как с этим в СНГ сейчас не знаю. Сам учился в Израиле поэтому сравниваю с израильскими вузами. У нас первый год программирования был 1 курс по-моему и я считаю это праильным.
Какую степень выдает этот универ после двух курсов? Для BA как-то маловато выходит.
Таким образом легко впасть в другую крайность. Заболеть оверинжинирингом. Ваши решения будут супер гибкими, но релиз у вас будет раз в два месяца, а у конкурентов два раза в неделю и вы потеряете клиентов.
Имхо в случае с быстрым и архитектурно слабым решением, ненадо говорить «нет». Нужно найти компромис. Возможно для POC нужно сделать именно так, но обязательно договорится о доп. времени на приведение такого кода в порядок в будущем (тут конечно тоже свои ньюансы...)
В целом легко сказать «нет», но это не отличает проффесионала. Это так же идет в разрез с пунктом ниже о понимании бизнеса клиента и работодателя.