Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Да, agile - Это плохая архитектура, это недостаток времени на вдумчивую разработку, это вечная гонка под минимальные стандарты и отсутствие творчества, так как часы на творчество менеджеры не предусмотрели, и с заказчиком что-то что предлагается командой, обсуждают они неохотно. Это бессмысленные дейли, где люди с постными физиономиями вынуждены выслушивать кучу информации, которая им не нужна, будучи вырванными из естественного внутреннего ритма разработки.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками. И это посредничество пользы разработке не приносит.
Да, аргумент про то, что самокатчики считают каждую минуту, весом. Люди, для кого время деньги, обычно являются основным источником дтп - таксисты, курьеры и т.д. В случае с самокатом нужно просто ограничивать скорость для прокатных самокатов до 15-20 км/ч, что вроде как уже сделано.
Про велодорожки - ну я катался какое-то время, с яжематерями, честно, не сталкивался. Я привык что люди нарушают правила, приходится объезжать. Не вижу огромной проблемы. Разговор в конце концов об ответственности людей кто ездит по тротуарам на великах в сравнении с теми кто ездит на самокатах. И эта проблема не нова и зависит от осознанности людей.
Такие же условия не обеспечивали и для велосипедистов. Может нужно просто ездить так, чтобы не давить людей на тротуарах? Мне это удается и на велосипеде и на самокате.
Логика Дурова абсолютно ясна и обоснована. Приложение было блокировано только в ночь перед первым днем голосования. Что это за люди, кто перед первым днем голосования не определился нужна ли им рекомендация УмГ - мне непонятно. Никакого принципиального вреда от блокировки бота УмГ в ночь перед первым днем голосования я не вижу. Все претензии в адрес Дурова - вопли ради воплей.
Переименование свойства объекта приводит к необходимости изменения всего кода, завязанного на данное свойство (как следствие, вместо переименования свойства/функции/… можно использовать добавление нового, с аналогичным функционалом, а затем, через какое-то время, удаление старого).
Это очень странный совет. Придется держать в голове где мы используем старое свойство, где новое. Почему сразу не заменить все через Ctrl + Shift + R ?
“Джентльменское соглашение” по поводу “публичной” и “приватной” частей пакета можно использовать не только в виде primary entry point, но и на уровне naming/placing-соглашений
Почему бы не использовать typescript вместо джентельменских соглашений?
Это действительно важно, пример автора работает и без нее, но если написать
``` let x = 1 let y = 2 [x, y] = [y, x] ``` Подобный код не скомпилируется
Поэтому точка с запятой перед выражением, начинающимся с квадратных скобок, дает гарантию корректной компиляции подобной строчки вне зависимости от того, какой код находится выше.
4-6 окладов. Я немедленно захотел туда устроиться. Просто компания мечты. Полгода тебе платят за то, что ты не ходишь на работу, а еще весь мир тебе сочувствует.
Все ж очень просто — тестировать надо какой то устоявшийся функционал. Будь то класс, который точно не будет меняться или будет, но незначительно, либо api сервера, либо рендеринг компонентов на фронте. Первый смысл тестов показать себе и другим что функционал работает корректно и отвечает заданным критериям задачи. Второй смысл — гарантия что система не упадет при внесении изменений. И все. Если смысл написания какого то класса — поддержка функционала некой программы то тестировать отдельно сам класс смысла нет никакого, достаточно текста конечных точек программы. Если же класс предполагается использовать как универсальное решение в прочих проектах, то тесты для класса необходимы. И очень важный момент — тесты должны писаться ДО написания функционала, после написания функционала они будут просто тестировать сами себя на соответствие программе, а не программу на соответствие тестам.
Покажите мне человека, который прекрасно разбирается в людях настолько что способен разобраться в причинах и погасить любой человеческий конфликт или дайте мне методику как такого человека определить на собеседовании чтобы взять тимлидом. И очевидно что hr кто будет брать такого человека должен разбираться в людях не хуже его и тогда где найти такого hr-а. Человеческая область — сложное искусство, поэтому лучше чтобы Вася был профессионалом и набрал себе профессиональных исполнителей. А конфликты — часть работы. Если в коллективе нет конфликтов значит людям все равно и это тревожный звонок.
добавить таблицу итогов и виртуальную таблицу выборки итоги + движения с последнего подсчета итогов это же вопрос нескольких часов. Если вы занимаетесь разработкой этой вещи несколько лет — то повторить хотя бы структуру хранения и получения данных для основных объектов 1с вполне можно было бы. А так молодец, думаю многие думали о том же(я в их числе) и даже начинали что-то делать, чтобы избавить разработку от бесконечного бойлерплейта и привести ее к лаконичности и основательности 1с, но немногие доводили до какого то работающего решения.
Не очень понял про эффективность скрама. Там же ежедневные часовые стенд апы, где ты зачем то отчитываешься на каком ты этапе решения задачи и как скоро ты ее решишь и слушаешь зачем то чужие отчёты. Скрам это постоянная непрерывная прогулка-гонка, где при каждом переходе проезжей части включается секундомер а вся прогулка состоит из непрерывных переходов проезжей части, зачастую туда обратно. Скрам не увеличивает эффективность ни в два раза, ни в полтора, это самое большое зло, созданное туповатыми янки для управления другими туповатыми янки и по обезьянней привычке подражать перенятое остальным цивилизоаанным миром.
А в остальном с автором согласен, разве что сроки при спокойной работе прогнозировать можно и с небольшой погрешностью.
Тормозит он несравненно меньше чем intelliJ и вообще работать в нем приятней, несмотря на некоторую ущербность функционала по сравнению со средами jet brain
Мне просто интересно в предверии поиска работы, на что делается акцент и что может сыграть(хотя видимо индивидуально)
1) Опыт из резюме, который теоретически можно написать вообще любой
2) Репозиторий, куда можно положить теоретически не свои задачи
3) Ссылки на тостер и stackoverflow с хорошим рейтингом и множеством отвеченных вопросов (тут уже не придраться, показатель относительно объективный)
4) Live собеседование (но оно может не дать ясной картины, так как кандидат может волноваться и задачи можно дать лишь простые)
И получается что тестовое на пару часов наиболее объективный показатель
Первое правило тестовых заданий — никогда не делайте тестовые задания!
Ну не знаю, на свою первую работу по фронтенду я устроился, написав тестовое задание. (3 дня писал, дважды переписывал), зато сразу на позицию миддла. Без тестового задания со мной даже разговаривать бы не стали.
Так же как с id и классами, может быть несколько элементов с одинаковыми id и их без проблем можно получить через селекторные запросы. И класс может быть представлен всего одним элементом. Это всего лишь соглашение.
"Если Вы уже получили оффер от другого работодателя (с бОльшей суммой, конечно), то что может остановить Вас?"
Ключи от новой квартиры. Реальный случай, когда брали в Москве умного и скромного чувака из региона, все были счастливы, обо всем договорились, ему оставалось уволиться и через две недели работать на новом месте в московском офисе напротив кремля. И тут он звонит и виновато говорит, что против ключей от новой квартиры в своём регионе у него нет контраргументов.
Возможен же такой код? Если при вызове каждого метода объект будет копироваться, это будет странно. Я бы подменил только сам set, но это все дело вкуса. Смысл был показать, что приспособить moment под иммутабельность недолго и не критичные потери производительности. 100% полагаю для программирования ничто.
Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Да, agile - Это плохая архитектура, это недостаток времени на вдумчивую разработку, это вечная гонка под минимальные стандарты и отсутствие творчества, так как часы на творчество менеджеры не предусмотрели, и с заказчиком что-то что предлагается командой, обсуждают они неохотно. Это бессмысленные дейли, где люди с постными физиономиями вынуждены выслушивать кучу информации, которая им не нужна, будучи вырванными из естественного внутреннего ритма разработки.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками. И это посредничество пользы разработке не приносит.
Да, аргумент про то, что самокатчики считают каждую минуту, весом. Люди, для кого время деньги, обычно являются основным источником дтп - таксисты, курьеры и т.д. В случае с самокатом нужно просто ограничивать скорость для прокатных самокатов до 15-20 км/ч, что вроде как уже сделано.
Про велодорожки - ну я катался какое-то время, с яжематерями, честно, не сталкивался. Я привык что люди нарушают правила, приходится объезжать. Не вижу огромной проблемы. Разговор в конце концов об ответственности людей кто ездит по тротуарам на великах в сравнении с теми кто ездит на самокатах. И эта проблема не нова и зависит от осознанности людей.
Такие же условия не обеспечивали и для велосипедистов. Может нужно просто ездить так, чтобы не давить людей на тротуарах? Мне это удается и на велосипеде и на самокате.
Логика Дурова абсолютно ясна и обоснована. Приложение было блокировано только в ночь перед первым днем голосования. Что это за люди, кто перед первым днем голосования не определился нужна ли им рекомендация УмГ - мне непонятно. Никакого принципиального вреда от блокировки бота УмГ в ночь перед первым днем голосования я не вижу. Все претензии в адрес Дурова - вопли ради воплей.
Это очень странный совет. Придется держать в голове где мы используем старое свойство, где новое. Почему сразу не заменить все через Ctrl + Shift + R ?
Почему бы не использовать typescript вместо джентельменских соглашений?
При наличии УмГ, о которой звонят из каждого утюга, неучастие никак не можно назвать "активной гражданской позицией", скорее пофигизмом
Это действительно важно, пример автора работает и без нее, но если написать
```
let x = 1
let y = 2
[x, y] = [y, x]
```
Подобный код не скомпилируется
Поэтому точка с запятой перед выражением, начинающимся с квадратных скобок, дает гарантию корректной компиляции подобной строчки вне зависимости от того, какой код находится выше.
4-6 окладов. Я немедленно захотел туда устроиться. Просто компания мечты. Полгода тебе платят за то, что ты не ходишь на работу, а еще весь мир тебе сочувствует.
Все ж очень просто — тестировать надо какой то устоявшийся функционал. Будь то класс, который точно не будет меняться или будет, но незначительно, либо api сервера, либо рендеринг компонентов на фронте. Первый смысл тестов показать себе и другим что функционал работает корректно и отвечает заданным критериям задачи. Второй смысл — гарантия что система не упадет при внесении изменений. И все. Если смысл написания какого то класса — поддержка функционала некой программы то тестировать отдельно сам класс смысла нет никакого, достаточно текста конечных точек программы. Если же класс предполагается использовать как универсальное решение в прочих проектах, то тесты для класса необходимы. И очень важный момент — тесты должны писаться ДО написания функционала, после написания функционала они будут просто тестировать сами себя на соответствие программе, а не программу на соответствие тестам.
Покажите мне человека, который прекрасно разбирается в людях настолько что способен разобраться в причинах и погасить любой человеческий конфликт или дайте мне методику как такого человека определить на собеседовании чтобы взять тимлидом. И очевидно что hr кто будет брать такого человека должен разбираться в людях не хуже его и тогда где найти такого hr-а. Человеческая область — сложное искусство, поэтому лучше чтобы Вася был профессионалом и набрал себе профессиональных исполнителей. А конфликты — часть работы. Если в коллективе нет конфликтов значит людям все равно и это тревожный звонок.
добавить таблицу итогов и виртуальную таблицу выборки итоги + движения с последнего подсчета итогов это же вопрос нескольких часов. Если вы занимаетесь разработкой этой вещи несколько лет — то повторить хотя бы структуру хранения и получения данных для основных объектов 1с вполне можно было бы. А так молодец, думаю многие думали о том же(я в их числе) и даже начинали что-то делать, чтобы избавить разработку от бесконечного бойлерплейта и привести ее к лаконичности и основательности 1с, но немногие доводили до какого то работающего решения.
Не очень понял про эффективность скрама. Там же ежедневные часовые стенд апы, где ты зачем то отчитываешься на каком ты этапе решения задачи и как скоро ты ее решишь и слушаешь зачем то чужие отчёты. Скрам это постоянная непрерывная прогулка-гонка, где при каждом переходе проезжей части включается секундомер а вся прогулка состоит из непрерывных переходов проезжей части, зачастую туда обратно. Скрам не увеличивает эффективность ни в два раза, ни в полтора, это самое большое зло, созданное туповатыми янки для управления другими туповатыми янки и по обезьянней привычке подражать перенятое остальным цивилизоаанным миром.
А в остальном с автором согласен, разве что сроки при спокойной работе прогнозировать можно и с небольшой погрешностью.
Тормозит он несравненно меньше чем intelliJ и вообще работать в нем приятней, несмотря на некоторую ущербность функционала по сравнению со средами jet brain
1) Опыт из резюме, который теоретически можно написать вообще любой
2) Репозиторий, куда можно положить теоретически не свои задачи
3) Ссылки на тостер и stackoverflow с хорошим рейтингом и множеством отвеченных вопросов (тут уже не придраться, показатель относительно объективный)
4) Live собеседование (но оно может не дать ясной картины, так как кандидат может волноваться и задачи можно дать лишь простые)
И получается что тестовое на пару часов наиболее объективный показатель
Вы не смотрите их репозиторий? Не просите примеры написанного ими кода?
Ну не знаю, на свою первую работу по фронтенду я устроился, написав тестовое задание. (3 дня писал, дважды переписывал), зато сразу на позицию миддла. Без тестового задания со мной даже разговаривать бы не стали.
Так же как с id и классами, может быть несколько элементов с одинаковыми id и их без проблем можно получить через селекторные запросы. И класс может быть представлен всего одним элементом. Это всего лишь соглашение.
"Если Вы уже получили оффер от другого работодателя (с бОльшей суммой, конечно), то что может остановить Вас?"
Ключи от новой квартиры. Реальный случай, когда брали в Москве умного и скромного чувака из региона, все были счастливы, обо всем договорились, ему оставалось уволиться и через две недели работать на новом месте в московском офисе напротив кремля. И тут он звонит и виновато говорит, что против ключей от новой квартиры в своём регионе у него нет контраргументов.
Возможен же такой код? Если при вызове каждого метода объект будет копироваться, это будет странно. Я бы подменил только сам set, но это все дело вкуса. Смысл был показать, что приспособить moment под иммутабельность недолго и не критичные потери производительности. 100% полагаю для программирования ничто.