Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Притом формы ввода/выводы информации, схемы обработки, абстрактные структуры массивов и элементов данных сами по себе тоже являются информацией (как и всё приложение) и подчиняются той же фундаментальной
Как мне все это (особенно первая блок-схема) напомнила мои годы учебы в ВА им. Ф.Э. Дзержинского в далеких 1971-76 г.г. Мы были первым набором на кафедру программирования. Но тогда только все начиналось.
А сейчас… Но какие выводы
Фундаментальная концепция приводит к появлению первых идей и к созданию первых моделей обработки данных.
Под стать выводам докторской диссертиции.
Кажется, тут упущена часть, которая относится к DevOps.
На самом деле, даже на первом этапе работы над проектом, разработка может перейти в перестройку архитектуры, и будет продолжаться весь жизненный цикл проекта.
На самом деле, даже на первом этапе работы над проектом, разработка может перейти в перестройку архитектуры, и будет продолжаться весь жизненный цикл проекта.
На мой взгляд, статья в чистом виде вода. Из чего это можно понять: пол текста — клишированные обороты, вроде
Много красивого текста, но по факту никакой полезной информации.
В случае, если автору хотелось рассказать про архитектуру, следовало бы просто прочитать литературу на это счет. Из признанного и успешно работающего: Мартин (Чистая архитектура и чистый код), Вигерс (разработка требований к программному обеспечению), Басс (архитектура программного обеспечения на практике), O'Reilly.
Кроме того, можно было бы взять другие источники по разработке: прочитать про DDD и другие подходы к проектированию. Помимо этого, нужно знать о том, как проектируется MVP и чем прототип отличается от MVP.
Фундаментальная концепция приводит к появлению первых идей и к созданию первых моделей обработки данных.
Много красивого текста, но по факту никакой полезной информации.
В случае, если автору хотелось рассказать про архитектуру, следовало бы просто прочитать литературу на это счет. Из признанного и успешно работающего: Мартин (Чистая архитектура и чистый код), Вигерс (разработка требований к программному обеспечению), Басс (архитектура программного обеспечения на практике), O'Reilly.
Кроме того, можно было бы взять другие источники по разработке: прочитать про DDD и другие подходы к проектированию. Помимо этого, нужно знать о том, как проектируется MVP и чем прототип отличается от MVP.
архитектура системы
Я смотрю, в yed нарисовано?
Кто в чём UML чертит? Структуру на этапе проектирования, диаграммы классов…
Кто в чём UML чертит? Структуру на этапе проектирования, диаграммы классов…
Зачем разрабатывается архитектура?
Кому и в чем от этого польза?
Кому и в чем от этого польза?
О структуре убедительных программ
Техника управления сложностью известна с древних времен: Divide et impera (разделяй и властвуй). Аналогия между построением доказательства и построением программы, пожалуй, просто поразительна. В обоих случаях даны отправные точки (аксиомы и существующая теория против примитивов и доступных библиотечных программ), в обоих случаях задана цель (доказанная теорема против желаемых результатов), в обоих случаях сложность преодолевается делением на части (леммы против подпрограмм и процедур).
Я полагаю, что гениальность программиста соответствует сложности решаемой задачи, а также полагаю, что он сумел добиться подходящего разделения задачи. Затем он продолжает действовать следующим образом:
* Он разрабатывает полные спецификации отдельных частей.
* Он убеждается, что проблема в целом решается при наличии в его распоряжении частей программы, удовлетворяющих этим спецификациям.
* Он разрабатывает отдельные части в соответствии со спецификациями, но при этом делает их максимально независимыми друг от друга и от окружения, в котором они будут использоваться.
Очевидно, что построение каждой такой отдельной части может снова оказаться сложной задачей, так что для данной части задачи потребуется дальнейшее разбиение.
Некоторые могут счесть описанный метод разбиения на части недостаточно прямолинейным и слишком извилистым путем достижения конечной цели. Мое собственное мнение я лучше всего могу выразить так: я твердо уверен, что царских дорог в математике нет, или, другими словами, что у меня очень маленькая голова, и я вынужден обходиться ей. Поэтому я рассматриваю технику разбиения на части как базовый прием человеческого мышления и считаю, что стоит попробовать создать условия, в которых она может быть наиболее плодотворно применена.
Предположение о том, что программист сделал подходящее разбиение, находит подтверждение в том, что становится возможным выполнить первые два этапа: спецификацию частей и проверку, что они совместно решают задачу. Здесь элегантность, точность, ясность и тщательное понимание задачи являются необходимыми предпосылками. Но в целом техника разбиения основывается на том, что обсуждалось значительно меньше, а именно на том, я назвал бы принципом невмешательства. На втором этапе подразумевается, что правильная работа целого может быть установлена путем рассмотрения только внешних спецификаций частей, без деталей их внутреннего строения. На третьем этапе принцип невмешательства всплывает снова; здесь подразумевается, что отдельные части могут быть поняты и построены независимо друг от друга.
Возможно, здесь уместно заметить, что если я правильно понял нынешнее отношение к проблеме определения языка, при несколько более формальном подходе состоятельность техники разбиения подвергается сомнению. Те, кто выдвигает возражения, аргументируют свою точку зрения следующим образом. Когда вы используете механизм, подобный описанному двухэтапному, во-первых, должны быть созданы спецификации, а во-вторых, описано, как все это работает. При этом вы вынуждены в лучшем случае сказать дважды одно и то же, но вероятнее всего, вы придете к противоречию. С точки зрения статистики, как ни грустно мне об этом говорить, последнее замечание достаточно серьезно. Единственный ясный путь к определению языка, возражают они, это просто определение механизмов, потому что все, что они будут делать, следует из этого. Мой вопрос: А как оно следует? мудро оставляют без ответа, и я боюсь, что это тонкое, но порой значительное различие между понятиями определено и известно сделают их работу интеллектуальным упражнением, которое ведет в тупик.
/Эдсгер Вайб Дейкстра. Программирование как вид человеческой деятельности. В переводе. Отрывок/
Техника управления сложностью известна с древних времен: Divide et impera (разделяй и властвуй). Аналогия между построением доказательства и построением программы, пожалуй, просто поразительна. В обоих случаях даны отправные точки (аксиомы и существующая теория против примитивов и доступных библиотечных программ), в обоих случаях задана цель (доказанная теорема против желаемых результатов), в обоих случаях сложность преодолевается делением на части (леммы против подпрограмм и процедур).
Я полагаю, что гениальность программиста соответствует сложности решаемой задачи, а также полагаю, что он сумел добиться подходящего разделения задачи. Затем он продолжает действовать следующим образом:
* Он разрабатывает полные спецификации отдельных частей.
* Он убеждается, что проблема в целом решается при наличии в его распоряжении частей программы, удовлетворяющих этим спецификациям.
* Он разрабатывает отдельные части в соответствии со спецификациями, но при этом делает их максимально независимыми друг от друга и от окружения, в котором они будут использоваться.
Очевидно, что построение каждой такой отдельной части может снова оказаться сложной задачей, так что для данной части задачи потребуется дальнейшее разбиение.
Некоторые могут счесть описанный метод разбиения на части недостаточно прямолинейным и слишком извилистым путем достижения конечной цели. Мое собственное мнение я лучше всего могу выразить так: я твердо уверен, что царских дорог в математике нет, или, другими словами, что у меня очень маленькая голова, и я вынужден обходиться ей. Поэтому я рассматриваю технику разбиения на части как базовый прием человеческого мышления и считаю, что стоит попробовать создать условия, в которых она может быть наиболее плодотворно применена.
Предположение о том, что программист сделал подходящее разбиение, находит подтверждение в том, что становится возможным выполнить первые два этапа: спецификацию частей и проверку, что они совместно решают задачу. Здесь элегантность, точность, ясность и тщательное понимание задачи являются необходимыми предпосылками. Но в целом техника разбиения основывается на том, что обсуждалось значительно меньше, а именно на том, я назвал бы принципом невмешательства. На втором этапе подразумевается, что правильная работа целого может быть установлена путем рассмотрения только внешних спецификаций частей, без деталей их внутреннего строения. На третьем этапе принцип невмешательства всплывает снова; здесь подразумевается, что отдельные части могут быть поняты и построены независимо друг от друга.
Возможно, здесь уместно заметить, что если я правильно понял нынешнее отношение к проблеме определения языка, при несколько более формальном подходе состоятельность техники разбиения подвергается сомнению. Те, кто выдвигает возражения, аргументируют свою точку зрения следующим образом. Когда вы используете механизм, подобный описанному двухэтапному, во-первых, должны быть созданы спецификации, а во-вторых, описано, как все это работает. При этом вы вынуждены в лучшем случае сказать дважды одно и то же, но вероятнее всего, вы придете к противоречию. С точки зрения статистики, как ни грустно мне об этом говорить, последнее замечание достаточно серьезно. Единственный ясный путь к определению языка, возражают они, это просто определение механизмов, потому что все, что они будут делать, следует из этого. Мой вопрос: А как оно следует? мудро оставляют без ответа, и я боюсь, что это тонкое, но порой значительное различие между понятиями определено и известно сделают их работу интеллектуальным упражнением, которое ведет в тупик.
/Эдсгер Вайб Дейкстра. Программирование как вид человеческой деятельности. В переводе. Отрывок/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С чего начать разработку архитектуры?