В учебниках/методичках/глоссарии/материалах/рабочих тетрадях есть указание дополнительной литературы. На худой конец можно спросить у преподавателя/сокурсников/старшекурсников и т.п. Если Вам надо углубиться в какую-то тему Вы выписываете собственно названия+автор нужных книг (для некоторых может потребоваться еще номер издания), идете в библиотеку и получаете нужные книги. Собственно в каждой книге есть содержание чтобы не требовалось читать ее полностью:) Трудности могут возникнуть если книга в единственном экземпляре то Вам предложат ознакомиться с ней в читальном зале но много раз когда я попадал на такое обычно большая часть моей группы уже была в читальном зале и мы коллективно штудировали нужную тему. Поэтому неясно о каких трудностях Вы говорите.
Сейчас появилось так много умных синтаксических штук, что знать их все просто невозможно. Да и зачем? Сколько способов нужно, чтобы проверить поле на пустое значение или сделать наследование многоуровневым? Неужели только один из этих способов правильный и намного лучше остальных? Конечно, в команде всегда найдётся сотрудник, который устроит скандал по этому поводу и испортит обеденный перерыв или летучку.
Правильно зачем изучать новшества в языке лучше не изучать и через пару лет оказаться в ситуации когда не понимаешь что делает код твоего проекта, да и количество способов проверить поле на пустоту как минимум равно количеству стандартных типов которые поддерживаются языком.
Но как быть вот с этим "Возвращая 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, старые подходы к решению типовых задач, старые паттерны и т.п.
Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Конечно накопятся разные проблемы, но тех, которые заложены в сами основы языков и культуры С/С++ точно не появятся.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
Это увеличит время вывода продуктов на рынок, но уже готовятся законодательные нормы, которые заставят поставщиков ПО серьёзнее относиться к безопасности.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
<input> заточен именно под это, особенно при правильной настройке.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
Из rich-вещей я написал на HTML аналог
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
В учебниках/методичках/глоссарии/материалах/рабочих тетрадях есть указание дополнительной литературы. На худой конец можно спросить у преподавателя/сокурсников/старшекурсников и т.п. Если Вам надо углубиться в какую-то тему Вы выписываете собственно названия+автор нужных книг (для некоторых может потребоваться еще номер издания), идете в библиотеку и получаете нужные книги. Собственно в каждой книге есть содержание чтобы не требовалось читать ее полностью:) Трудности могут возникнуть если книга в единственном экземпляре то Вам предложат ознакомиться с ней в читальном зале но много раз когда я попадал на такое обычно большая часть моей группы уже была в читальном зале и мы коллективно штудировали нужную тему. Поэтому неясно о каких трудностях Вы говорите.
Теперь так библиотека называется:)
Если Вы про заучивания всех билетов за ночь и шпоры в часах то это навыки скорее контрпродуктивные.
Правильно зачем изучать новшества в языке лучше не изучать и через пару лет оказаться в ситуации когда не понимаешь что делает код твоего проекта, да и количество способов проверить поле на пустоту как минимум равно количеству стандартных типов которые поддерживаются языком.
Мартин много про что не пишет :) И более того воспринимать его тейки буквально вне зависимости от здравого смысла такая себе идея. Принимать как рекомендацию да. Как я сказал выше проблема с возвратом 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, старые подходы к решению типовых задач, старые паттерны и т.п.
Проблемы старых библиотек не в том что они не компилируются а в том что они написаны на старых редакциях языка с использованием "старых подходов".
Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
"упрощая игру в игры" :) Игра в игру, новое измерение.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.