Аджайл — это просто собирательное название для разных методик. И экстремальное программирование туда входит.
Коллективное владение и инспекция кода — это тоже довольно размытые понятия — скорее пожелания. И они по разному в разных методиках реализуются. В парном программировании инспекция кода происходит постоянно. В других методиках иногда, когда время выделяют. Одна из целей ревью — обмен знаниями о продукте.
А то, что владение кодом плохо, я написал выше, основываясь на своем опыте. Если вы что-то меняете, у вас должна быть возможность менять в любом месте. Конечно, предупреждая других, если кто-то еще работает с той частью. Иначе страх перед изменениями в одном конце системы может породить кривой код или мусор в другом конце.
Я знаю что вредной может быть высокая связанность слоев, но зависимость в принципе… с чего вдруг. Ваши классы по любому будет кто то использовать — ui например.
Я имел ввиду о принадлежности кода каким-то отдельным личностям. Т.е. когда начинают разделять код на части и закреплять ответственных. Тогда складывается странная ситуация — один человек пишет свой кусок и крайне боится потревожить чужой кусок кода.
Это просто уже какие-то непроизводственные отношения. Не относящиеся к программированию. Может в коллективе и дедовщина есть, не знаю.
Чем более безличное программирование — тем лучше. Т.е. не важно, что кто-то использует ваши классы или нет. Вы спокойно меняете свои классы и меняете то место, где они используются. Вы одинаковый владелец всех слоев кода, как и все остальные. Мне не нравится ситуация, когда в программировании для бизнеса начинают считать — это гуи-девелопер, это девелопер на стороне СУБД, а этот серверную часть пишет. И вот тогда начинаются всякие нехорошие вещи.
В гибких технологиях разработки много внимания уделяется обмену знаниями, ревью кода и чтобы программисты менялись местами (никто не владел куском кода единолично).
Отличные требования )
Правда писать весь код, чтобы показать как, это будет стоить дороговато. Хотя без графики за несколько дней можно написать, показывая, как инкрементально добавляются требования. Вот, если бы какое-то 7 требование противоречило более раннему, проблем было бы больше. Например, что сетки больше нет, а солдаты не рубят друг друга, а играют в карты ))) Проблемы с таким требованием были бы при любом подходе к программированию. Но эволюционное — снижает затраты.
1) Игра походовая. Значит, есть одно состояние в один момент. Как минимум. И возможность перехода в новое состояние. Есть солдаты и есть у них координаты. Плюс поведение — рубят и стреляют. Понятно.
2) Появляется Герой. По всей видимости, игра двух или несколько игроков, живых или компьютера. Игрок владеет героем, герой войском. Игрока мы не моделируем. К каждому солдату добавляется ссылка на Героя. Свойства становятся динамически вычисляемыми, в зависимости от свойств Героя.
3) Маги. Насколько я понял, это новый тип солдат. Ага, у нас бывают разные типы. Первые только рубились и стреляли. Маги только стреляют. Магией, а не пулями. Тогда мы расширяем солдат, делаем базовый и наследники. Маг, таким образом, также как и солдат, связаны с героем. Поэтому сделать расчет силы удара мага в зависимости от количества солдат, которыми владеет Герой — не представляет проблем. Такие умения даются почти даром в смысле кода. А, да, забыл. Это не обычная стрельба, т.к. ведет себя по другому. Ну и отлично, список действий фигур (будем так называть солдат и магов) расширяется до трех: удар, стрельба, швыряние магии. Горение от магии «постепенно» сжигает здоровье. Значит в фигуру добавляем еще список «заклятий» и счетчик связанных с ними ходов. Запрет ходить можно сделать пока отдельно, по сравнению с другими действиями, вроде горения. Не обобщаем.
4) Добавить препятствия? Легко. До этого мы структуру данных, моделирующую сетку, не делали. Была не нужна. Теперь сделаем. Тем более, что при появлении препятствий появляется более сложный алгоритм движения — поиск кратчайшего пути для бота, например. Хотя, о ботах не говорили. А и для человека нужно, если он будет указывать конечную точку движения солдата. Летающие солдаты и ходящие имеют разные алгоритмы передвижения. Реализуется какой-то «стратегией» (паттерном).
5) У солдат уже есть возможность гореть некоторое количество ходов, значит есть способ расходовать что-то по ходам. Если не надо по ходам, а это, допустим, количество стрел, так тогда делаем класс Оружие, который имеет конечный или бесконечный ресурс. Обычное оружие — бесконечный, лук — конечный (при каждом использовании счетчик уменьшается, пока не достигнет нуля). Пост-эффекты уже есть, маги постарались.
6) Тоже никаких проблем. Делаем свойства по умолчанию, потом, при создании экземпляра солдата, некоторые характеристики меняем. Но если нам нужно еще отображение этих свойств (доспехи или что-то подчеркивающее легкость и т.д.), добавляет список артефактов солдата, а его свойства суммируют его личные навыки и полученные от артефактов.
Мне тяжело представить, как это сделали бы без эволюционного проектирования. Вот, я писал эту статью. Концентрировался на коде. Казалось бы, очень простой код и каждый раз я с помощью элементарных соображений приходил к выводу, что и как менять. Но если конечную схему классов нарисовать, то она уже довольно большая. Если бы я сразу пытался всё охватить, все ваши требования по игре и нарисовать схему, то сложностей было бы больше. Я пытался бы всё охватить. А это тяжело и не нужно.
Любые классы вообще поменять проще пареной репы, пока их никто не использует.
А кто-то мешает рефакторить код, который использует наши любые классы? Принадлежность кода кому-то — это вредное явление.
Да, я в курсе, что тематика предыдущей статьи была другая. Поэтому и написал новую. Хотел бы поругать предыдущего автора или показать просто как надо решать задачи, то сделал бы это в комментариях. У него отличная статья, но другая.
KISS и YAGNI по-моему, почти одно и то же. Простота и отсутствие функционала, без которого можно обойтись — близкие понятия. Если говорить о простоте, то очень относительное понятие. Борис делал много лишнего (или вы ошиблись, хотели сказать Маркус?). Откуда он взял микроволновки, откуда повара? То, что ему казалось логично — просто его представления о мире, которые он реализовывал, пытаясь угадать, как пойдет разработка дальше. Т.е. постелить солому туда, где может упасть. И очень быстро забросал соломой весь ландшафт и ходить не смог ))
В комментариях там много говорилось о некой золотой середине. Т.к. предполагалось, что Маркус не делал рефакторинга и не думал вообще, чем его ветвления обернуться потом. Т.е. неверное понимание YAGNI.
Как-то там стал вопрос — планировать (Борис) или нет (Маркус). И думали многие о середине. Тут нужна не середина. Однозначно — не планировать. Но и не запускать код, пока с него будет невозможно выбраться.
Да, спасибо за вашу статью. Я долго решался, писать свою или нет. У вас там сразу начали кидать решения, в том числе и на шарпе.
Но решил писать отдельную, т.к. тема у меня другая — YAGNI. А у вас отличная идея, как могут приходить требования, разрушая планы.
Я часто общался и спорил с коллегами по поводу целесообразности YAGNI. Но это никак нельзя объяснить просто на пальцах. Это навыки оценки и рефакторинга кода. А говорить о теории можно сколько угодно. У оппонентов возникают сомнения не в том, что это, а в том — как это вообще возможно.
Вот для «как» нужен пример. С головы такой отвлеченный и удачный пример тяжело придумать. Даже если каждый день так кодишь. Обычные задачи либо слишком узконаправлены, нелаконичны и не подчеркивают то, что хочется сказать.
Так что ваша статья послужила отличным материалом для примера YAGNI. Я мог бы еще написать статью с картинками и графиками, больше теоретическую. Но начинать с практики нужно.
Где-то то же самое. Так, как в посте, возможно начать проект. Далее он где-то так и развивается. Я не люблю UML, как и многие, кто следует такому YAGNI. Но общие черты, алгоритмы, документируются. После кодирования. Для проектирования не особо нужно.
А для передачи знаний — сгодится. Но лучше всего должны документироваться требования. Т.е. как-то собираться, структурироваться. И они связаны с автоматическими тестами.
Тогда, имея минимальное понимание всего, что хотят пользователи и приблизительное о коде, можно подхватить эстафету и дальше так развивать продукт.
Я разное понимаю под ИИ и даже то, что он давно уже есть.
Но в данном случае я подразумеваю именно то.
Тут, конечно, спорить нечего, слышал мнение людей в этой области, что долго еще. Вычислительных мощностей не хватает.
Но и у меня есть мнение, тоже в этой области не новичок. Область тяжелая, вряд ли какой-то идеал появится в ближайшее будущее.
Но тем не менее, когда я слежу за своими мыслями, они кажутся довольно примитивными ))))
Потом, если понаблюдать за многими программистами, то кажется, что местами и современный утюг бы справился.
Возможно и не будет одномоментного прорыва. Но рутина будет уходить, всё больше будет интеллектуальной работы. Сначала появятся автоматические автомобили, потом замена механической (тупой работы), потом роботы-блондинки. Ну и со временем, эти блондинки не только будут кофе программистам подавать.
Это всё предположения, но лично мне представляется этот эволюционный процесс лавинообразным.
Есть некоторая основа в программировании, которая не меняется. Многие годы, уже десятилетия, полстолетия. Для этого нужен опыт, читать, прорабатывать и много лет. Это подход вообще, что в какой последовательности делать. Видеть минусы и плюсы решений.
А молодежь этого опыта не имеет и может упрекать в консерватизме, и чесать про базы данных на джейсоне, о каких-то нодах веба, о плюшечках какой-то графической тулзы. Много чего появляется и за всем не угонишься. Но молодежь не пытается лес за деревьями увидеть. Хватая поверхностно знания о каких-то частностях, считая, что это модно, правильно и современно. И с их точки зрения люди с опытом и в возрасте — консервативны.
1. Вы не строите дополнительную СУБД. Это уже всё объясняет.
Этого уже достаточно. Давайте сделаем шаг назад и представим себе, что база данных не реляционная. И внутри использует ваш любимый язык. Допустим, шарп или джаву. Т.е. там вы внутри могли бы работать с объектами, как хотели бы. И они сразу же при фиксации транзакции были бы сохраненными, вам даже знать не надо, куда. Здесь же, это всё сервер БД.
Вы бы в этом случае делали бы еще какой-то другой сервер, через который общались с такой СУБД? Т.е. решили, что этот сервер плохой, давайте ка сделаем свою поделку. Очевидно, что решение плохое?
Точно та же логика касается и обычных реляционных СУБД. Они разрабатываются для обработки данных. Они могут обслуживать одновременно много запросов. Они могут поддерживать много коннекшинов. Но вы почему-то думаете, что это всего лишь мешок для прятания и доставания объектов и упорно пытаетесь делать свои поделки, т.е. свою прослойку, ведущую себя как СУБД, только тупую, опасную и с нуля. При этом в вашу СУБД данные загружаются из реляционной СУБД. А значит находятся в двух местах сразу. А значит появляются еще и дополнительные расходы на синхронизацию. Дополнительные потенциальные баги. Вы вообще делаете кучу всего лишнего. Это как бы если бы задача у вас стояла «купить хлеб», а вы строите завод для изготовления бетона, строите дорогу к предполагаемому магазину, строите магазин, завозите хлеб, а потом только у вас всё готово, чтобы купить хлеб.
Хлеб можно покупать сразу. Таблицами можно моделировать вполне жестко и успешно предметную область. Да, это не ООП. Но ряд плюсов даже получше, чем в ООП есть.
Только при этом, будет меньше ограничений для разработчика.
Не отгораживайтесь от БД ;)
Запросы тоже пишет разработчик. Вам запрещают работать с хранимками? Хранимки — это код. И не надо думать, что их должны писать кто-то избранный, какой-то базовик.
Я думаю комментатор выше хотел сказать, что это выглядит действительно странно — класть в хранимки логику, если ровно тот же SQL-запрос можно послать на БД из самого приложения. Только при этом, будет меньше ограничений для разработчика.
Совсем не странно. Разница, конечно, не большая, если у вас код хранится уже записанный и присылается запросами извне, или в хранимках. В данном случае хранимки всего лишь дают еще один уровень развязки. Приложению надо будет всего лишь вызывать осмысленное имя, не имея представления о внутреннем устройстве. Что дает возможность менять внутренности хранимом независимо от внешних модулей.
Другое дело, когда у вас и не будет записанного кода, а будет формироваться. Опасность уже выше. И большая связь с кодом на ЯОП.
Методологически я считаю, что СУБД должна использоваться как сервер, полностью. Не нужна в принципе прослойка еще какого-то сервера. Потому что по сути вы создаете второй сервер и дублируете данные и строите тупой упрощенный, опасный второй сервер.
Но так как мы живем не в идеальном мире, то надо сказать, что Transact-SQL (я его использую для хранимок), имеет много минусов. SQL — хорош. Транзакт — это жуткая вещь. Если вы умеете готовить хранимки по минимуму используя IF, WHILE, то всё отлично. Если же код превращается в императивщину (возможно из-за вас или плохой архитектуре БД), то есть смысл такие части писать на ЯОП. Поэтому, я бы по максимуму использовал бы хранимки. В редких местах, можно использовать шарп. Это практический совет, как провести черту.
Очень надеюсь, что придумают что-то более адекватное, чем транзакт, и тогда вопросы снимут на чем писать
Я Фаулера, конечно, читал. И с этим его взглядом не согласен. И этот взгляд, кстати, не является единственным. Читайте Best Practices майкрософт. Там говорится, что только в маленьких проектах можно давать доступ напрямую коду к таблицам. Т.е. формировать запросы.
Вы, возможно, не поняли всё, что я выше написал. Я пытался аргументировать, почему база должна отвечать далеко не только за хранение. Если бы она отвечала за хранение, то она вам не нужна. Очевидно, что она не для хранения предназначается, иначе не делали бы ее столь сложной. СУБД делают далеко не для хранения, но и для обработки информации. Не зря пытаются делать оптимальными алгоритмы и ускорять джойны и т.д.
То, что у вас там было с проектом, я не знаю и в спор вступать не хочу. Очевидно, что говнокод может быть написать на любом языке. И без хранимок тоже.
Нет, я не базовик. Разрабатываю всё, от гуи, до хранимок. И мой взгляд на эти вещи выработался со временем и опытом. Мне не составит большого труда создавать предметную область и на шарпе. Но вижу в этом бОльшие проблемы и больше потенциальных мест для ошибок.
Не совсем. Я бы использовал реляционные СУБД. И по максимуму бы использовал хранимки (в меру, не превращая в кашу).
Вообще, очень неплохо было бы, чтобы придумали нечто поинтереснее, чем императивные и такие «топорные» процедуры. В принципе это получается.
А что не получается, то получается «доработать напильником». Некоторые рекурсивные задачи или парсеры или динамические объекты — дописываются, хранятся в таблицах и вполне можно писать и хранимки на шарпе.
Если бы был такой хороший язык, позволяющий легко оперировать кодом, инкапсулировать его, делать свои объекты для кода, давать им имена, да и лучшей строгости в типизации хочется — я вполне за, чтобы этим занимался один сервер. Не нужен сервер СУБД, и отдельно АПП.
А пока, приходится разделять. Но для меня такая условная черта. Если можно и код не легаси, а я пишу, то СУБД — по сути содержит нормализованные сущности с хорошей моделью предметной области, хорошо обернутые в хранимки и доступ через них, а в АПП слой модели либо отражает базу, либо более высокого уровня, либо имеет объекты, близкие к обработке ГУИ.
Но и не спорю, что у нереляционных СУБД есть свои области применения. Сейчас сам одну делаю. Но там реально, совершенно другие требования и другая задача. Там не моделирование предметной области, а вычислительная конкретная задача.
Я писал о том, что многим хватит легковесного NoSQL. Но не потому, что оно легковеснее. Как раз почти всегда вижу с этим только бОльшие проблемы для кодирования. Но если человек по факту не использует SQL, то конечно, ему хватит NoSQL. Это самозамкнутое измерение — хватит или не хватит. Человек сам определяет свой темп работы, регулирует поток задач, а потом говорит, что ему быстрее не надо — он с потоком вполне справляется.
Мне не нравится тоже что код в двух местах. И тут уже кому как нравится на какой стороне кодировать.
Ну так, да, паттерны сами получаются. Поэтому и говорю про отказ от паттернов. В том плане, что лучше бы о них не думать, потому как они заставляют думать наперед. Другое дело, когда они естественно появляются. Не все, конечно.
Но оказывается, есть ряд паттернов, которые часто используются и часто появляются. При этом архитектура как бы «утрясается». Сначала пишете как-то, потом рефакторингом трясете до положения, когда вам код нравится. Вместе с паттернами. Можно было бы графически нарисовать, как получается на диаграммах Эйлера, сначала смысловое пересечение, как потом в коде два разных класса соединяются через базовый, появляется степень свободы (и жесткость). Как потом отвязываемся от классов через интерфейс. Буквально, во многих случаях можно представлять графически воздействие требования, появление в результате этого необходимости пересмотреть жесткость и гибкость в каких-то измерениях (а программа — это многомерная структура, где мерность — количество независимых переменных).
Такое воображение может быть много кому помогло бы представить, почему возможно в ООП эволюционное проектирование.
Именно это я и хотел сказать — если в ХП всё это есть, значит «Хьюстон, у нас проблема».
Нельзя не согласиться. Если такое г начали использовать в хранимках, то лучше это в шарп вынести.
Но, чёрт возьми, рассчёт перерасхода сотрудника в заданном периоде согласно его лимиту и настройкам бухгалтерии, переход документа дальше по цепочке авторизации — всё это не реализовать на голом SQL, простыми запросами.
Вопрос только в знании SQL (и набить руку). Я не увидел в таком примере ничего пугающего. Скорее всего реализуется без единого цикла или ветвления. Набором запросов. Конечно, нужно, чтобы адекватно были созданы таблицы.
Иначе придётся программировать слишком много процедур, почти полностью повторяя исходную структуру таблиц
Иначе в шарпе придется повторять всю исходную структуру таблиц. Разница только в объеме кода и где лучше, быстрее исправлять.
Почему люди стараются упрятать максимум в ХП, скрыть все детали от прикладных программистов? Когда есть доступ к полноценной, целостной модели — как и у кода, так и у ХП, разработка же становится на порядок проще!
Мне не нравится, что многие почему-то считают, что есть некие прикладные программисты, а есть базовики. И базовики пишут SQL-код. Я не люблю базовиков как класс. Они, те кто не были программистами, редко и хранимки пишут так как надо. Думаю, что программист, пишущий код приложения, должен одинаково хорошо и SQL владеть и писать код в любом месте, ограничиваясь задачей, а не компонентом. Тогда проблем не будет. Вы, как программист, имеете доступ ко всему коду.
Скрывать любые части кода от разработчика вообще по-моему плохая практика. Это антипаттерн управления «Разведение грибов».
В этом треде витает спор между «ВСЯ логика в ХП» vs «ничего в ХП». Лично я — за золотую середину, смещённую в сторону шарпа :)
Я вынуждено тоже имею такую т.з., только шарп у меня не выигрывает. Конечно, какие-то вещи тяжело сделать в БД. Но тут стоит задуматься о правильности архитектуры или даже о качестве задачи (возможно задачу можно решить гораздо более простыми средствами). Одна из задач, тяжело поддающихся реляционным БД — это динамическое количество атрибутов у сущности. Но в принципе, это если бы на шарпе мне захотелось написать класс, который имеет динамическое количество свойств (настоящих). Пришлось бы шаманствами с отражением заниматься. Это плохо. Но плохо еще то, что шарп намного более гибкий и носом сам по себе не ткнет, что есть проблемы в задаче. Вы себе сделаете Dictionary, не будете пользоваться свойствами, и вам покажется, что классная и красивая архитектура.
SQL — прекрасный язык. Расширенные языки для написания хранимок — очень плохие языки. И вынуждено приходится идти на то, что если появляются в хранимках циклы, ветвления — это в шарп. Но часто это из-за низкой квалификации в базах данных появляется.
А если рассуждать вообще, в отрыве от конкретных БД (к сожалению работаем только на конкретных), то я уверен, что данные и их обработка должны быть как можно ближе. Не должно быть понятия отдельно — это хранилище, а тут мы прикрутим шарп и будем работать. Это чревато написанием второй БД на шарпе. Начинаются пляски с кешированием (т.е. дублированием данных, что очень не гуд), потом, эти данные уже в памяти и программист создает свою бд, с транзакциями, с оптимизациями. Конечно, эти попытки выглядят очень убого, а безопасность и целостность данных на порядок всегда ниже. Но программист, видимо, горд таким умением. С другой стороны, да, это говорит, что СУБД в большинстве своем для бизнес-приложений тащат большой оверхед. Раз сплошь и рядом делают свои поделки, херят безопасность и при этом считается почти стандартом разработки бизнес-приложений.
И кому-то хватит даже key-value… Но в том, что их можно реализовать самому за день — вы не правы. Вон Ayende уже сколько пилит свою RavenDB :)
Иногда и за час. Всё зависит от задач. БД — понятие гораздо более широкое. Не стоит подразумевать под этим нечто монументальное. (Я имею опыт разработки разных нереляционных БД, на разных языках, не шарп).
Key-Value на каком-то другом языке и отдельном сервере (процессе), придется делать. Если же вы на шарпе пишете, то тут вообще и писать почти ничего не надо. Дублирование данных — это зло. Значит и другого процесса не надо. Будете писать библиотеку. Заводите инкрементальный идентификатор для всех любого типа объектов. И даже хеш вычислять не нужно будет. И или скрываете в коде (лучше сгенерированном) классов-сущностей вызовы по связям через поиск по этим идентификаторам, либо пишете простой менеджер, который этим управляет. Можете сделать файл с индексами и файл для хранения (сбрасывания сериализированных объектов). Можете чуть сложнее — много файлов и разбиение на таблицы через хеш. Плюс, учитываете, если хотите, какую-то безопасность, на случай аппаратного сбоя. Но это не обязательно, учитывая уровень безопасности обычных наших руками сделаных кэшей.
Всё это довольно просто. Всегда удивляло, почему люди используют SQL-Server или Оракл, когда верят, что это просто мешок для поднятия и прятания объектов. На стыковку с ними больше усилий тратят.
Всё, что вы описали, это просто опыт, но опыт, который звучит примерно так:
«Я обходился всегда без этого и поэтому я думаю, что это не нужно.»
Это замкнутый круг. Например, многие программисты утверждают, что им не нужна математика совершенно. Потому что им в работе это не нужно. Тоже замкнутый круг. Им эту работу никто и не даст никогда. Будут гуи интерфейс простой клепать до конца дней.
Теперь применительно к ответу выше.
Сложную логику SQL'ем (декларативно) не описать — нужны циклы, условия
Да почти всё можно описать. Есть небольшие места, где не всё. Например:
динамические запросы
Но такие запросы в большинстве случаев означают непонимание реляционной модели и плохую (иногда крайне плохую) архитектуру.
Чтобы было понятнее, приведу пример с шарпом. Оказывается, там то же самое. Представьте, что вы в коде вдруг не смогли выразить предметную область средствами самого языка и прибегаете к механизму отражения. И пишете код, вроде такого:
«если объект имеет тип такой-то, то сделаем вот это».
Хреново, правда? Вот что-то похожее с динамическим SQL. Значит неудача постигла в понимании как надо выразить задачу запросом. Как надо смоделировать таблицы. Например, забыли, что таблица является сущностью, а решили, что это контейнер просто. Далее, напихали одну и ту же по сути сущность в две таблицы. Конечно, теперь джойн не очень получится, лучше делать динамический запрос, чтобы в каждом случае подставлять желаемую таблицу. А то SQL сам по себе плохо выбирает в чистом и понятном для него коде.
Или второй пример. Вы не смогли на шарпе (опять же) выразить смысл. И решили написать супер-пупер гибкий фреймворк, в котором есть состояние системы и простые команды, работающие по событиям в зависимости от состояния (такое себе перечисление). А команды являются простыми и нерасширяемыми, но с возможностью собираться в цепочки. Вот такой конечный автомат.
Поздравляю, если такое сделали, вы архиплохой шарпист (это не лично вам, а пример). Вы по сути не пользуетесь языком и его средствами, а поверх него написали что-то вроде своего интерпретатора. Настолько гибкого и универсального, насколько и нетипизируемого, опасного и скорее всего невыразительного.
Т.е. понятно, думаю, что такое язык поверх языка. Аналогично, вы не хотите работать с SQL.
При этом язык SQL во много раз мощнее, чем С#. Конечно, я рассматриваю просто императивную часть, без linq и лямбд, т.е. изначальную основу шарпа. На линькью, кстати, тоже не стоит городить огород там где может работать SQL. Т.к. линькью заточен на работу со списками. А значит, более широкого применения. И это же значит, что более опасный, более многословный. Захотите бОльшей жесткости, чтобы получить реляционные отношения, вам придется всё это ручками делать. Вопрос большой — зачем? Повторюсь, ручками сделать можно всё что угодно. Готовы спорить, что умнее команды Оракла или SQL-Server?
Циклы и ветвления, которые якобы нужны — это пусть к сложным багам и тяжелой поддержки. Это императивный код со всеми вытекающими, вроде — вероятность бесконечной рекурсии и переполнения стека. Или просто не выхода из цикла. Не говоря уже о том, что вы пишете по шагам, что нужно делать а не «как».
Что-то трансформировали, что-то — слили воедино для простоты. Кто гарантирует, что клиентский код удобно ляжет на этот срез и не захочет в каких-то случаях получать данные в другом срезе? Доступ к некоторой сущности, которую для простоты объединили с другой или вообще спрятали. Или сгруппированные данные по другому полю? Список сущностей, но немного не так отфильтрованный? Результат — ещё больше хранимых процедур
Никто не гарантирует, что не захотят в другом срезе. И да, результат — процедур больше. Но хочу вас разочаровать, на шарпе даже хуже. Там тоже код не телепатически узнает что делать надо. Если вы не захотите писать процедуры, то придется писать на шарпе. Неужели это так сладко писать на шарпе?
На шарпе кода будет в десятки раз больше. Вам нужен другой срез, другая группировка? На SQL пишется в несколько строк. А представляю, сколько кода, да еще с ядренными алгоритмами, для которых мозг нужен, будет на шарпе — в виде циклов, хеширования, сбаллансированных деревьев, которых нет в стандартной поставке. Просто рай для людей, любящих работать руками.
Да, SQL не идеален — нет инкапсуляции, не очень с тьюринг-полнотой. Но плюсы все таки есть и огромные. Оверхед волнует? Мне лично его в рюкзаке не носить. Написать быстро приложение и не думать о производительности (это на счет монстра) — это как раз реляционные СУБД.
А желание перейти на NoSQL звучит где-то так: давайте писать всё с нуля. NoSQL базы — это по сути очень обрезанные по функционалу базы в сравнению с реляционными. И всё, что я про них хорошего слышал, это то, что на них работают такие большие монстры, вроде твиттера, выдерживая нагрузку. Повторюсь, такие базы и покупать не нужно, их можно сделать, умея работать с файлами, за день (с самым простым функционалом). А такие «монстры», вроде твиттера или фейсбука имеют потребности в моделировании предметной области совершенно примитивные, которые наверное проще, чем бухгалтерские приложения для обслуживания ларька.
Поэтому я бы не кидался в NoSQL. А и еще думаю, что оптимизация почти всегда предварительна. И пока мы тут спорим, в районе 5 лет железо кардинально изменит взгляды на то, как можно строить СУБД и на оптимальность.
Почему вдруг? Ни разу не слышал внятных ответов. (Кстати когда-то сам так думал, когда опыта было 1-2 года, но тогда просто где-то вычитал и просто хотел работать на своем языке, а SQL казался тяжелочитаемым).
Но всё не так. Большая СУБД разрабатывается как сервер. Хорошо продумывается математика, оптимизация. Обычно, разрабатывают много неглупых людей.
А потом появляются домашние программисты бизнес-логики, которые уверены, что базы нужны только для хранения объектов, а логику, включая транзакции, они будут писать сами.
Мне нравится такая аналогия: пещерные люди за бешеные деньги покупают очень дорого танк последней модели. Привязывают тачку и возят танком копья.
Если есть желание не пользовать реляционные БД — так кто мешает. Фокус в том, что простые базы для хранения в файлах и быстрого поиска по хешу — делаются нормальным программистом за день.
Лично мне кажется, что мода на NoSql — слишком временна. Да, есть проблемы с производительностью. Но в большинстве случаев они не такие большие и эти проблемы берет на себя СУБД. И кстати, в большинстве случаев прекрасно справляется. Не хорошо программисту думать об оптимизациях. Надежность на первом месте. Скорость разработки.
Проблемы производительности связаны с текущим железом. В частности, очень сильно с разделением на ОЗУ и файловую системы. Работа с файлами пока не очень быстрая. Это вообще узкое место во всём. И это узкое место в любом случае уберут. Сделают возможно специальные машины для реляционных — и тогда все эти вопросы оптимальности NoSql перестанут быть аргументом.
Есть три этапа становления программиста. Может больше, но я пока не знаю новых.
1. Новичок. Учится кодить и кодит хоть как-нибудь и радуется, что программы его вообще работают.
2. Любовь к паттернам и проектированию. Наступает после детального изучения книги банды четырех. Человеку кажется, что если он понял, как и что делает каждый паттерн, что такое наследование, то можно ВСЁ запроектировать.
3. Отказ от паттернов. Переход на эволюционное проектирование. ТДД. Да, я верно говорю — ТДД — это не просто организация процесса. Это эволюционное проектирование. Оно явно и не явно заставляет так проектировать.
Вы пока на втором этапе. Эта статья написана человеком, либо на третьем этапе, либо переходящим на третий. У него появилось откровение, что можно разбираться на ходу с проблемами (поэтому красной таблетки не существует).
Примечательно, что на каждом этапе человек считает себя профессионалом. Новичок, правда, не всегда, если рядом есть примеры хороших программистов. А вот на втором — да. Я не хочу вас оскорблять, мне тоже не удалось пропустить второй этап. Я помню, какие «причудливые» архитектуры создавал. Зато сейчас я эффективнее в разы.
Возможно будет четвертый этап — уход от говноязыков.
Аджайл — это просто собирательное название для разных методик. И экстремальное программирование туда входит.
Коллективное владение и инспекция кода — это тоже довольно размытые понятия — скорее пожелания. И они по разному в разных методиках реализуются. В парном программировании инспекция кода происходит постоянно. В других методиках иногда, когда время выделяют. Одна из целей ревью — обмен знаниями о продукте.
А то, что владение кодом плохо, я написал выше, основываясь на своем опыте. Если вы что-то меняете, у вас должна быть возможность менять в любом месте. Конечно, предупреждая других, если кто-то еще работает с той частью. Иначе страх перед изменениями в одном конце системы может породить кривой код или мусор в другом конце.
Я имел ввиду о принадлежности кода каким-то отдельным личностям. Т.е. когда начинают разделять код на части и закреплять ответственных. Тогда складывается странная ситуация — один человек пишет свой кусок и крайне боится потревожить чужой кусок кода.
Это просто уже какие-то непроизводственные отношения. Не относящиеся к программированию. Может в коллективе и дедовщина есть, не знаю.
Чем более безличное программирование — тем лучше. Т.е. не важно, что кто-то использует ваши классы или нет. Вы спокойно меняете свои классы и меняете то место, где они используются. Вы одинаковый владелец всех слоев кода, как и все остальные. Мне не нравится ситуация, когда в программировании для бизнеса начинают считать — это гуи-девелопер, это девелопер на стороне СУБД, а этот серверную часть пишет. И вот тогда начинаются всякие нехорошие вещи.
В гибких технологиях разработки много внимания уделяется обмену знаниями, ревью кода и чтобы программисты менялись местами (никто не владел куском кода единолично).
Правда писать весь код, чтобы показать как, это будет стоить дороговато. Хотя без графики за несколько дней можно написать, показывая, как инкрементально добавляются требования. Вот, если бы какое-то 7 требование противоречило более раннему, проблем было бы больше. Например, что сетки больше нет, а солдаты не рубят друг друга, а играют в карты ))) Проблемы с таким требованием были бы при любом подходе к программированию. Но эволюционное — снижает затраты.
1) Игра походовая. Значит, есть одно состояние в один момент. Как минимум. И возможность перехода в новое состояние. Есть солдаты и есть у них координаты. Плюс поведение — рубят и стреляют. Понятно.
2) Появляется Герой. По всей видимости, игра двух или несколько игроков, живых или компьютера. Игрок владеет героем, герой войском. Игрока мы не моделируем. К каждому солдату добавляется ссылка на Героя. Свойства становятся динамически вычисляемыми, в зависимости от свойств Героя.
3) Маги. Насколько я понял, это новый тип солдат. Ага, у нас бывают разные типы. Первые только рубились и стреляли. Маги только стреляют. Магией, а не пулями. Тогда мы расширяем солдат, делаем базовый и наследники. Маг, таким образом, также как и солдат, связаны с героем. Поэтому сделать расчет силы удара мага в зависимости от количества солдат, которыми владеет Герой — не представляет проблем. Такие умения даются почти даром в смысле кода. А, да, забыл. Это не обычная стрельба, т.к. ведет себя по другому. Ну и отлично, список действий фигур (будем так называть солдат и магов) расширяется до трех: удар, стрельба, швыряние магии. Горение от магии «постепенно» сжигает здоровье. Значит в фигуру добавляем еще список «заклятий» и счетчик связанных с ними ходов. Запрет ходить можно сделать пока отдельно, по сравнению с другими действиями, вроде горения. Не обобщаем.
4) Добавить препятствия? Легко. До этого мы структуру данных, моделирующую сетку, не делали. Была не нужна. Теперь сделаем. Тем более, что при появлении препятствий появляется более сложный алгоритм движения — поиск кратчайшего пути для бота, например. Хотя, о ботах не говорили. А и для человека нужно, если он будет указывать конечную точку движения солдата. Летающие солдаты и ходящие имеют разные алгоритмы передвижения. Реализуется какой-то «стратегией» (паттерном).
5) У солдат уже есть возможность гореть некоторое количество ходов, значит есть способ расходовать что-то по ходам. Если не надо по ходам, а это, допустим, количество стрел, так тогда делаем класс Оружие, который имеет конечный или бесконечный ресурс. Обычное оружие — бесконечный, лук — конечный (при каждом использовании счетчик уменьшается, пока не достигнет нуля). Пост-эффекты уже есть, маги постарались.
6) Тоже никаких проблем. Делаем свойства по умолчанию, потом, при создании экземпляра солдата, некоторые характеристики меняем. Но если нам нужно еще отображение этих свойств (доспехи или что-то подчеркивающее легкость и т.д.), добавляет список артефактов солдата, а его свойства суммируют его личные навыки и полученные от артефактов.
Мне тяжело представить, как это сделали бы без эволюционного проектирования. Вот, я писал эту статью. Концентрировался на коде. Казалось бы, очень простой код и каждый раз я с помощью элементарных соображений приходил к выводу, что и как менять. Но если конечную схему классов нарисовать, то она уже довольно большая. Если бы я сразу пытался всё охватить, все ваши требования по игре и нарисовать схему, то сложностей было бы больше. Я пытался бы всё охватить. А это тяжело и не нужно.
Ошибся, ответ ниже
А кто-то мешает рефакторить код, который использует наши любые классы? Принадлежность кода кому-то — это вредное явление.
Да, я в курсе, что тематика предыдущей статьи была другая. Поэтому и написал новую. Хотел бы поругать предыдущего автора или показать просто как надо решать задачи, то сделал бы это в комментариях. У него отличная статья, но другая.
KISS и YAGNI по-моему, почти одно и то же. Простота и отсутствие функционала, без которого можно обойтись — близкие понятия. Если говорить о простоте, то очень относительное понятие. Борис делал много лишнего (или вы ошиблись, хотели сказать Маркус?). Откуда он взял микроволновки, откуда повара? То, что ему казалось логично — просто его представления о мире, которые он реализовывал, пытаясь угадать, как пойдет разработка дальше. Т.е. постелить солому туда, где может упасть. И очень быстро забросал соломой весь ландшафт и ходить не смог ))
В комментариях там много говорилось о некой золотой середине. Т.к. предполагалось, что Маркус не делал рефакторинга и не думал вообще, чем его ветвления обернуться потом. Т.е. неверное понимание YAGNI.
Как-то там стал вопрос — планировать (Борис) или нет (Маркус). И думали многие о середине. Тут нужна не середина. Однозначно — не планировать. Но и не запускать код, пока с него будет невозможно выбраться.
Но решил писать отдельную, т.к. тема у меня другая — YAGNI. А у вас отличная идея, как могут приходить требования, разрушая планы.
Я часто общался и спорил с коллегами по поводу целесообразности YAGNI. Но это никак нельзя объяснить просто на пальцах. Это навыки оценки и рефакторинга кода. А говорить о теории можно сколько угодно. У оппонентов возникают сомнения не в том, что это, а в том — как это вообще возможно.
Вот для «как» нужен пример. С головы такой отвлеченный и удачный пример тяжело придумать. Даже если каждый день так кодишь. Обычные задачи либо слишком узконаправлены, нелаконичны и не подчеркивают то, что хочется сказать.
Так что ваша статья послужила отличным материалом для примера YAGNI. Я мог бы еще написать статью с картинками и графиками, больше теоретическую. Но начинать с практики нужно.
А для передачи знаний — сгодится. Но лучше всего должны документироваться требования. Т.е. как-то собираться, структурироваться. И они связаны с автоматическими тестами.
Тогда, имея минимальное понимание всего, что хотят пользователи и приблизительное о коде, можно подхватить эстафету и дальше так развивать продукт.
Но в данном случае я подразумеваю именно то.
Тут, конечно, спорить нечего, слышал мнение людей в этой области, что долго еще. Вычислительных мощностей не хватает.
Но и у меня есть мнение, тоже в этой области не новичок. Область тяжелая, вряд ли какой-то идеал появится в ближайшее будущее.
Но тем не менее, когда я слежу за своими мыслями, они кажутся довольно примитивными ))))
Потом, если понаблюдать за многими программистами, то кажется, что местами и современный утюг бы справился.
Возможно и не будет одномоментного прорыва. Но рутина будет уходить, всё больше будет интеллектуальной работы. Сначала появятся автоматические автомобили, потом замена механической (тупой работы), потом роботы-блондинки. Ну и со временем, эти блондинки не только будут кофе программистам подавать.
Это всё предположения, но лично мне представляется этот эволюционный процесс лавинообразным.
А молодежь этого опыта не имеет и может упрекать в консерватизме, и чесать про базы данных на джейсоне, о каких-то нодах веба, о плюшечках какой-то графической тулзы. Много чего появляется и за всем не угонишься. Но молодежь не пытается лес за деревьями увидеть. Хватая поверхностно знания о каких-то частностях, считая, что это модно, правильно и современно. И с их точки зрения люди с опытом и в возрасте — консервативны.
Этого уже достаточно. Давайте сделаем шаг назад и представим себе, что база данных не реляционная. И внутри использует ваш любимый язык. Допустим, шарп или джаву. Т.е. там вы внутри могли бы работать с объектами, как хотели бы. И они сразу же при фиксации транзакции были бы сохраненными, вам даже знать не надо, куда. Здесь же, это всё сервер БД.
Вы бы в этом случае делали бы еще какой-то другой сервер, через который общались с такой СУБД? Т.е. решили, что этот сервер плохой, давайте ка сделаем свою поделку. Очевидно, что решение плохое?
Точно та же логика касается и обычных реляционных СУБД. Они разрабатываются для обработки данных. Они могут обслуживать одновременно много запросов. Они могут поддерживать много коннекшинов. Но вы почему-то думаете, что это всего лишь мешок для прятания и доставания объектов и упорно пытаетесь делать свои поделки, т.е. свою прослойку, ведущую себя как СУБД, только тупую, опасную и с нуля. При этом в вашу СУБД данные загружаются из реляционной СУБД. А значит находятся в двух местах сразу. А значит появляются еще и дополнительные расходы на синхронизацию. Дополнительные потенциальные баги. Вы вообще делаете кучу всего лишнего. Это как бы если бы задача у вас стояла «купить хлеб», а вы строите завод для изготовления бетона, строите дорогу к предполагаемому магазину, строите магазин, завозите хлеб, а потом только у вас всё готово, чтобы купить хлеб.
Хлеб можно покупать сразу. Таблицами можно моделировать вполне жестко и успешно предметную область. Да, это не ООП. Но ряд плюсов даже получше, чем в ООП есть.
Не отгораживайтесь от БД ;)
Запросы тоже пишет разработчик. Вам запрещают работать с хранимками? Хранимки — это код. И не надо думать, что их должны писать кто-то избранный, какой-то базовик.
Совсем не странно. Разница, конечно, не большая, если у вас код хранится уже записанный и присылается запросами извне, или в хранимках. В данном случае хранимки всего лишь дают еще один уровень развязки. Приложению надо будет всего лишь вызывать осмысленное имя, не имея представления о внутреннем устройстве. Что дает возможность менять внутренности хранимом независимо от внешних модулей.
Другое дело, когда у вас и не будет записанного кода, а будет формироваться. Опасность уже выше. И большая связь с кодом на ЯОП.
Методологически я считаю, что СУБД должна использоваться как сервер, полностью. Не нужна в принципе прослойка еще какого-то сервера. Потому что по сути вы создаете второй сервер и дублируете данные и строите тупой упрощенный, опасный второй сервер.
Но так как мы живем не в идеальном мире, то надо сказать, что Transact-SQL (я его использую для хранимок), имеет много минусов. SQL — хорош. Транзакт — это жуткая вещь. Если вы умеете готовить хранимки по минимуму используя IF, WHILE, то всё отлично. Если же код превращается в императивщину (возможно из-за вас или плохой архитектуре БД), то есть смысл такие части писать на ЯОП. Поэтому, я бы по максимуму использовал бы хранимки. В редких местах, можно использовать шарп. Это практический совет, как провести черту.
Очень надеюсь, что придумают что-то более адекватное, чем транзакт, и тогда вопросы снимут на чем писать
Вы, возможно, не поняли всё, что я выше написал. Я пытался аргументировать, почему база должна отвечать далеко не только за хранение. Если бы она отвечала за хранение, то она вам не нужна. Очевидно, что она не для хранения предназначается, иначе не делали бы ее столь сложной. СУБД делают далеко не для хранения, но и для обработки информации. Не зря пытаются делать оптимальными алгоритмы и ускорять джойны и т.д.
То, что у вас там было с проектом, я не знаю и в спор вступать не хочу. Очевидно, что говнокод может быть написать на любом языке. И без хранимок тоже.
Нет, я не базовик. Разрабатываю всё, от гуи, до хранимок. И мой взгляд на эти вещи выработался со временем и опытом. Мне не составит большого труда создавать предметную область и на шарпе. Но вижу в этом бОльшие проблемы и больше потенциальных мест для ошибок.
Вообще, очень неплохо было бы, чтобы придумали нечто поинтереснее, чем императивные и такие «топорные» процедуры. В принципе это получается.
А что не получается, то получается «доработать напильником». Некоторые рекурсивные задачи или парсеры или динамические объекты — дописываются, хранятся в таблицах и вполне можно писать и хранимки на шарпе.
Если бы был такой хороший язык, позволяющий легко оперировать кодом, инкапсулировать его, делать свои объекты для кода, давать им имена, да и лучшей строгости в типизации хочется — я вполне за, чтобы этим занимался один сервер. Не нужен сервер СУБД, и отдельно АПП.
А пока, приходится разделять. Но для меня такая условная черта. Если можно и код не легаси, а я пишу, то СУБД — по сути содержит нормализованные сущности с хорошей моделью предметной области, хорошо обернутые в хранимки и доступ через них, а в АПП слой модели либо отражает базу, либо более высокого уровня, либо имеет объекты, близкие к обработке ГУИ.
Но и не спорю, что у нереляционных СУБД есть свои области применения. Сейчас сам одну делаю. Но там реально, совершенно другие требования и другая задача. Там не моделирование предметной области, а вычислительная конкретная задача.
Я писал о том, что многим хватит легковесного NoSQL. Но не потому, что оно легковеснее. Как раз почти всегда вижу с этим только бОльшие проблемы для кодирования. Но если человек по факту не использует SQL, то конечно, ему хватит NoSQL. Это самозамкнутое измерение — хватит или не хватит. Человек сам определяет свой темп работы, регулирует поток задач, а потом говорит, что ему быстрее не надо — он с потоком вполне справляется.
Мне не нравится тоже что код в двух местах. И тут уже кому как нравится на какой стороне кодировать.
Но оказывается, есть ряд паттернов, которые часто используются и часто появляются. При этом архитектура как бы «утрясается». Сначала пишете как-то, потом рефакторингом трясете до положения, когда вам код нравится. Вместе с паттернами. Можно было бы графически нарисовать, как получается на диаграммах Эйлера, сначала смысловое пересечение, как потом в коде два разных класса соединяются через базовый, появляется степень свободы (и жесткость). Как потом отвязываемся от классов через интерфейс. Буквально, во многих случаях можно представлять графически воздействие требования, появление в результате этого необходимости пересмотреть жесткость и гибкость в каких-то измерениях (а программа — это многомерная структура, где мерность — количество независимых переменных).
Такое воображение может быть много кому помогло бы представить, почему возможно в ООП эволюционное проектирование.
Нельзя не согласиться. Если такое г начали использовать в хранимках, то лучше это в шарп вынести.
Вопрос только в знании SQL (и набить руку). Я не увидел в таком примере ничего пугающего. Скорее всего реализуется без единого цикла или ветвления. Набором запросов. Конечно, нужно, чтобы адекватно были созданы таблицы.
Иначе в шарпе придется повторять всю исходную структуру таблиц. Разница только в объеме кода и где лучше, быстрее исправлять.
Мне не нравится, что многие почему-то считают, что есть некие прикладные программисты, а есть базовики. И базовики пишут SQL-код. Я не люблю базовиков как класс. Они, те кто не были программистами, редко и хранимки пишут так как надо. Думаю, что программист, пишущий код приложения, должен одинаково хорошо и SQL владеть и писать код в любом месте, ограничиваясь задачей, а не компонентом. Тогда проблем не будет. Вы, как программист, имеете доступ ко всему коду.
Скрывать любые части кода от разработчика вообще по-моему плохая практика. Это антипаттерн управления «Разведение грибов».
Я вынуждено тоже имею такую т.з., только шарп у меня не выигрывает. Конечно, какие-то вещи тяжело сделать в БД. Но тут стоит задуматься о правильности архитектуры или даже о качестве задачи (возможно задачу можно решить гораздо более простыми средствами). Одна из задач, тяжело поддающихся реляционным БД — это динамическое количество атрибутов у сущности. Но в принципе, это если бы на шарпе мне захотелось написать класс, который имеет динамическое количество свойств (настоящих). Пришлось бы шаманствами с отражением заниматься. Это плохо. Но плохо еще то, что шарп намного более гибкий и носом сам по себе не ткнет, что есть проблемы в задаче. Вы себе сделаете Dictionary, не будете пользоваться свойствами, и вам покажется, что классная и красивая архитектура.
SQL — прекрасный язык. Расширенные языки для написания хранимок — очень плохие языки. И вынуждено приходится идти на то, что если появляются в хранимках циклы, ветвления — это в шарп. Но часто это из-за низкой квалификации в базах данных появляется.
А если рассуждать вообще, в отрыве от конкретных БД (к сожалению работаем только на конкретных), то я уверен, что данные и их обработка должны быть как можно ближе. Не должно быть понятия отдельно — это хранилище, а тут мы прикрутим шарп и будем работать. Это чревато написанием второй БД на шарпе. Начинаются пляски с кешированием (т.е. дублированием данных, что очень не гуд), потом, эти данные уже в памяти и программист создает свою бд, с транзакциями, с оптимизациями. Конечно, эти попытки выглядят очень убого, а безопасность и целостность данных на порядок всегда ниже. Но программист, видимо, горд таким умением. С другой стороны, да, это говорит, что СУБД в большинстве своем для бизнес-приложений тащат большой оверхед. Раз сплошь и рядом делают свои поделки, херят безопасность и при этом считается почти стандартом разработки бизнес-приложений.
Иногда и за час. Всё зависит от задач. БД — понятие гораздо более широкое. Не стоит подразумевать под этим нечто монументальное. (Я имею опыт разработки разных нереляционных БД, на разных языках, не шарп).
Key-Value на каком-то другом языке и отдельном сервере (процессе), придется делать. Если же вы на шарпе пишете, то тут вообще и писать почти ничего не надо. Дублирование данных — это зло. Значит и другого процесса не надо. Будете писать библиотеку. Заводите инкрементальный идентификатор для всех любого типа объектов. И даже хеш вычислять не нужно будет. И или скрываете в коде (лучше сгенерированном) классов-сущностей вызовы по связям через поиск по этим идентификаторам, либо пишете простой менеджер, который этим управляет. Можете сделать файл с индексами и файл для хранения (сбрасывания сериализированных объектов). Можете чуть сложнее — много файлов и разбиение на таблицы через хеш. Плюс, учитываете, если хотите, какую-то безопасность, на случай аппаратного сбоя. Но это не обязательно, учитывая уровень безопасности обычных наших руками сделаных кэшей.
Всё это довольно просто. Всегда удивляло, почему люди используют SQL-Server или Оракл, когда верят, что это просто мешок для поднятия и прятания объектов. На стыковку с ними больше усилий тратят.
Всё, что вы описали, это просто опыт, но опыт, который звучит примерно так:
«Я обходился всегда без этого и поэтому я думаю, что это не нужно.»
Это замкнутый круг. Например, многие программисты утверждают, что им не нужна математика совершенно. Потому что им в работе это не нужно. Тоже замкнутый круг. Им эту работу никто и не даст никогда. Будут гуи интерфейс простой клепать до конца дней.
Теперь применительно к ответу выше.
Да почти всё можно описать. Есть небольшие места, где не всё. Например:
Но такие запросы в большинстве случаев означают непонимание реляционной модели и плохую (иногда крайне плохую) архитектуру.
Чтобы было понятнее, приведу пример с шарпом. Оказывается, там то же самое. Представьте, что вы в коде вдруг не смогли выразить предметную область средствами самого языка и прибегаете к механизму отражения. И пишете код, вроде такого:
«если объект имеет тип такой-то, то сделаем вот это».
Хреново, правда? Вот что-то похожее с динамическим SQL. Значит неудача постигла в понимании как надо выразить задачу запросом. Как надо смоделировать таблицы. Например, забыли, что таблица является сущностью, а решили, что это контейнер просто. Далее, напихали одну и ту же по сути сущность в две таблицы. Конечно, теперь джойн не очень получится, лучше делать динамический запрос, чтобы в каждом случае подставлять желаемую таблицу. А то SQL сам по себе плохо выбирает в чистом и понятном для него коде.
Или второй пример. Вы не смогли на шарпе (опять же) выразить смысл. И решили написать супер-пупер гибкий фреймворк, в котором есть состояние системы и простые команды, работающие по событиям в зависимости от состояния (такое себе перечисление). А команды являются простыми и нерасширяемыми, но с возможностью собираться в цепочки. Вот такой конечный автомат.
Поздравляю, если такое сделали, вы архиплохой шарпист (это не лично вам, а пример). Вы по сути не пользуетесь языком и его средствами, а поверх него написали что-то вроде своего интерпретатора. Настолько гибкого и универсального, насколько и нетипизируемого, опасного и скорее всего невыразительного.
Т.е. понятно, думаю, что такое язык поверх языка. Аналогично, вы не хотите работать с SQL.
При этом язык SQL во много раз мощнее, чем С#. Конечно, я рассматриваю просто императивную часть, без linq и лямбд, т.е. изначальную основу шарпа. На линькью, кстати, тоже не стоит городить огород там где может работать SQL. Т.к. линькью заточен на работу со списками. А значит, более широкого применения. И это же значит, что более опасный, более многословный. Захотите бОльшей жесткости, чтобы получить реляционные отношения, вам придется всё это ручками делать. Вопрос большой — зачем? Повторюсь, ручками сделать можно всё что угодно. Готовы спорить, что умнее команды Оракла или SQL-Server?
Циклы и ветвления, которые якобы нужны — это пусть к сложным багам и тяжелой поддержки. Это императивный код со всеми вытекающими, вроде — вероятность бесконечной рекурсии и переполнения стека. Или просто не выхода из цикла. Не говоря уже о том, что вы пишете по шагам, что нужно делать а не «как».
Никто не гарантирует, что не захотят в другом срезе. И да, результат — процедур больше. Но хочу вас разочаровать, на шарпе даже хуже. Там тоже код не телепатически узнает что делать надо. Если вы не захотите писать процедуры, то придется писать на шарпе. Неужели это так сладко писать на шарпе?
На шарпе кода будет в десятки раз больше. Вам нужен другой срез, другая группировка? На SQL пишется в несколько строк. А представляю, сколько кода, да еще с ядренными алгоритмами, для которых мозг нужен, будет на шарпе — в виде циклов, хеширования, сбаллансированных деревьев, которых нет в стандартной поставке. Просто рай для людей, любящих работать руками.
Да, SQL не идеален — нет инкапсуляции, не очень с тьюринг-полнотой. Но плюсы все таки есть и огромные. Оверхед волнует? Мне лично его в рюкзаке не носить. Написать быстро приложение и не думать о производительности (это на счет монстра) — это как раз реляционные СУБД.
А желание перейти на NoSQL звучит где-то так: давайте писать всё с нуля. NoSQL базы — это по сути очень обрезанные по функционалу базы в сравнению с реляционными. И всё, что я про них хорошего слышал, это то, что на них работают такие большие монстры, вроде твиттера, выдерживая нагрузку. Повторюсь, такие базы и покупать не нужно, их можно сделать, умея работать с файлами, за день (с самым простым функционалом). А такие «монстры», вроде твиттера или фейсбука имеют потребности в моделировании предметной области совершенно примитивные, которые наверное проще, чем бухгалтерские приложения для обслуживания ларька.
Поэтому я бы не кидался в NoSQL. А и еще думаю, что оптимизация почти всегда предварительна. И пока мы тут спорим, в районе 5 лет железо кардинально изменит взгляды на то, как можно строить СУБД и на оптимальность.
Почему вдруг? Ни разу не слышал внятных ответов. (Кстати когда-то сам так думал, когда опыта было 1-2 года, но тогда просто где-то вычитал и просто хотел работать на своем языке, а SQL казался тяжелочитаемым).
Но всё не так. Большая СУБД разрабатывается как сервер. Хорошо продумывается математика, оптимизация. Обычно, разрабатывают много неглупых людей.
А потом появляются домашние программисты бизнес-логики, которые уверены, что базы нужны только для хранения объектов, а логику, включая транзакции, они будут писать сами.
Мне нравится такая аналогия: пещерные люди за бешеные деньги покупают очень дорого танк последней модели. Привязывают тачку и возят танком копья.
Если есть желание не пользовать реляционные БД — так кто мешает. Фокус в том, что простые базы для хранения в файлах и быстрого поиска по хешу — делаются нормальным программистом за день.
Лично мне кажется, что мода на NoSql — слишком временна. Да, есть проблемы с производительностью. Но в большинстве случаев они не такие большие и эти проблемы берет на себя СУБД. И кстати, в большинстве случаев прекрасно справляется. Не хорошо программисту думать об оптимизациях. Надежность на первом месте. Скорость разработки.
Проблемы производительности связаны с текущим железом. В частности, очень сильно с разделением на ОЗУ и файловую системы. Работа с файлами пока не очень быстрая. Это вообще узкое место во всём. И это узкое место в любом случае уберут. Сделают возможно специальные машины для реляционных — и тогда все эти вопросы оптимальности NoSql перестанут быть аргументом.
Есть три этапа становления программиста. Может больше, но я пока не знаю новых.
1. Новичок. Учится кодить и кодит хоть как-нибудь и радуется, что программы его вообще работают.
2. Любовь к паттернам и проектированию. Наступает после детального изучения книги банды четырех. Человеку кажется, что если он понял, как и что делает каждый паттерн, что такое наследование, то можно ВСЁ запроектировать.
3. Отказ от паттернов. Переход на эволюционное проектирование. ТДД. Да, я верно говорю — ТДД — это не просто организация процесса. Это эволюционное проектирование. Оно явно и не явно заставляет так проектировать.
Вы пока на втором этапе. Эта статья написана человеком, либо на третьем этапе, либо переходящим на третий. У него появилось откровение, что можно разбираться на ходу с проблемами (поэтому красной таблетки не существует).
Примечательно, что на каждом этапе человек считает себя профессионалом. Новичок, правда, не всегда, если рядом есть примеры хороших программистов. А вот на втором — да. Я не хочу вас оскорблять, мне тоже не удалось пропустить второй этап. Я помню, какие «причудливые» архитектуры создавал. Зато сейчас я эффективнее в разы.
Возможно будет четвертый этап — уход от говноязыков.