От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
С другой стороны, писать конкретный прямолинейный код может быть еще более разрушительно, так как со временем код естественным образом начинает запутываться, подобно сваленным в кучу проводам, удивительным образом самопроизвольно спутывающимся в неразвязываемый узел. В слишком конкретном коде в нужный момент не получится заменить компонент на аналогичный, хотя, надо сказать, что в хорошо абстрагированном коде такая проблема, как ни странно, тоже нередка, так как вдруг выясняется, что абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу, так как написать в одной конкретной программе все возможные виды абстракций невозможно, как и предвидеть любые будущие требования. Да и вообще, человеческий мозг слаб и мал, и не способен продумать, представить и просчитать все заранее.
Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Здравствуйте, Eternity, Вы писали:
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Боюсь, что помогает тут только опыт, полученный путем набивания многих шишек в попытках все заабстрагировать или написать все в функции main().
Лично я по этому опыту пришел к отказу от предварительного дизайна деревьев абстракции, а выращивании их путем рефакторинга кода, написанного без введения абстракций. Плюс не стесняюсь делать и выбрасывать прототипы. Но это тоже не есть модель гарантированного успеха, потому что к этому прикладывается некое чутье, выработанное за годы мучений с написанным мною же кодом )
Здравствуйте, Eternity, Вы писали:
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Абстрактное представление это и есть баланс. Т.е. это представление того что надо сделать на теперешний момент. По мере проработки деталей возникают уточнение модели и тут уж кроме собственного таланта, опыта и знаний никто не поможет. Ты и сам ответ можешь дать кто лучше составит модель опытный и умный или глупый начинающий.
Здравствуйте, Eternity, Вы писали:
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
Противники убийства животных могут найти другие аналогии, например, поиск сексуальных партнеров.
Здравствуйте, Eternity, Вы писали:
E>невозможно, как и предвидеть любые будущие требования.
Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
rfq>Наоборот, поиск по настоящему работающих абстракций и составляет наибольшее удовольствие. Это как охота на дичь — сначала приходится потопать, несколько раз промазать, и только потом получить заслуженное удовлетворение.
Хороший программист должень получать удовольствие от создания работающей программы, а не от самого факта написания кода. ИМХО конечно.
Ну а насчет абстракций — хороший программист должен быть еще и ленив, и создавать абстракции лишь тогда, когда они ему облегчат написание кода. Навык определять какая абстракции облегчит жизнь в будущем, а какая — совсем наоборот — приобретается с опытом.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Eternity, Вы писали:
E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
Значит абстракции подобраны неверно или имплементированы неправильно. Абстракции
должны как раз уменьшать количество всяческих модификаций в связи с изменением
требований. Посмотрите на фундаментальную теорему разработки ПО.
One level of indirection и есть абстракция.
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Это главная задача программиста -- отобразить абстрактное в конкретное.
Здравствуйте, Vaako, Вы писали:
V>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
Есть предложения по практической реализации?
Здравствуйте, Eternity, Вы писали:
E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе[...]
Абстракции не несут ни вреда ни пользы — это необходимость, т.к. решение задач происходит в рамках абстракций.
E>[...]при изменении или уточнении требований к программе или модификации используемого алгоритма приходится[...]
2) Выбор абстракций всегда зависит от задачи.
Если вы считаете траекторию метеороида в солнечной системе, то лучшей абстракцией будет материальная точка (тело для которого свойства типа объём, размер, форма, температура и т.д нам безразличны), эту абстракцию можно записать например вот так:
abstract class Solid
{
Microsoft.Xna.Framework.Vector3 Position {get; set;}
double Mass {get;}
}
Но всё меняется как только этот метеороид становится метеором. Нас в этот момент уже будут интересовать его плотность, форма и т.д. — без этого его траекторию уже нельзя будет вычислить.
E>дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
ЩИТО?
зачем какие-то там стены?
E>С другой стороны, писать конкретный прямолинейный код [...]
E>[...]абстракции были сделаны не в тех местах, недостаточны или просто не подходят под новую задачу[...]
Это как?!
Вот метеороид стал метеоритом, и встаёт задача его транспортировки, но существующие абстракции почему-то не учитывают его радиоактивности. Ясен пень, что для новой задачи нужна новая абстракция — теперь это опасный груз, имеющий какую-то ценность.
E>Это мучительное балансирование между абстрактным и конкретным — одна из дилемм программирования, которые снижают продуктивность программистов, убивают удовольствие от работы и убивают проекты и стартапы.
Выбор и манипулирование абстракциями — не снижают продуктивность работы, это сама работа (т.е. её часть).
E>Можно ли как-то научиться, есть ли какая-то более-менее четкая методика для соблюдения баланса между абстрактным и конкретным в программировании?
Необходимо всё-таки запомнить значение слова абстрагирование.
Абстрагирование — это мысленное выделение, вычленение некоторых элементов конкретного множества и отвлечение их от прочих элементов данного множества.
Для каждой задачи будет свой набор абстракций. Один и тот же человек в разных программах может выступать в качестве пользователя ИС, физического лица, пешехода, правонарушителя, пациента и т.д. В каждой из задач он будет рассматриваться по разному, важными будут разные атрибуты, с ним будут производить совершенно разные действия.
При этом все задачи одновременно решить невозможно: в некоторых ситуациях у человека может даже имени не быть (напр. первая неделя в роддоме).
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, 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>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
Здравая мысль. Только нужны гораздо более мощные средства рефакторинга и вообще управления кодом, чем есть сейчас.
Здравствуйте, A13x, Вы писали:
A>Помимо опыта, мне кажется, соблюдать этот баланс поможет осмысление и желание следовать принципам DRY, YAGNI, KISS.
С одной стороны, это здравые идеи, и я, конечно, стараюсь им следовать, но, с другой стороны, они, к сожалению, слишком общие, да и ничего особенно не раскрывают.
Например, как определить что значит "просто"? Самый простой для понимания способ решения задачи? А что насчет очень сложного для понимания, но очень простого для реализации? А если я сейчас сделаю весьма сложное решение, которое в будущем позволит решить множество однотипных задач очень просто?
К сожалению, реальность слишком сложна для таких простых сентенций как "старайся делать проще".
То же самое можно сказать про остальные два принципа. Например, "Don't repeat yourself". Что лучше, некоторое количество копипасты, но код при этом остается простым и понятным любому, или избавиться от дублирования, сделав код сложнее и непонятнее, и потратить гораздо больше времени, чем если бы ты просто продублировал?
Проблема таких высказываний — неуниверсальность.
В реальности мы опять остаемся один на один с балансированием без четкого метода.
Здравствуйте, Eternity, Вы писали: E>От использования абстракций в программировании у меня осталось впечатление об их большем вреде, чем пользе, так как слишком часто при изменении или уточнении требований к программе или модификации используемого алгоритма приходится дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
самые лучшие абстракции, которые переживают любые изменения это естественные понятия, которые очевидны еще в самом начале разработки. а вот абстракции, навернутые для поддержания кода часто изменения не переживают. то есть если мы делаем игру про танки у нас все равно будут танки, но вот какой-нить там адаптер, соединяющий танк с гусеницами он легко может не пережить изменения в физике, так как в реальном мире никакого адаптера конечно же нет.
вот тут уже важная квалификация, опыт то бишь для того, чтобы не создавать лишних взаимосвязей на этом этапе.
я советую на эту тему книжку "чистый код" Роберта Мартина
Здравствуйте, Философ, Вы писали:
E>>дырявить или перестраивать стену абстракции, с таким трудом построенную и оттестированную, так, что лучше было бы вообще без стены.
Ф>ЩИТО? Ф>зачем какие-то там стены?
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, Vaako, Вы писали:
V>>Отсюда следствие — нужно уйти от необходимости предсказывать. То есть если бы можно было бы любое решение отменить в любой момент и заменить его новым, то тогда не нужно было бы продумывать с самого начала "правильный способ".
E>Здравая мысль. Только нужны гораздо более мощные средства рефакторинга и вообще управления кодом, чем есть сейчас.
Более можнные — да, рефакторинг — нет. Управление кодом — смотря что под этим понимать.
Здравствуйте, Eternity, Вы писали:
E>Здравствуйте, A13x, Вы писали:
A>>Помимо опыта, мне кажется, соблюдать этот баланс поможет осмысление и желание следовать принципам DRY, YAGNI, KISS.
E>К сожалению, реальность слишком сложна для таких простых сентенций как "старайся делать проще".
Именно поэтому ценится опыт. Это сложноформализуемо и часто требует творческого подхода.
E>То же самое можно сказать про остальные два принципа. Например, "Don't repeat yourself". Что лучше, некоторое количество копипасты, но код при этом остается простым и понятным любому, или избавиться от дублирования, сделав код сложнее и непонятнее, и потратить гораздо больше времени, чем если бы ты просто продублировал?
Важно умение соблюдать баланс и руководствоваться здравым смыслом.
Если проще сделать общее решение и устранить дублирование в десяти местах — делай общее решение.
Если нужно выбирать между копипастой из трех похожих строк кода в двух разнесенных местах и редизайном системы с реорганизацией иерархии классов — проще скопипастить.
И т.п.
E>Проблема таких высказываний — неуниверсальность.
Ну так и никто не говорил об универсальном алгоритме для разработки софта. Тогда мы были бы не нужны.
ИМХО сами по себе абстракции — отнюдь не зло скорее наоборот. Почему не сформулировать в каком-то месте "а здесь мы применим линейный список, а если потом окажется медленно, заменим его на дерево или хеш-таблицу?" Мыслить на этом уровне проще, чем прямо-таки садиться и применить некий контейнер просто потому, что он попался на данный момент под руку, а потом окажется, что все это никуда не годится...
Плохо другое. За абстракциями не видят конкретной реализации. Сказано List — значит, будет List. А то, что одна реализация этого List дает O(N) для одних операций и O(1) для других, а другая реализация наоборот — так это же на уровне абстракций не видно, и обсуждать не стоит. А потом удивляемся, что все так медленно работает или много памяти требует...
