Как стать автором
Обновить
35
0
Сергей Галанин @SergeyGalanin

Программы—программистам! Польза—пользователям!

Отправить сообщение

Алёна, спасибо за отличную статью!

Можете рассказать подробнее вот про это?

Фишка этой библиотеки в том, что описание компонента во вкладке «Дизайн» подтягивается через скрипт из Figma. То есть, дизайнеры рисуют и описывают правила поведения компонента, а разработчики потом забирают фрейм на сайт.

Можно предложить решение, из-за которого разработчики не будут спорить, что оно говно))
В конце статьи не хватает ссылки на следующую часть. Приходится в начало крутить, где ссылки на все части.
Репозиторий контейнеров или образов?
Не-не-не: «Ветер дует неправильно. Правильно дуть вот так».
Редко кто осознанно размазывает знания о функционале по коду, думаю чаще это происходит из-за неверно выбранной абстракции, в таком случае поздно инкапсулировать — надо рефакторить код.

Ну почему же поздно? Рефакторинг в данной ситуации и будет состоять в извлечении метода/класса, то есть, в «моей терминологии», в инкапсуляции кусочков кода куда-то там.

А деньги нормальные люди хранят целыми числами в копейках или в Decimal-типах, так что мимо.

А ненормальные обрабатывают во float-ах, и тоже неплохо зарабатывают.
Всё-таки в данном контексте собрать и спрятать — одно и то же. В проекте как правило весь код всем программистам физически доступен, никто доступ к нему не ограничивает. И всё же собрать в одном месте означает спрятать собранное из мест, где оно было/могло быть раньше, в специально отведённое место (класс, модуль, библиотеку — по желанию).

Например (условно), раньше в коде я после каждой операции сложения денег выполнял округление, чтобы избежать побочных эффектов точности:
sum = round(money_a + money_b)

И таких мест по коду было очень много. В каждой такой точке содержался кусочек знания о том, что реализация денег в этом коде хреновая (в виде float), деньги нужно постоянно округлять.

Потом я заменяю сложение с округлением на специальный вызов, который сам умеет правильно складывать деньги с нужным округлением:
sum = add_money(money_a, money_b)

Теперь вы читаете add_money, и не видите никаких round. Я спрятал round? — спрятал.
Таким вот нехитрым способом я прячу от глаз подальше подробности того, как нужно работать с деньгами в этом коде: просто вызывай add_money — и всё всегда будет хорошо, и никаких проблем с точностью.

А что я сделал? Я инкапсулировал код, который выполняет нужные операции, в отдельный модуль, в отдельную функцию. Инкапсулировал? — да. Спрятал? — тоже да.
Мне показалось, что мы говорим об одном и том же. Я тоже о сокрытии сложности, которая реализуется через убирание под кат лишних подробностей.
ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F

Термин уж больно хороший: заворачивание чего-то во что-то. Как раз то, о чём я и говорю.
Очень правильный вопрос.

Для начала встречный вопрос: вы согласны, что размазывание деталей реализации по всему коду — это плохо?

Второй вопрос: вы согласны, что значение термина — это вопрос договорённости?

Теперь мой ответ.

Я считаю, что определение в вики хуже, потому что оно не ведёт прямиком к полезному эффекту сокрытия реализации. И даже сокрытие данных, которое могло бы способствовать сокрытию реализации, в классическом понимании инкапсуляции не подразумевается.

Можно объединить поля данных и некоторые процедуры, к ним относящиеся, в одном классе, но это не гарантирует, что знания об устройстве объекта больше нигде не всплывут. Гарантию может дать только сам программист, если будет твёрдо придерживаться правила сосредотачивать все знания об устройстве объекта в одном месте.

Фактически, определение из вики — это частный случай моего определения: да, инкапсуляцию в смысле сокрытия реализации можно осуществить в том числе и при помощи инкапсуляции данных и методов в один класс.

P.S.
Определения терминов из мира программирования формируются исходя из работ авторитетных товарищей из этого мира программирования. Между тем, товарищи Роберт Мартин и Мартин Фаулер не намного умнее нас с вами, просто они пишут книги, а мы — нет. Поэтому я предлагаю нам с вами тоже сделать свой вклад в улучшение мира программирования. Например, путём корректировки некоторых не очень хороших определений терминов на определения, которые приведут в конечном итоге к созданию более качественного кода каждым программистом.
Anemic не исключает сокрытия реализации = инкапсуляции, хоть данные и помещаются отдельно от функций. Раз есть тенденция к популяризации anemic — значит, для кого-то это имеет смысл. Значит, инкапсуляция в смысле википедии не так уж и хороша, раз ей пренебрегают.

Да, мне тоже любопытно понять, почему anemic набирает популярность. Думаю, у её приверженцев есть достаточно сильные аргументы.
Я ждал этого вопроса.
Тут, очевидно, всё дело в издании. В одном издании пошла одна редакция, в другом — другая. Где-то редактор исправил, где-то цензор, а где-то и сам автор подсуетился.
У автора ребуса была другая редакция, чем та, что мне удалось скачать.
Видел этот косяк, но поленился искать правильное издание или подчищать скан…
Меня не устроило то, что кто-то посторонний потратил моё личное время и усилия, хотя я его об этом не просил и не позволял.

Да, я тоже иногда пишу обработчики ошибок, которые выдают пользователю «неизвестная внутренняя ошибка». Но только в том случае, когда пользователю действительно нечего рассказать (ошибка в базе по нештатной причине, например), и только для того, чтобы не показывать ему голую страницу 500. Никакие данные, введённые пользователем, при этом не теряются.

Согласен, что в случае ошибки с пунктом доставки, возможно, никак нельзя было установить причину. Но что-то мне подсказывает, что на самом деле можно. Просто нет такой привычки у программистов. Ну это как в былые времена не было практики подсвечивать поля ввода с ошибкой, а описания ошибок просто вываливались вверху страницы одной кучей после сабмита. И хорошо, если можно было понять, что не так с полем, а то часто получал просто «поле заполнено неправильно». Да ещё пароль с подтверждением очищались, и их перед каждой попыткой сабмита надо было набивать снова и снова.

Верю, что когда-нибудь забота о пользователе шагнёт ещё дальше, и в продуктах повсеместно(!) будут не только подсвечиваться неправильно заполненные поля, но и вообще на каждом шагу будут даваться подсказки, что можно предпринять даже в нештатной ситуации.
Плюс 100 этой публикации. Я как пользователь и одновременно программист всегда бываю вдвойне в ступоре от подобных сообщений. Первый ступор от того, что как пользователь я понятия не имею, как такую проблему решить. Пятиминутный квест оформления заказа превращается в многодневный квест бодания с техподдержкой. Второй ступор от того, что как программист я знаю: не так уж и трудно в месте возникновения ошибки собрать побольше сведений о ней и донести до пользователя, как ему жить с этой ошибкой дальше. Это предельно важно! Только программист знает, что именно в недрах его программы стряслось, и какими обходными путями можно попробовать эту ошибку обойти.

Ну и диагностику неплохо бы собирать, чтобы, если уж пользователь обратился в техподдержку, то его не посылали бы на попробовать сделать то же самое в другом браузере, а смогли сходу выдать внятный ответ.

Просто не так давно натыкался на такую ошибку при оформлении заказа в одном крупном магазине. И заказ-то был уже не первый, и магазин-то солидный — так нет же: «попробуйте повторить позже». Была бы хоть какая альтернатива — сразу молча ушёл бы, и магазин потерял клиента с ежегодными платежами в 10к рублей. Но идти некуда, я потыкался в других браузерах и отправился в техподдержку. Где меня предсказуемо послали обратно в те же самые другие браузеры. И только после того, как я сдерживая мат, вежливо объяснил, что всё это я уже сделал до обращения, и вопросил: а не начать ли программистам уделять больше внимания проблемам пользователей, через несколько дней получил ответ, что ошибка возникала из-за выбранного мной пункта выдачи. Тогда я спокойно выбрал другой пункт выдачи, находящийся от первого в трёхстах метрах, и совершенно без проблем завершил оформление заказа.

Вопрос: вот зачем так трепать нервы покупателям?

А вот это офигенно, зачёт! Я до такого не додумался.

К чему мотивирует — это всё понятно)
Можно личный вопрос, чисто из любопытства: сколько Вы в планке можете простоять? На 15-минутный митинг хватит? А рассказ коллеги, услышанный в планке, хорошо воспримется и запомнится? А как насчёт что-нибудь записать по ходу обсуждения?
Не, я понимаю, что в реальности на постоянной основе так никто не делает, но как вообще такая мысль могла в голову прийти?))
Я бы предпочёл митинг отдельно, а здоровье отдельно. А при таком смешении можно не получить ни того, ни другого ((
Митинг в планке — жесть…
Не убирайте таблицу.
У Венеры — понятно где, только у статУи тряпка загораживает. У Чужого, наверное, где-то в том же месте. А где писька у фрикаделек — даже стесняюсь думать…

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность