maxatwork правильно написал про масштабы. Я ничуть не стебусь. Написать 10 строчек «глупого» кода на питоне, потом еще 10 строк в другом месте и понять, что вот оно, вырисовалось, убить эти 20 строчек и написать вместо них 15 строк более абстрактного кода — что в этом такого?
Очень часто (в разных областях — % разный) бывает так, что 15 строк абстрактного не нужны и хватит 10 строк «тупого». Вот тут-то и кроется выгода. Наш код в итоге проще (а значит его проще поддерживать втч), а то, для чего нужны дополнительные уровни абстракции — эти уровни абстракции получают.
Про строчки — это не буквально, конечно. Можно вместо «строчки» подставить что-нибудь в духе «усилия», или еще что-то.
Это такой прием просто, вот автору так удобнее — именно написать код и не держать его в голове. Вам — удобнее держать в голове и не писать по нескольку раз. Это же не значит, что один способ плох, а другой хорош.
Насчет предусмотреть. Идея-то вот в чем. Можно предусмотреть, что код будет похож, и вынести его в какой-то отдельный блок. А можно предусмотреть, что будет похож, и попробовать на практике, чем именно он будет отличаться, чтобы потом вынести в отдельный блок уже на более высоком уровне абстракции.
Ну это я уже 3й раз одно и то же пишу чего-то :)
P.S. Если честно, не понял причины такого накала страстей тут в комментариях, чего все так грязью поливают друг на друга)
Пишем, вообщем, «тупой» код до тех пор, пока закономерность не выявится, и после этого рефакторим, а не пытаемся эту закономерность предугадать заранее (что, конечно, сделать можно, но для этого в голове держать нужно больше всего).
Ну в общем правильно. Автор делает одинаковые или почти одинаковые куски кода. Зачем он это делает? Чтобы увидеть, где они. Зачем старается делать именно одинаковые куски кода («похожие куски кода в разных классах или методах доводите до идентичности»)? Чтобы выделить общее. Когда становится понятно, какой именно код является общим и где именно он используется, весь копипаст выкидывается и пишется класс, который в себя включает необходимый функционал. Мы, по сути, обычно занимаемся тем же, только в голове — прикидываем, какой код где повторяется, у нас в голове этот копипаст. У подхода с реальным написанием такого кода есть как плюсы, так и минусы. Главный плюс — архитектурные решения можно немного откладывать до того времени, когда информации для нахождения удачной архитектуры будет больше, ну и меньше всего в голове держать нужно. Минусы, конечно, тоже есть — думаю, больше писанины на определенных этапах, что может как компенсироваться более удачной архитектурой, так и нет (за время, потраченное на доведение копипасты до идентичности, можно бы отрефакторить первоначальный не самый лучший «сервисный класс» с учетом выявленных новых требований).
> куски кода в разных классах или методах доводите до идентичности… Выполняйте эту процедуру столько, сколько необходимо для того, чтобы у вас в голове созрел дизайн следующего сервисного класса.
а как узнать, что это уже знаешь, пока не прочитаешь?)
Вы правильно делаете, что доверяете себе, а не тупо выбираете паттерн из книжки и пытаетесь его всунуть в код, это и есть, насколько я знаю, традиционный подход к использованию паттернов. Наверное, все, кто читает книжки про паттерны, понимают, что половину и так знали до этого. Но про них просто полезно почитать, чтобы свой «словарь» расширить, да и может это знание помочь избежать каких-нибудь неочевидных граблей.
По-моему так автор под соусом copy-paste подал вполне обычный и современный подход к программированию, основанный на паттернах, тестировании, рефакторинге)
сразу не понял, какой вообще смысл описывать словами (и где-то еще учитывать) то, что можно с примерно теми же усилиями описать в терминах какой-то утилиты автоматического тестирования, отсюда подозрение (не оправдавшееся) что ручные тесты — не антоним автоматизированных, а что-то другое )
А не могли бы вкратце рассказать, что такое ручные тесты?) Вдруг как-то веду их учет, и сам не знаю.
а то гугл выдает что-то в духе
>Hand-тест используется в клинической практике для выявления пациентов, склонных к деструктивному разрушительному поведению; в силовых структурах, профессиональном спорте — для отбора лиц, обладающих адекватной агрессией и «бойцовскими» качествами; в системе исполнения наказаний — для прогноза рецидивов и агрессивной делинквентности среди правонарушителей; в сексологии — для исследования особенностей психосексуальной ориентации, прогноза сексуальной агрессии и т. д.
>К слову, самый удобны способ ветвления я видел в ClearCase (в его «true» версии — из консоли и с конфигспеками). Там, установив пару строчек в конфиге своего среза репозитария, можно делать ветку автоматически при чекауте элемента — т.е. ты даже не будешь задумываться о том, что ты делаешь ветку и работаешь с ней.
т.е. чекаут на ревизию, потом коммит и автоматом ветка создается? это как-то отличается от стандартного поведения hg?
Собрался и написал свой аплоадер под google gears, unobtrusive-аналог загрузчика вконтакте, картинки пережимает, превью показывает, файлы загружает, обычную отправку форм эмулирует — не нужно делать никаких изменений на стороне сервера, есть хелперы для интеграции с django-вскими formset'ами.
Пока документация не готова, но мне нравится, что получается. Пока в качестве preview кину сюда ссылку на него, вдруг кому пригодится. Лицензия MIT, так что если кому интересно — используйте, подключайтесь к разработке. Пиар проведу, так сказать, предварительный.
Думаете, что Обама рад этой премии? Его теперь с утроенной силой все станут мутузить по поводу того, что он нихрена не делает. Уверен, что он это прекрасно понимает, и нобелевский комитет прекрасно понимает. Поэтому думаю, что комитет решил в такой манере вмешаться в политику и надавить на американского президента. Ход почти гениальный, как мне кажется) И ни с кем кроме Обамы не сработало бы, т.к. тот выехал на общественном мнении и от этого мнения зависит очень сильно.
js никто не отключает, а на тех, кто его отключает, можно забить, тут правда ваша.
Другое дело, что есть невинные люди с мобильными браузерами, люди с медленным-нестабильным коннектом, у которых что-то недогрузилось. Еще бывает криво написанный js (или js, не учитывающий особенностей некоторых браузеров), который может ломаться при определенных условиях. Где-нибудь в одном месте сломается, браузер выполнение всего остального js прекратит. Причин может быть много. Если код на сервере мы можем контролировать полностью, то на клиенте js выполняется в зоопарке окружений, над которым мы не властны. Поэтому мне кажется идеологически очень правильным подход с graceful degradation. И, более того, думаю, что как бы не развивался веб, подход все равно останется актуальным, т.к. контролировать среду выполнения у клиента мы не можем.
Но до того, как возвратить, тестирует. Т.е. оверхед будет не при запуске на прогонку тест-кейсов, а при импорте. Ну или, если угодно, запуск на прогонку будет при импорте, в отличии от обычных доктестов и юнит-тестов, которые выполняются по требованию.
Иногда это вполне допустимо, но как универсальное решение — не катит точно. Универсальное решение с похожим подходом и без оверхеда — обычные доктесты.
Раз тут знающие люди собрались, можно вопрос задать?
Все банально: есть таблица, в ней есть FK на другую таблицу, нужно получить связанные значения. Насколько запрос вида `id in (18,20,30)` хуже джоина, и хуже ли он? Предположим, что id нужных связанных объектов уже известны, например, получены другим запросом. Понятно, что 2 запроса хуже, чем один, но тот первый запрос не учитываем, считаем, что id'шники известны нам и так, волшебным образом.
Очень часто (в разных областях — % разный) бывает так, что 15 строк абстрактного не нужны и хватит 10 строк «тупого». Вот тут-то и кроется выгода. Наш код в итоге проще (а значит его проще поддерживать втч), а то, для чего нужны дополнительные уровни абстракции — эти уровни абстракции получают.
Про строчки — это не буквально, конечно. Можно вместо «строчки» подставить что-нибудь в духе «усилия», или еще что-то.
Насчет предусмотреть. Идея-то вот в чем. Можно предусмотреть, что код будет похож, и вынести его в какой-то отдельный блок. А можно предусмотреть, что будет похож, и попробовать на практике, чем именно он будет отличаться, чтобы потом вынести в отдельный блок уже на более высоком уровне абстракции.
Ну это я уже 3й раз одно и то же пишу чего-то :)
P.S. Если честно, не понял причины такого накала страстей тут в комментариях, чего все так грязью поливают друг на друга)
> куски кода в разных классах или методах доводите до идентичности… Выполняйте эту процедуру столько, сколько необходимо для того, чтобы у вас в голове созрел дизайн следующего сервисного класса.
Вы правильно делаете, что доверяете себе, а не тупо выбираете паттерн из книжки и пытаетесь его всунуть в код, это и есть, насколько я знаю, традиционный подход к использованию паттернов. Наверное, все, кто читает книжки про паттерны, понимают, что половину и так знали до этого. Но про них просто полезно почитать, чтобы свой «словарь» расширить, да и может это знание помочь избежать каких-нибудь неочевидных граблей.
сразу не понял, какой вообще смысл описывать словами (и где-то еще учитывать) то, что можно с примерно теми же усилиями описать в терминах какой-то утилиты автоматического тестирования, отсюда подозрение (не оправдавшееся) что ручные тесты — не антоним автоматизированных, а что-то другое )
а то гугл выдает что-то в духе
>Hand-тест используется в клинической практике для выявления пациентов, склонных к деструктивному разрушительному поведению; в силовых структурах, профессиональном спорте — для отбора лиц, обладающих адекватной агрессией и «бойцовскими» качествами; в системе исполнения наказаний — для прогноза рецидивов и агрессивной делинквентности среди правонарушителей; в сексологии — для исследования особенностей психосексуальной ориентации, прогноза сексуальной агрессии и т. д.
т.е. чекаут на ревизию, потом коммит и автоматом ветка создается? это как-то отличается от стандартного поведения hg?
Пока документация не готова, но мне нравится, что получается. Пока в качестве preview кину сюда ссылку на него, вдруг кому пригодится. Лицензия MIT, так что если кому интересно — используйте, подключайтесь к разработке. Пиар проведу, так сказать, предварительный.
bitbucket.org/kmike/gearsuploader/wiki/ru
Другое дело, что есть невинные люди с мобильными браузерами, люди с медленным-нестабильным коннектом, у которых что-то недогрузилось. Еще бывает криво написанный js (или js, не учитывающий особенностей некоторых браузеров), который может ломаться при определенных условиях. Где-нибудь в одном месте сломается, браузер выполнение всего остального js прекратит. Причин может быть много. Если код на сервере мы можем контролировать полностью, то на клиенте js выполняется в зоопарке окружений, над которым мы не властны. Поэтому мне кажется идеологически очень правильным подход с graceful degradation. И, более того, думаю, что как бы не развивался веб, подход все равно останется актуальным, т.к. контролировать среду выполнения у клиента мы не можем.
Иногда это вполне допустимо, но как универсальное решение — не катит точно. Универсальное решение с похожим подходом и без оверхеда — обычные доктесты.
Все банально: есть таблица, в ней есть FK на другую таблицу, нужно получить связанные значения. Насколько запрос вида `id in (18,20,30)` хуже джоина, и хуже ли он? Предположим, что id нужных связанных объектов уже известны, например, получены другим запросом. Понятно, что 2 запроса хуже, чем один, но тот первый запрос не учитываем, считаем, что id'шники известны нам и так, волшебным образом.