Да и вообще, я не про превосходство одних над другими, а про то, что от природы мы (каждый по отдельности) к чему-то более приспособлены, а к чему-то менее. И разница между менее и более бывает столь велика, что одно дело будет получаться само собой, а в другом высот не достичь, как ни бейся.
Моё мнение простое — внутренний интерес к программированию важнее локации и желаемых условий труда.
Нельзя вот так просто ни стать программистом, ни глядя в какую-то конкретную статью выбрать будущую область деятельности и язык программирования.
А если я начну расписывать всё, о чём стоит подумать, и что стоит попробовать тому, кто решился стать программистом, никакого комментария не хватит. Да и в одну статью это не влезет.
Вы слишком однобоко смотрите на вопрос. Как на интерес того, кто решил пойти в программиста, так и на то, какие языки востребованы и где.
В этом наивном обзоре вы напрочь забыли про базы данных и веб, про BigData и Machine Learniing, про то, что доход — далеко не единственный интерес программиста, да и в корпоративной разработке часто всё не так, как вы тут описываете.
А вы что, и правда верите, что любого человека можно научить чему угодно?
Я знаю, что при желании многому можно научиться, но есть области, куда лезть примерно бессмысленно. Я, например, лишён музыкального слуха, играть на инструментах могу только механически.
А вам предлагаю научить усидчивости человека с СДВГ.
Я ж молчу про более тяжёлые и доказанные генетические заболевания.
Подозреваю, многое от программы обучения зависит? Но если есть гибкость, наверно лучше сконцентрироваться на нескольких самых употребимых и научить их писать реализацию и читать описание. Они потом хоть смогу прочесть про остальные и хоть с каким-то шансом суметь написать реализацию.
А то ведь как бывает: приходит на собеседование студент, что-то писал даже, паттерны изучал в институте. А спросишь его, встречался ли они с ними в своей практике, отвечает, что нет. Хотя что-то работающее писал на ASP.Net, а там ведь паттерны на каждом шагу.
Если уж спросить, в чём суть — объяснить не могут, зачем они нужны — тоже. Грустно.
От генетики многое зависит. Склад ума, склонность к логическим и абстрактным размышлениям,… да много чего, даже усидчивость.
Научиться решать типовые задачки под копирку можно, но разработчиком стать сможет далеко не каждый.
Ну, «и так сойдёт» делают на любых языках и технологиях :)
А вот про иное мнение мне тоже интересно. И да, про трудности с расширением контракта слышал. Но что касается современных систем, можете показать/рассказать, как «правильно» обрабатывать exceptions в примере, который я описал выше?
Интересно, какой код потом будут писать ваши студенты?
На моей практике всё же лучше заходили описания от живых примеров, когда сначала даётся ситуация/проблема, потом ищется хорошее решение, а потом показывается, что это за паттерн.
Часто так удавалось вправить мозги тем, кто книжку читал или на курсах (или в институте) изучал паттерны.
Вариант с синтетическим кодом, имхо, плох тем, что в памяти останется реализация, а не сам паттерн. Потом оказывается, что они не могут применить паттерн в другой ситуации, или в упор не видят паттер в коде реального приложения.
Сам я про паттерны узнал (и книжку GoF) узнал позже, чем начал их применять. Было прикольно читать описания паттернов и вспоминать, где я так делал :)
Понятно, что сослались, но:
а) не факт, что это мнение верно
б) не факт, что оно актуально.
Иначе говоря, всякое мнение может быть верным в определённой ситуации.
Предложенный дизайн ошибок настолько специфичен, что нигде более не встречается в мэйнстримовских языках.
PS
я не джавист, но до сих пор помню, как лет 15 назад коллеги, писавшие на джаве, многоэтажно крыли этот подход, порождающий кучу лишнего кода, за которым ещё и следить приходилось.
Это как бы намекает, что начиная с 9-й версии это уже не аргумент?
Т.е. даже без уточнения истории этого утверждения, оно не является правилом уже лет 6 как?
Так ведь по сути, насколько я понял, вы лишь немного упрощаете синтаксис?
Так может и статью стоило соответственно озаглавить и убрать из неё лишнюю спорную лирику?
Отдельно про последний абзац с отсылкой на доку по java. Интересно, сколько лет этому чудесному утверждению:
Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.
и сколько гигаватт энергии ушло у разработчиков на борьбу с этим подходом?
Моя личная претензия: почему код, который я вызываю, сам решает, смогу ли я продолжить работу после ошибки?
Во-первых, всё же не понятно, при чём тут C#, в котором обработка исключений сделана иначе. В частности, нет необходимости указывать возможные ошибки, вылетающие из метода.
Во-вторых, все эти призывы обработать ошибку максимально близко к месту возникновения хороши только для однослойных приложений. Более-менее объёмное приложение в современном мире может содержать десятки слоёв. И вот, скажите, как обрабатывать ошибку записи в БД при обработке веб-запроса? Вот вам примерная схема слоёв сайта:
Browser — SPA (view-controller-service-ajax) — WebServer — WebController — ValidationLayer — BusinesLayer — DataAccessLayer — StorageService — DBConnectionsLayer — DataBaseApp — SQL.
Допустим, ошибка вылетает при обработке запроса внутри БД.
Каждый слой — это не один класс, часто это несколько библиотек, работающих совместно. Часть кода наша, часть системная/сторонняя.
Точка возникновения исключения — ошибка при исполнении sql-кода.
Где ловить? Как решение принимать? Что пользователь увидит?
А если наш BusinesLayer должен обработать как запросы из браузера, так и от интеграционного сервиса на шине?
Я не знаю, как правильнее сделать в java, но в мире .net обычно ловят ошибку там, где требуется действие. Иногда это запись в лог и проброс ошибки дальше. Иногда это селективная проверка тех ошибок, с которыми в данном месте понятно, что можно сделать полезного.
На примере выше, возможны такие варианты:
StorageService логгирует все ошибки, для части известных ошибок возможна повторная обработка (например таймаут подключения), всё остальное выкидывается наверх.
DataAccessLayer кроме логгирования может обработать ошибки конкурирующих запросов и повторить неуспешные (в зависимости от типа запроса и типа ошибки), необработанное всё же выкидывается наверх.
BusinesLayer, например, может принимать решение о том, повторять ли запрос, прервать ли цепочку обработки (например, при ошибке на 5-м из 10 элементов, продолжить или прервать и откатить предыдущие)
WebController может часть ошибок оборачивать в что-то, понятное пользователю (та же ошибка конкуренции может приводить к сообщению «кто-то уже поменял запись, повторить запрос?»), а всё неопознанное превратится в «ошибка на сервере, код ошибки ###, сообщите его администратору».
А в SPA слои должны аккуратно прокинуть ошибку до того view, который покажет ошибку пользователю в красивом виде.
Как это всё сделать на .net без всяких извращения, я знаю. А как ваш обработчик поможет такое сделать в java?
Значит вам везло. Я встречал…
Только один пункт всё же стал хуже — маркет чаще стал попадаться в поиске по слишком уж частичному совпадению, это да. Но это не поиск в магазине, в реклама самого маркета :(
Да и вообще, я не про превосходство одних над другими, а про то, что от природы мы (каждый по отдельности) к чему-то более приспособлены, а к чему-то менее. И разница между менее и более бывает столь велика, что одно дело будет получаться само собой, а в другом высот не достичь, как ни бейся.
Нельзя вот так просто ни стать программистом, ни глядя в какую-то конкретную статью выбрать будущую область деятельности и язык программирования.
А если я начну расписывать всё, о чём стоит подумать, и что стоит попробовать тому, кто решился стать программистом, никакого комментария не хватит. Да и в одну статью это не влезет.
В этом наивном обзоре вы напрочь забыли про базы данных и веб, про BigData и Machine Learniing, про то, что доход — далеко не единственный интерес программиста, да и в корпоративной разработке часто всё не так, как вы тут описываете.
Я знаю, что при желании многому можно научиться, но есть области, куда лезть примерно бессмысленно. Я, например, лишён музыкального слуха, играть на инструментах могу только механически.
А вам предлагаю научить усидчивости человека с СДВГ.
Я ж молчу про более тяжёлые и доказанные генетические заболевания.
А то ведь как бывает: приходит на собеседование студент, что-то писал даже, паттерны изучал в институте. А спросишь его, встречался ли они с ними в своей практике, отвечает, что нет. Хотя что-то работающее писал на ASP.Net, а там ведь паттерны на каждом шагу.
Если уж спросить, в чём суть — объяснить не могут, зачем они нужны — тоже. Грустно.
Научиться решать типовые задачки под копирку можно, но разработчиком стать сможет далеко не каждый.
Вот серьёзно: не всякий может стать программистом, особенно таким, про которого пишете в начале, с баблом и карьерой.
А вот про иное мнение мне тоже интересно. И да, про трудности с расширением контракта слышал. Но что касается современных систем, можете показать/рассказать, как «правильно» обрабатывать exceptions в примере, который я описал выше?
— докажете?
Да и вообще, у вас как-то слишком жёстко получается — «есть два мнения: моё и неправильное» :)
На моей практике всё же лучше заходили описания от живых примеров, когда сначала даётся ситуация/проблема, потом ищется хорошее решение, а потом показывается, что это за паттерн.
Часто так удавалось вправить мозги тем, кто книжку читал или на курсах (или в институте) изучал паттерны.
Вариант с синтетическим кодом, имхо, плох тем, что в памяти останется реализация, а не сам паттерн. Потом оказывается, что они не могут применить паттерн в другой ситуации, или в упор не видят паттер в коде реального приложения.
Сам я про паттерны узнал (и книжку GoF) узнал позже, чем начал их применять. Было прикольно читать описания паттернов и вспоминать, где я так делал :)
а) не факт, что это мнение верно
б) не факт, что оно актуально.
Иначе говоря, всякое мнение может быть верным в определённой ситуации.
Предложенный дизайн ошибок настолько специфичен, что нигде более не встречается в мэйнстримовских языках.
PS
я не джавист, но до сих пор помню, как лет 15 назад коллеги, писавшие на джаве, многоэтажно крыли этот подход, порождающий кучу лишнего кода, за которым ещё и следить приходилось.
Т.е. даже без уточнения истории этого утверждения, оно не является правилом уже лет 6 как?
Так может и статью стоило соответственно озаглавить и убрать из неё лишнюю спорную лирику?
и сколько гигаватт энергии ушло у разработчиков на борьбу с этим подходом?
Моя личная претензия: почему код, который я вызываю, сам решает, смогу ли я продолжить работу после ошибки?
Во-вторых, все эти призывы обработать ошибку максимально близко к месту возникновения хороши только для однослойных приложений. Более-менее объёмное приложение в современном мире может содержать десятки слоёв. И вот, скажите, как обрабатывать ошибку записи в БД при обработке веб-запроса? Вот вам примерная схема слоёв сайта:
Browser — SPA (view-controller-service-ajax) — WebServer — WebController — ValidationLayer — BusinesLayer — DataAccessLayer — StorageService — DBConnectionsLayer — DataBaseApp — SQL.
Допустим, ошибка вылетает при обработке запроса внутри БД.
Каждый слой — это не один класс, часто это несколько библиотек, работающих совместно. Часть кода наша, часть системная/сторонняя.
Точка возникновения исключения — ошибка при исполнении sql-кода.
Где ловить? Как решение принимать? Что пользователь увидит?
А если наш BusinesLayer должен обработать как запросы из браузера, так и от интеграционного сервиса на шине?
Я не знаю, как правильнее сделать в java, но в мире .net обычно ловят ошибку там, где требуется действие. Иногда это запись в лог и проброс ошибки дальше. Иногда это селективная проверка тех ошибок, с которыми в данном месте понятно, что можно сделать полезного.
На примере выше, возможны такие варианты:
StorageService логгирует все ошибки, для части известных ошибок возможна повторная обработка (например таймаут подключения), всё остальное выкидывается наверх.
DataAccessLayer кроме логгирования может обработать ошибки конкурирующих запросов и повторить неуспешные (в зависимости от типа запроса и типа ошибки), необработанное всё же выкидывается наверх.
BusinesLayer, например, может принимать решение о том, повторять ли запрос, прервать ли цепочку обработки (например, при ошибке на 5-м из 10 элементов, продолжить или прервать и откатить предыдущие)
WebController может часть ошибок оборачивать в что-то, понятное пользователю (та же ошибка конкуренции может приводить к сообщению «кто-то уже поменял запись, повторить запрос?»), а всё неопознанное превратится в «ошибка на сервере, код ошибки ###, сообщите его администратору».
А в SPA слои должны аккуратно прокинуть ошибку до того view, который покажет ошибку пользователю в красивом виде.
Как это всё сделать на .net без всяких извращения, я знаю. А как ваш обработчик поможет такое сделать в java?
Только один пункт всё же стал хуже — маркет чаще стал попадаться в поиске по слишком уж частичному совпадению, это да. Но это не поиск в магазине, в реклама самого маркета :(
И, если уж начинать с азов, то не с этих. Совсем новичка тут много собьёт с толку.