Легко представить, как через некоторое время родители начнут поднимать волну возмущения, чтобы учителя не мучили детей в школе, уменьшали часы математики.
А некоторые люди чувствуют вообще пытки при мысли об уборке квартиры. Или приготовлении пищи.
Лучше бы на себе провели исследование, с какой болью они утром сталкиваются при мысли, что надо проснуться и пойти на работу.
«Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.»
Что есть «несущественные стороны»? Это субъективно не важные характеристики. «Не важные» — это зависит от целей человека и целей его моделирования. Например, бумажная модель будущего дома в точности показывает пропорции и возможно цвета поверхностей. Но материал и размеры не важны, поэтому размер маленький, а модель из бумаги, а не бетона.
По сути можно всегда выделять из потока информации существенную информацию и шум. Поиск существенной информации — это и есть в какой-то мере абстрагирование. Поиск аналитической формулы, наиболее точно описывающей набор точек, называют задачей регрессии. Т.е. такая формула — это сжатое представление набора точек. Грубо говоря, формулу передать можно меньшим числом байт.
Это только один из вариантов моделей поиска закономерностей. Все другие практически делают то же самое. Ищут существенное, что можно передать меньшим числом байт, возможно с потерей точности. Что делает нейронная сеть? Она переводит большое разнообразие точек в намного меньшее количество информации, хранящееся в ее весах, когда она обучится. При этом, если выбрать большую, чем требуется нейронную сеть (с бОльшим количеством нейронов и весов, то такая сеть может «переобучиться» — т.е. обучиться шумам. И тогда на новых данных, которых не было на этапе обучения, она будет показывать плохую точность.
Преобразование Фурье? То же самое. Сложную кривую превращает в ряд коэффициентов. И чем их меньше, тем больше «сглаживание». Название метода «сокращения длины описаний» говорит сам за себя.
То, что описал в этой статье Натан Марц — это его интуитивное понимание и аналогии. Как работает ТДД? Где-то так же: сначала «чтобы было», на второй фазе — рефакторинг — т.е. сокращение описания (вынесение в базовые классы и т.д.), наведение «красоты» (избавление от магических чисел, например). Ну и тесты перед этим, чтобы задать ограничения.
Что является в его понимании страданием? Это по сути YAGNI. Т.е. страдания — это способ оценки что действительно важно, а что нет. То, без чего можно обойтись — не делают. Я, например, интуитивно использую другую аналогию. Каждая строчка кода — зло, программирование — зло, и красоты нет в этом процессе. Т.е. использую принцип сопротивления написанию кода. И тогда оценка качества кода сводится не к выбору лучшего решения, а выбору наименее худшего.
Вот пример граблей, которые я сам себе сделал. Писал прототип, нужна была оптимальность. Я написал передачу в метод одного массива и в нем преобразование. Массив очень большой. Возможно съел бы всю память. И я придумал (заранее) не очень сложный, но хитрый алгоритм, который не делает копию, а преобразовывает этот же массив.
Всё классно работало, но через неделю обнаружил интересный факт. Копия массива всё же делалась. Потому что, как оказалось позже, мне понадобился в другом месте исходный, неподпорченный массив.
Вроде бы казалось, оптимизацию я провел недорогую по времени и простую. Но она совершенно не нужна, усложняет в итоге значительно метод и мало того, она замедляет в конечном счете выполнение. Т.к. копия всё равно уже есть, извращаться не нужно.
Любая оптимизация заранее — зло. Даже недорогая. Оптимизировать нужно только ботлнеки. А где они будут, выяснить можно только замерами.
Точно. Оптимизированный код — как обрезанное одеяло. Если этого не делать, то потом из бОльшего одеяла всегда можно сделать меньшее. А наоборот нельзя будет сделать. )))
Если пишете как можно проще, значит кода меньше. Значит менее болезненно и без нащупывания будет изменять, добавлять и т.д.
Если пишете используя DRY, то значит ни код, ни данные не повторяются. Значит, например, кеширование делать потом будет совсем не болезненно. Не надо искать разные места и синхронизировать.
Я на самом деле не противник NoSQL баз. Но только для очень ограниченных случаев. Сам ровно сейчас создаю свою с нуля СУБД. Но там четкая и строгая задача, задача датамайнинга. С такими алгоритмами, что нужно заточить субд полностью.
Но вообще их делать и не пользоваться реляционными в общем случае — совсем не гуд. Создавая такие мелкие свои СУБД я уже давно осознал, какое это благо пользоваться готовыми. Для моделирования, для бизнес-задач, пока ничего лучше не придумали. Брать NoSQL-льные базы для таких задач — ну прямо зло. Это огрызки реляционных баз данных по функционалу.
Вы так боитесь за оптимальность работы вашего приложения? Любая оптимизация (абсолютно) до написания кода является преждевременной. Думать об оптимальности до получения продукта — самое большее зло, которое можно придумать.
Реляционные БД во-первых очень оптимальные, над ними работают много людей. Неглупых. Во-вторых они строгие. Декларативно можно большую половину работы с данными описать. А что важнее правильности работы программы и надежности? Оптимальность, повторю, на двадцать пятом месте. Неприятно, что программисты почему-то считают оптимальность своих программ большим достоинством. Это что-то психологическое.
Плюсуем к плюсам еще скорость разработки — и видим большой профит.
О будущем.
1. Алгоритмы работы с данными — это в первую очередь связано с архитектурой машины. Оптимизация алгоритмов на данный момент происходит в несколько шагов и главная особенность, связанна с машиной — это маленькая и дорогая ОЗУ (энергозависимая) и большой медленный винт. То, что происходит в памяти, происходит значительно быстрее. Поэтому одна из задач оптимизации — загрузить по полной процессор и почти по полной память, но не выйти в своп. Из этого алгоритмы усложняются. Большие объемы данных начинают бить на куски и т.д.
Все знают об этом узком месте. И работы ведутся. Насколько я знаю, уже есть способы хранить энергонезависимо данные со скоростью обращения к ним заметно превышающую скорость обращения к текущей ОЗУ. Ведутся исследования и испытания по доработке, чтобы это попало в производство. Думаю, в районе 5-10 лет такое произойдет.
А как только это произойдет, сам подход к алгоритмам и их оптимизациям изменится.
2. Очевидно, что алгоритмы также связаны с моделью работы с памятью. Базы данных — это одно из важнейших направлений в разработке. И я не удивлюсь, если в скором времени придумают железные решения для реляционных СУБД. Т.к. они себя хорошо зарекомендовали в течении многих лет.
Также я не считаю прямо идеалом реляционные СУБД. Но они явно лучше многих вещей. Например, писать на шарпе или джаве гораздо опаснее и менее лаконично, чем на SQL. Возможно, в скором будущем придумают модель получше реляционной. Доработают ее.
Но взять и отказаться в пользу NoSQL-льных огрызков… Почему это огрызки. Реляционная СУБД позволяем матипулировать данными в разных направлениях, как захотите. Поддерживает фильр, сортировку, группировку по любым колонкам и джойны.
Древовидная база будет сильно оптимально заточена под джойны, с учетом если угадали, как эти джойны будут происходить. Как только нужно будет делать непредусмотренные джойны — приехали. То же с группировкой.
А программисты, хвалящие NoSQL базы, может быть думают, что будут только гуглы и фейсбуки создавать? Размечтались. )))
Да, объем данных будет расти. Но и железо будет расти. Возможно, реляционные СУБД как раз станут не медленнее всяких NoSQL. Во вторых, на очень больших объемах данных, обычно, операционная деятельность не ведется. Большие объемы нужны для аналитики. Там и БД другие. Нереляционные. Олапы и всякое другое.
Сотки не такая уж и большая проблема достигнуть. Главное — не ставьте цель, а просто каждый день делайте. Не нужен андроид. Не нужны и 6 недель. Не имеет значение, 6 недель или год.
Тут не альтруизм. Когда 10-тки раз споришь и объясняешь что-то, а потом замечаешь, что хабр у людей имеет некий авторитет, то проще сюда запостить. Оно сразу отражается и на коллективе в котором работаешь. Главное не разболтать свой ник )))
Требования не даются просто заказчиком без обсуждения. Я вообще противник любых лишних звеньев, вроде пиэмов, системных аналитиков, которые препятствуют прямому общению с заказчиком. Требования идут от заказчика, но не так: я сказал, а вы делайте как хотите. Это всё, по нормальному, происходит в процессе общения. Дело в том, что заказчик знает свою предметную область. Программист знает языки программирования. Но в общении с заказчиком рождается нечто новое — новый язык, новые термины. И мы, программисты, с нашей точки зрения, называем именно это предметной областью. И мы ее моделируем. Так вот эта предметная область — это новый язык, который на стыке «наук» появляется. Программисту нужна связь, не только к нему, но и от него.
Потому что, как я в статье показал, буквально, код — это перевод требований на язык программирования. Это лингвистическая по сути вещь. «Предметную область» не могут родить в общении с заказчиком люди, не имеющие отношение к программированию или даже не знающее именно того языка, на котором разработка ведется.
А в процессе общения с заказчиком программист не пассивен. Он может предлагать дополнительные варианты. Потому что ему код даже может подсказывать, какие еще интересные абстракции получаются. Возможно, заказчик и не подозревает, что такое можно сделать.
А про хлеб. Ну, я ж брал пример статьи о Борисе и Маркусе. Какие были требования, так и переписал. Потом, в задачу статьи не входило объяснение, как вести переговоры. Да и это, скорее всего, не формализируется. А вот, когда требования сформированы — тут уже хорошо происходит формализация. На требования, даже пишут тесты. Таким образом, для заказчика, процесс разработки выглядит как черный ящик. Он, общаясь утвердил некоторые требования. Которые четко зафиксированы в документе. А на по окончанию, даже не проекта, а допустим небольшого этапа, спринта, он получает продукт, который в точности удовлетворяет записанным требованиям и это доказано автоматическими тестами. Ну и презентацию можно сделать, показать вручную прохождение тестов.
Но мне один класс кажется проще. Потому что действительно, хлеб задуман сразу один и печка одна. Плодить классы мне кажется нецелесообразно было бы.
Потом, это упрощение наследования, на данном этапе. Ведь полиморфизм можно организовать далеко не только виртуальными методами. Есть некоторый маркер типа и вы можете, например, выставлять наружу свойства-делегаты и подменять в зависимости от маркера типа.
Но когда еще нет поведения, то остается просто маркер типа.
Пример очень утрирован. Я его взял с предыдущей статьи другого человека. Понятное дело, многое пришлось за уши притягивать. Ваши требования для игры, возможно интереснее. Но статья получилась по ним бы гораздо объемнее.
Нет. Непрофессионализм — это когда человек готов за копейки ползать перед заказчиком и делать что угодно, потому что тот деньги платит. Даже нарушать процесс, технологию разработки.
Программист — это самурай проекта, а не самурай заказчика или денег или начальства. Программист болеет ТОЛЬКО за проект. И грош цена такому профессионалу, если он через это перешагивает. Вы, допустим, заказчик. Вы бы согласились нанять подлизу, который пытается вам угодить на словах, а пишет говнокод?
Не со всеми заказчиками надо работать. Их много. Можно выбирать поадекватнее. Потому что бывают заказчики, которые вообще не хотят формулировать, что они хотят. И ведут себя как барины: я вам денег плачу, вы обязаны сделать мне хорошо, а как — сами придумайте.
Ягни — это глубокая философия, как НАДО развиваться проекту. Это серьезная практика. Работа с кодом, умение оценивать, преобразовывать информацию.
При этом, конечно, должно быть и прямое общение с заказчиком. Никто не мешает программисту предлагать некоторые пути развития проекта с т.з. требований. Только в общении рождаются требования. И программист тоже может придумывать требования. Но только ОБЯЗАТЕЛЬНО их обсуждать с заказчиком, а не делать и строить из себя фокусника. Делать он может только то, что утверждено в обсуждении с заказчиком.
Пусть плюет. Не нужно с таким заказчиком работать.
Этот ягни — глубокая философия. Он позволяет писать очень качественно, быстро. Позволяет не сломаться проекту при любых требованиях. И позволяет оценивать по настоящему что нужно, а что нет. Кто это не совсем понимает, тот никогда вообще адекватных архитектур не делал. Просто у таких не будет меры и оценки, что правильно, а что нет. В большинстве случаев, те, кто «проектируют наперед» — не проектируют ВООБЩЕ. У них критерии «красиво» (прямо как бабы на лугу, усюсюкаются ))), или «гибко» (ацки плохой критерий). Больше нет критерия, кроме «кажется».
Да, возможно. Но поднять уровень можно в разы, а может быть в десятки.
Со мной пару раз была такая странная вещь. Как-то неожиданно я становился на день приблизительно в разы умнее. Как попадать в это состояние, не знаю. Само собой произвольно происходило.
И хотя я занимаюсь иногда довольно сложной деятельностью (не всегда), но в тех случаях был очевидный прорыв. Первый раз на сложном функциональном языке работал, так я тогда смог писать код, который создает код, который выполняется. До сих пор жутковато так программировать. Язык тот был write-only, крайне тяжело читаемый. И писать на нем сложно. Хотя эффективно. Но писать код, который создает код на нем же — ацкая вещь. А тогда у меня была ясность мышления в разы больше и я спокойно писал, никак не боясь ошибиться и особо и не проверял код, был уверен, что всё верно.
Второй раз, я уже на шарпе работал и уже второй год поддерживал легаси код. Он был плохой. Но когда снова такая ясность образовалась, я вдруг увидел кучу ошибок и начал править, с которыми два года сосуществовал.
Наверное, предел есть. Но очень хочется быть умнее уже сейчас. Хотя бы на немного.
И по всей видимости никакими тренировками и (или) медицинскими способами качество интеллекта поднять невозможно.
Сильно сомневаюсь. По себе знаю. В нашей западной культуре никогда и не было на самом деле тренировок. Обучение математике с ранних лет, конечно, дает свой эффект. Но далеко не факт, что это лучший способ. Тренировки на принципе повторения того, к чему готовитесь, не всегда эффективны.
Основная проблема, по-моему, — это сложность концентрации. Ум прыгает с мысли на мысли, у него они роятся. Из-за этого теряется ясность понимания задачи, ясность представления. А эта штука, вообще-то, легко тренируется.
Ситуация 2 вполне часто бывает и обоснована.
Но в статье я всего лишь один срез показывал — ничего не делать без подтверждения заказчика. И это верно. Другое дело — вы не пассивны в общении с заказчиком. Там даже небольшой пример есть «вступаем в полемику».
Общение с заказчиком и «кристаллизация» требований не рассматривались. Заказчик не всегда может родить требования. И для этого существует общение. Можно вступать в спор, «полемику». Но только то, что после этого «утверждено» заказчиком, то и реализовывается. Если заказчик сильно отказывается, когда вам нужны уточнения — то тогда, я бы посоветовал с ним прощаться. Видимо он неадекватный. Обычно, заказчики заинтересованы в конечном результате, и поэтому в объяснению своих желаний тоже.
Есть вариант, что заказчик не в курсе обо всех тенденциях и нельзя от него получить какую-то конкретику по каким-то направлениям. Тогда можете реализовывать любое. Так же, как в статье — какой-то взвешенный алгоритм наименьших квадратов. Заказчик может быть вообще даже и близко не в теме. Но тем не менее, есть возможность реализовать что-то, а потом спрашивать уточнение. Это что-то вроде рабочей заглушки. Но надо помнить, что это заглушка. И потом уточнить, даже если заказчика устраивает.
Коллективное владение кода — не только декларация. Если один человек пишет код одной части, а другой разработчик никогда в него не заглядывал, то даже если дать ему возможность там править, он скорее всего пойдет к первому и попытается делегировать работу.
Ревью кода, в моем понимании, — это далеко не одобрение. На одобрение можно ложить с прибором. Считаем, что коллектив взрослый и папа никому не нужен. Если начнется одобрение/неодобрение, то начнутся нехорошие вещи:
1. Если разработчик, ведущий ревью, по рангу не выше, то неодобряя код может напороться на серьезное сопротивление.
2. Если нужно одобрение и не выполняется пункт 1, то тогда появляется некий папа, который ревьювит код и разрешает комитить.
Во втором случае не происходит обмена знаниями о коде, о частях системы. Поэтому ревью проводится не для одобрений на основе которых делаются выводы о комите. Ревью кода — это другие разработчики проводят, желательно, не близко связанные с этим участком. Тогда они вдумчиво читая, находят до 90 процентов багов. Даже юнит-тесты меньший процент дают. Далее, они действительно сохраняют комментарии в документе по поводу читаемых и нечитаемых мест. Что очень полезно разработчику, который писал код. Он может не обратить внимания на ревью или доказывать, что считает, что его код правильно написан. Но тем не менее, информация для него полезная и может принять к сведению.
Главная польза — уменьшение багов. Вторая по значимости — передача знаний. В парном программировании ревью тоже те же цели преследует, но оно идет постоянно. И пары меняются. Тогда знания о коде распространяются и почти любой может залезть в любое место и разобраться, порефакторить, если что.
Класс пустой — на вырост. Это просто декларация, что это объект и он другой, отличается от любого другого.
В общем, задача такая. Можно класс. Можно энам сразу было возвращать. Но я не хотел уже так всем голову морочить.
Писать пустой класс, я тоже часто пишу. Допустим, я знаю, что буду работать с неким объектом. Но мне надо написать некие алгоритмы работы с ним (позже они могут перенестись в него самого, а он стать базовым и т.д.).
Но пока, создал пустой класс и ни о чем не думаю, просто оперирую им. Я не думаю в этот момент, как его будут использовать. Потом, в другой задаче об этом буду думать. Таким образом я всегда смотрю на код как-то локально.
Конечно, тут очень надуманная задача. Если нет ГУИ и совершенно не объясняется, что с объектом делает конечный пользователь, то и делать ничего не надо. Обычно требования пляшут оттуда. Но мне хотелось показать принцип, как размышлять. А не вообще все нюансы.
Объект, в котором внутри перечисление всего лишь — это способ такой упрощенной упаковки типов и не создавания наследников. Как только они станут нужны, тогда и появятся. При этом не факт, что перечисление исчезнет. Оно часто используется и далее.
Пустой класс хлеб — вполне нормально. Если у него нет поведения пока по требованиям.
Я иногда и пустые интерфейсы пишу. Зачем? Чтобы знать, что класс его поддерживает.
Это конечно, редко и скорее всего не нужно. Но это на «вырост». Добавляются потом какие-то методы и т.д.
Так и с хлебом. Надо начинать развивать проект с чего-то? Есть хлеб, как класс, как сущность, которая отличается от других, но ПОКА не имеет ни состояния, ни поведения. А угадывать наперед я не хочу. И пока концентрируюсь на том, как закодить работу с этим объектом, а не что он делает. Это позволяет по частям развивать архитектуру.
switch и if-else не так плохи сами по себе. Тут тоже расчитывать надо баланс. Если любые ветвления заменять виртуальными методами, то ничего хорошего не получится. Код будет не читаем. Будет много классов, да еще скорее всего в разных файлах. И чтобы понять, каким образом происходит выбор, придется долго в код смотреть, переключать страницы. При небольшом количестве елементов в switch — может быть гораздо лучшим решением. Смотрите на метод и пытаетесь понять, насколько легко читается. Если легче будут уже классы — переходите на классы. Как промежуточный вариант, можно структурами данных моделировать — Dictionary<>
«Будь просто хорошим человеком, не мешай нам и мы простим твою тупость. А лучше вымри»
Встречаю эту тему в третий раз.
Легко представить, как через некоторое время родители начнут поднимать волну возмущения, чтобы учителя не мучили детей в школе, уменьшали часы математики.
А некоторые люди чувствуют вообще пытки при мысли об уборке квартиры. Или приготовлении пищи.
Лучше бы на себе провели исследование, с какой болью они утром сталкиваются при мысли, что надо проснуться и пойти на работу.
«Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.»
Что есть «несущественные стороны»? Это субъективно не важные характеристики. «Не важные» — это зависит от целей человека и целей его моделирования. Например, бумажная модель будущего дома в точности показывает пропорции и возможно цвета поверхностей. Но материал и размеры не важны, поэтому размер маленький, а модель из бумаги, а не бетона.
По сути можно всегда выделять из потока информации существенную информацию и шум. Поиск существенной информации — это и есть в какой-то мере абстрагирование. Поиск аналитической формулы, наиболее точно описывающей набор точек, называют задачей регрессии. Т.е. такая формула — это сжатое представление набора точек. Грубо говоря, формулу передать можно меньшим числом байт.
Это только один из вариантов моделей поиска закономерностей. Все другие практически делают то же самое. Ищут существенное, что можно передать меньшим числом байт, возможно с потерей точности. Что делает нейронная сеть? Она переводит большое разнообразие точек в намного меньшее количество информации, хранящееся в ее весах, когда она обучится. При этом, если выбрать большую, чем требуется нейронную сеть (с бОльшим количеством нейронов и весов, то такая сеть может «переобучиться» — т.е. обучиться шумам. И тогда на новых данных, которых не было на этапе обучения, она будет показывать плохую точность.
Преобразование Фурье? То же самое. Сложную кривую превращает в ряд коэффициентов. И чем их меньше, тем больше «сглаживание». Название метода «сокращения длины описаний» говорит сам за себя.
То, что описал в этой статье Натан Марц — это его интуитивное понимание и аналогии. Как работает ТДД? Где-то так же: сначала «чтобы было», на второй фазе — рефакторинг — т.е. сокращение описания (вынесение в базовые классы и т.д.), наведение «красоты» (избавление от магических чисел, например). Ну и тесты перед этим, чтобы задать ограничения.
Что является в его понимании страданием? Это по сути YAGNI. Т.е. страдания — это способ оценки что действительно важно, а что нет. То, без чего можно обойтись — не делают. Я, например, интуитивно использую другую аналогию. Каждая строчка кода — зло, программирование — зло, и красоты нет в этом процессе. Т.е. использую принцип сопротивления написанию кода. И тогда оценка качества кода сводится не к выбору лучшего решения, а выбору наименее худшего.
В общем, всё — одно и то же
Всё классно работало, но через неделю обнаружил интересный факт. Копия массива всё же делалась. Потому что, как оказалось позже, мне понадобился в другом месте исходный, неподпорченный массив.
Вроде бы казалось, оптимизацию я провел недорогую по времени и простую. Но она совершенно не нужна, усложняет в итоге значительно метод и мало того, она замедляет в конечном счете выполнение. Т.к. копия всё равно уже есть, извращаться не нужно.
Любая оптимизация заранее — зло. Даже недорогая. Оптимизировать нужно только ботлнеки. А где они будут, выяснить можно только замерами.
Если пишете как можно проще, значит кода меньше. Значит менее болезненно и без нащупывания будет изменять, добавлять и т.д.
Если пишете используя DRY, то значит ни код, ни данные не повторяются. Значит, например, кеширование делать потом будет совсем не болезненно. Не надо искать разные места и синхронизировать.
Где-то так.
Но вообще их делать и не пользоваться реляционными в общем случае — совсем не гуд. Создавая такие мелкие свои СУБД я уже давно осознал, какое это благо пользоваться готовыми. Для моделирования, для бизнес-задач, пока ничего лучше не придумали. Брать NoSQL-льные базы для таких задач — ну прямо зло. Это огрызки реляционных баз данных по функционалу.
Вы так боитесь за оптимальность работы вашего приложения? Любая оптимизация (абсолютно) до написания кода является преждевременной. Думать об оптимальности до получения продукта — самое большее зло, которое можно придумать.
Реляционные БД во-первых очень оптимальные, над ними работают много людей. Неглупых. Во-вторых они строгие. Декларативно можно большую половину работы с данными описать. А что важнее правильности работы программы и надежности? Оптимальность, повторю, на двадцать пятом месте. Неприятно, что программисты почему-то считают оптимальность своих программ большим достоинством. Это что-то психологическое.
Плюсуем к плюсам еще скорость разработки — и видим большой профит.
О будущем.
1. Алгоритмы работы с данными — это в первую очередь связано с архитектурой машины. Оптимизация алгоритмов на данный момент происходит в несколько шагов и главная особенность, связанна с машиной — это маленькая и дорогая ОЗУ (энергозависимая) и большой медленный винт. То, что происходит в памяти, происходит значительно быстрее. Поэтому одна из задач оптимизации — загрузить по полной процессор и почти по полной память, но не выйти в своп. Из этого алгоритмы усложняются. Большие объемы данных начинают бить на куски и т.д.
Все знают об этом узком месте. И работы ведутся. Насколько я знаю, уже есть способы хранить энергонезависимо данные со скоростью обращения к ним заметно превышающую скорость обращения к текущей ОЗУ. Ведутся исследования и испытания по доработке, чтобы это попало в производство. Думаю, в районе 5-10 лет такое произойдет.
А как только это произойдет, сам подход к алгоритмам и их оптимизациям изменится.
2. Очевидно, что алгоритмы также связаны с моделью работы с памятью. Базы данных — это одно из важнейших направлений в разработке. И я не удивлюсь, если в скором времени придумают железные решения для реляционных СУБД. Т.к. они себя хорошо зарекомендовали в течении многих лет.
Также я не считаю прямо идеалом реляционные СУБД. Но они явно лучше многих вещей. Например, писать на шарпе или джаве гораздо опаснее и менее лаконично, чем на SQL. Возможно, в скором будущем придумают модель получше реляционной. Доработают ее.
Но взять и отказаться в пользу NoSQL-льных огрызков… Почему это огрызки. Реляционная СУБД позволяем матипулировать данными в разных направлениях, как захотите. Поддерживает фильр, сортировку, группировку по любым колонкам и джойны.
Древовидная база будет сильно оптимально заточена под джойны, с учетом если угадали, как эти джойны будут происходить. Как только нужно будет делать непредусмотренные джойны — приехали. То же с группировкой.
А программисты, хвалящие NoSQL базы, может быть думают, что будут только гуглы и фейсбуки создавать? Размечтались. )))
Да, объем данных будет расти. Но и железо будет расти. Возможно, реляционные СУБД как раз станут не медленнее всяких NoSQL. Во вторых, на очень больших объемах данных, обычно, операционная деятельность не ведется. Большие объемы нужны для аналитики. Там и БД другие. Нереляционные. Олапы и всякое другое.
Требования не даются просто заказчиком без обсуждения. Я вообще противник любых лишних звеньев, вроде пиэмов, системных аналитиков, которые препятствуют прямому общению с заказчиком. Требования идут от заказчика, но не так: я сказал, а вы делайте как хотите. Это всё, по нормальному, происходит в процессе общения. Дело в том, что заказчик знает свою предметную область. Программист знает языки программирования. Но в общении с заказчиком рождается нечто новое — новый язык, новые термины. И мы, программисты, с нашей точки зрения, называем именно это предметной областью. И мы ее моделируем. Так вот эта предметная область — это новый язык, который на стыке «наук» появляется. Программисту нужна связь, не только к нему, но и от него.
Потому что, как я в статье показал, буквально, код — это перевод требований на язык программирования. Это лингвистическая по сути вещь. «Предметную область» не могут родить в общении с заказчиком люди, не имеющие отношение к программированию или даже не знающее именно того языка, на котором разработка ведется.
А в процессе общения с заказчиком программист не пассивен. Он может предлагать дополнительные варианты. Потому что ему код даже может подсказывать, какие еще интересные абстракции получаются. Возможно, заказчик и не подозревает, что такое можно сделать.
А про хлеб. Ну, я ж брал пример статьи о Борисе и Маркусе. Какие были требования, так и переписал. Потом, в задачу статьи не входило объяснение, как вести переговоры. Да и это, скорее всего, не формализируется. А вот, когда требования сформированы — тут уже хорошо происходит формализация. На требования, даже пишут тесты. Таким образом, для заказчика, процесс разработки выглядит как черный ящик. Он, общаясь утвердил некоторые требования. Которые четко зафиксированы в документе. А на по окончанию, даже не проекта, а допустим небольшого этапа, спринта, он получает продукт, который в точности удовлетворяет записанным требованиям и это доказано автоматическими тестами. Ну и презентацию можно сделать, показать вручную прохождение тестов.
Но мне один класс кажется проще. Потому что действительно, хлеб задуман сразу один и печка одна. Плодить классы мне кажется нецелесообразно было бы.
Потом, это упрощение наследования, на данном этапе. Ведь полиморфизм можно организовать далеко не только виртуальными методами. Есть некоторый маркер типа и вы можете, например, выставлять наружу свойства-делегаты и подменять в зависимости от маркера типа.
Но когда еще нет поведения, то остается просто маркер типа.
Пример очень утрирован. Я его взял с предыдущей статьи другого человека. Понятное дело, многое пришлось за уши притягивать. Ваши требования для игры, возможно интереснее. Но статья получилась по ним бы гораздо объемнее.
Программист — это самурай проекта, а не самурай заказчика или денег или начальства. Программист болеет ТОЛЬКО за проект. И грош цена такому профессионалу, если он через это перешагивает. Вы, допустим, заказчик. Вы бы согласились нанять подлизу, который пытается вам угодить на словах, а пишет говнокод?
Не со всеми заказчиками надо работать. Их много. Можно выбирать поадекватнее. Потому что бывают заказчики, которые вообще не хотят формулировать, что они хотят. И ведут себя как барины: я вам денег плачу, вы обязаны сделать мне хорошо, а как — сами придумайте.
Ягни — это глубокая философия, как НАДО развиваться проекту. Это серьезная практика. Работа с кодом, умение оценивать, преобразовывать информацию.
При этом, конечно, должно быть и прямое общение с заказчиком. Никто не мешает программисту предлагать некоторые пути развития проекта с т.з. требований. Только в общении рождаются требования. И программист тоже может придумывать требования. Но только ОБЯЗАТЕЛЬНО их обсуждать с заказчиком, а не делать и строить из себя фокусника. Делать он может только то, что утверждено в обсуждении с заказчиком.
Этот ягни — глубокая философия. Он позволяет писать очень качественно, быстро. Позволяет не сломаться проекту при любых требованиях. И позволяет оценивать по настоящему что нужно, а что нет. Кто это не совсем понимает, тот никогда вообще адекватных архитектур не делал. Просто у таких не будет меры и оценки, что правильно, а что нет. В большинстве случаев, те, кто «проектируют наперед» — не проектируют ВООБЩЕ. У них критерии «красиво» (прямо как бабы на лугу, усюсюкаются ))), или «гибко» (ацки плохой критерий). Больше нет критерия, кроме «кажется».
Со мной пару раз была такая странная вещь. Как-то неожиданно я становился на день приблизительно в разы умнее. Как попадать в это состояние, не знаю. Само собой произвольно происходило.
И хотя я занимаюсь иногда довольно сложной деятельностью (не всегда), но в тех случаях был очевидный прорыв. Первый раз на сложном функциональном языке работал, так я тогда смог писать код, который создает код, который выполняется. До сих пор жутковато так программировать. Язык тот был write-only, крайне тяжело читаемый. И писать на нем сложно. Хотя эффективно. Но писать код, который создает код на нем же — ацкая вещь. А тогда у меня была ясность мышления в разы больше и я спокойно писал, никак не боясь ошибиться и особо и не проверял код, был уверен, что всё верно.
Второй раз, я уже на шарпе работал и уже второй год поддерживал легаси код. Он был плохой. Но когда снова такая ясность образовалась, я вдруг увидел кучу ошибок и начал править, с которыми два года сосуществовал.
Наверное, предел есть. Но очень хочется быть умнее уже сейчас. Хотя бы на немного.
Сильно сомневаюсь. По себе знаю. В нашей западной культуре никогда и не было на самом деле тренировок. Обучение математике с ранних лет, конечно, дает свой эффект. Но далеко не факт, что это лучший способ. Тренировки на принципе повторения того, к чему готовитесь, не всегда эффективны.
Основная проблема, по-моему, — это сложность концентрации. Ум прыгает с мысли на мысли, у него они роятся. Из-за этого теряется ясность понимания задачи, ясность представления. А эта штука, вообще-то, легко тренируется.
Но в статье я всего лишь один срез показывал — ничего не делать без подтверждения заказчика. И это верно. Другое дело — вы не пассивны в общении с заказчиком. Там даже небольшой пример есть «вступаем в полемику».
Общение с заказчиком и «кристаллизация» требований не рассматривались. Заказчик не всегда может родить требования. И для этого существует общение. Можно вступать в спор, «полемику». Но только то, что после этого «утверждено» заказчиком, то и реализовывается. Если заказчик сильно отказывается, когда вам нужны уточнения — то тогда, я бы посоветовал с ним прощаться. Видимо он неадекватный. Обычно, заказчики заинтересованы в конечном результате, и поэтому в объяснению своих желаний тоже.
Есть вариант, что заказчик не в курсе обо всех тенденциях и нельзя от него получить какую-то конкретику по каким-то направлениям. Тогда можете реализовывать любое. Так же, как в статье — какой-то взвешенный алгоритм наименьших квадратов. Заказчик может быть вообще даже и близко не в теме. Но тем не менее, есть возможность реализовать что-то, а потом спрашивать уточнение. Это что-то вроде рабочей заглушки. Но надо помнить, что это заглушка. И потом уточнить, даже если заказчика устраивает.
Коллективное владение кода — не только декларация. Если один человек пишет код одной части, а другой разработчик никогда в него не заглядывал, то даже если дать ему возможность там править, он скорее всего пойдет к первому и попытается делегировать работу.
Ревью кода, в моем понимании, — это далеко не одобрение. На одобрение можно ложить с прибором. Считаем, что коллектив взрослый и папа никому не нужен. Если начнется одобрение/неодобрение, то начнутся нехорошие вещи:
1. Если разработчик, ведущий ревью, по рангу не выше, то неодобряя код может напороться на серьезное сопротивление.
2. Если нужно одобрение и не выполняется пункт 1, то тогда появляется некий папа, который ревьювит код и разрешает комитить.
Во втором случае не происходит обмена знаниями о коде, о частях системы. Поэтому ревью проводится не для одобрений на основе которых делаются выводы о комите. Ревью кода — это другие разработчики проводят, желательно, не близко связанные с этим участком. Тогда они вдумчиво читая, находят до 90 процентов багов. Даже юнит-тесты меньший процент дают. Далее, они действительно сохраняют комментарии в документе по поводу читаемых и нечитаемых мест. Что очень полезно разработчику, который писал код. Он может не обратить внимания на ревью или доказывать, что считает, что его код правильно написан. Но тем не менее, информация для него полезная и может принять к сведению.
Главная польза — уменьшение багов. Вторая по значимости — передача знаний. В парном программировании ревью тоже те же цели преследует, но оно идет постоянно. И пары меняются. Тогда знания о коде распространяются и почти любой может залезть в любое место и разобраться, порефакторить, если что.
В общем, задача такая. Можно класс. Можно энам сразу было возвращать. Но я не хотел уже так всем голову морочить.
Писать пустой класс, я тоже часто пишу. Допустим, я знаю, что буду работать с неким объектом. Но мне надо написать некие алгоритмы работы с ним (позже они могут перенестись в него самого, а он стать базовым и т.д.).
Но пока, создал пустой класс и ни о чем не думаю, просто оперирую им. Я не думаю в этот момент, как его будут использовать. Потом, в другой задаче об этом буду думать. Таким образом я всегда смотрю на код как-то локально.
Конечно, тут очень надуманная задача. Если нет ГУИ и совершенно не объясняется, что с объектом делает конечный пользователь, то и делать ничего не надо. Обычно требования пляшут оттуда. Но мне хотелось показать принцип, как размышлять. А не вообще все нюансы.
Объект, в котором внутри перечисление всего лишь — это способ такой упрощенной упаковки типов и не создавания наследников. Как только они станут нужны, тогда и появятся. При этом не факт, что перечисление исчезнет. Оно часто используется и далее.
Я иногда и пустые интерфейсы пишу. Зачем? Чтобы знать, что класс его поддерживает.
Это конечно, редко и скорее всего не нужно. Но это на «вырост». Добавляются потом какие-то методы и т.д.
Так и с хлебом. Надо начинать развивать проект с чего-то? Есть хлеб, как класс, как сущность, которая отличается от других, но ПОКА не имеет ни состояния, ни поведения. А угадывать наперед я не хочу. И пока концентрируюсь на том, как закодить работу с этим объектом, а не что он делает. Это позволяет по частям развивать архитектуру.
switch и if-else не так плохи сами по себе. Тут тоже расчитывать надо баланс. Если любые ветвления заменять виртуальными методами, то ничего хорошего не получится. Код будет не читаем. Будет много классов, да еще скорее всего в разных файлах. И чтобы понять, каким образом происходит выбор, придется долго в код смотреть, переключать страницы. При небольшом количестве елементов в switch — может быть гораздо лучшим решением. Смотрите на метод и пытаетесь понять, насколько легко читается. Если легче будут уже классы — переходите на классы. Как промежуточный вариант, можно структурами данных моделировать — Dictionary<>