Здравствуйте, Eternity, Вы писали:
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Боюсь, что помогает тут только опыт, полученный путем набивания многих шишек в попытках все заабстрагировать или написать все в функции main().
Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. Плюс не стесняюсь делать и выбрасывать прототипы. Но это тоже не есть модель гарантированного успеха, потому что к этому прикладывается некое чутье, выработанное за годы мучений с написанным мною же кодом )
Здравствуйте, Eternity, Вы писали:
E>невозможно, как и предвидеть любые будущие требования.
Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
С другой стороны, писать конкретный прямолинейный код может быть еще более разрушительно, так как со временем код естественным образом начинает запутываться, подобно сваленным в кучу проводам, удивительным образом самопроизвольно спутывающимся в неразвязываемый узел. В слишком конкретном коде в нужный момент не получится заменить компонент на аналогичный, хотя, надо сказать, что в хорошо абстрагированном коде такая проблема, как ни странно, тоже нередка, так как вдруг выясняется, что абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу, так как написать в одной конкретной программе все возможные виды абстракций невозможно, как и предвидеть любые будущие требования. Да и вообще, человеческий мозг слаб и мал, и не способен продумать, представить и просчитать все заранее.
Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Здравствуйте, Eternity, Вы писали:
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
Противники убийства животных могут найти другие аналогии, например, поиск сексуальных партнеров.
Здравствуйте, Erop, Вы писали:
A>>Но нужно быть готовым выкинуть и переделать, когда ситуация (или ее понимание) сильно изменится. A>>А чтобы понимание пришло раньше, а не позже, существуют техники. Например, прототипирование и ранняя обратная связь от пользователя.
E>А я с этим полностью согласен. И грамотная архитектура тут очень в тему будет, так как позволит выикинуть не всё, а только то, что устареет. И тут абстракции на пользу, а не во вред, обычно...
Ну тогда мирдружбажвачка и, конечно же,
// От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
А прикиньте как инженерам железок. 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
Там очень четко и подробно расписано как моделировать данные, чтобы не было мучительно больно переделывать все пару раз.
Вот смотрите. Если представить, что у нас с вами есть долгосрочные отношения, то эти отношения можно представить в виде проекта. С неопределенностями.
Вы сделали предположение, что на мой конкретный вопрос меня устроит бла-бла-бла ни о чем
, предположили, что мне не понравился намек на квалификацию. И опять мимо.
2 предположения в условиях неопределенности и оба неверных.
Почему же вы продолжаете считать, что возможно сразу же найти нужную абстракцию, когда вы, в начале работ, не до конца понимаете стоящую перед вами задачу?
Исходя из моего опыта (это намек на мою достаточно высокую квалификацию), человеческие отношения, или коммуникация, является наиболее неопределеннй частью построения системы.
Построить a system не сложно, сложно реализовать the system. Т.е. мало что-то заабстрагировать и закодировать, важно сделать именно то, что нужно заказчику. И именно из-за этих отношений ранее выбранные абстракции становятся негодными.
Здравствуйте, 0x7be, Вы писали:
0>Возможно, что без статического контроля агрессивный рефакторинг становится более рискованным делом.
Да. Как ты писал, подход опирается на рефакторинг. Какие средства, поддерживающие преобразования кода у нас есть:
1. человеческий мозг,
2. автоматизированное тестирование,
3. средства, основанные на статической типизиции.
Первый пункт. Человеческий мозг сильно ограничен по объему обрабатываемой информации.
Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.
Получается, "выращивание" правильных структур кода может опираться только на третий пункт.
rfq>Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
Хороший программист должень получать удовольствие от создания работающей программы, а не от самого факта написания кода. ИМХО конечно.
Ну а насчет абстракций — хороший программист должен быть еще и ленив, и создавать абстракции лишь тогда, когда они ему облегчат написание кода. Навык определять какая абстракции облегчит жизнь в будущем, а какая — совсем наоборот — приобретается с опытом.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Eternity, Вы писали:
E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
Значит абстракции подобраны неверно или имплементированы неправильно. Абстракции
должны как раз уменьшать количество всяческих модификаций в связи с изменением
требований. Посмотрите на фундаментальную теорему разработки ПО.
One level of indirection и есть абстракция.
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Это главная задача программиста -- отобразить абстрактное в конкретное.
Здравствуйте, Eternity, Вы писали:
E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе[...]
Абстракции не несут ни вреда ни пользы — это необходимость, т.к. решение задач происходит в рамках абстракций.
E>[...]при изменении или уточнении требований к программе или модификации используемого алгоритма приходится[...]
2) Выбор абстракций всегда зависит от задачи.
Если вы считаете траекторию метеороида в солнечной системе, то лучшей абстракцией будет материальная точка (тело для которого свойства типа объём, размер, форма, температура и т.д нам безразличны), эту абстракцию можно записать например вот так:
abstract class Solid
{
Microsoft.Xna.Framework.Vector3 Position {get; set;}
double Mass {get;}
}
Но всё меняется как только этот метеороид становится метеором. Нас в этот момент уже будут интересовать его плотность, форма и т.д. — без этого его траекторию уже нельзя будет вычислить.
E>дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
ЩИТО?
зачем какие-то там стены?
E>С другой стороны, писать конкретный прямолинейный код [...]
E>[...]абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу[...]
Это как?!
Вот метеороид стал метеоритом, и встаёт задача его транспортировки, но существующие абстракции почему-то не учитывают его радиоактивности. Ясен пень, что для новой задачи нужна новая абстракция — теперь это опасный груз, имеющий какую-то ценность.
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Выбор и манипулирование абстракциями — не снижают продуктивность работы, это сама работа (т.е. её часть).
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Необходимо всё-таки запомнить значение слова абстрагирование.
Абстрагирование — это мысленное выделение, вычленение некоторых элементов конкретного множества и отвлечение их от прочих элементов данного множества.
Для каждой задачи будет свой набор абстракций. Один и тот же человек в разных программах может выступать в качестве пользователя ИС, физического лица, пешехода, правонарушителя, пациента и т.д. В каждой из задач он будет рассматриваться по разному, важными будут разные атрибуты, с ним будут производить совершенно разные действия.
При этом все задачи одновременно решить невозможно: в некоторых ситуациях у человека может даже имени не быть (напр. первая неделя в роддоме).
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, A13x, Вы писали:
A>Помимо опыта, мне кажется, соблюдать этот баланс поможет осмысление и желание следовать принципам DRY, YAGNI, KISS.
С одной стороны, это здравые идеи, и я, конечно, стараюсь им следовать, но, с другой стороны, они, к сожалению, слишком общие, да и ничего особенно не раскрывают.
Например, как определить что значит "просто"? Самый простой для понимания способ решения задачи? А что насчет очень сложного для понимания, но очень простого для реализации? А если я сейчас сделаю весьма сложное решение, которое в будущем позволит решить множество однотипных задач очень просто?
К сожалению, реальность слишком сложна для таких простых сентенций как "старайся делать проще".
То же самое можно сказать про остальные два принципа. Например, "Don't repeat yourself". Что лучше, некоторое количество копипасты, но код при этом остается простым и понятным любому, или избавиться от дублирования, сделав код сложнее и непонятнее, и потратить гораздо больше времени, чем если бы ты просто продублировал?
Проблема таких высказываний — неуниверсальность.
В реальности мы опять остаемся один на один с балансированием без четкого метода.
Здравствуйте, Eternity, Вы писали: E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
самые лучшие абстракции, которые переживают любые изменения это естественные понятия, которые очевидны еще в самом начале разработки. а вот абстракции, навернутые для поддержания кода часто изменения не переживают. то есть если мы делаем игру про танки у нас все равно будут танки, но вот какой-нить там адаптер, соединяющий танк с гусеницами он легко может не пережить изменения в физике, так как в реальном мире никакого адаптера конечно же нет.
вот тут уже важная квалификация, опыт то бишь для того, чтобы не создавать лишних взаимосвязей на этом этапе.
я советую на эту тему книжку "чистый код" Роберта Мартина
ИМХО сами по себе абстракции — отнюдь не зло скорее наоборот. Почему не сформулировать в каком-то месте "а здесь мы применим линейный список, а если потом окажется медленно, заменим его на дерево или хеш-таблицу?" Мыслить на этом уровне проще, чем прямо-таки садиться и применить некий контейнер просто потому, что он попался на данный момент под руку, а потом окажется, что все это никуда не годится...
Плохо другое. За абстракциями не видят конкретной реализации. Сказано List — значит, будет List. А то, что одна реализация этого List дает O(N) для одних операций и O(1) для других, а другая реализация наоборот — так это же на уровне абстракций не видно, и обсуждать не стоит. А потом удивляемся, что все так медленно работает или много памяти требует...
Здравствуйте, Eternity, Вы писали: E>так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
я сегодня прямо каким-то ущербным чувствую. все жалуются на эту проблему, а у меня ее никогда не было.
например, у меня в жизни никогда не болела голова. вот так, чтобы без болезни сама по себе. я тоже не знаю, как такое бывает.
вот пишут люди, а потом, говорят, переписывать надо. а зачем? ну в чем проблема выбрать абстракции? ну вот есть пользователь, так, есть, там, танк — отлично. вот абстракция, вот абстракция, все вместе они образуют что нам нужно. зачем там что-то кардинально менять в будущем?
Здравствуйте, akava, Вы писали: A>А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
я очень люблю программирование, проектирование и оптимизацию как часть этого процесса. в том смысле, что я много времени провел изучаю, как работают __разные__ люди и всевозможные __разные__ подходы к проектированию, тестированию и разработке. вы удивитесь, насколько по разному люди могут делать одно и то же. сейчас мой вывод таков, что ничего загадочного в проектировании нормальной системы, которая будет всех долгие годы устраивать и которую потом не придется переделывать, нет. это достаточно просто. настолько же просто, как, например, сделать операцию на сердце. вы сможете ее сделать? я вот не смогу. почему? потому что это в принципе невозможно? нет. потому, что у меня недостаточно знаний и опыта. а так никаикх сложностей нет — все давно известно и изучено. не надо искать оправдания отсуствиям этих самых знаний и опыта, нужно просто учиться и внимательно изучать и перенимать лучшие решения, а не просто разводить руками, что "меняются требования" и "слишком много неопределенностей".
Здравствуйте, akava, Вы писали: A>Вот смотрите. Если представить, что у нас с вами есть долгосрочные отношения, то эти отношения можно представить в виде проекта. С неопределенностями. A>Вы сделали предположение, что на мой конкретный вопрос меня устроит бла-бла-бла ни о чем
, предположили, что мне не понравился намек на квалификацию. И опять мимо. A>2 предположения в условиях неопределенности и оба неверных. A>Почему же вы продолжаете считать, что возможно сразу же найти нужную абстракцию, когда вы, в начале работ, не до конца понимаете стоящую перед вами задачу?
Если вас интересует почему я подумал, что у вас слишком мало опыта, чтобы рассуждать об архитектуре, то я сделал это по этому предложению: "Адаптеры между гусиницами и танком делают, не потому что абстракции хочется."
Оно написано с двумя ошибками, типичными для малочитающих людей. Я не граммар-наци, но просто конкретно такие ошибки своейственны тем, кто мало читает. Что косвенно говорит о том, что вы не знакомы с литературой по проектированию, дизайну, архитектуре, которой очень много и ее надо читать. И без чтения ее ничего толкового не выйдет. Логично, что столкнувшись с проблемой, стоит изучить опыт решения ее. Вы не знаете никаких подходов к проблеме и, судя по всему, даже не пытались исследовать пути ее решения. Опыт у вас быть может, но тут важен правильный опыт, а не повторение раз за разом одних и тех же плохих решений. Я об этом тоже написал в первом посте. Извиняюсь, что написал слишком размыто. A>Исходя из моего опыта (это намек на мою достаточно высокую квалификацию), человеческие отношения, или коммуникация, является наиболее неопределеннй частью построения системы. A>Построить a system не сложно, сложно реализовать the system. Т.е. мало что-то заабстрагировать и закодировать, важно сделать именно то, что нужно заказчику. И именно из-за этих отношений ранее выбранные абстракции становятся негодными.
Если вы реально хотите разобраться в проектировании, то начните хотя бы с этого
— Буч — ООП анализ и проектирование
— Robert C Martin Clean code
— Гамма и кто-то там Паттерны проектирования
— бонусом — Александреску — современное проектирование на С++
там найдутся ответы на годами мучающие вас вопросы и нам не понадобится препираться на форуме и обсуждать квалификацию друг друга
Здравствуйте, Eternity, Вы писали:
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Абстрактное представление это и есть баланс. Т.е. это представление того что надо сделать на теперешний момент. По мере проработки деталей возникают уточнение модели и тут уж кроме собственного таланта, опыта и знаний никто не поможет. Ты и сам ответ можешь дать кто лучше составит модель опытный и умный или глупый начинающий.
Здравствуйте, Vaako, Вы писали:
V>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
Есть предложения по практической реализации?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Vaako, Вы писали:
V>>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ". 0>Есть предложения по практической реализации?
К сожалению да. Например у нас есть последовательность версий во времени 1 –a-> 2 –b-> 3 –c-> 4 …
Теперь стоит задача откатить изменение “b” и получить версию без него, но с добавлением всего что было добавлено в “c”. В подавляющем числе случаев автоматически получить невозможно поскольку под “c после b” понимается немного не то что содержится в “c до b” и даже “c до b и до a”. Если изменения в программе независимы (ортогональны), то их можно было бы выполнять в любом порядке. Например, когда “a” “b” “c” изменяют каждый свою часть программы, которые так отделены друг от друга интерфейсами что изменения незаметны, тогда действительно порядок операций можно выполнять произвольно, откатывать изменения обратно и в любом случае под каждой операцией понимались бы одни и те же действия.
В реальности каждая операция зависит от порядка операций до нее. Потому нет никакой “ортоганальности” или что эквивалентно – нельзя так разбить программу на части, чтобы все изменения касались только своих изолированных частей, на которые никак не влияют другие изменения. Выходом из ситуации является задание всех случаев такой “зависимости”, то есть вместо аналитического задания функции “с” мы используем неалгоритмическую процедуру, перечисляя все случаи изменений версии программы, которые мы обобщаем под одним названием “изменение c”. Конкретно это будут разные по своему содержанию действия:
1 –a-> 2 –b-> 3 –c-> 4 …
1 –a-> 2 –c-> 5 …
1 –c-> 6 …
И т.д по всем преобразованиям “a” “b” “c” и т.д. Получаем N-мерный куб, где ребра это операции, одно измерение – обобщение одной операции, N — количество обобщенных операций, а вершины – различные версии программы.
Ортогональность в этом случае всего лишь четыре аксиомы группы, которые будут соблюдаться и после перехода на неалгоритмизируемые процедуры. Проблема в том что эти неалгоритмизируемые заданы не так строго как нам бы того хотелось (не буду уточнять почему). Интересно что мы можем попытаться искать инварианты таких преобразований и даже следуя рекомендации Клейна построить на группе преобразований геометрию. Эти инварианты иногда совпадают с тем что принято называть “паттерны проектирования”, но главная странность, что эти инварианты не связаны с функциональностью рассматриваемой программы а относятся скорее к тому что относится к общепринятым приемам мышления программиста. Отсюда следует несколько неприятных субъективных особенностей – N-мерный куб будит различаться от программиста к программисту, причем даже если один и тот же программист несколько раз возмется за его построение. Эту, а также другие проблемы также придется решать. Но зато мы можем больше не задумываться над тем какой интерфейс выбрать или какой паттерн применить или как разбить программу на части или какое проектирование выбрать — сверху-вниз ии снизу-вверх.
Здравствуйте, Eternity, Вы писали:
E>... E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Помимо опыта, мне кажется, соблюдать этот баланс поможет осмысление и желание следовать принципам DRY, YAGNI, KISS.
Здравствуйте, rfq, Вы писали:
rfq>Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
Здравствуйте, Vaako, Вы писали:
V>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
Здравая мысль. Только нужны гораздо более мощные средства рефакторинга и вообще управления кодом, чем есть сейчас.
Здравствуйте, Философ, Вы писали:
E>>дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
Ф>ЩИТО? Ф>зачем какие-то там стены?
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, Vaako, Вы писали:
V>>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
E>Здравая мысль. Только нужны гораздо более мощные средства рефакторинга и вообще управления кодом, чем есть сейчас.
Более можнные — да, рефакторинг — нет. Управление кодом — смотря что под этим понимать.
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, A13x, Вы писали:
A>>Помимо опыта, мне кажется, соблюдать этот баланс поможет осмысление и желание следовать принципам DRY, YAGNI, KISS.
E>К сожалению, реальность слишком сложна для таких простых сентенций как "старайся делать проще".
Именно поэтому ценится опыт. Это сложноформализуемо и часто требует творческого подхода.
E>То же самое можно сказать про остальные два принципа. Например, "Don't repeat yourself". Что лучше, некоторое количество копипасты, но код при этом остается простым и понятным любому, или избавиться от дублирования, сделав код сложнее и непонятнее, и потратить гораздо больше времени, чем если бы ты просто продублировал?
Важно умение соблюдать баланс и руководствоваться здравым смыслом.
Если проще сделать общее решение и устранить дублирование в десяти местах — делай общее решение.
Если нужно выбирать между копипастой из трех похожих строк кода в двух разнесенных местах и редизайном системы с реорганизацией иерархии классов — проще скопипастить.
И т.п.
E>Проблема таких высказываний — неуниверсальность.
Ну так и никто не говорил об универсальном алгоритме для разработки софта. Тогда мы были бы не нужны.
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, rfq, Вы писали:
rfq>>Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
E>Ну да, охота на дичь. Только дичь — это я.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Eternity, Вы писали: E>>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены. __>самые лучшие абстракции, которые переживают любые изменения это естественные понятия, которые очевидны еще в самом начале разработки.
А что делать с теми что не очевидны вначале? Причем таких очень много. Любой проект начинается с неопределенности. Для определения неопределенности придумали кучу техник. Прототипировани, например, или частые итерации и фидбэк.
Про адаптеры.
Адаптеры между гусиницами и танком делают, не потому что абстракции хочется. А потому, что у нас уже есть гусеницы от трактора и мы можем время съэкономить.
Сам напсал аналогию и подумал: а вы уверены, что в реальном танкостроении нет "адаптеров", которые позволяют ставить новые башни на старые, серийные шасси?
Я не спец в танкостроении, но уверен такие случаи не единичны.
Здравствуйте, akava, Вы писали: A>В следующий раз не утруждайте себя писать так много ттекста ни о чем.
а вы это зачем написали? не понравился намек на квалификацию?
да, проектирование это одна из самых сложнейших вещей в программировании, да и много где и да, она требует наивысшей квалификации. да, эту квалификацию нельзя получить прочитав одну книжку по сайтам и че-то там поделав, этому нужно долго и целенаправленно учиться и не где попало, а еще и место такое фиг найдешь, где в этом действительно разбираются. и да, большинство программистов не обладает квалификацией достаточной для грамотного проектирования, так как это им нафиг не нужно, это не их часть работы
Здравствуйте, 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>Пример чего? Неопределенности в начале проекта? Вы издеваетесь???
пример того, как по первоначальным условиям было спроектировано грамотное решение (с примером условия и решения), затем задача изменилась всвязи с бизнес-требованиями и теперь грамотное решение, которое было разработано вначале оказалось ну вообще не в тему и пришлось все перекраивать
А в каком из этих примеров тянет ввести вредную с будущем абстракцию?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alexander Polyakov, Вы писали:
0>>Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. ... AP>А для языков с динамической типизацией такой подход работает?
Не вижу причин ему не работать, хотя в большом масштабе только на статически типизированных языках применял.
Возможно, что без статического контроля агрессивный рефакторинг становится более рискованным делом.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Вопрос задал, потому что хочется лучше понять, о чем говорит 0x7be. AP>Ок, пусть для динамических языков тоже работает. Тогда следующий вопрос. Как осуществляется рефакторинг? Рассмотрим ситуацию. Пусть прошло много времени, достаточно, чтобы детали задачи исчезли из головы разработчика, или пришел другой разработчик. Встала новая задача. Для ее реализации требуется нарастить/обрезать текущие абстракции. Тесты написаны. Как разработчик будет загружать к себе в голову необходимый минимум информации для выполнения наращивания/обрезания абстракций? В случае статических языков есть навигация. Что в случае динамических языков?
Я не думаю, что навигация по типам — это game changer в вопросах "загрузки" знаний в мозг программиста. Плохой и/или непокрытый тестами код на статически типизированном языке тоже сложно понять и безопасно изменить.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, akava, Вы писали:
A>>https://freelance.ru/projects/335505/ A>>https://freelance.ru/projects/342878/ A>>https://freelance.ru/projects/342844/
E>А в каком из этих примеров тянет ввести вредную с будущем абстракцию?
Разговор вышел из контекста абстракций и перешел в контекст неопределенности в начале проекта. Именно это я и привел.
Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, akava, Вы писали: A>>Пример чего? Неопределенности в начале проекта? Вы издеваетесь??? __>пример того, как по первоначальным условиям было спроектировано грамотное решение (с примером условия и решения), затем задача изменилась всвязи с бизнес-требованиями и теперь грамотное решение, которое было разработано вначале оказалось ну вообще не в тему и пришлось все перекраивать
Так вот я об этом и говорю. Как можно спроектировать грамотное решение, если ты не до конца представляешь все тонкости задачи, а то что "очевидно еще в самом начале разработки" не соответствует реальности?
Когда все с самого начала понятно проектировать не сложно. Сложно проектировать с учетом изменения и уточнения требований. Вот это сложно.
Из-за этого даже целая группа методологий возникла, agile. И не только в нем, в больших и формальных методологиях тоже заклвдываются циклы обратной связи.
Здравствуйте, akava, Вы писали: A>Когда все с самого начала понятно проектировать не сложно. Сложно проектировать с учетом изменения и уточнения требований. Вот это сложно.
мой опыт говорит о том, что нород умудряется проектировать даже простые вещи очень криво
A>Из-за этого даже целая группа методологий возникла, agile. И не только в нем, в больших и формальных методологиях тоже заклвдываются циклы обратной связи.
и тогда школьники регили "нам говорят сначала думать, потом делать, а у нас не получается, давайте мы будем делать, потом переделывать, потом еще переделывать и так пока мы всех не задолбаем и нас не пристрелят"
Здравствуйте, akava, Вы писали:
A>Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.
Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
A>>Но, например, при разработке интернет магазина можно захотеть сделать абстракцию мета-товар или "универсальный интерфейс к платежной системе". Да мало ли что можно надизайнить.
E>Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо...
Отвечу тем же То что знания о задаче и требования к ней могут менятся, вовсе и не значит, что проектировать не нужно...
Но нужно быть готовым выкинуть и переделать, когда ситуация (или ее понимание) сильно изменится.
А чтобы понимание пришло раньше, а не позже, существуют техники. Например, прототипирование и ранняя обратная связь от пользователя.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.
По моему опыту, не нужно 100% покрытие (всех веток вычислений), чтобы достаточно безопасно проведести рефакторинг. А уж ляпы, связанные с типизацией, ловятся еще меньшим количеством тестов.
С другой стороны, 100% покрытие не гарантирует отсутствие багов.
Здравствуйте, Alexander Polyakov, Вы писали: AP>Первый пункт. Человеческий мозг сильно ограничен по объему обрабатываемой информации.
поэтому стоит избегать связности между компонентами
AP>Второй пункт. Полное покрытие требует экспоненциального количества тестов в зависимости от числа входных параметров.
тесты надо уметь писать
Здравствуйте, akava, Вы писали:
E>>Дык можно, не не нужно. То, что сдуру можно накосячить с архитектурой, вовсе и не значит, что проектиовать систему не надо... A>Отвечу тем же То что знания о задаче и требования к ней могут менятся, вовсе и не значит, что проектировать не нужно...
A>Но нужно быть готовым выкинуть и переделать, когда ситуация (или ее понимание) сильно изменится. A>А чтобы понимание пришло раньше, а не позже, существуют техники. Например, прототипирование и ранняя обратная связь от пользователя.
А я с этим полностью согласен. И грамотная архитектура тут очень в тему будет, так как позволит выикинуть не всё, а только то, что устареет. И тут абстракции на пользу, а не во вред, обычно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Eternity, Вы писали:
E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде,
то есть fopen во вашему вред, а программирование НГМД на асме через порты ввода-вывода по вашему благо?
E> чем пользе, так как слишком часто при изменении или уточнении требований E> к программе или модификации используемого алгоритма приходится дырявить
абстракции на то и абстракции, чтобы ничего дырявить не приходилось. например, если вы изначально спроектировали дизнайн программы так, чтобы работать с _символами_, а не байтами, то необходимость поддержки разных кодировок затронет лишь саму абстракцию, но не повлияет на остальную массу кода.
E> С другой стороны, писать конкретный прямолинейный код может быть еще более разрушительно,
вы путаете абстракцию с декомпозицией. это разные вещи.
E> что абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу,
это нужно обсуждать на конкретных примерах. хорошим примером абстракции является файловая система. "хорошим" в плохом смысле этого слова. работа с большим кол-вом мелких файлов на хардах ужасно тормозит, но если натянуть поверх фс еще один уровень абстракции, сложив мелкие файлы в tar-подобный формат и упорядочив их в том порядке в каком к ним осуществляется доступ -- получаем колоссальный выигрыш (десятки, а то и сотни раз). конечно, не без ограничений. произвольный доступ к tarу будет ничуть не быстрее. это и есть проблема абстракций. популярные фс не позволяют создать группу файлов с последовательным доступом.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
