Гибкости куда угодно и как угодно не бывает. Гибкость обычно в каком-то направлении (степени свободы), а в других жесткость.
Кстати, жесткость — это самое важное, намного важнее гибкости. Жесткость — это строгая типизация. Жесткость — это выражение того, что вы хотите и способность программы от этого не отклоняться.
Самое гибкое в разных направлениях — не пользоваться даже типами, а память сырую выделять. «просто объект». Вот это будет очень гибкая вещь.
Но нормально, когда пишут, все таки устанавливают некоторые жесткие ограничения. И иногда закладывают гибкость (иногда лишнюю, см. выше). И предугадывание ведет к проблемам.
Какой-то простой пример. Моделируете предметную область. Объекты: яблоко, груша, арбуз.
По YAGNI: не делаете общего предка. Понадобилось, уточнились требования — сделали. Но еще не знаете, как сделать иерархию, заказчик всё еще молчит. Но и не страшно, потом расширите.
По предугадывание. Закладываете гибкость и пишете базовый «фрукт», «овощь», «еда». Можете потом расширять иерархию, если угадали, добавлять новые фрукты, овощи. Всё для этого готово. Но проблема, если заказчика будет интересовать совсем не это, а: «форма» или «цвет» или даже «полосатость». Что в этом случае делать? Выпиливать старый предугаданный код. Может случиться, что ваша иерархия не только бесполезна, а очень мешает.
1. Вы потратили время на написание кода. Вы могли бы почти такое же время потратить и потом, но вы делали заранее.
2.1 Вы потратили время на выпиливание не нужного кода.
2.2 Вы не потратили время на выпиливание кода, он не вредит, но может «авось» понадобиться. Тогда вы тратите время на поддержку кода (юнит-тесты).
Вообще, юнит-тесты заставляют прилагать усилия и благодаря этому стараться не делать лишнего и не отрываться от Земли.
Вы спросили как можно эволюционно выделять абстракции — и я вам показал как.
Подход этот очень здравый. Называется YAGNI. В паре с KISS дает хороший эффект. Подход надо попробовать и прочувствовать, тогда поймете, почему таким образом г… нокод не получается. Никаких костылей не будет. Вы, видимо, забываете о рефакторинге. Именно рефакторинг делает из кода то, что нужно. Архитектура будет не идеальной, возможно, но достаточно хорошей и поддающейся изменениям.
Про энам с тремя полями, что-то не понял. Где вы увидели проблему? Есть энам с тремя ролями. Нет никакой сущности, которая описывает роли. Заказчику потребовались новые роли. И что? Заводите таблицу, добавляете роли, сколько хотите. С поля выкашиваете энам, предварительно замапив на новую таблицу. Потом устанавливаете ключ. Работы минут на 15. (тесты также поправить, но всё это не сверхзатратно).
Правда, зачем сразу делали энам — загадка. Это не относится к эволюционному программированию. Достаточно на данный момент — это не значит «не использовать реляционную модель».
По ТДД всё делается маленькими циклами: тест -> кодирование самым простым и очевидным способом, чтобы тест прошел -> рефакторинг, направленный на приведение кода в нормальный вид.
Последний шаг как раз и гарантирует, что не будет г… нокода. То, что нужно на данный момент, не относится к рефакторингу. Рефакторинг — обязательная часть процесса. Нельзя рассуждать так: оно на данный момент работает и этого достаточно, поэтому не будем рефакторить. Достаточность относится ко всему, кроме тестов и рефакторинга — это часть процесса. В какой-то момент и энамы исчезнут.
На счет скорости разработки, могу поспорить. Такой подход по моему мнению значительно ускоряет разработку. Если у вас совсем маленький проект, однодневный, то может быть без тестов напишете быстрее. А в любом достаточно большом проекте через некоторое время после начала более важным критерием становится возможность расширений и изменений, с одновременными проверками — не сломалось ли что-то.
Вот здесь и помогают тесты. А рефакторинг помогает быть «коду в форме» и готовым к любым изменениям. Гибкость — это не всегда гибкость. Если вы что-то предугадываете, закладывая гибкость, то это означает жесткость изменений в других направлениях. Постоянный рефакторинг и соответствие текущим требованиям позволяют быть проекту достаточно гибким в любом направлении.
Как раз в здравом уме так и делают — исходят из требований. Я показал механику на этом примере. Программист, создавая объекты, таблицы или колонки всегда сам себе задает вопрос:
— Ровно на этот момент что необходимо и достаточно?
Пример вымышленный, возможно, не делают прямо таких мелких шагов, как здесь. Но суть приблизительно такая.
Таблицы БД я привел для примера, потому что они более строгие, чем ООП, но вместе с тем похожи на объекты ООП. На таблицах очевиднее, как разделять общее и частности. В ООП — то же самое — выделение базового класса.
Но с БД немного другая ситуация, если у вас уже внедрен проект, а вы его дописываете, а не разрабатываете с нуля. Могут быть проблемы с данными. Но в общем, если мы говорим об этапе разработки, то такая техника корректна.
Именно так и должно быть, потому что программирование — раздел математики. Это точная наука. Поэтому надо использовать «объективные техники». Т.е. делать как можно меньше предположений, а использовать правила. Информация к нам поступает от заказчика. Поэтому надо опираться только на нее. Если требование не прозвучало, то его не было. А прозвучит, только тогда будем кодить. Кодирование — это требования на языке программирования. И есть различные способы оценки качества кода. Один из них — объем кода. Даже так можно анализировать. Вы выделяете абстракцию (базовые классы) и это сокращает описание. Сокращение описания — это не что иное, как выделение существенной информации. Т.е. знаний.
могу кратко пояснить, как выделяются уровни абстракции на ходу. Отлично выделяются и лучше, чем предугадывать.
Если вы знакомы с реляционными БД, то сначала на таблицах, так очевиднее.
У вас есть пока небольшая бухгалтерская программа. И есть одна из таблиц — Orders (заказы). Колонки, помимо денег, хранят атрибуты заказчика — имя, телефон. Вы это так писали, такие были на данный момент требования. Внезапно обнаруживаете, что связки имен и телефонов повторяются. Что надо делать? Выносить в отдельную таблицу.
Точно так же в ООП. У вас на текущий момент класс Order, у которого есть поля — имя и телефон. Выделить абстракцию? Не вопрос. Создаете класс OrderingCustomer. Туда выносите атрибуты — имя и телефон. Здесь, побольше возможностей, поэтому и смотрите, этот класс выносить за пределы класса или внутри класса оставить. Смотрите на текущие требования и выбираете наиболее ограниченный вариант. Проблемы?
Второй пример. У вас уже есть таблица OrderingCustomers. Кроме того в процессе разработки при постепенном поступлении требований появилась таблица Employers. И вы видите, что часть колонок пересекается. Имя и телефон. Пора выделить новую сущность — Persons. Вынести эти колонки туда и в таблицах OrderingCustomer и Employers установить ключи. Это простая по сути операция поиска общего и частностей. Частности в исходных таблицах, общее в новой.
В ООП. Ровно точно так же. Только еще и поведение выделяете, общее и частное. Уже появляются абстракции. Проблемы?
Вдруг вам понадобилось обрабатывать одинаково эти разные объекты. Создаете фабрику, тогда вас перестает волновать, что за объекты. Еще больше понадобилось абстрагирование — создаете интерфейсы, наследуете объекты.
Нет никаких проблем создавать абстракции исходя из нужд «здесь и сейчас». И нет никаких проблем делать это постепенно и менять по мере надобности.
Заметьте, я примеры дал, почти механические. Вы, теоретически, могли бы сразу увидеть, что имя и телефон относятся к человеку и смоделировать и это. Но а если это не потребуется? Может вы хотите вообще вселенную смоделировать включая атомы? Это не возможно, т.к. объективной истины нет, а модели субъективны )))
Заказчик, который дает требования к проекту, мог повернуть не в ту сторону, куда вы предугадываете и с объектами вышла бы незадача. Архитектура в конце концов при постоянном предугадывании становится деревянной, не позволяющей вносить дальнейшие изменения. А потом, появляются мысли и желания о полном переписывании системы. Корни этих желаний — неумении проводить рефакторинг и непонимание, как разрабатывать исходя из текущих требованих по принципу YAGNI.
«Интересно как же вы будете выделять уровни абстракции без проектирования»
Фаулера и Бека Кента читать до просветления :)
Отчего такая любовь к Макконелу? Да, нужен, да, хорош. Но воспринимать надо критически. Не всё подходит для любых языков. Некоторые советы для некоторых языков просто вредны. Макконел С++сник.
И хреново в нашей отрасли то, что некоторые аналогии приходят извне из общих рассуждений, прямо со студентами. Просто из языка, перевода или созвучности. Т.е. эти аналогии вроде даже насильно специально не навязывают, но как только появляется снова неопытный программист, он повторяет одно и то же.
Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…
Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.
Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).
Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.
А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.
Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.
Нельзя делить на черное и белое. Главное, конечно, люди. Без них и аджайла и не аджайла не будет. Так же от людей самих зависит, как они лучше работать будут, как понимают методику, по которой работают в проекте.
Но всё же хорошие программисты в разных условиях по разному будут эффективны. Если приходит менеджер, который узколобо верит только в водопад и планирование и появляется некий комитет «более умных» которые будут утверждать каждый шаг и не давать «умным программистам» вести проект и общаться (разведение грибов), то любой проект можно тормознуть на года и скорость разработки будет одинакова, что при таком же штате индусов/студентов.
Слабость причем? Обычно люди рассуждают о том, что им не хватает. О силе-слабости?
«Ты кричишь как бездомная
— Да здравствует дом!
Я кричу как безумный
— Да здравствует лужа!»
Заранее — это может быть синонимом констатации факта — преждевременно. Всему свое время. Делать то, что хочу (или желать делать только то, что хочу) — может быть признаком детской капризности, которая идет вразрез с логикой и эффективностью.
Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.
Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
Иногда (часто) тренды, бренды — всего лишь маркетинг. Ничего плохого не хочу говорить о майкрософт, но эти любят сделать какую-нибудь очевидную простую вещь, а раскручивать так, что кажется, в истории такого рывка вперед не было.
Я против велосипедов, но иногда надо и смотреть на профит. Пример, ORM. Кучу раньше времени тратил по прикручиванию. То хранимые процедуры не получается прикрутить, то ленивость, то еще что-то. Потом сделал свой генератор классов и код, связывающийся с бд, компилируется в рантайме. Кода на несколько страниц. Без напряжения делается за день. Вот и вопрос — велосипед ли я изобретал? Стоило мне тратить время на эти все фреймворки, которые тяжелые, много функционала, а тот, который нужен — либо его нет, либо дописывать костыли надо, которые соизмеримы со своим кодом.
Да элементарно выключить )) У нас компания об этом позаботилась. Закрыли любые меседжеры и внешнюю почту. Хабр забыли. Если бы еще сюда не заходил, был бы полный идеал. Но сюда стараюсь заходить до работы или после.
Высокая концентрация — это вопрос самоорганизации. У меня, например, в большинстве случаев очень высокая сконцентрированность — и не потому, что я прямо себя заставляю или какой-то идеальный, а просто когда не отвлекаюсь. Само собой происходит. Если выключить все отвлекающие вещи и войти в ритм, то и не представляю, что ПП заставит меня еще больше концентрироваться.
Когда есть задачи и когда они не десятиминутные, то бывает так увлекаешься, что оторваться тяжело на «бытовые» нужды )))
Обсуждение — хорошо. Если не отвлекает. Чужой взгляд тоже дает эффект. Потому как много раз замечал: вроде всё понимаю ясно и делаю всё, кажется, верно, но если рядом другой человек и он спросит «почему так», то замечаю свои ошибки. Да и вообще-то, я пишу код не для себя. И если другому человеку не понятно, это сигнал, что код объективно непонятный.
Это хорошо, только непонятно, будет ли пара работать эффективнее, чем по одному. Даже если немного качественнее, но два человека тратили время.
и на счет экономики бы поспорил. Гагарина помнят, но из своего кармана мало кто платил. А за автомобиль половина населения зад рвут на работе.
Всё опять же упирается и в ресурсы тоже. Далеко не все исследования требуют масштабных вложений. Например, физика сейчас разделилась на две части — одна — эксперименты, которые чем дальше, тем сложнее и дороже делать. А вторая — математика. Вторая — это потому что вычислительные мощности появились решать то, что раньше было тяжело или невозможно. Т.е. имея дома компьютер, можете себе что-то моделировать. Если специалист, конечно (я не специалист, просто рядом был с такими )) Алгоритмы — очень много интересных нерешенных и потенциально решаемых вещей. Вложения сюда — больше интеллект и знания, а не дорогие установки.
Генетика, воспроизводства и программирование клеток. Вот, где-то на хабре было на днях, что IBM разглядела подробно через свой микроскоп молекулы. Так что ДНК программировать — не за горами. Или моделировать, что будет если код менять. Микроскоп дорогой, исследования не завершены, но сомневаюсь, что они хоть на два порядка приближаются по стоимости к полету на Марс. А выгода будет колоссальной. Или транспорт. Очень он опасный сейчас. Не удовлетворяет требованиям по скорости давно. Жить за городом и ездить час на работу (да и в городе) — неэкономно. Сам транспорт неэкономный. Физика говорит, что если сумма потенциальных и кинетических энергий одинакова, то можно не тратить на это энергию. Отсюда — вакуум, и отсутствие трения, — верный путь к уменьшению потерь энергии и одновременно к увеличению скорости перемещения.
Всё это интересно. Конечно, нельзя быть специалистом во всем. Но при желании можно поучаствовать в любом из направлений. Полет на Марс, по-моему, но фоне этого выглядит и одновременно убого и недостижимо — летят 4 человека, а желающих оставить след в истории немного побольше ))
Я программист, и привык оценивать важность требований заказчика и целесообразность. Если он забывает об этом, то проще и дешевле его раньше переубедить, чем делать.
Здесь подобная ситуация. Рассматриваем (просто с нашей обывательской т.з.) цель доставки людей на Марс сейчас. Исследование планеты — не проходит. Эффективнее, дешевле и безопаснее исследовать автоматическими станциями. С моей т.з. цели могут быть две (три?):
1. Пиар. Очень хочется кому-то славы. Компаниям, политикам. Тема прогрета уже лет 40 различными фантастами. Этот пункт не считаю важным, чтобы за него платили люди. Тот, кто хочет пиариться, пусть сам строит корабль и сам летит, не рискуя чужими жизнями.
2. Люди, как предмет исследования. Их здоровье, самочувствие и возможность создать комплекс на чужой планете, пригодный для жизни.
3.? Авось они там что-то увидят такое необычное, что случайно не мог обнаружить марсоход или инопланетян встретят, а те на контакт пойдут. Науку же движет любопытство. И как здесь заметили многие, наперед неизвестно, что может это дать. Так и Америку бы не открыли и вообще не возможен был бы прогресс.
На счет третьего — так вообще всё может быть. Но не всё бывает в обязательном порядке. Ставку делать на случай бессмысленно.
На счет второго — слишком дорого. И деньгами. И людьми жертвовать. Конечно, полетят туда «герои», которые согласятся на это и их жизни и их здоровье будут положены на алтарь будущего человечества. Если у них не удастся, будет понятно почему.
Но. Бывают оправданные жертвы, а бывает дурость. Жертвы премии Дарвина тоже могут принести пользу своими органами.
В данном случае не имеет смысла переться на другую планету:
1. Не попробовав на Луне. Дешевле, ближе и логичнее.
2. Не создав для начала условия с помощью автоматов и не проведя исследования, гарантирующие хоть какую-то безопасность.
Тогда возможно и можно кого-то посылать. Но опять, сложный вопрос: зачем? Век, когда нужно человеческое присутствие в каждой дыре — заканчивается. Уже достаточно глаз-приборов, компьютеров и т.д.
Человечество возможно уже почти готово высадиться на Марс. Но это почти то же самое, что я готов политься на березе. Смысл почти тот же. Вы ставите сами так вопрос, что рисуете в воображении это как большое достижение, крайне необходимое, чтобы провести какую-то черту. Но это всего лишь раскрученная навязанная идея.
Человечество тогда будет оправдано расселяться, когда на Земле ему будет места маловато, а создавать условия на других планетах и летать туда-сюда будет дешево. А до этого времени можно проводить точечные исследования на такую возможность. Но не слать людей на гибель и не рисковать ими. Кстати, это может дать обратный эффект. Из-за несчастного случая, который вероятен из-за непоследовательности и спешки, у многих людей надолго отпадет охота куда-то летать.
Вы не правы. Есть много видов современных ИИ, которые обучаются и даже самообучаются.
Старый добрый человек пока что более универсальный. ИИ, которые обучаются, обычно, имеют уже некоторую модель обучения и могут решать определенный тип задач.
Но этим они и ценны. Решают они эти задачи куда более эффективно человека. Представьте себе, чтобы в гугле работало 300 миллиардов тёть, которые в ответ на ваши запросы искали для вас релевантные ответы.
Кому как. Почему скучно? Как раз поболее умственные задачи. Может не так эффектно выглядит. Космический корабль большой и дымит хорошо. Но по сути, задача доставки людей — это просто задача доставки. Сложная по ресурсам. Но не сверхинтеллектуальная (не бросайте помидоры). Законы Кеплера, классическая механика — известны давно. Почти школьная программа. Нужно только собрать корабль… Да, проблем мелких много и сложные, не спорю. Но неужели, например, исследование и попытка воспроизвести клетки живого организма — менее сложная задача? И при этом менее ресурсоемкая. Поиск новых источников энергии — это не физика? Это разве скучно и несложно? По-вашему, сложнее металл для корабля подобрать и костюмы сделать? Транспорт — это тоже очень занятная проблема. Люди как в каменном веке ездят «пешком» — управляя руками авто. Что довольно медленно (очень медленно на самом деле, чем может быть при нынешних технологиях) и при этом смертельно опасно — одна из основных причин неестественной смерти. Разве изобрести новый вид транспорта легко и скучно? Космические полеты, кстати, повторюсь, уже изобретены. Там только ресурсы и надежность просчитать.
Вопрос про ИИ не для этого поста. А вообще, во-первых задача интересная, а во-вторых, под силу исследованиям в домашних условиях. Ну и в третьих, ИИ — более широкое понятие, чем копия человека. Человека и родить можно. А ИИ нужен для практических задач. И не обязательно суперуниверсальный.
Если этим не будет заниматься значительная часть человечества, то пусть. Наука должна двигаться во всех направлениях.
Но на счет губной помады для собак )) На Земле по-моему есть гораздо и гораздо больше интересных нерешенных задач, которые действительно выгодны и более любопытны, чем построить человеческий поросятник в безвоздушном пространстве ))) Никаких других целей и предмета для гордости не замечаю. Исследование планеты вполне хорошо происходит автоматическим способом. Кстати, и дешевле, чем везти несколько тонн продуктов и несколько людей. Которые нужны-то только для того, чтобы посмотреть, что с ними будет потом. Почему на животных сразу не проверить? Да еще в один конец отправлять. Прямо «Омон Ра» какой-то.
Я за прогресс и не против, что когда-то люди будут расселяться. Но на нынешних технологиях — и опасно и бессмысленно и для здоровья вредно.
на земле столько задач интресных, в которых может каждый поучаствовать: искусственный разум, алгоритмы, робототехника. Бессмертие возможно не за горами. Лечение болезней. Уменьшение потребления энергии и новые источники энергии. Транспорт (достали автомобили, правда?). Жилье — удешевление строительства и автоматизация. Менее затратное выращивание пищи. Социальные проблемы. Физика (коллайдер и новые модели).
Куда не посмотришь, столько нерешенных и вместе с тем интересных проблем. И нужных. По моему и интереснее, чем просто доставить людей куда-то и развернуть палатки с воздухом.
Кстати, жесткость — это самое важное, намного важнее гибкости. Жесткость — это строгая типизация. Жесткость — это выражение того, что вы хотите и способность программы от этого не отклоняться.
Самое гибкое в разных направлениях — не пользоваться даже типами, а память сырую выделять. «просто объект». Вот это будет очень гибкая вещь.
Но нормально, когда пишут, все таки устанавливают некоторые жесткие ограничения. И иногда закладывают гибкость (иногда лишнюю, см. выше). И предугадывание ведет к проблемам.
Какой-то простой пример. Моделируете предметную область. Объекты: яблоко, груша, арбуз.
По YAGNI: не делаете общего предка. Понадобилось, уточнились требования — сделали. Но еще не знаете, как сделать иерархию, заказчик всё еще молчит. Но и не страшно, потом расширите.
По предугадывание. Закладываете гибкость и пишете базовый «фрукт», «овощь», «еда». Можете потом расширять иерархию, если угадали, добавлять новые фрукты, овощи. Всё для этого готово. Но проблема, если заказчика будет интересовать совсем не это, а: «форма» или «цвет» или даже «полосатость». Что в этом случае делать? Выпиливать старый предугаданный код. Может случиться, что ваша иерархия не только бесполезна, а очень мешает.
1. Вы потратили время на написание кода. Вы могли бы почти такое же время потратить и потом, но вы делали заранее.
2.1 Вы потратили время на выпиливание не нужного кода.
2.2 Вы не потратили время на выпиливание кода, он не вредит, но может «авось» понадобиться. Тогда вы тратите время на поддержку кода (юнит-тесты).
Вообще, юнит-тесты заставляют прилагать усилия и благодаря этому стараться не делать лишнего и не отрываться от Земли.
Подход этот очень здравый. Называется YAGNI. В паре с KISS дает хороший эффект. Подход надо попробовать и прочувствовать, тогда поймете, почему таким образом г… нокод не получается. Никаких костылей не будет. Вы, видимо, забываете о рефакторинге. Именно рефакторинг делает из кода то, что нужно. Архитектура будет не идеальной, возможно, но достаточно хорошей и поддающейся изменениям.
Про энам с тремя полями, что-то не понял. Где вы увидели проблему? Есть энам с тремя ролями. Нет никакой сущности, которая описывает роли. Заказчику потребовались новые роли. И что? Заводите таблицу, добавляете роли, сколько хотите. С поля выкашиваете энам, предварительно замапив на новую таблицу. Потом устанавливаете ключ. Работы минут на 15. (тесты также поправить, но всё это не сверхзатратно).
Правда, зачем сразу делали энам — загадка. Это не относится к эволюционному программированию. Достаточно на данный момент — это не значит «не использовать реляционную модель».
По ТДД всё делается маленькими циклами: тест -> кодирование самым простым и очевидным способом, чтобы тест прошел -> рефакторинг, направленный на приведение кода в нормальный вид.
Последний шаг как раз и гарантирует, что не будет г… нокода. То, что нужно на данный момент, не относится к рефакторингу. Рефакторинг — обязательная часть процесса. Нельзя рассуждать так: оно на данный момент работает и этого достаточно, поэтому не будем рефакторить. Достаточность относится ко всему, кроме тестов и рефакторинга — это часть процесса. В какой-то момент и энамы исчезнут.
На счет скорости разработки, могу поспорить. Такой подход по моему мнению значительно ускоряет разработку. Если у вас совсем маленький проект, однодневный, то может быть без тестов напишете быстрее. А в любом достаточно большом проекте через некоторое время после начала более важным критерием становится возможность расширений и изменений, с одновременными проверками — не сломалось ли что-то.
Вот здесь и помогают тесты. А рефакторинг помогает быть «коду в форме» и готовым к любым изменениям. Гибкость — это не всегда гибкость. Если вы что-то предугадываете, закладывая гибкость, то это означает жесткость изменений в других направлениях. Постоянный рефакторинг и соответствие текущим требованиям позволяют быть проекту достаточно гибким в любом направлении.
— Ровно на этот момент что необходимо и достаточно?
Пример вымышленный, возможно, не делают прямо таких мелких шагов, как здесь. Но суть приблизительно такая.
Таблицы БД я привел для примера, потому что они более строгие, чем ООП, но вместе с тем похожи на объекты ООП. На таблицах очевиднее, как разделять общее и частности. В ООП — то же самое — выделение базового класса.
Но с БД немного другая ситуация, если у вас уже внедрен проект, а вы его дописываете, а не разрабатываете с нуля. Могут быть проблемы с данными. Но в общем, если мы говорим об этапе разработки, то такая техника корректна.
Именно так и должно быть, потому что программирование — раздел математики. Это точная наука. Поэтому надо использовать «объективные техники». Т.е. делать как можно меньше предположений, а использовать правила. Информация к нам поступает от заказчика. Поэтому надо опираться только на нее. Если требование не прозвучало, то его не было. А прозвучит, только тогда будем кодить. Кодирование — это требования на языке программирования. И есть различные способы оценки качества кода. Один из них — объем кода. Даже так можно анализировать. Вы выделяете абстракцию (базовые классы) и это сокращает описание. Сокращение описания — это не что иное, как выделение существенной информации. Т.е. знаний.
Если вы знакомы с реляционными БД, то сначала на таблицах, так очевиднее.
У вас есть пока небольшая бухгалтерская программа. И есть одна из таблиц — Orders (заказы). Колонки, помимо денег, хранят атрибуты заказчика — имя, телефон. Вы это так писали, такие были на данный момент требования. Внезапно обнаруживаете, что связки имен и телефонов повторяются. Что надо делать? Выносить в отдельную таблицу.
Точно так же в ООП. У вас на текущий момент класс Order, у которого есть поля — имя и телефон. Выделить абстракцию? Не вопрос. Создаете класс OrderingCustomer. Туда выносите атрибуты — имя и телефон. Здесь, побольше возможностей, поэтому и смотрите, этот класс выносить за пределы класса или внутри класса оставить. Смотрите на текущие требования и выбираете наиболее ограниченный вариант. Проблемы?
Второй пример. У вас уже есть таблица OrderingCustomers. Кроме того в процессе разработки при постепенном поступлении требований появилась таблица Employers. И вы видите, что часть колонок пересекается. Имя и телефон. Пора выделить новую сущность — Persons. Вынести эти колонки туда и в таблицах OrderingCustomer и Employers установить ключи. Это простая по сути операция поиска общего и частностей. Частности в исходных таблицах, общее в новой.
В ООП. Ровно точно так же. Только еще и поведение выделяете, общее и частное. Уже появляются абстракции. Проблемы?
Вдруг вам понадобилось обрабатывать одинаково эти разные объекты. Создаете фабрику, тогда вас перестает волновать, что за объекты. Еще больше понадобилось абстрагирование — создаете интерфейсы, наследуете объекты.
Нет никаких проблем создавать абстракции исходя из нужд «здесь и сейчас». И нет никаких проблем делать это постепенно и менять по мере надобности.
Заметьте, я примеры дал, почти механические. Вы, теоретически, могли бы сразу увидеть, что имя и телефон относятся к человеку и смоделировать и это. Но а если это не потребуется? Может вы хотите вообще вселенную смоделировать включая атомы? Это не возможно, т.к. объективной истины нет, а модели субъективны )))
Заказчик, который дает требования к проекту, мог повернуть не в ту сторону, куда вы предугадываете и с объектами вышла бы незадача. Архитектура в конце концов при постоянном предугадывании становится деревянной, не позволяющей вносить дальнейшие изменения. А потом, появляются мысли и желания о полном переписывании системы. Корни этих желаний — неумении проводить рефакторинг и непонимание, как разрабатывать исходя из текущих требованих по принципу YAGNI.
Фаулера и Бека Кента читать до просветления :)
Отчего такая любовь к Макконелу? Да, нужен, да, хорош. Но воспринимать надо критически. Не всё подходит для любых языков. Некоторые советы для некоторых языков просто вредны. Макконел С++сник.
И хреново в нашей отрасли то, что некоторые аналогии приходят извне из общих рассуждений, прямо со студентами. Просто из языка, перевода или созвучности. Т.е. эти аналогии вроде даже насильно специально не навязывают, но как только появляется снова неопытный программист, он повторяет одно и то же.
Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…
Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.
Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).
Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.
А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.
Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.
Но всё же хорошие программисты в разных условиях по разному будут эффективны. Если приходит менеджер, который узколобо верит только в водопад и планирование и появляется некий комитет «более умных» которые будут утверждать каждый шаг и не давать «умным программистам» вести проект и общаться (разведение грибов), то любой проект можно тормознуть на года и скорость разработки будет одинакова, что при таком же штате индусов/студентов.
«Ты кричишь как бездомная
— Да здравствует дом!
Я кричу как безумный
— Да здравствует лужа!»
Заранее — это может быть синонимом констатации факта — преждевременно. Всему свое время. Делать то, что хочу (или желать делать только то, что хочу) — может быть признаком детской капризности, которая идет вразрез с логикой и эффективностью.
Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.
Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
Я против велосипедов, но иногда надо и смотреть на профит. Пример, ORM. Кучу раньше времени тратил по прикручиванию. То хранимые процедуры не получается прикрутить, то ленивость, то еще что-то. Потом сделал свой генератор классов и код, связывающийся с бд, компилируется в рантайме. Кода на несколько страниц. Без напряжения делается за день. Вот и вопрос — велосипед ли я изобретал? Стоило мне тратить время на эти все фреймворки, которые тяжелые, много функционала, а тот, который нужен — либо его нет, либо дописывать костыли надо, которые соизмеримы со своим кодом.
Когда есть задачи и когда они не десятиминутные, то бывает так увлекаешься, что оторваться тяжело на «бытовые» нужды )))
Обсуждение — хорошо. Если не отвлекает. Чужой взгляд тоже дает эффект. Потому как много раз замечал: вроде всё понимаю ясно и делаю всё, кажется, верно, но если рядом другой человек и он спросит «почему так», то замечаю свои ошибки. Да и вообще-то, я пишу код не для себя. И если другому человеку не понятно, это сигнал, что код объективно непонятный.
Это хорошо, только непонятно, будет ли пара работать эффективнее, чем по одному. Даже если немного качественнее, но два человека тратили время.
Всё опять же упирается и в ресурсы тоже. Далеко не все исследования требуют масштабных вложений. Например, физика сейчас разделилась на две части — одна — эксперименты, которые чем дальше, тем сложнее и дороже делать. А вторая — математика. Вторая — это потому что вычислительные мощности появились решать то, что раньше было тяжело или невозможно. Т.е. имея дома компьютер, можете себе что-то моделировать. Если специалист, конечно (я не специалист, просто рядом был с такими )) Алгоритмы — очень много интересных нерешенных и потенциально решаемых вещей. Вложения сюда — больше интеллект и знания, а не дорогие установки.
Генетика, воспроизводства и программирование клеток. Вот, где-то на хабре было на днях, что IBM разглядела подробно через свой микроскоп молекулы. Так что ДНК программировать — не за горами. Или моделировать, что будет если код менять. Микроскоп дорогой, исследования не завершены, но сомневаюсь, что они хоть на два порядка приближаются по стоимости к полету на Марс. А выгода будет колоссальной. Или транспорт. Очень он опасный сейчас. Не удовлетворяет требованиям по скорости давно. Жить за городом и ездить час на работу (да и в городе) — неэкономно. Сам транспорт неэкономный. Физика говорит, что если сумма потенциальных и кинетических энергий одинакова, то можно не тратить на это энергию. Отсюда — вакуум, и отсутствие трения, — верный путь к уменьшению потерь энергии и одновременно к увеличению скорости перемещения.
Всё это интересно. Конечно, нельзя быть специалистом во всем. Но при желании можно поучаствовать в любом из направлений. Полет на Марс, по-моему, но фоне этого выглядит и одновременно убого и недостижимо — летят 4 человека, а желающих оставить след в истории немного побольше ))
))) Опечатка
Здесь подобная ситуация. Рассматриваем (просто с нашей обывательской т.з.) цель доставки людей на Марс сейчас. Исследование планеты — не проходит. Эффективнее, дешевле и безопаснее исследовать автоматическими станциями. С моей т.з. цели могут быть две (три?):
1. Пиар. Очень хочется кому-то славы. Компаниям, политикам. Тема прогрета уже лет 40 различными фантастами. Этот пункт не считаю важным, чтобы за него платили люди. Тот, кто хочет пиариться, пусть сам строит корабль и сам летит, не рискуя чужими жизнями.
2. Люди, как предмет исследования. Их здоровье, самочувствие и возможность создать комплекс на чужой планете, пригодный для жизни.
3.? Авось они там что-то увидят такое необычное, что случайно не мог обнаружить марсоход или инопланетян встретят, а те на контакт пойдут. Науку же движет любопытство. И как здесь заметили многие, наперед неизвестно, что может это дать. Так и Америку бы не открыли и вообще не возможен был бы прогресс.
На счет третьего — так вообще всё может быть. Но не всё бывает в обязательном порядке. Ставку делать на случай бессмысленно.
На счет второго — слишком дорого. И деньгами. И людьми жертвовать. Конечно, полетят туда «герои», которые согласятся на это и их жизни и их здоровье будут положены на алтарь будущего человечества. Если у них не удастся, будет понятно почему.
Но. Бывают оправданные жертвы, а бывает дурость. Жертвы премии Дарвина тоже могут принести пользу своими органами.
В данном случае не имеет смысла переться на другую планету:
1. Не попробовав на Луне. Дешевле, ближе и логичнее.
2. Не создав для начала условия с помощью автоматов и не проведя исследования, гарантирующие хоть какую-то безопасность.
Тогда возможно и можно кого-то посылать. Но опять, сложный вопрос: зачем? Век, когда нужно человеческое присутствие в каждой дыре — заканчивается. Уже достаточно глаз-приборов, компьютеров и т.д.
Человечество возможно уже почти готово высадиться на Марс. Но это почти то же самое, что я готов политься на березе. Смысл почти тот же. Вы ставите сами так вопрос, что рисуете в воображении это как большое достижение, крайне необходимое, чтобы провести какую-то черту. Но это всего лишь раскрученная навязанная идея.
Человечество тогда будет оправдано расселяться, когда на Земле ему будет места маловато, а создавать условия на других планетах и летать туда-сюда будет дешево. А до этого времени можно проводить точечные исследования на такую возможность. Но не слать людей на гибель и не рисковать ими. Кстати, это может дать обратный эффект. Из-за несчастного случая, который вероятен из-за непоследовательности и спешки, у многих людей надолго отпадет охота куда-то летать.
Старый добрый человек пока что более универсальный. ИИ, которые обучаются, обычно, имеют уже некоторую модель обучения и могут решать определенный тип задач.
Но этим они и ценны. Решают они эти задачи куда более эффективно человека. Представьте себе, чтобы в гугле работало 300 миллиардов тёть, которые в ответ на ваши запросы искали для вас релевантные ответы.
Но на счет губной помады для собак )) На Земле по-моему есть гораздо и гораздо больше интересных нерешенных задач, которые действительно выгодны и более любопытны, чем построить человеческий поросятник в безвоздушном пространстве ))) Никаких других целей и предмета для гордости не замечаю. Исследование планеты вполне хорошо происходит автоматическим способом. Кстати, и дешевле, чем везти несколько тонн продуктов и несколько людей. Которые нужны-то только для того, чтобы посмотреть, что с ними будет потом. Почему на животных сразу не проверить? Да еще в один конец отправлять. Прямо «Омон Ра» какой-то.
Я за прогресс и не против, что когда-то люди будут расселяться. Но на нынешних технологиях — и опасно и бессмысленно и для здоровья вредно.
на земле столько задач интресных, в которых может каждый поучаствовать: искусственный разум, алгоритмы, робототехника. Бессмертие возможно не за горами. Лечение болезней. Уменьшение потребления энергии и новые источники энергии. Транспорт (достали автомобили, правда?). Жилье — удешевление строительства и автоматизация. Менее затратное выращивание пищи. Социальные проблемы. Физика (коллайдер и новые модели).
Куда не посмотришь, столько нерешенных и вместе с тем интересных проблем. И нужных. По моему и интереснее, чем просто доставить людей куда-то и развернуть палатки с воздухом.