// От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
А прикиньте как инженерам железок. 10 лет делаешь ракету а она разбивается о небесную твердь.
После таких обломов умные люди придумали себе работу по названию системная инженерия.
Они обещают и делают в большинстве случаев весь проект в рамках запланированных бюджета и времени.
Для этого по напридумывали кучу разных правил — методов, практик.
Одним из таких принципов является метод гамбургера. Тут http://ailev.livejournal.com/920248.html детально расписано.
В программировании та же штука.
Нужны функции/действия. Есть исполнитель — процессор/кластер. Есть ресурсы — память, ввод, вывод.
Нужно запланировать последовательность действий по перемещению, хранению, изменению сигналов.
Чтобы получить желаемое состояние ресурсов/информации на ресурсах.
Реализация каждой функции "размазывается" по разным ресурсам.
Если неудачно выбраны структуры данных, приходится постоянно рефакторить.
Вспомните ассемблер — ячейка памяти напрямую адресовалась. Очень неудобно помнить физический адрес размещения памяти для каждой переменной.
Ввели абстракцию имя — адрес оставить процессору, имя — человеку. Функцию хранения данных "отвязали" от конкретных реализаций.
Дальше ввод абстракций только увеличивался. Циклы, процедуры, структуры, модули, классы, объекты, интерфейсы.
Все делалось для отдаления реализации/конструкции от функции.
Вершиной абстрактного подхода оказались функциональные языки. Однако пока требуют хорошего железа и выверта мозгов.
Но человечество упорно идет к своей второй цели — general artificial intelligence. Универсального решателя проблем.
Чтобы не зная конкретных деталей реализации операций, планировать и выполнять их.
Упомянутые ранее системные инженеры замучились писать плагины конвертации между кучей CAD/PLM/ERP.
Тогда взяли и придумали нейтральный формат хранения данных — iso 15926.
Теперь хватило разработать по одному плагину на программу и обмениваться данными без проблем совместимости.
А по поводу работы с абстракциями можете полистать книгу Криса Партриджа — "Business Objects: Re-Engineering for Re-Use" http://ailev.livejournal.com/938647.html
Там очень четко и подробно расписано как моделировать данные, чтобы не было мучительно больно переделывать все пару раз.
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, rfq, Вы писали:
rfq>>Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
E>Ну да, охота на дичь. Только дичь — это я.
Здравствуйте, Eternity, Вы писали: E>так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
я сегодня прямо каким-то ущербным чувствую. все жалуются на эту проблему, а у меня ее никогда не было.
например, у меня в жизни никогда не болела голова. вот так, чтобы без болезни сама по себе. я тоже не знаю, как такое бывает.
вот пишут люди, а потом, говорят, переписывать надо. а зачем? ну в чем проблема выбрать абстракции? ну вот есть пользователь, так, есть, там, танк — отлично. вот абстракция, вот абстракция, все вместе они образуют что нам нужно. зачем там что-то кардинально менять в будущем?
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Eternity, Вы писали: E>>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены. __>самые лучшие абстракции, которые переживают любые изменения это естественные понятия, которые очевидны еще в самом начале разработки.
А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
Про адаптеры.
Адаптеры между гусиницами и танком делают, не потому что абстракции хочется. А потому, что у нас уже есть гусеницы от трактора и мы можем время съэкономить.
Сам напсал аналогию и подумал: а вы уверены, что в реальном танкостроении нет "адаптеров", которые позволяют ставить новые башни на старые, серийные шасси?
Я не спец в танкостроении, но уверен такие случаи не единичны.
Здравствуйте, akava, Вы писали: A>А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
я очень люблю программирование, проектирование и оптимизацию как часть этого процесса. в том смысле, что я много времени провел изучаю, как работают __разные__ люди и всевозможные __разные__ подходы к проектированию, тестированию и разработке. вы удивитесь, насколько по разному люди могут делать одно и то же. сейчас мой вывод таков, что ничего загадочного в проектировании нормальной системы, которая будет всех долгие годы устраивать и которую потом не придется переделывать, нет. это достаточно просто. настолько же просто, как, например, сделать операцию на сердце. вы сможете ее сделать? я вот не смогу. почему? потому что это в принципе невозможно? нет. потому, что у меня недостаточно знаний и опыта. а так никаикх сложностей нет — все давно известно и изучено. не надо искать оправдания отсуствиям этих самых знаний и опыта, нужно просто учиться и внимательно изучать и перенимать лучшие решения, а не просто разводить руками, что "меняются требования" и "слишком много неопределенностей".
Здравствуйте, akava, Вы писали: A>В следующий раз не утруждайте себя писать так много ттекста ни о чем.
а вы это зачем написали? не понравился намек на квалификацию?
да, проектирование это одна из самых сложнейших вещей в программировании, да и много где и да, она требует наивысшей квалификации. да, эту квалификацию нельзя получить прочитав одну книжку по сайтам и че-то там поделав, этому нужно долго и целенаправленно учиться и не где попало, а еще и место такое фиг найдешь, где в этом действительно разбираются. и да, большинство программистов не обладает квалификацией достаточной для грамотного проектирования, так как это им нафиг не нужно, это не их часть работы
Вот смотрите. Если представить, что у нас с вами есть долгосрочные отношения, то эти отношения можно представить в виде проекта. С неопределенностями.
Вы сделали предположение, что на мой конкретный вопрос меня устроит бла-бла-бла ни о чем
, предположили, что мне не понравился намек на квалификацию. И опять мимо.
2 предположения в условиях неопределенности и оба неверных.
Почему же вы продолжаете считать, что возможно сразу же найти нужную абстракцию, когда вы, в начале работ, не до конца понимаете стоящую перед вами задачу?
Исходя из моего опыта (это намек на мою достаточно высокую квалификацию), человеческие отношения, или коммуникация, является наиболее неопределеннй частью построения системы.
Построить a system не сложно, сложно реализовать the system. Т.е. мало что-то заабстрагировать и закодировать, важно сделать именно то, что нужно заказчику. И именно из-за этих отношений ранее выбранные абстракции становятся негодными.
Здравствуйте, akava, Вы писали: A>Вот смотрите. Если представить, что у нас с вами есть долгосрочные отношения, то эти отношения можно представить в виде проекта. С неопределенностями. A>Вы сделали предположение, что на мой конкретный вопрос меня устроит бла-бла-бла ни о чем
, предположили, что мне не понравился намек на квалификацию. И опять мимо. A>2 предположения в условиях неопределенности и оба неверных. A>Почему же вы продолжаете считать, что возможно сразу же найти нужную абстракцию, когда вы, в начале работ, не до конца понимаете стоящую перед вами задачу?
Если вас интересует почему я подумал, что у вас слишком мало опыта, чтобы рассуждать об архитектуре, то я сделал это по этому предложению: "Адаптеры между гусиницами и танком делают, не потому что абстракции хочется."
Оно написано с двумя ошибками, типичными для малочитающих людей. Я не граммар-наци, но просто конкретно такие ошибки своейственны тем, кто мало читает. Что косвенно говорит о том, что вы не знакомы с литературой по проектированию, дизайну, архитектуре, которой очень много и ее надо читать. И без чтения ее ничего толкового не выйдет. Логично, что столкнувшись с проблемой, стоит изучить опыт решения ее. Вы не знаете никаких подходов к проблеме и, судя по всему, даже не пытались исследовать пути ее решения. Опыт у вас быть может, но тут важен правильный опыт, а не повторение раз за разом одних и тех же плохих решений. Я об этом тоже написал в первом посте. Извиняюсь, что написал слишком размыто. A>Исходя из моего опыта (это намек на мою достаточно высокую квалификацию), человеческие отношения, или коммуникация, является наиболее неопределеннй частью построения системы. A>Построить a system не сложно, сложно реализовать the system. Т.е. мало что-то заабстрагировать и закодировать, важно сделать именно то, что нужно заказчику. И именно из-за этих отношений ранее выбранные абстракции становятся негодными.
Если вы реально хотите разобраться в проектировании, то начните хотя бы с этого
— Буч — ООП анализ и проектирование
— Robert C Martin Clean code
— Гамма и кто-то там Паттерны проектирования
— бонусом — Александреску — современное проектирование на С++
там найдутся ответы на годами мучающие вас вопросы и нам не понадобится препираться на форуме и обсуждать квалификацию друг друга
Здравствуйте, 0x7be, Вы писали:
0>... или написать все в функции main(). 0>Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. ...
А для языков с динамической типизацией такой подход работает?
Здравствуйте, __kot2, Вы писали:
__>там найдутся ответы на годами мучающие вас вопросы и нам не понадобится препираться на форуме и обсуждать квалификацию друг друга
Квалификацию обсуждаете только вы. Мою квалификацию. Мне ваша квалификация фиолетово.
Диагнозы по фотографии тоже ставите только вы. Если экстраполировать вашу способность анализировать ситуацию на ведение проектов и создание архитектуры, то ваше первое сообщение, вызвавшее улыбку, станет вызывать смех.
Мне от вас нужен не диагноз по фотографии, а ваши комментарии по поводу следующего: __>самые лучшие абстракции, которые переживают любые изменения это естественные понятия, которые очевидны еще в самом начале разработки.
А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
И этого:
Про адаптеры.
Адаптеры между гусеницами и танком делают не потому, что абстракции хочется. А потому, что у нас уже есть гусеницы от трактора и мы можем время сэкономить.
Сам написал аналогию и подумал: а вы уверены, что в реальном танкостроении нет "адаптеров", которые позволяют ставить новые башни на старые, серийные шасси?
Я не спец в танкостроении, но уверен такие случаи не единичны.
Здравствуйте, Alexander Polyakov, Вы писали:
0>>... или написать все в функции main(). 0>>Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. ... AP>А для языков с динамической типизацией такой подход работает?
Работает, конечно, почему возникли сомнения?
Кстати, не вырывайте фразу из контекста. Без замечания "Но это тоже не есть модель гарантированного успеха, потому что к этому прикладывается некое чутье, выработанное за годы мучений с написанным мною же кодом", эта фраза становится бессмысленной и чертовски вредной.
Это самое чутье часто подсказывает, что конкретная абстракция как раз нужна в конкретном месте.
Тут еще можно добавить, что с опытом появляется набор надежных, доказавших свою полезность абстракций (а с ними набор ограничений, т.е. случаев когда эти абстракции применять не стоит). Такие абстракции, если видишь подходящее им место, конечно же используются сразу.
Примером таких абстракций может служить вынесение внешних сервисов за интерфейсы. Я это делаю практически всегда, за исключением случаев мелких проектов или прототипирования "на выброс".
Здравствуйте, akava, Вы писали:
0>>>... или написать все в функции main(). 0>>>Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. ... AP>>А для языков с динамической типизацией такой подход работает? A>Работает, конечно, почему возникли сомнения?
Вопрос задал, потому что хочется лучше понять, о чем говорит 0x7be.
Ок, пусть для динамических языков тоже работает. Тогда следующий вопрос. Как осуществляется рефакторинг? Рассмотрим ситуацию. Пусть прошло много времени, достаточно, чтобы детали задачи исчезли из головы разработчика, или пришел другой разработчик. Встала новая задача. Для ее реализации требуется нарастить/обрезать текущие абстракции. Тесты написаны. Как разработчик будет загружать к себе в голову необходимый минимум информации для выполнения наращивания/обрезания абстракций? В случае статических языков есть навигация. Что в случае динамических языков?
A>Тут еще можно добавить, что с опытом появляется набор надежных, доказавших свою полезность абстракций (а с ними набор ограничений, т.е. случаев когда эти абстракции применять не стоит). Такие абстракции, если видишь подходящее им место, конечно же используются сразу.
В первоначальном посте говориться о постепенном выращивании абстракций под конкретный проект, а вы тут пишите о вытаскивании из сундука уже готовых абстракций. Это ровно противоположные стратегии. Тем самым у вас получается смешанная стратегия. Что ж вполне разумно. Сейчас интересно обсудить ту часть стратегии, которая относится к выращиванию.
Здравствуйте, akava, Вы писали: A>Третье сообщение и мимо. Вы просто АС!
таких людей, которые пишут "пять мимо" — их в моей жизни было миллион. Когда я разговаривал и знал таких людей лично, то для меня было понятно, что обвчно человек занимается самообманом или просто выкручивается из ситуации. на меня это не работает. то есть я понимаю, если вы хотите не потерять лицо, перед другими, читающми эту ветку, но я гораздо больше доверяю собственным выводам о вас, чем вашим заверениям. никто же о себе плохо говорить не будет.
A>P.S. За ошибки действительно сорри. Но вот проблему вы неправильно продиагностировали. Ошибки были сделаны из-за спешки.
Это еще одно из распространенных заблуждений-отмазок. "мы торопились, поэтому так получилось". когда человек торопится, он делает так, как делал раньше, он не думает, у него времени. И если получается какаха (я тут больше о программировании), то это просто опыт у человека такой, а не потому, что времени было мало
Здравствуйте, akava, Вы писали: A>А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
приведите мне пример
A>И этого: A>Про адаптеры. A>Адаптеры между гусеницами и танком делают не потому, что абстракции хочется. А потому, что у нас уже есть гусеницы от трактора и мы можем время сэкономить. A>Сам написал аналогию и подумал: а вы уверены, что в реальном танкостроении нет "адаптеров", которые позволяют ставить новые башни на старые, серийные шасси? A>Я не спец в танкостроении, но уверен такие случаи не единичны.
нет, не уверен. но инженерия она везде инженерия. если бы не было говнокодеров среди инженеров, не было бы автоваза
Здравствуйте, Alexander Polyakov, Вы писали:
AP>>>А для языков с динамической типизацией такой подход работает? A>>Работает, конечно, почему возникли сомнения? AP>Вопрос задал, потому что хочется лучше понять, о чем говорит 0x7be. AP>Ок, пусть для динамических языков тоже работает. Тогда следующий вопрос. Как осуществляется рефакторинг? Рассмотрим ситуацию. Пусть прошло много времени, достаточно, чтобы детали задачи исчезли из головы разработчика, или пришел другой разработчик. Встала новая задача. Для ее реализации требуется нарастить/обрезать текущие абстракции. Тесты написаны. Как разработчик будет загружать к себе в голову необходимый минимум информации для выполнения наращивания/обрезания абстракций? В случае статических языков есть навигация. Что в случае динамических языков?
Ага, т.е. тут вопрос в том, что для динамических языков возможности рефакторинга значитально слабее из-за отсутствия compile-time проверки?
Если вопрос в этом, то я даже в статически типизированных языках не представляю мало-мальски серьезный рефакторинг без тестов. А если есть тесты, то и в динамике не все так страшно становится. Хотя да, с поддержкой компилятора рефакторить проще.
Про навигацию не понял. Ну нету и нету (хотя она есть, только не такая развитая). Делают же люди крупные системы на динамике и ничего, не запутываются.
У меня опыта работы с динамикой (Питон) не много, но, насколько я вижу, каких-то существенных проблем нет.
A>>Тут еще можно добавить, что с опытом появляется набор надежных, доказавших свою полезность абстракций (а с ними набор ограничений, т.е. случаев когда эти абстракции применять не стоит). Такие абстракции, если видишь подходящее им место, конечно же используются сразу. AP>В первоначальном посте говориться о постепенном выращивании абстракций под конкретный проект, а вы тут пишите о вытаскивании из сундука уже готовых абстракций. Это ровно противоположные стратегии. Тем самым у вас получается смешанная стратегия. Что ж вполне разумно. Сейчас интересно обсудить ту часть стратегии, которая относится к выращиванию.
Согласен, об этом не говорит 0x7be. Это я добавил от себя и это то, что я делаю.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, akava, Вы писали: A>>А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк. __>приведите мне пример
Пример чего? Неопределенности в начале проекта? Вы издеваетесь??? https://freelance.ru/projects/335505/
Необходима разработка интернет-магазина .Подключение платежных систем не требуется, только обработка заявок. Дизайн должен быть очень хорошего качества.
1. Найти самую актуальную базу диск и шин в интернете.
Фото+все технические параметры (образец уже завели в базе).
1A. Найти данные по шинам для грузовых машин и мотошин. (возможно такого нет).
1B. Найти скрипт «подбор шин по марке автомобиля».
2. Загрузить всё это на сайт (PRESTASHOP), что бы отображались как товары отсутствующие на складе. Важно! Что бы все необходимые параметры были занесены корректно.
2A. Установить скрипт «подбор шин по марке автомобиля».
3. Настроить в престашоп загрузчик остатков из базы данных поставщика и загрузить остатки, 4 эксель файла.
3A. В случае неисполнения 1A, сформировать каталог по шинам для грузовых машин и мотошин из остатков.
4. Объяснить сотруднику, как синхронизировтаь остатки из этих файлов в дальнейшем.
Внимание! Задания 1–4 оплачиваются только когда будут все они полностью выполнены.
Задания с буквами 1A 1B 2A и тд это дополнительные задания и являются бонусом и оплатой сверх задания.
Навыки программирования не требуется, но требуется хороший опыт в работе с базами данных. Т.е. базы в интернете будут не в том формате, которые понимает престашоп, нужно будет их подредактировать. И правильно настроить загрузчик престашопа.
Остатки от поставщика тоже необходимо привести в удобоваримую форму.
Скрипт подбора по машине уже готовый, его просто нужно правильно установить.
Требуется на yii фреймворке с нуля написать закрытую административную панель для формирования отчетов по существующим таблицам из базы данных. Предполагается, что это личный кабинет, и пользоваться его ресурсами может только авторизованный пользователь. Необходимо предусмотреть роли для того чтобы блокировать просмотр и формирование отчетов по пользователям (т.е. у некоторых пользователей будет доступен только один отчет, с заданным жестко некоторыми полями фильтра). Стандартный дизайн как при установке yii меня устраивает.
Функции:
— Авторизация пользователей
— Назначение ролей и прав пользователям
— Формирование отчетов — отчеты должны формироваться из заданных заранее в фильтрах условиях.
(На будущее — выгрузка сформированного отчета в excel.)
— Редактор таблиц (добавление/удаление строк, редактирование имеющихся)
Предстоит написать сначала закрытую часть, а затем добавлять туда отчеты. За сложные отчеты готов платить отдельные деньги. Все работы по договоренности. Примеры реализованных вами отчетов дадут вам преимущество. От вас — сроки и цена.
Вы в каждом случае понимаете, что нужно будет сделать? Не в общем, а конкретно от начала до конца.
Ну хорошо, вы, может, и понимаете, но вы уверены, что понимает сам заказчик что ему нужно? Я не уверен.
A>>И этого: A>>Про адаптеры. A>>Адаптеры между гусеницами и танком делают не потому, что абстракции хочется. А потому, что у нас уже есть гусеницы от трактора и мы можем время сэкономить. A>>Сам написал аналогию и подумал: а вы уверены, что в реальном танкостроении нет "адаптеров", которые позволяют ставить новые башни на старые, серийные шасси? A>>Я не спец в танкостроении, но уверен такие случаи не единичны. __>нет, не уверен. но инженерия она везде инженерия. если бы не было говнокодеров среди инженеров, не было бы автоваза
Давайте пример приведу.
Вот раздобыла разведка чертежи новых шасси новейшего танка условного противника. Шасси на несколько порядков превышают наши аналоги.
Пришла задача модернизировать наши танки новым видом шасси. Как будете решать?
Хотя нет, аналогия не уместна, в IT производство не стоит практически ничего. Тогда вводная меняется: Мы перехватили "вражеский" состав с новыми шасси. Нужно оснастить ими наши танки.
В какой момент появиться физический адаптер? А в условиях нехватки времени?
Здравствуйте, akava, Вы писали: A>Пример чего? Неопределенности в начале проекта? Вы издеваетесь???
пример того, как по первоначальным условиям было спроектировано грамотное решение (с примером условия и решения), затем задача изменилась всвязи с бизнес-требованиями и теперь грамотное решение, которое было разработано вначале оказалось ну вообще не в тему и пришлось все перекраивать
А в каком из этих примеров тянет ввести вредную с будущем абстракцию?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
