Чем меньше архитектуры, тем лучше [из Хочу заделаться говно-кодером]
Чем меньше архитектуры, тем лучше. Это напрямую следует из определения термина "архитектура".а можно услышать это определение. а то как-то сомнительно звучит.
Архитекту́ра, или зо́дчество— искусство и наука строить, проектироватьздания и сооруженияпрограммы и информационные системы (включая их комплексы а также сама совокупностьзданий и сооруженийпрограмм и информациионых систем, создающих программную среду для жизни и деятельности человека. В архитектуре взаимосвязаны функциональные (назначение, польза технические (прочность, долговечность) и эстетические (красота) свойства объектов.
Чем меньше архитектуры, тем лучше. Это напрямую следует из определения термина "архитектура".Давай, расскажи мне как ты без предварительного проектирования напишешь сколько-нибудь сложный программный продукт. К примеру, логический движок походовой игры на дискретном поле с поддержкой до 10 игроков (опустим движок рендеринга и сетевой код) и настраиваемыми логическими правилами (правила могут меняться без перекомпиляции проекта, желательно, вообще на лету без перезапуска игры)
а можно услышать это определениеВот у Фаулера:
Архитектура
Одно из странных свойств, присущих индустрии программного обеспечения, связано с тем, что какой-либо термин может иметь множество противоречивых толкований. Ве¬роятно, наиболее многострадальным оказалось понятие архитектура (architecture). Мне кажется, оно принадлежит к числу тех нарочито эффектных слов, которые употребляют¬ся преимущественно для обозначения чего-то, считающегося значительным и серьез¬ным. (Нет, я слишком прагматичен, чтобы цинично пользоваться этим фактом, стараясь привлечь внимание читающей публики.:—
Термин "архитектура" пытаются трактовать все, кому не лень, и всяк на свой лад. Впрочем, можно назвать два общих варианта. Первый связан с разделением системы на наиболее крупные составные части; во втором случае имеются в виду некие конструктивные решения, которые после их принятия с трудом поддаются изменению. Также рас¬тет понимание того, что существует более одного способа описания архитектуры и сте-пень важности каждого из них меняется в продолжение жизненного цикла системы.
Время от времени Ралф Джонсон (Ralph Johnson участвуя в списке рассылки, от¬правлял туда замечательные сообщения, одно из которых, касающееся проблем архитек¬туры, совпало с периодом завершения мною чернового варианта книги. В этом сообще¬нии он подтвердил мое мнение о том, что архитектура— весьма субъективное понятие. В лучшем случае оно отображает общую точку зрения команды разработчиков на резуль¬таты проектирования системы. Обычно это согласие в вопросе идентификации главных компонентов системы и способов их взаимодействия, а также выбор таких решений, которые интерпретируются как основополагающие и не подлежащие изменению в будущем. Если позже оказывается, что нечто изменить легче, чем казалось вначале, это "нечто" легко исключается из "архитектурной" категории.
Мартин Фаулер, Архитектура корпоративных программных приложений
Чем меньше решений, которые нельзя менять в будущем, тем лучше. Отсюда получаем, что чем меньше архитектуры, тем лучше.
Давай, расскажи мне как ты без предварительного проектирования напишешь сколько-нибудь сложный программный продукт. К примеру, логический движок походовой игры на дискретном поле с поддержкой до 10 игроков (опустим движок рендеринга и сетевой код) и настраиваемыми логическими правилами (правила могут меняться без перекомпиляции проекта, желательно, вообще на лету без перезапуска игры)Запускаешь Visual Studio с ReSharper-ом и работаешь над кодом.
Чем меньше решений, которые нельзя менять в будущем, тем лучше. Отсюда получаем, что чем меньше архитектуры, тем лучше.ты читаешь слова
чего?
Запускаешь Visual Studio с ReSharper-ом и работаешь над кодом.давай, с чего ты начнешь?
студия за тебя уже напишет
int main(...) { return 0; }
продолжу за шурика
from BestPractices import ControllableQuery
давай, с чего ты начнешь?С выяснения что видит пользователь и как взаимодействует с игрой.
Чем меньше решений, которые нельзя менять в будущем, тем лучше. Отсюда получаем, что чем меньше архитектуры, тем лучше.хорошо, что ты привел цитату, так яснее видно, что ты ее не понял
архитектура - это когда в одних местах прибито гвоздями, а в других есть свобода.
хорошая архитектура - это когда прибито там, где не нужно будет чему-то меняться в будущем, а свобода и гибкость оставлена в тех местах, где с легкостью вкрячиваются новые фичи и масштабируется система в целом
выражение "меньше архитектуры" вообще малоосмысленно, но я его понимаю так, что "меньше архитектурных решений". так вот и свобода и ограничения являются "решениями".
декомпозиция системы, подходы к решению проблем, словарь в области решения - все это часть архитектуры
это когда прибито там, где не нужно будет чему-то меняться в будущем, а свобода и гибкость оставлена в тех местах, где с легкостью вкрячиваются новые фичи и масштабируется системаВ будущем может поменяться всё, чем меньше прибито, тем лучше.
В будущем может поменяться всёэто неверно, корень овердизайнов
чем меньше прибито, тем лучшея с этим лично не согласен
это неверно, корень овердизайновя говорю про то, что дизайна надо меньше, ты мне отвечаешь про овердизайн, где последовательность и логика?
я с этим лично не согласенЭто жизнь, с ней не поспоришь.
я говорю про то, что дизайна надо меньше, ты мне отвечаешь про овердизайн, где последовательность и логика?да ты же демагог!
да ты же демагог!Подозреваю, что ты просто не в курсе современных инструментов программирования. Твои воззрения похожи на воззрения 60-летнего.
Подозреваю, что ты просто не в курсе современных инструментов программирования.так и есть.
подкинь плиз ссылочек и ключевых слов, я почитал бы
мне даже не ловко, ReSharper же
мне даже не ловко, ReSharper жевау, теперь я в тренде
У тебя секретная бета-версия решарпера, которая помогает избавиться от архитектуры в приложении? 
С выяснения что видит пользователь и как взаимодействует с игрой.это компонент, пользователь - другой компонент
ну так вот, нету описания API, ты его сам должен написать
все известные требования я тебе уже написал:
походовая игра на дискретном поле
список участвующих сущностей - неизвестно, но можно предположить в общем случае: поле, объект поля, юнит, игрок. В будущем могут добавиться новые сущности или могут измениться текущие.
правила взаимодействия сущностей - задаются извне в виде неких скриптов
в каждый ход действия совершает 1 игрок
покажи мне, куда в решарпере забить это описание, чтобы он мне код нагенерил
Фаулер здесь не прав. Он подменяет общее понятие архитектуры - понятием жесткой архитектуры.
Архитектура - это принятые решения об устройстве кода, которые не пересматриваются без серьезных на то оснований.
Один из признаков хорошей архитектуры - это: когда код с минимальными усилиями реорганизуется в том числе и под изменение архитектурных решений.
В этом как раз неудачность понимания Фаулера - в его определении архитектура хорошей не бывает.
ps
Выбор языка, выбор используемых языковых конструкций, выбор используемых библиотек, выбор стиля написания кода, выбор способа декомпозиции кода - это всё архитектурные решения.
Решения о том, что приложение хранит данные в реляционной базе, а для доступа к БД используется plain-sql - это всё архитектурные решения.
Даже твои решения, что в твоем приложении не будет использоваться MVC, MVVM и т.д. - это всё тоже архитектурные решения. Что состояние будет хранится в ui-элементах - это тоже архитектурное решение.
То, что код пишется под активное использование ReSharper-а - это тоже архитектурное решение.
Существенное отличие архитектурных решений от других решений - что они считаются непоколебимыми длительное время, Т.е. не происходит так, что в понедельник принимается решение - что пишется на C#, в среду на C++, а в пятницу - на Java. Во вторник считается что данные будут хранится в реляционке, в четверг - в nosql, а в выходные - на прямую на диске, а на следующей неделе - все эти метания по новой.
Второе важное следствие, что на основе архитектурных решений принимаются последующие решения. Это и тянет за собой жесткость архитектуры в той или иной степени - теперь при изменении основополающих решений приходится пересмотреть и все решения, которые на него опирались.
Архитектура - это принятые решения об устройстве кода, которые не пересматриваются без серьезных на то оснований.
Один из признаков хорошей архитектуры - это: когда код с минимальными усилиями реорганизуется в том числе и под изменение архитектурных решений.
В этом как раз неудачность понимания Фаулера - в его определении архитектура хорошей не бывает.
ps
Выбор языка, выбор используемых языковых конструкций, выбор используемых библиотек, выбор стиля написания кода, выбор способа декомпозиции кода - это всё архитектурные решения.
Решения о том, что приложение хранит данные в реляционной базе, а для доступа к БД используется plain-sql - это всё архитектурные решения.
Даже твои решения, что в твоем приложении не будет использоваться MVC, MVVM и т.д. - это всё тоже архитектурные решения. Что состояние будет хранится в ui-элементах - это тоже архитектурное решение.
То, что код пишется под активное использование ReSharper-а - это тоже архитектурное решение.
Существенное отличие архитектурных решений от других решений - что они считаются непоколебимыми длительное время, Т.е. не происходит так, что в понедельник принимается решение - что пишется на C#, в среду на C++, а в пятницу - на Java. Во вторник считается что данные будут хранится в реляционке, в четверг - в nosql, а в выходные - на прямую на диске, а на следующей неделе - все эти метания по новой.
Второе важное следствие, что на основе архитектурных решений принимаются последующие решения. Это и тянет за собой жесткость архитектуры в той или иной степени - теперь при изменении основополающих решений приходится пересмотреть и все решения, которые на него опирались.
ох, ну кто выполнил саммон шурика?
все известные требования я тебе уже написал:что заказчикам или хотя бы тестировщикам отдадим?
походовая игра на дискретном поле
список участвующих сущностей - неизвестно, но можно предположить в общем случае: поле, объект поля, юнит, игрок. В будущем могут добавиться новые сущности или могут измениться текущие.
правила взаимодействия сущностей - задаются извне в виде неких скриптов
в каждый ход действия совершает 1 игрок
что заказчикам или хотя бы тестировщикам отдадим?готовый компонент (в виде библиотеки + документация)
А заказчики заказали игру или компонент? :-)
Вообще, я согласен с Шуриком, на тему того, что чем меньше жестко прибитых гвоздями вещами - тем лучше, однако считаю, как и писалось выше, однако. Однако - жизнь, штука злая - и над кодом работают разные люди, разной квалификации. И если проект развивается достаточно долго, у него есть два варианта развития:
1. Он остается консистентным - разные части проекта написано единообразно, программисты приходят, уходят, но они могут продолжать работать над проектом. И мера и причина этой консистентности и будет являться архитектурой данного проекта.
2. Консистентность не является основным приоритетом. Тогда рано или поздно программисты напарываются на то, что консистентность стало поддерживать слишком дорого (проект разросся, новые требования выбились из старых предположений, старые вещи никто не переписывал, ибо архитектура не нужна и их, блин, слишком дохрена) - и получаются разные модули одного проекта написаны разным языком. И это существенно замедляет работу новых программистов, отрицает знания одним программистом многих модулей сразу и много чего еще.
В общем этот путь, на мой взгляд, может сработать, только когда проект не успеет напороться на эту стадию - то есть не более, чем среднего размера. А в проектах малого размера даже, вероятно, будет плюсом то, что каждая задача решается оптимальным для нее образом, не под влиянием жестких рамок.
Вообще, я согласен с Шуриком, на тему того, что чем меньше жестко прибитых гвоздями вещами - тем лучше, однако считаю, как и писалось выше, однако. Однако - жизнь, штука злая - и над кодом работают разные люди, разной квалификации. И если проект развивается достаточно долго, у него есть два варианта развития:
1. Он остается консистентным - разные части проекта написано единообразно, программисты приходят, уходят, но они могут продолжать работать над проектом. И мера и причина этой консистентности и будет являться архитектурой данного проекта.
2. Консистентность не является основным приоритетом. Тогда рано или поздно программисты напарываются на то, что консистентность стало поддерживать слишком дорого (проект разросся, новые требования выбились из старых предположений, старые вещи никто не переписывал, ибо архитектура не нужна и их, блин, слишком дохрена) - и получаются разные модули одного проекта написаны разным языком. И это существенно замедляет работу новых программистов, отрицает знания одним программистом многих модулей сразу и много чего еще.
В общем этот путь, на мой взгляд, может сработать, только когда проект не успеет напороться на эту стадию - то есть не более, чем среднего размера. А в проектах малого размера даже, вероятно, будет плюсом то, что каждая задача решается оптимальным для нее образом, не под влиянием жестких рамок.
Однако - жизнь, штука злаяЖизнь — штука злая, и шурик говорит полную хуйню, и неясно, как это можно не понимать.
Код без какой-то архитектуры — это дао, выраженное словами: с одной стороны он легко изменяется под любую задачу, а с другой — в силу предыдущего пункта — представляет что-то вроде AbstractProblemFactoryConfig.java или даже скорее просто пустого диска. Или даже просто компьютера, чтобы не привязываться к диску. А вдруг разрабатываться и запускаться будем на мобилках или вообще МФУ? Точно, идеальный код без архитектуры — это пустой мозг
Архитектура программы — это как у скульптора, просто умение отсечь лишнее. Ты задаёшь какие-то граничные условия и благодаря этому не используешь AbstractAbstractAbstract. Если ты знаешь, что всегда будешь жить на T-SQL, тебе не надо будет придумывать какие-то костыли на случай, если вдруг захочется использовать мускуль или тем более sqlite. Если рёбра графов неотрицательные, ты можешь пользоваться Дейкстрой. Если ты пишешь программу без архитектуры, ты будешь пользоваться бесконечными фабриками и бесконечным конфигом, в котором на всякий случай надо задать, фон-неймановская ли у тебя архитектура и не возвращает ли системный вызов write(2) котика. В результате твой код, конечно, будет раздут, нечитаем, будет тормозить, потому что при поиске пути в графе ты на каждой итерации будешь проверять, не открылся ли вдруг телепорт в точку назначения, а заказчик выберет простую unix-way поделку, которая будет просто решать задачу за конечное время.
Архитектура же ограничивает, она говорит, что интерфейс — для мобилки, кнопку заказчик всегда нажимает руками, а не хуём, T-SQL на мобилке не работает, поэтому пользуемся только sqlite без хранимых процедур. Воздухом можно дышать, воду пить.
Ты задаёшь какие-то граничные условия и благодаря этому не используешь AbstractAbstractAbstract.А зачем вообще использовать AbstractAbstractAbstract, если архитектуры нет? Реализуешь Concrete1, Concrete2. Если вдруг оказалось, что они похожи - выносишь общее в суперкласс через небольшой рефакторинг и продолжаешь писать конкретный код.
А зачем вообще использовать AbstractAbstractAbstract, если архитектуры нет? Реализуешь Concrete1, Concrete2. Если вдруг оказалось, что они похожи - выносишь общее в суперкласс через небольшой рефакторинг и продолжаешь писать конкретный код.Пример AbstractAbstractAbstract — это не только фабрика НЁХ (хотя если какому-нибудь архитектурно независимому разработчику вдруг придёт в голову пресловутый переезд с MSSQL, хранимых процедур и расширенного языка запросов на sqlite и ANSI SQL, я с интересом посмотрю на твои пляски с заменой Concrete* это ещё и какой-нибудь волшебный костыль или метаязык, чтобы не завязываться, например, на C# или вообще .NET — это ведь тоже часть архитектуры.
В реальном мире конечно люди думают, что окей, мы это всё напишем на С++, а если упрёмся в производительность, отдельный куски перепишем на ассемблерных вставках, поэтому можно в принципе не париться о том, что с нами кто-то захочет линковаться из Си или ещё каких языков. Но у чуваков «без архитектуры» таких серьёзных ограничений быть не должно, ты всегда должен быть готов быть вызванным функцией на фортране77 и прологе, и сам исполнить десяток ассемблерных инструкций для MIPS. Хотя это я конечно переборщил, в мире шурика за пределами решарпера жизни нет.
Вместо архитектуры можно привязаться к средствам разработки. Ну банально взять набор <Program Name/> и говорить, что мы будем писать на всём, что поддерживается им, поддержкой называем способность компилить, дебагать, подсвечивать синтаксис. И всё.
Вместо архитектуры можно привязаться к средствам разработкиэто не замена архитектуры чем-то принципиально другим, это и есть архитектура - изменить твое решение и начать использовать $OTHER_PROGRAM вместо $PROGRAM будет сложно.
Причем в контексте изначального треда, архитектор — это же целая профессия. Т.е. человек изо дня в день будет приходить на работу, и что он будет делать, чем заниматься? Выбирать целыми днями платформу и IDE?
Это делегация всех вопросов архитектуры доверенному разработчику программного пакета. Если он включит новый язык в поставку, то и мы включаем его в спектр допустимых решений.
архитектор - это роль на проекте, выполнять её может человек с любой должностью, в твоем случае ты сам выбираешь платформу => ты и есть архитектор.
конечно когда есть архитектор как должность - он обычно занимается несколькими проектами одновременно, причем большая часть работы во время старта проекта.
конечно когда есть архитектор как должность - он обычно занимается несколькими проектами одновременно, причем большая часть работы во время старта проекта.
Это делегация всех вопросов архитектуры доверенному разработчику программного пакета. Если он включит новый язык в поставку, то и мы включаем его в спектр допустимых решений.что ты будешь делать, когда потребуется достигнуть какого-нибудь нефункционального требования, а на выбранном программном пакете такое будет решаться _очень_ дорого и заказчик скажет искать другие способы решения?
конечно когда есть архитектор как должность - он обычно занимается несколькими проектами одновременно, причем большая часть работы во время старта проекта.Для этого нужен постоянный поток новых проектов. А это уже эльфизм.
Для этого нужен постоянный поток новых проектов. А это уже эльфизм.Я уверен что в 99% компаний, где численность программистов от 1000 человек есть постоянный поток новых проектов. Если же его нет, то в такой компании скорее всего не надо работать.
Не буду браться за проекты, которые не могу решить.
я с интересом посмотрю на твои пляски с заменой Concrete*Всё очень просто. Если Concrete* слишком разные, чтобы их можно было отрефакторить в наследника одного класса, значит этого не нужно делать. Нужно писать адаптер.
Не буду браться за проекты, которые не могу решить.ты можешь решить, но для этого нужно поменять архитектурное решение - отказаться от $PROGRAM1 в пользу $PROGRAM2
Я уверен что в 99% компаний, где численность программистов от 1000 человек есть постоянный поток новых проектов. Если же его нет, то в такой компании скорее всего не надо работать.в компания, где 1000 программистов, тонны легаси кода
и живут эти компании за счет именно этого кода
новые проекты если и есть, то их доля не так велика
ты точно эльф
в компания, где 1000 программистов, тонны легаси кодаOkay, поверю тебе, а не собственному опыту.
и живут эти компании за счет именно этого кода
новые проекты если и есть, то их доля не так велика
ты точно эльф
тонны легаси кодакстати, легаси код означает, что системы не переписывают раз в год, а поддерживают, а значит архитектура их такова, что поддерживать приложение дешевле, чем написать новое.
кстати, легаси код означает, что системы не переписывают раз в год, а поддерживают, а значит архитектура их такова, что поддерживать приложение дешевле, чем написать новое.Возвращаемся к вопросу, что тут делает архитектор?
Пусть за это берутся специалисты по $PROGRAM2 . Я за мировое распределение труда.
Возвращаемся к вопросу, что тут делает архитектор?а ты посчитай, сколько нужно новых проектов в год чтобы занять 1000 программистов, вот по моей прикидке: 1000 программистов -> 100 проектов -> если в среднем проект живет 10 лет -> 10 проектов в год.
конечно если архитектор приходит и говорит "мы используем инновационный контроллабл квери, сисярп и виндовс 10 потому что ничего больше не умеем", то ему будет мало работы, тут я согласен.
Пусть за это берутся специалисты по $PROGRAM2 . Я за мировое распределение труда.будешь сокращать своих специалистов в смежных областях (слабо связанных с $PROGRAM1)? хотя давай я угадаю - в твоей команде один человек и нет никакого планирования.
1000 программистов -> 100 проектов -> если в среднем проект живет 10 лет -> 10 проектов в год.
В итоге сколько нужно архитекторов на 1000 программистов? 1? На это я и намекаю.
ну это была очень грубая оценка снизу, в реальности думаю раз в 10 больше хотя бы.
Пусть за это берутся специалисты по $PROGRAM2кстати, как ты думаешь, кто должен дать оценку, что на $PROGRAM1 решение будет намного дороже, чем на $PROGRAM2?
Настолько далеко моё воображение не простирается.
Рынок. Специалист по PROGRAM1 знает сколько будет стоить реализация задачи на его любимом наборе технологий. Если предлагают больше денег, чем он думает будет работа, он соглашается, и, видимо, PROGRAM1 подходит хорошо для этой задачи. Если предлагают меньше его ожиданий, значит эту задачу лучше решит кто-нибудь другой.
Программистам мешают нормально кодить архитекторы, которые вечно предлагают нерабочие архитектуры.
Архитекторам мешают создавать идеальные архитектуры безздарные программисты, которые не могут ничего реализовать.
Архитекторам мешают создавать идеальные архитектуры безздарные программисты, которые не могут ничего реализовать.
Программистам мешают нормально кодить архитекторы, которые вечно предлагают нерабочие архитектуры.В нашей Вселенной реализовано нарушение симметрии — без архитекторов программное обеспечение создается, без программистов нельзя создать программное обеспечение.
Архитекторам мешают создавать идеальные архитектуры безздарные программисты, которые не могут ничего реализовать.
Нет никакого нарушения симметрии.
Каждый программист обладает свойством архитектора в той или иной степени.
Можно утверждать, что суммарный заряд программизма и архитектуризма всегда равен нулю.
Каждый программист обладает свойством архитектора в той или иной степени.
Можно утверждать, что суммарный заряд программизма и архитектуризма всегда равен нулю.
Каждый программист обладает свойством архитектора в той или иной степени.Это не противоречит моему утверждению. Еще раз убеждаюсь, что у тебя с логикой проблемы.
Программистам мешают нормально кодить архитекторы, которые вечно предлагают нерабочие архитектурыочевидно, что это плохие архитекторы.
Архитекторам мешают создавать идеальные архитектуры безздарные программисты, которые не могут ничего реализовать.1. идеальной архитектуры не бывает
2. уровень команды, необходимый для реализации проекта - тоже часть архитектуры, поэтому если архитектор придумал крутое техническое решение, но для его реализации невозможно найти достаточное количество специалистов нужной компетенции - это плохая архитектура.
В нашей Вселенной реализовано нарушение симметрии — без архитекторов программное обеспечение создается, без программистов нельзя создать программное обеспечение.архитектор может придумать такую архитектуру, что никакого программного обеспечения создавать вообще не надо будет.
Всё очень просто. Если Concrete* слишком разные, чтобы их можно было отрефакторить в наследника одного класса, значит этого не нужно делать. Нужно писать адаптер.Я на всякий случай поинтересуюсь: это архитектура или нет?
Для этого нужен постоянный поток новых проектов. А это уже эльфизм.Опять-таки интересно: те проекты, которые ты делаешь, развиваются? В них появляются новые фичи, модули? Или написал ControllableQuery и годами только фиксишь в нём баги?
Опять-таки интересно: те проекты, которые ты делаешь, развиваются? В них появляются новые фичи, модули? Или написал ControllableQuery и годами только фиксишь в нём баги?ControllableQuery именно для этого и был сделан, чтобы проекты было легко развивать.
В проектах, где для доступа к БД используется ControllableQuery, изменения в базу (и в соответствующие объекты и структуры данных) вносятся легко и без опасений.
Развитие проектов — это и есть цель ControllableQuery. Ты пытаешься критиковать, совсем не разобравшись в теме.
Развитие проектов — это и есть цель ControllableQuery. Ты пытаешься критиковать, совсем не разобравшись в теме.Попытка представить относительно тонкую прослойку общения с БД в большинстве приложений за смысл их существования и основную сложность - вызывает некоторое недоумение.
Вероятно, есть и такие проекты. Но есть и не такие. И их не то, чтобы мало.
Попытка представить относительно тонкую прослойку общения с БД в большинстве приложений за смысл их существования и основную сложность - вызывает некоторое недоумение.Не, не, я на общность не претендую. ControllableQuery касается только общения с БД. Для других областей есть другие инструменты, например, ReSharper. К тому же инструменты это только инструменты, сами они софт не пишут.
Не, не, я на общность не претендую. ControllableQuery касается только общения с БД. Для других областей есть другие инструменты, например, ReSharper. К тому же инструменты это только инструменты, сами они софт не пишут.Хорошо, я все-таки уточню - как ты относишься к тому, что проект должен находиться в более менее консистентном состоянии, для того, чтобы считаться контролируемым и предсказуемым?
И если ты с этим согласен - то можешь пояснить, как этого достигнуть без свода рекомендаций по организации кодовой базы, взаимодействия между модулями, организации модулей, разбиения по слоям (которое в совокупности и зовется архитектурой)?
P.S. - за решарпер я вам все-таки безбожно завидую >.<
Идеальная архитектура — это такая, в рамках которой самой последний говнокодер будет писать правильно и чисто.
Потому что она так построена, что он, сука, даже дернуться не может.
Потому что она так построена, что он, сука, даже дернуться не может.
ControllableQuery именно для этого и был сделан, чтобы проекты было легко развивать.Решение о том, что в проекте используется ControllableQuery - как по твоему, это архитектурное решение? Да или нет, и почему?
Решение о том, что в проекте используется ControllableQuery - это по твоему архитектурное решение?Насколько я успел понять шурика, есть вещи, которые являются не архитектурой, а откровением свыше, потому что «а как же иначе, без этого?!»: C#, Resharper, ControllableQuery. Это не архитектура, а концепция мироздания.
три кита программирования
Решение о том, что в проекте используется ControllableQuery - как по твоему, это архитектурное решение? Да или нет, и почему?Лично я не использую слово "архитектура", потому что нахожу его бесполезным и даже вредным.
Соответственно, у меня нет определение что такое “архитектура”.
Для ответа на твой вопрос могу принять за определение то, что написал Фаулер.
Поменять Controllable Query на ADO.NET довольно просто. Заменить на фрейворк, который SQL не использует, а использует свои языки запросов, тут уже сложнее. Переписывать SQL запросы на другой язык потребует большого участия человека. Получаем, что менять в некоторых направлениях легко в некоторых сложнее, т.е. по Фаулеру это, наверное, полуархитектурное решение.
Честно говорят, мне становится скучно от этого словоблудия. Это примерно как обсуждать паттерны.
Пацаны, расходимся, он просто замазаться боится и стесняется признать.
Шурик, не стесняйся, все делают это, не веришь — в лисе спроси!
Шурик, не стесняйся, все делают это, не веришь — в лисе спроси!
Лично я не использую слово "архитектура""Жопа есть, а слова нет!" (С)
Для ответа на твой вопрос могу принять за определение то, что написал Фаулер.Проблема в том, что Фаулер под архитектурой понимает какую-то хрень (по крайней мере в твоей цитате). А потом утверждает, что эту хрень делать не надо - с этим не поспоришь. Это безусловно верно: хрень делать не надо.
Но, если зайти с конструктивной стороны, то все остальные под архитектурой понимают иное. В широком смысле, любой набор решений о коде, который затрагивает большие объемы кода и не пересматривается длительное время; в более узком смысле - тоже самое, но уже не всякие решения, а только такие которые затрагивают организацию кода.
При широком использовании понятия архитектура - codestyle и т.д. входят в архитектуру, при узком - нет.
Называть же архитектурой только то, что мешает(!) изменять код - это какое-то ущербное толкование понятия архитектура.
взаимодействия между модулями, организации модулей, разбиения по слоямЯ готов обсуждать то, что есть в языке, на котором пишется проект. Нет межъязыкового понятий "модуль" и "слой". Например, в C# нет модулей и слоев. Я готов обсуждать типы (классы, структуры, интерфейсы методы, сборки, пространства имен.
Еще более важное это:
1. излишние использование mutable состояние;
2. излишние использование кастов;
3. излишние использование рефлекшена (без квазицитирования).
Как правило, при использовании фрейворков присутствует излишние использование всех трех пунктов. Например, в этот элементарном уже присутствуют 1-2 пункты.
Среди программистов часто встречается такое психологическое явление: начитаются "авторитетных" книжек и искренне думают, что так проекту будет лучше, а собственному не авторитетному анализу они не доверяют.
P.S. По поводу слоев вспомнил. До появления типизированного языка запросов в C# было такое понятие как data access layer. После появления LINQ это понятие уже история.
До появления типизированного языка запросов в C# было такое понятие как data access layer. После появления LINQ это понятие уже история.linq - это и есть data access layer. Он лишь стал прозрачнее и гибче.
linq - это и есть data access layer. Он лишь стал прозрачнее и гибче.слой исчез
>> linq - это и есть data access layer. Он лишь стал прозрачнее и гибче.
> слой исчез
Императивщики иногда такие забавные...
Это спор о "шаблонах проектирования:" в языках программирования,
где есть анонимные функции, весь этот идиотизм о "командах" и
т.п. "шаблонах" не нужен. С точки зрения фаната явы, знать эти
"шаблоны проектирования" очень важно, а с точки зрения зрения
разумного человека, вся польза заключается в умении собрать
велосипед руками. Что касается исчезновения, это вопрос о том,
считать ли ту часть вашего интерпретатора, которая занимается
этим вашим LINQ, "исчезнувшим" слоем или нет.
---
"Университет развивает все способности, в том числе и глупость."
> слой исчез
Императивщики иногда такие забавные...
Это спор о "шаблонах проектирования:" в языках программирования,
где есть анонимные функции, весь этот идиотизм о "командах" и
т.п. "шаблонах" не нужен. С точки зрения фаната явы, знать эти
"шаблоны проектирования" очень важно, а с точки зрения зрения
разумного человека, вся польза заключается в умении собрать
велосипед руками. Что касается исчезновения, это вопрос о том,
считать ли ту часть вашего интерпретатора, которая занимается
этим вашим LINQ, "исчезнувшим" слоем или нет.
---
"Университет развивает все способности, в том числе и глупость."
Что касается исчезновения, это вопрос о том,Этот слой теперь не нужно выписывать на каждом прикладном проекте. В этом смысле он исчез.
считать ли ту часть вашего интерпретатора, которая занимается
этим вашим LINQ, "исчезнувшим" слоем или нет.
Чем меньше нужно делать, тем лучше.
Если при этом еще и бабла платят, то вообще забок.
Если при этом еще и бабла платят, то вообще забок.
в языках программирования, где есть анонимные функцииК слову, если не требовать искаропки, сложно придумать язык программирования, где нет анонимных функций, мне кажется.
> К слову, если не требовать искаропки, сложно придумать язык
> программирования, где нет анонимных функций, мне кажется.
Что значит "если не требовать искаропки?"
Либо анонимные функции есть, либо их нет.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> программирования, где нет анонимных функций, мне кажется.
Что значит "если не требовать искаропки?"
Либо анонимные функции есть, либо их нет.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
питон
Либо их можно сделать.
"Нет" — это для тех, кто не может.
"Нет" — это для тех, кто не может.
питонформально в петоне они есть, правда, только однострочные, и больше одной операции туда не всунешь.
> Либо их можно сделать.
> "Нет" --- это для тех, кто не может.
"Можно сделать" это как раз "собери велосипед вручную,"
что мы и видим на примере явы. Собрать-то можно, просто в итоге
получается куча, в которой надо уметь распознавать анонимные
функции, если хочешь продолжать работать с этим кодом.
---
"История не учительница, она классная дама: сама она никого
и ничему не учит, но больно наказывает за невыученные уроки."
> "Нет" --- это для тех, кто не может.
"Можно сделать" это как раз "собери велосипед вручную,"
что мы и видим на примере явы. Собрать-то можно, просто в итоге
получается куча, в которой надо уметь распознавать анонимные
функции, если хочешь продолжать работать с этим кодом.
---
"История не учительница, она классная дама: сама она никого
и ничему не учит, но больно наказывает за невыученные уроки."
анонимная операция выходит уже
К слову, если не требовать искаропки, сложно придумать язык программирования, где нет анонимных функций, мне кажется.даже в си и паскале?
вообще, приведи пример языка, где их нет искаропки, но можно как-то реализовать руками анонимные функции.
чисто ради самообразования, может я чего не знаю.
анонимная операция выходит ужепишешь например map(lambda x: if x ... и обламываешься, потому что более чем однострочную конструкцию в лямбду не запихнешь.
они честно содрали из лиспа схему применения функций второго порядка, а она не ложится на синтаксис отступов.
вообще, питону сыграла злую шутку его быстрая популярность, которая практически заморозила откровенно сырой стандарт
пишешь например map(lambda x: if x ... и обламываешься, потому что более чем однострочную конструкцию в лямбду не запихнешь.А потом учишь язык еще немножко и пишешь map(lambda x: foo(x) if x else bar(x iter)
вообще, питону сыграла злую шутку его быстрая популярность, которая практически заморозила откровенно сырой стандартЧто такое "стандарт питона"?
Между первым релизом языка и его популярностью прошло лет 15, если что.
> вообще, приведи пример языка, где их нет искаропки, но можно
> как-то реализовать руками анонимные функции.
> чисто ради самообразования, может я чего не знаю.
"Как-то" всегда реализовать можно: достаточно вытащить анонимные
функции на верхний уровень, это превратит их в глобальные,
которые уже можно проименовать.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> как-то реализовать руками анонимные функции.
> чисто ради самообразования, может я чего не знаю.
"Как-то" всегда реализовать можно: достаточно вытащить анонимные
функции на верхний уровень, это превратит их в глобальные,
которые уже можно проименовать.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
"Как-то" всегда реализовать можно: достаточно вытащить анонимныекартинка про троллейбус и буханку хлеба.jpg
функции на верхний уровень, это превратит их в глобальные,
которые уже можно проименовать.
Что такое "стандарт питона"?Функционал стандартной реализации CPython версии 2, за неимением ничего более стандартного в питоне)
Между первым релизом языка и его популярностью прошло лет 15, если что.первый релиз был непойми чем, полноценным языком стала вторая версия, она же и получила популярность такую, что третья версия оказалась мало кому нужна.
но даже с 1994 года срок не такой большой, а крупных итераций в развитии языка было всего две, что совсем мало. о причинах этого можно спорить, но сырость питона - это к сожалению факт.
Ага, а потом учишь ещё немного и используешь eval для многострочных конструкций.
> Ага, а потом учишь ещё немного и используешь eval для многострочных конструкций.
Надо заметить, что это либо жёсткий сарказм, либо редкостный идиотизм.
---
"В следующий раз, когда ты скажешь, что 2*2=4,
я скажу тебе, что ты это содрал из стиля контры."
Надо заметить, что это либо жёсткий сарказм, либо редкостный идиотизм.
---
"В следующий раз, когда ты скажешь, что 2*2=4,
я скажу тебе, что ты это содрал из стиля контры."
Надо заметить, что это либо жёсткий сарказм, либо редкостный идиотизм.Это айвенго, не обвиняй его в сарказме.
C++03, например.
Даже C++98, если уж педантично.
Даже C++98, если уж педантично.Если не влом, покажи как.
И еще, таки C и фортран тоже? раз ты сказал, что сложно придумать язык, где такое невозможно
Если не влом, покажи как.Следите за объявлениями.
На сях это потребует некоторой programmer's discipline, примерно как то же ООП в GObject.
Оставить комментарий
6yrop
Чем меньше архитектуры, тем лучше. Это напрямую следует из определения термина "архитектура".