про опердени
Jan. 29th, 2013 02:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stdrayКогда читаешь в интернете разные программистские дискуссии, постоянно натыкаешься на некоторые шаблонные суждения. Например,
- когда говорят про high load, ведут речь за хорошую горизонтальную масштабируемость;
- когда говорят про embedded, обсуждают, как станцевать вальс на площадке размером с пятирублевую монету;
- когда говорят про enterprise, имеют в виду либо оскорбление, либо CRUD.
Хотя в последнем случае разница довольно условна. То есть «энторпрайз» - это такие сферические неудобные медленные приложения в вакууме, а круды — это продукт деятельности макак, школьников и индусов.Это значит, например, что индийцы не индуисты круды писать не могут. То есть круды — это что-то плохое и простое.
Хотя, конечно, только от того, что какую-то деятельность заклеймили как простую и бесполезную, проще от этого она точно становится. Чем дальше, тем важнее становится информация. И все, кому не лень (и кому лень тоже) занимаются её накоплением, структурированием и анализом. При этом мой опыт таков, что данные — вещь удивительно не гибкая. Поскольку есть информация сама по себе, а есть ее представление, выбранное для решения конкретной задачи. Эти представления являются первой сложностью. Первой, в том смысле, что все начинается c выбора представления: как данные разделить на маленькие кусочки, как выразить эти кусочки в терминах своего инструментария (модель данных приложения, модель постоянного хранилища), как обеспечить их согласованность и определенную сложность доступа к ним. Хотя по этому поводу написано достаточно много, от нормальных форм реляционной базы данных до паттернов Фаулера, эта задача все же не является тривиальной. Слепое следование рекомендациям ни к чему хорошему не приводит, потому приходится постоянно оценивать свои решения, насколько они кажутся удачными, начиная с момента разработки и заканчивая текущим моментом (если апликуха до него дожила). И тут большую роль играет опыт, поскольку он позволяет учесть значительно больше вариантов использования и сложных граничных случаев.
Здесь же вторая проблема. Постоянное хранение информации чаще всего предполагает использование РСУБД. А реляционная модель данных очень сильно отличается от объектно-ориентированной (что касается фп, то я пока не понимаю, есть там какой-то свой подход к этому вопросу или нет). Потому на ровном месте возникает одновременно две модели данных, которые в ручном или полуручном режиме надо отобразить друг на друга. У Фаулера фигурирует 30%, мол именно такая часть времени разработки проекта тратится на это самое отображение. Я, пожалуй, согласен с этой оценкой для любой нетривиальной модели.
Третья проблема — это обратная совместимость представления информации. Когда имеешь дело с одной книжной полкой, то все достаточно просто: можно ее перевесить или, по желанию, переложить книги в шкаф. Все равно кроме тебя никто этими книгами не пользуется, потому никаких неудобств не возникает. Однако, если управляешься с библиотекой имени Ленина все гораздо сложнее. И какие-то глобальные изменения и перестановки — это последнее, что хочется делать, поскольку уже существуют посетители, которые будут разочарованы, если библиотека с привычного места денется черти куда, есть персонал, который просто не сможет обеспечивать работу библиотеки, если принципы ее функционирования в один момент радикально изменятся. С крудами, я думаю, ситуация очень похожая. Данные копятся давно, за ними ходят какие-то приложения, которые не имеют какой-то единой модели. И потому любое изменение может приводить к непредсказуемым последствиям. «Удалил из таблицы очевидно лишнее поле IsDeleted? Иди починяй вооон тот отчет, который теперь не генерируется.» И такое происходит сплошь и рядом, то есть велика вероятность, что если модель была спроектирована неудачно и на текущем этапе является неудобной, с этим придется мириться и работать дальше.
Четвертая проблема — это множественные представления одних и тех же данных. Модели данных проектируется под задачу, а не «вообще». Потому на определенный момент времени нас может все устраивать, а в следующий требуют реализовать определенную хотелку, для которой имеющаяся модель не годится совершенно (именно невозможно с этим жить, а не просто неудобно работать как в прошлом пункте). Хотя при этом все исходные данные для решения задачи имеются. В такой ситуации, из имеющейся базы информация выдирается, преобразуется к нужному виду и укладывается в новую бд. И проблем становится в 2 раза больше, или в 3, если новая и старая базы могут независимо изменяться и должны синхронизироваться между собой.
Стоит отметить, что предыдущий пункт является лишь частным проявлением более общей проблемы — слабой формализации и изменчивости требований. Это пятое. И здесь, как, водится, можно считать всех вокруг идиотами :
- заказчика, который плохо формулирует, чего ему, собственно, нужно
- аналитика, который не сумел выбить из заказчика точные требования
- архитектора, который неудачно декомпозировал систему
- себя, захардкодившего определенное поведение, которое вдруг оказалось изменяемым
Но я полагаю, что дело обстоит немного иначе. Подобные приложения имеют 2 основных задачи: автоматизация процессов и контроль за этими самыми процессами. Чтобы автоматизировать какой-то процесс, необходим профессионал, разбирающийся во всех нюансах данной деятельности, но найти такого возможно не всегда, поскольку чаще всего задействована уйма людей, каждый из которых, делает свою работу и может очень хорошо в ней ориентироваться, но не видит картины в целом. И лишь когда система запущена, начинаются всякие уточнения. По окончание притирки, неизбежно возникают мысли, что система может приносить еще больше пользы. И, таким образом, либо система отправится на свалку истории (если возложенные надежды не оправдались или фирма, не справившись с основной деятельностью, разорилась), либо будет развиваться бесконечно (например, если хочется иметь контроль за новыми аспектами деятельности).
Это бесконечное развитие приведет ко всем вышеописанным проблемам. И тут надо всячески уменьшать связанность компонентов, стараться максимально их повторно использовать, вносить гибкость в определенных местах. Книжки по паттернам как раз про это (хотя зачастую там описываются решения микроскопических проблем, что мало может помочь). Так или иначе, общее направления развития понятно — собрать накопленный опыт, проанализировать, найти повторяющиеся подходы, обобщить и поделиться, описав, как паттерн проектирования. Я со времени своего знакомства с функциональной парадигмой программирования так и не смог понять, почему многие адепты фп считают паттерны чем-то плохим и утверждают, что если выбранный яп обладает некоторыми особенностями (как-то АТД, сопоставление с образцом, ФВП, оптимизация хвостовой рекурсии и тд), то все проблемы решаются сами собой. Вопрос «как?» для меня до сих пор открыт.
Ко всем прочему объемы данных растут, так что приходится заниматься сегментированием и репликацией данных. В условиях жестких требований к консистетности данных приходится обеспечивать транзакцию для операций разнесенных во времени и пространстве. Как приходится заниматься тем же самым горизонтальным масштабированием. Как приходится иметь дело с разного рода мутными форматами данных, рисуя для них какие-то кустарные парсеры, валидаторы и сериализаторы.
Я лишь хочу сказать, что существуют тенденции. Допустим, в обществе распространено мнение, что быть юристом или экономистом каким — это модно, престижно и труд интеллектуальный. А среди программистиов, возникают суждения, мол разработка конпеляторов или там высоконагруженных систем — это илитка, а остальные, так, в грязи копаются. Хотя вопрос сложности открыт, да и с полезностью все неоднозначно.
- когда говорят про high load, ведут речь за хорошую горизонтальную масштабируемость;
- когда говорят про embedded, обсуждают, как станцевать вальс на площадке размером с пятирублевую монету;
- когда говорят про enterprise, имеют в виду либо оскорбление, либо CRUD.
Хотя в последнем случае разница довольно условна. То есть «энторпрайз» - это такие сферические неудобные медленные приложения в вакууме, а круды — это продукт деятельности макак, школьников и индусов.
Хотя, конечно, только от того, что какую-то деятельность заклеймили как простую и бесполезную, проще от этого она точно становится. Чем дальше, тем важнее становится информация. И все, кому не лень (и кому лень тоже) занимаются её накоплением, структурированием и анализом. При этом мой опыт таков, что данные — вещь удивительно не гибкая. Поскольку есть информация сама по себе, а есть ее представление, выбранное для решения конкретной задачи. Эти представления являются первой сложностью. Первой, в том смысле, что все начинается c выбора представления: как данные разделить на маленькие кусочки, как выразить эти кусочки в терминах своего инструментария (модель данных приложения, модель постоянного хранилища), как обеспечить их согласованность и определенную сложность доступа к ним. Хотя по этому поводу написано достаточно много, от нормальных форм реляционной базы данных до паттернов Фаулера, эта задача все же не является тривиальной. Слепое следование рекомендациям ни к чему хорошему не приводит, потому приходится постоянно оценивать свои решения, насколько они кажутся удачными, начиная с момента разработки и заканчивая текущим моментом (если апликуха до него дожила). И тут большую роль играет опыт, поскольку он позволяет учесть значительно больше вариантов использования и сложных граничных случаев.
Здесь же вторая проблема. Постоянное хранение информации чаще всего предполагает использование РСУБД. А реляционная модель данных очень сильно отличается от объектно-ориентированной (что касается фп, то я пока не понимаю, есть там какой-то свой подход к этому вопросу или нет). Потому на ровном месте возникает одновременно две модели данных, которые в ручном или полуручном режиме надо отобразить друг на друга. У Фаулера фигурирует 30%, мол именно такая часть времени разработки проекта тратится на это самое отображение. Я, пожалуй, согласен с этой оценкой для любой нетривиальной модели.
Третья проблема — это обратная совместимость представления информации. Когда имеешь дело с одной книжной полкой, то все достаточно просто: можно ее перевесить или, по желанию, переложить книги в шкаф. Все равно кроме тебя никто этими книгами не пользуется, потому никаких неудобств не возникает. Однако, если управляешься с библиотекой имени Ленина все гораздо сложнее. И какие-то глобальные изменения и перестановки — это последнее, что хочется делать, поскольку уже существуют посетители, которые будут разочарованы, если библиотека с привычного места денется черти куда, есть персонал, который просто не сможет обеспечивать работу библиотеки, если принципы ее функционирования в один момент радикально изменятся. С крудами, я думаю, ситуация очень похожая. Данные копятся давно, за ними ходят какие-то приложения, которые не имеют какой-то единой модели. И потому любое изменение может приводить к непредсказуемым последствиям. «Удалил из таблицы очевидно лишнее поле IsDeleted? Иди починяй вооон тот отчет, который теперь не генерируется.» И такое происходит сплошь и рядом, то есть велика вероятность, что если модель была спроектирована неудачно и на текущем этапе является неудобной, с этим придется мириться и работать дальше.
Четвертая проблема — это множественные представления одних и тех же данных. Модели данных проектируется под задачу, а не «вообще». Потому на определенный момент времени нас может все устраивать, а в следующий требуют реализовать определенную хотелку, для которой имеющаяся модель не годится совершенно (именно невозможно с этим жить, а не просто неудобно работать как в прошлом пункте). Хотя при этом все исходные данные для решения задачи имеются. В такой ситуации, из имеющейся базы информация выдирается, преобразуется к нужному виду и укладывается в новую бд. И проблем становится в 2 раза больше, или в 3, если новая и старая базы могут независимо изменяться и должны синхронизироваться между собой.
Стоит отметить, что предыдущий пункт является лишь частным проявлением более общей проблемы — слабой формализации и изменчивости требований. Это пятое. И здесь, как, водится, можно считать всех вокруг идиотами :
- заказчика, который плохо формулирует, чего ему, собственно, нужно
- аналитика, который не сумел выбить из заказчика точные требования
- архитектора, который неудачно декомпозировал систему
- себя, захардкодившего определенное поведение, которое вдруг оказалось изменяемым
Но я полагаю, что дело обстоит немного иначе. Подобные приложения имеют 2 основных задачи: автоматизация процессов и контроль за этими самыми процессами. Чтобы автоматизировать какой-то процесс, необходим профессионал, разбирающийся во всех нюансах данной деятельности, но найти такого возможно не всегда, поскольку чаще всего задействована уйма людей, каждый из которых, делает свою работу и может очень хорошо в ней ориентироваться, но не видит картины в целом. И лишь когда система запущена, начинаются всякие уточнения. По окончание притирки, неизбежно возникают мысли, что система может приносить еще больше пользы. И, таким образом, либо система отправится на свалку истории (если возложенные надежды не оправдались или фирма, не справившись с основной деятельностью, разорилась), либо будет развиваться бесконечно (например, если хочется иметь контроль за новыми аспектами деятельности).
Это бесконечное развитие приведет ко всем вышеописанным проблемам. И тут надо всячески уменьшать связанность компонентов, стараться максимально их повторно использовать, вносить гибкость в определенных местах. Книжки по паттернам как раз про это (хотя зачастую там описываются решения микроскопических проблем, что мало может помочь). Так или иначе, общее направления развития понятно — собрать накопленный опыт, проанализировать, найти повторяющиеся подходы, обобщить и поделиться, описав, как паттерн проектирования. Я со времени своего знакомства с функциональной парадигмой программирования так и не смог понять, почему многие адепты фп считают паттерны чем-то плохим и утверждают, что если выбранный яп обладает некоторыми особенностями (как-то АТД, сопоставление с образцом, ФВП, оптимизация хвостовой рекурсии и тд), то все проблемы решаются сами собой. Вопрос «как?» для меня до сих пор открыт.
Ко всем прочему объемы данных растут, так что приходится заниматься сегментированием и репликацией данных. В условиях жестких требований к консистетности данных приходится обеспечивать транзакцию для операций разнесенных во времени и пространстве. Как приходится заниматься тем же самым горизонтальным масштабированием. Как приходится иметь дело с разного рода мутными форматами данных, рисуя для них какие-то кустарные парсеры, валидаторы и сериализаторы.
Я лишь хочу сказать, что существуют тенденции. Допустим, в обществе распространено мнение, что быть юристом или экономистом каким — это модно, престижно и труд интеллектуальный. А среди программистиов, возникают суждения, мол разработка конпеляторов или там высоконагруженных систем — это илитка, а остальные, так, в грязи копаются. Хотя вопрос сложности открыт, да и с полезностью все неоднозначно.