Главное уточнить хороший код для кого/чего. Для машины это явно — тот который требует меньше ресурсов на выполнение. А для человека — тот который ему будет легче понять.
По моему мнению трудность в понимании кода другими сегодня это основная проблема в промышленной разработке.
Пришел к выводу что легкий для восприятия код это простой код т.е. с минимальным кол-во элементов и связей между ними. Другими словами проблема комбинаторная.
Поэтому при рефакторинге, считаю, нужно уделять внимание не добавлению абстракций а уменьшению кол-ва элементов и связей между ними — явных и неявных.
Ну и прекрасно, не только в США такая ситуация удаленка сейчас координально улучшила лично мою жизнь — не трачу время на дорогу, больше отдыхаю, лучше питаюсь домашней едой, а продуктивность выросла.
Кажется странным — переместиться из максимально либеральной Калифорнии в самое сердце Техаса, известного своими консервативными взглядами.
Для читателей из СНГ это явно вызовет непонимание в США — либералы это левые/социалисты. Консерваторы за свободу личную и рыночную. Поэтому непонятно что тут странно в выборе :)
На мой взгляд тут леваки не причем, амазон, фб и другие их как раз активно используют в свох целях что бы давить на малый бизен — вообдить разные органичения и требования под благими левыми идеями которые сметртельны для не крупных корпорация.
Вообще есть рыночная конкуренция когда ты совершается обмен в результате которого обе стороны в выйгрыше и это приводит к прогрессу общества. Есть использование системы в своих целях за счет подкупа или демпинга цены.
Очередная гениальная идея ничем не обоснованная кроме "ощущением" автора :), цель которой решить проблемы багов в программах, а результат ещё больше багов — потому что все выше описанное приводит к усложнению. Программист(99%) допускает баги когда не понимает как работает код, соответственно чем сложнее код тем меньше шансов что код поймут коректно.
Про исключение уже все давно расписано и объяснено — перехватывайте их в том месте где вы понимаете как восстановиться работу программы. Что касается многопользовательских сетевых приложений — в большинстве случаев место перехвата это верхняя точка, а действие по восстановление работы программы это возвращение ошибки в ответ на запрос.
Опыт показывает, что правы те люди, которые говорят, что логи не нужны.
Либо вы должны сейчас привести пример как находится и решается проблема которая возникла на проде но нигде в логах не зафиксирована. Либо это все же не опыт а его отсутствие вместе с фантазиями на тему идеального ПО.)
Метрики и алертинг по логам это просто и удобно — очень junion подход все пытаться оптимизировать по потребляемым ресурсам RAM, CPU и т.д., когда в подавляющем большенстве случаев нужно оптимизировать трудозатраты.
Одно дело когда вы в реальном проекте пользуетесь IDE и ищите решение на SoF, это помогает ускорить процесс и проверить себя. Другое когда без этих инструментов ничего не можете написать. Наверное в идеальном собеседовании должны быть затронуты разные аспекты и дать задачу на кодирование что бы посмотреть как человек над ней работает это вполне разумно. Вопрос какая конкретно задача и что вы этой задачей проверяете.
Проблема в описанная статье объясняется очень просто или же руководство не доверяет в полной мере тем кто собеседует и по этому пытается стандартизировать собеседование или собеседующему наплевать и он просто не хочет напрягаться — а что может быть проще выбрать задачу в сети прочитать её решение и расслабиться пока кандидат напрягается.)
Когда то не было google и пользователи искали информацию по каталогам. Зато у них был свободный и быстрый доступ к информации в сети. Если мы не хотим монополии в сети нужно об этом думать уже сейчас.
В коде есть две составляющие сложности — объективная которая обусловлена решаемой задачей и привнесенная программистом в виде абстракций. Первую мы не можем изменить, хотя часто и тут можно изменить постановку проблемы не меняя конечного результата. Второе мы можем свести к минимуму.
На своем опыте убедился что почти всегда проблемы это результат переусложнения в коде с целью что-то обобщить и т.п. В итоге код всегда становиться трудно понимать — но автор всегда будет доказывает что там скрыт особый смысл который привносит особые свойства — расширяемось, гибкость, и т.п. аргументы можно слышать. На практике все вокруг плюются, кроме автора и каждый кто плюется порождает аналогичное самобытное решение.
Для того чтобы понять как сделать код проще, нужно понимать что сложность комбинаторное явление и если мы хотим уменьшить сложность нужно уменьшать кол-во комбинаций в коде. Т.е. не писать лишних абстракций и т.п.
Мои оценочные суждения — это первый крупный этап. Серьезные изменения в обществе не происходят в один момент. Это процесс во времени разбиты на серию пиков. В принципе если изучать историю так всегда и было.
То что произошло летом это результат постепенного, за десятки лет изменения общества, которое накопилось и катализаторов в виде выборов и плохой ситуации в экономическе.
Очень высока вероятно что летом мы увидим новый пик.
Потому что this указывает на объект в котором он вызывается, соответственно на элемент <button/> если его не обернуть в функцию. А если обернуть то на объект функции OnClick().
Логично ли это — да.
Очевидно — нет.
Но благодаря динамической природе this вам не нужно прокидывать "контекст".
Ну да сначала из-за "преступности" закрывают vpn, tor, блокчей и т.д. Потом ты по паспорту ходит в интернет, потом тебя судят за не правильное высказывание в сети видете ли кого то оскорбило, затем таких увольняют с работы с черной меткой, в завершающей стадии садят в одиночную камеру за мыслепреступление потому что враг общества и деструктивный элемент. В принципе уже почти все воплощено в жизнь но ещё не соединено единым центром и не доведено до конечной цели.)
На мой взгляд наиболее частая проблема это крайне не компетентный менеджер который не может оценить работу сотрудников и делает это в силу своих знаний по принципу кто ему лучше втерся в доверии и соответсвует его субьекивныйм целям и ожиданиям.
Где то я уже похожее видел, точно в — гороскопе.)
Набор каких то стереотипов и ярлыков, каждый раз на основании субъективного мнения автора исходя из его жизненного опыта.
Clojure все это имеет только с читаемым синтаксисом, иммутабельными и lazy коллекциями ивозможностью писать код в runtime(что вообще есть кульминация языка).)
У меня все супер, психика в порядке, много лет работаю удаленно. Понял что основной принцип это когда вы не одни дома, поэтому если с вами дома все время жена/подруга. Проблем с одиночеством может и не быть. Либо у вас друзья с которыми вы постоянно встречаетесь. Через день/два.)
Главное уточнить хороший код для кого/чего. Для машины это явно — тот который требует меньше ресурсов на выполнение. А для человека — тот который ему будет легче понять.
По моему мнению трудность в понимании кода другими сегодня это основная проблема в промышленной разработке.
Пришел к выводу что легкий для восприятия код это простой код т.е. с минимальным кол-во элементов и связей между ними. Другими словами проблема комбинаторная.
Поэтому при рефакторинге, считаю, нужно уделять внимание не добавлению абстракций а уменьшению кол-ва элементов и связей между ними — явных и неявных.
Ну и прекрасно, не только в США такая ситуация удаленка сейчас координально улучшила лично мою жизнь — не трачу время на дорогу, больше отдыхаю, лучше питаюсь домашней едой, а продуктивность выросла.
Для читателей из СНГ это явно вызовет непонимание в США — либералы это левые/социалисты. Консерваторы за свободу личную и рыночную. Поэтому непонятно что тут странно в выборе :)
На мой взгляд тут леваки не причем, амазон, фб и другие их как раз активно используют в свох целях что бы давить на малый бизен — вообдить разные органичения и требования под благими левыми идеями которые сметртельны для не крупных корпорация.
Вообще есть рыночная конкуренция когда ты совершается обмен в результате которого обе стороны в выйгрыше и это приводит к прогрессу общества. Есть использование системы в своих целях за счет подкупа или демпинга цены.
Ну только если то что вы написали не считать сообщением на формуме :)
Похоже автору главное написать статью..)
Очередная гениальная идея ничем не обоснованная кроме "ощущением" автора :), цель которой решить проблемы багов в программах, а результат ещё больше багов — потому что все выше описанное приводит к усложнению. Программист(99%) допускает баги когда не понимает как работает код, соответственно чем сложнее код тем меньше шансов что код поймут коректно.
Про исключение уже все давно расписано и объяснено — перехватывайте их в том месте где вы понимаете как восстановиться работу программы. Что касается многопользовательских сетевых приложений — в большинстве случаев место перехвата это верхняя точка, а действие по восстановление работы программы это возвращение ошибки в ответ на запрос.
Либо вы должны сейчас привести пример как находится и решается проблема которая возникла на проде но нигде в логах не зафиксирована. Либо это все же не опыт а его отсутствие вместе с фантазиями на тему идеального ПО.)
Метрики и алертинг по логам это просто и удобно — очень junion подход все пытаться оптимизировать по потребляемым ресурсам RAM, CPU и т.д., когда в подавляющем большенстве случаев нужно оптимизировать трудозатраты.
Одно дело когда вы в реальном проекте пользуетесь IDE и ищите решение на SoF, это помогает ускорить процесс и проверить себя. Другое когда без этих инструментов ничего не можете написать. Наверное в идеальном собеседовании должны быть затронуты разные аспекты и дать задачу на кодирование что бы посмотреть как человек над ней работает это вполне разумно. Вопрос какая конкретно задача и что вы этой задачей проверяете.
Проблема в описанная статье объясняется очень просто или же руководство не доверяет в полной мере тем кто собеседует и по этому пытается стандартизировать собеседование или собеседующему наплевать и он просто не хочет напрягаться — а что может быть проще выбрать задачу в сети прочитать её решение и расслабиться пока кандидат напрягается.)
Когда то не было google и пользователи искали информацию по каталогам. Зато у них был свободный и быстрый доступ к информации в сети. Если мы не хотим монополии в сети нужно об этом думать уже сейчас.
В коде есть две составляющие сложности — объективная которая обусловлена решаемой задачей и привнесенная программистом в виде абстракций. Первую мы не можем изменить, хотя часто и тут можно изменить постановку проблемы не меняя конечного результата. Второе мы можем свести к минимуму.
На своем опыте убедился что почти всегда проблемы это результат переусложнения в коде с целью что-то обобщить и т.п. В итоге код всегда становиться трудно понимать — но автор всегда будет доказывает что там скрыт особый смысл который привносит особые свойства — расширяемось, гибкость, и т.п. аргументы можно слышать. На практике все вокруг плюются, кроме автора и каждый кто плюется порождает аналогичное самобытное решение.
Для того чтобы понять как сделать код проще, нужно понимать что сложность комбинаторное явление и если мы хотим уменьшить сложность нужно уменьшать кол-во комбинаций в коде. Т.е. не писать лишних абстракций и т.п.
Мои оценочные суждения — это первый крупный этап. Серьезные изменения в обществе не происходят в один момент. Это процесс во времени разбиты на серию пиков. В принципе если изучать историю так всегда и было.
То что произошло летом это результат постепенного, за десятки лет изменения общества, которое накопилось и катализаторов в виде выборов и плохой ситуации в экономическе.
Очень высока вероятно что летом мы увидим новый пик.
Интересно какую бы идею фрейда вы изложили если бы в статье было написано что "доказана" связь?)
Уберите детей от
экранаклавиатуры...)Если this не причем тогда вы можете написать
<div onClick={this.doSome}>?Потому что this указывает на объект в котором он вызывается, соответственно на элемент <button/> если его не обернуть в функцию. А если обернуть то на объект функции OnClick().
Логично ли это — да.
Очевидно — нет.
Но благодаря динамической природе this вам не нужно прокидывать "контекст".
Ну да сначала из-за "преступности" закрывают vpn, tor, блокчей и т.д. Потом ты по паспорту ходит в интернет, потом тебя судят за не правильное высказывание в сети видете ли кого то оскорбило, затем таких увольняют с работы с черной меткой, в завершающей стадии садят в одиночную камеру за мыслепреступление потому что враг общества и деструктивный элемент. В принципе уже почти все воплощено в жизнь но ещё не соединено единым центром и не доведено до конечной цели.)
На мой взгляд наиболее частая проблема это крайне не компетентный менеджер который не может оценить работу сотрудников и делает это в силу своих знаний по принципу кто ему лучше втерся в доверии и соответсвует его субьекивныйм целям и ожиданиям.
Где то я уже похожее видел, точно в — гороскопе.)
Набор каких то стереотипов и ярлыков, каждый раз на основании субъективного мнения автора исходя из его жизненного опыта.
Clojure все это имеет только с читаемым синтаксисом, иммутабельными и lazy коллекциями ивозможностью писать код в runtime(что вообще есть кульминация языка).)
У меня все супер, психика в порядке, много лет работаю удаленно. Понял что основной принцип это когда вы не одни дома, поэтому если с вами дома все время жена/подруга. Проблем с одиночеством может и не быть. Либо у вас друзья с которыми вы постоянно встречаетесь. Через день/два.)