Такое повсеместно, к сожалению, но тогда встает вопрос о "факторе автобуса", как бы я не хотел замкнуть на себя некоторые вещи прямо сейчас, в перспективе года это выглядит не самым лучшим решением. И это очень негативно влияет на проект, как то: меньше возможность тот код чинить и понимать, фактор автобуса, снижение качества кода одного человека, или неприятие других взглядов. Со стороны себя любимого конечно хочется найти позицию, где будешь отвечать один за всё, но со стороны проекта - нафик, нафик.
Это не следствие какого-то намеренного умысла просто "рабочие моменты" очень плавно могут превращаться в это. Т.е. допустим я решил какую-то проблему в одной части системы по требованию кого-то в другом отделе (маркетинга, бизнеса и т.п.) кто заинтересован в этой доработке, после мы с ним допустим доводили эту проблему до конца еще какое-то время обсуждая что-то и докручивая. Впоследствии этот человек будет обращаться ко мне за доработками или просто чтобы обсудить проблему в этом конкретном месте проекта просто потому что он меня знает и для него это проще. Пример возможно утрированный но в целом имеет место быть.
В тот раз я отделался "ай-яй-яй" и штрафом минус два дня к отпуску.
А это точно прописано в контракте и не нарушает законы?
Он же ввел понятие контекста ревью. Очень расточительно по времени выйдет просматривать огромную простыню кода без каких-либо комментариев, понять что этот код вообще должен делать и как работает. Если ваш коллега за соседним столом, то не составит большого труда сесть вместе и просмотреть и обсудить изменения, но когда такой возможности нет, функция на четыре экрана становится просто головной болью. Поэтому с недавних пор, кроме самих изменений мы и тестов к ним, мы еще требуем контекст, наличие тестов и правильно оформленное описание.
Возможно вы скажете, что задача код-ревью это проверка изменений, а не способность написать короткое эссе - "как я пофиксил этим летом" к PR. Но подумайте, что описание комита это финализация задачи, и если вы не можете сформулировать в пяти-шести коротких предложениях, что конкретно было сделано, то есть повод задуматься, всё ли сделано в задаче что нужно.
Такое возможно только в командах где практики владения кодом соблюдаются и большая часть команды может быть переиспользована на любых частях проекта. В реальности часто бывает что есть разные люди в команде ответственны за некие части проекта в которых исторически они разбираются лучше. Тут даже написание эссе может не помочь с пониманием того что сделано.
В учебниках/методичках/глоссарии/материалах/рабочих тетрадях есть указание дополнительной литературы. На худой конец можно спросить у преподавателя/сокурсников/старшекурсников и т.п. Если Вам надо углубиться в какую-то тему Вы выписываете собственно названия+автор нужных книг (для некоторых может потребоваться еще номер издания), идете в библиотеку и получаете нужные книги. Собственно в каждой книге есть содержание чтобы не требовалось читать ее полностью:) Трудности могут возникнуть если книга в единственном экземпляре то Вам предложат ознакомиться с ней в читальном зале но много раз когда я попадал на такое обычно большая часть моей группы уже была в читальном зале и мы коллективно штудировали нужную тему. Поэтому неясно о каких трудностях Вы говорите.
Сейчас появилось так много умных синтаксических штук, что знать их все просто невозможно. Да и зачем? Сколько способов нужно, чтобы проверить поле на пустое значение или сделать наследование многоуровневым? Неужели только один из этих способов правильный и намного лучше остальных? Конечно, в команде всегда найдётся сотрудник, который устроит скандал по этому поводу и испортит обеденный перерыв или летучку.
Правильно зачем изучать новшества в языке лучше не изучать и через пару лет оказаться в ситуации когда не понимаешь что делает код твоего проекта, да и количество способов проверить поле на пустоту как минимум равно количеству стандартных типов которые поддерживаются языком.
Но как быть вот с этим "Возвращая null , мы фактически создаем для себя лишнюю работу, а для вызывающей стороны - лишние проблемы. "? Сам Мартин про это ничего не пишет (внезапно), а как надо чтобы соответствовать высоким (хе хе) стандартам клинкода?
Мартин много про что не пишет :) И более того воспринимать его тейки буквально вне зависимости от здравого смысла такая себе идея. Принимать как рекомендацию да. Как я сказал выше проблема с возвратом null распространяется на любые типы данных, просто с null ошибка моментально даст о себе знать крашем в то время как другие типы выстрелят по другому. Примеры - метод возвращает int и ожидается положительные числа но вдруг приходит отрицательное, метод возвращает enum на 3 числа (1,2,3 допустим) а приходит 4. На самом деле вариантов такого много и моя мысль в том что обработка возвращаемых значений это нормальная практика. Проблема в том что часто не всегда и не везде хочется делать какие-либо проверки и запрет на использование null преподноситься своего рода панацеей с одной стороны делают ненужными написание проверок а с другой стороны избавляющего от крашей.
Ну я не знаю, а что ожидать от метода поиска, если подходящего элемента нет? Это в любом случае надо обработать - будет там null, будет там исключение, будет там какой-то result с булевым полем найдено или нет, будет там default.
Если написано в описании метода что он вернет null для кейса когда ничего не найдено то это полностью валидное использование null. Вызывающий код осведомлен о то что такое возможно и он должен обработать такой кейс (т.е. проверку на null) и это абсолютно правильное поведение. Т.е. метод Find(predicate) в его описании написано что if not found then null, if not founded item.
Обычно проблемным считается случай когда в методе (по ошибке или по отсутствии документации или еще чему) вызывающий код не ожидает что там будет null. Т.е. метод Find(predicate) в его описании написано что if result will be foundede item.
Основная проблема которая бередит умы в том что в большинстве своем получается второй кейс причем в крайне неожиданных местах что очень больно бьет по стабильности проекта.
Проблема null не в том что его надо избегать а в том когда метод который !не должен! возвращать null начинает его возвращать. Т.е. это уже перетекает в плоскость логики и ожиданий от вызывающего кода. Но тоже самое будет например в случае если метод возвращает int но четко написано что отрицательных значений не может быть а потом бац и возвращается отрицательное значение которое вызывающий код явно не будет ожидать.
Тут еще важный момент что нужна не просто вышка а вышка по айтишной или околоайтишной специальности. Потому что например инженер-озеленитель после окончания вышки также имеет и высшее техническое образование и является инженером но обладает ли он той же базой знаний как инженер учившийся на айтишной специальности?
Для многих удаленка удобна из-за отсутствия необходимости добираться по много времени в пробкам в часы пик до работы, также открылись возможности куда-то сходить рядом с домом сразу после работы а не ехать еще час и более и уставшим плюхнуться на диванчик. Незабываем про возможность пойти отвести детей в садик/выгулять собаку/сходить в магаз/сделать какие-то дела в рабочее по факту время и в большинстве это происходит без ущерба для работы.
Кстати, если в России ручной тестировщик и автотестер — обязательные члены любой команды
громкое заявление что они обязательные, за время моей работы просто тестировщик (обычно ручник) когда был и был именно в моей команде а не как это бывает в отдельном отделе тестирования то это уже было прям радость. А так тестированием занимались кто угодно но кроме тестировщиков.
От того, что в библиотеке старые подходы она хуже работать не станет.
Библиотека хуже работать не станет но если Вам вдруг по каким-то причинам понадобиться открыть ее и разобраться с багом каким-нибудь или даже доработать под себя потому что ее давно не обновляли вот тогда то и начнутся трудности. И чем она старее она тем больнее с ней будет работать.
Откройте любую старую С++ библиотеку и у Вас хлынет кровь из глаз потому что ее писали десятки лет назад используя старую версию компилятора, использовались старые функций из стандартной библиотеки которые могут быть уже deprecated, старые подходы к решению типовых задач, старые паттерны и т.п.
Можно было -1+ опыта указать:)
Это не следствие какого-то намеренного умысла просто "рабочие моменты" очень плавно могут превращаться в это. Т.е. допустим я решил какую-то проблему в одной части системы по требованию кого-то в другом отделе (маркетинга, бизнеса и т.п.) кто заинтересован в этой доработке, после мы с ним допустим доводили эту проблему до конца еще какое-то время обсуждая что-то и докручивая. Впоследствии этот человек будет обращаться ко мне за доработками или просто чтобы обсудить проблему в этом конкретном месте проекта просто потому что он меня знает и для него это проще. Пример возможно утрированный но в целом имеет место быть.
А это точно прописано в контракте и не нарушает законы?
Такое возможно только в командах где практики владения кодом соблюдаются и большая часть команды может быть переиспользована на любых частях проекта. В реальности часто бывает что есть разные люди в команде ответственны за некие части проекта в которых исторически они разбираются лучше. Тут даже написание эссе может не помочь с пониманием того что сделано.
Если они знают где Вы живете то боюсь у меня для Вас плохие новости.
Если только это не противоречит тому что написано в его контракте.
Не просветите что это за аргументы?
а может быть еще меньше сделать время на ответ?
В учебниках/методичках/глоссарии/материалах/рабочих тетрадях есть указание дополнительной литературы. На худой конец можно спросить у преподавателя/сокурсников/старшекурсников и т.п. Если Вам надо углубиться в какую-то тему Вы выписываете собственно названия+автор нужных книг (для некоторых может потребоваться еще номер издания), идете в библиотеку и получаете нужные книги. Собственно в каждой книге есть содержание чтобы не требовалось читать ее полностью:) Трудности могут возникнуть если книга в единственном экземпляре то Вам предложат ознакомиться с ней в читальном зале но много раз когда я попадал на такое обычно большая часть моей группы уже была в читальном зале и мы коллективно штудировали нужную тему. Поэтому неясно о каких трудностях Вы говорите.
Теперь так библиотека называется:)
Если Вы про заучивания всех билетов за ночь и шпоры в часах то это навыки скорее контрпродуктивные.
Правильно зачем изучать новшества в языке лучше не изучать и через пару лет оказаться в ситуации когда не понимаешь что делает код твоего проекта, да и количество способов проверить поле на пустоту как минимум равно количеству стандартных типов которые поддерживаются языком.
Мартин много про что не пишет :) И более того воспринимать его тейки буквально вне зависимости от здравого смысла такая себе идея. Принимать как рекомендацию да. Как я сказал выше проблема с возвратом null распространяется на любые типы данных, просто с null ошибка моментально даст о себе знать крашем в то время как другие типы выстрелят по другому. Примеры - метод возвращает int и ожидается положительные числа но вдруг приходит отрицательное, метод возвращает enum на 3 числа (1,2,3 допустим) а приходит 4. На самом деле вариантов такого много и моя мысль в том что обработка возвращаемых значений это нормальная практика. Проблема в том что часто не всегда и не везде хочется делать какие-либо проверки и запрет на использование null преподноситься своего рода панацеей с одной стороны делают ненужными написание проверок а с другой стороны избавляющего от крашей.
Да обработка результата это нормально.
Если написано в описании метода что он вернет null для кейса когда ничего не найдено то это полностью валидное использование null. Вызывающий код осведомлен о то что такое возможно и он должен обработать такой кейс (т.е. проверку на null) и это абсолютно правильное поведение. Т.е. метод Find(predicate) в его описании написано что if not found then null, if not founded item.
Обычно проблемным считается случай когда в методе (по ошибке или по отсутствии документации или еще чему) вызывающий код не ожидает что там будет null. Т.е. метод Find(predicate) в его описании написано что if result will be foundede item.
Основная проблема которая бередит умы в том что в большинстве своем получается второй кейс причем в крайне неожиданных местах что очень больно бьет по стабильности проекта.
Проблема null не в том что его надо избегать а в том когда метод который !не должен! возвращать null начинает его возвращать. Т.е. это уже перетекает в плоскость логики и ожиданий от вызывающего кода. Но тоже самое будет например в случае если метод возвращает int но четко написано что отрицательных значений не может быть а потом бац и возвращается отрицательное значение которое вызывающий код явно не будет ожидать.
Это близкая специальность к архитектору (не ПО а из строительных направлений).
Тут еще важный момент что нужна не просто вышка а вышка по айтишной или околоайтишной специальности. Потому что например инженер-озеленитель после окончания вышки также имеет и высшее техническое образование и является инженером но обладает ли он той же базой знаний как инженер учившийся на айтишной специальности?
Для многих удаленка удобна из-за отсутствия необходимости добираться по много времени в пробкам в часы пик до работы, также открылись возможности куда-то сходить рядом с домом сразу после работы а не ехать еще час и более и уставшим плюхнуться на диванчик. Незабываем про возможность пойти отвести детей в садик/выгулять собаку/сходить в магаз/сделать какие-то дела в рабочее по факту время и в большинстве это происходит без ущерба для работы.
громкое заявление что они обязательные, за время моей работы просто тестировщик (обычно ручник) когда был и был именно в моей команде а не как это бывает в отдельном отделе тестирования то это уже было прям радость. А так тестированием занимались кто угодно но кроме тестировщиков.
Библиотека хуже работать не станет но если Вам вдруг по каким-то причинам понадобиться открыть ее и разобраться с багом каким-нибудь или даже доработать под себя потому что ее давно не обновляли вот тогда то и начнутся трудности. И чем она старее она тем больнее с ней будет работать.
Откройте любую старую С++ библиотеку и у Вас хлынет кровь из глаз потому что ее писали десятки лет назад используя старую версию компилятора, использовались старые функций из стандартной библиотеки которые могут быть уже deprecated, старые подходы к решению типовых задач, старые паттерны и т.п.
Проблемы старых библиотек не в том что они не компилируются а в том что они написаны на старых редакциях языка с использованием "старых подходов".