Не очень верится, что это не ради денег. Идти на такой риск, когда сам видишь как других сажают. Либо у этих людей не все в порядке с головой, либо он не договаривает.
> в любой момент мы можем прочитать и записать значение undefined, следовательно, кто-то может перезаписать его за нас и сравнение с undefined будет некорректным.
С таким же успехом кто-то может перезаписать все свойства документа, jQuery, и методы массивов. После этого он может облить ваш компьютер бензином и поджечь его.
Обычно методы с 'and' в названии — это code smell. Я бы сделал $device->notify(). Функция сама «достает» из device все данные, необходимые для уведомления. Для этого на может вызывать locate() или не вызывать, это деталь реализации, которой незачем торчать наружу.
Насчет главной идеи поста — выработал такую эвристику: я обычно разрабатываю снизу вверх, и когда у меня есть минимальный кусок кода, который можно тестировать независимо от всего остального — то выношу в отдельную функцию, даже если я не планировал ее создавать, и она не нужна в финальном API. Таким образом получается писать по 300-400 строк кода без багов. Запускаешь программу — и она просто работает. Вторая эвристика — не выносить дублирующийся код сразу, а подождать, пока наберется несколько похожих вариаций. Часто оказывается, что есть лучший способ убрать дублирование, чем я предполагал изначально, и предждевременная попытка это сделать не дала бы мне увидеть такую возможность. И третья эвристика — не разбивать методы исключительно ради разбивки. Часто один длинный метод читается лучше и понятнее, чем тот же метод разбитый на несколько маленьких. В оличие от автора поста я выношу что-то, только если оно начинает мозолить глаза и мешать.
Искал сейчас источник, но не нашел, исследование показывало, что оптимальный размер метода — от 30 до 50 строк. Размер больше 120 строк коррелирует с большим количеством багов, а множество мелких методов по 5 строк делает программу более сложной для понимания и поддержки.
Стало интересно, что это за мужик с вентилем в глазнице. Оказывается, это неизвестный прохожий, сфотографированный на улицах Сиэтла. А вентиль символизирует слоган «Open your eyes».
Мне очень понравился курс Udacity Design of Computer Programs. Целенаправленно учить Пайтон желания не возникало, но тут он легко выучился сам собой. Кроме того Норвиг пишет очень красивый код.
Одно из чудес искусства заключается в его способности передавать красоту не только эмоциональную, но и интеллектуальную. И то и другое требует подготовки. Пятилетний ребенок не воспримет эмоциональную составляющую «Невыносимой легкости бытия», как бы тонко он не чувствовал. Так и человек со стороны не поймет интеллектуальную красоту метода лагранжевых релаксаций — у него нет базы для понимания.
Один восхищается тем, как классно художник нарисовал сиськи, и думает что понимает, за что ценится эта картина. Другой восхищается знанием анатомии 80 уровня, продуманным ракурсом и светотенью, революционными для своего времени выбором цвета. Он также видит параллели с тем, что происходило в жизни художника на момент создания картины, и какое место она занимает в процессе его творческого развития. Что не мешает ему видеть классные сиськи.
Человеку не в теме доступа только поверхностная красота. Очень легко думать, что понимаешь, и при этом не понимать. Посмотрите какие картины люди покупают домой, какие пользуются популярностью в интернете. В 99% случаев это блевотное убожество и лубок. Им сказали восхищайся Мона Лизой — они восхищаются.
Насколько я ничерта не смыслю в изобразительном искусстве я понял только после того, как почитал Гомбриха, Иттена, и Бергера, и попробовал сам рисовать и заниматься дизайном. Увидев «Девочку на шаре» где-то на уличной выставке я бы сказал что это работа хорошего художника. Но что выделяет ее на фоне миллиона других хороших картин — для меня загадка.
Есть простая причина, почему не снимают фильмы про программистов. Самое интересное в программировании — это непосредственно процесс. Красивые алгоритмы, элегантные решения, создание чего-то из ничего. Я часами могу наблюдать как программирует Норвиг, или как Седжвик рассказывает про алгоритмы. Для меня это интереснее любого сериала. Но чтобы ощутить всю драму, нужно понимать, о чем идет речь. Как классическая музыка или изобразительное искусство — это недоступно человеку не в теме. Не потому что он примитивный, а потому что он сам ничего не создал в этой области, не понимает нюансов, правил игры, и не может оценить красоту того, что сделали другие.
Но объяснить в общих чертах «кто мы и что мы здесь делаем» несложно. Без программистов, на бытовом уровне мы бы тут же заметили отсуствие нескольких вещей: Гугла, хочешь что-то узнать — идешь в библиотеку читать теплую ламповую книгу 1976 года. Фейсбука (что в общем-то неплохо), Скайпа, Офиса (никаких ксерокопий и скачанных рефератов, все ручками). Компьютерных игр. Заказа товаров через интернет, сравнения цен и отзывов. Мобильной связи, GPS, цифрового фото, видео, и музыки.
Если говорить о субъективном восприятии процесса, работа программиста похожа на работу писателя. Исследование предметной области, сбор и анализ материала, поиск подходящей структуры и стиля изложения. Поиск правильных слов, редактирование, мучительные попытки как можно более ясно и просто выразить мысль.
Иногда это больше похоже на работу архитектора или дизайнера. Что наиболее приоритетно? Кто этим будет пользоваться? Где можно сэкономить? Что может потребоваться изменить в будущем? Как разрулить конфликтующие цели? Какой заложить запас прочности? Как защититься от человеческого фактора? Как сделать все понятным без документации? Как спланировать и распределить работу, чтобы уложиться в сроки?
Мне кажется это ближе к реальности, чем истории про Васю-рубаку и Машу-подозреваку. Почему люди думают, что если завернуть объяснение в сказку про медвежат и козлят, оно от этого станет доступнее?
Я не хожу на работу за заработной платой. Точнее, заработной платы мне недостаточно. Если моя работы тупа и бессмысленна, я найду другую с не меньшей зарплатой. Я не хочу постоянно смотреть на часы и ждать когда уже наступит конец рабочего дня или животворительная пятница.
В жизни нет такой дилеммы — либо делаешь что скажут, либо портишь себе нервы. Всегда есть третья опция.
А ищите, наверное, чтобы полюбоваться. Я ищу правила, чтобы что-то в них изменить или добавить. И в этом случае столбик намного удобнее. А сворачивать правила умеет любой программерский редактор.
С таким же успехом кто-то может перезаписать все свойства документа, jQuery, и методы массивов. После этого он может облить ваш компьютер бензином и поджечь его.
Насчет главной идеи поста — выработал такую эвристику: я обычно разрабатываю снизу вверх, и когда у меня есть минимальный кусок кода, который можно тестировать независимо от всего остального — то выношу в отдельную функцию, даже если я не планировал ее создавать, и она не нужна в финальном API. Таким образом получается писать по 300-400 строк кода без багов. Запускаешь программу — и она просто работает. Вторая эвристика — не выносить дублирующийся код сразу, а подождать, пока наберется несколько похожих вариаций. Часто оказывается, что есть лучший способ убрать дублирование, чем я предполагал изначально, и предждевременная попытка это сделать не дала бы мне увидеть такую возможность. И третья эвристика — не разбивать методы исключительно ради разбивки. Часто один длинный метод читается лучше и понятнее, чем тот же метод разбитый на несколько маленьких. В оличие от автора поста я выношу что-то, только если оно начинает мозолить глаза и мешать.
Искал сейчас источник, но не нашел, исследование показывало, что оптимальный размер метода — от 30 до 50 строк. Размер больше 120 строк коррелирует с большим количеством багов, а множество мелких методов по 5 строк делает программу более сложной для понимания и поддержки.
(Арнольд Рогалик)
Насколько я ничерта не смыслю в изобразительном искусстве я понял только после того, как почитал Гомбриха, Иттена, и Бергера, и попробовал сам рисовать и заниматься дизайном. Увидев «Девочку на шаре» где-то на уличной выставке я бы сказал что это работа хорошего художника. Но что выделяет ее на фоне миллиона других хороших картин — для меня загадка.
Но объяснить в общих чертах «кто мы и что мы здесь делаем» несложно. Без программистов, на бытовом уровне мы бы тут же заметили отсуствие нескольких вещей: Гугла, хочешь что-то узнать — идешь в библиотеку читать теплую ламповую книгу 1976 года. Фейсбука (что в общем-то неплохо), Скайпа, Офиса (никаких ксерокопий и скачанных рефератов, все ручками). Компьютерных игр. Заказа товаров через интернет, сравнения цен и отзывов. Мобильной связи, GPS, цифрового фото, видео, и музыки.
Если говорить о субъективном восприятии процесса, работа программиста похожа на работу писателя. Исследование предметной области, сбор и анализ материала, поиск подходящей структуры и стиля изложения. Поиск правильных слов, редактирование, мучительные попытки как можно более ясно и просто выразить мысль.
Иногда это больше похоже на работу архитектора или дизайнера. Что наиболее приоритетно? Кто этим будет пользоваться? Где можно сэкономить? Что может потребоваться изменить в будущем? Как разрулить конфликтующие цели? Какой заложить запас прочности? Как защититься от человеческого фактора? Как сделать все понятным без документации? Как спланировать и распределить работу, чтобы уложиться в сроки?
Мне кажется это ближе к реальности, чем истории про Васю-рубаку и Машу-подозреваку. Почему люди думают, что если завернуть объяснение в сказку про медвежат и козлят, оно от этого станет доступнее?
В жизни нет такой дилеммы — либо делаешь что скажут, либо портишь себе нервы. Всегда есть третья опция.