Способы программирования

пиши как тебе нравится.

Пока получается шняга одна, нужно уже заканчивать школьные игры и начинать серьёзные вещи делать.

переходи, потихоньку.

Как научиться абстрагироваться от возможностей языка или неполных знаний языка и построить модель будущей программы так, чтобы продумать все детали и не переписывать код по 2-3 раза, после нахождения лучшего варианта?

Никак. Ты слишком многого хочешь, так не бывает.

абстрагироваться от возможностей языка или неполных знаний языка и построить модель будущей программы

Почитай про DDD (https://en.wikipedia.org/wiki/Domain-driven_design), это даст тебе представление о предметных областях, о том как разрабатывать софт опираясь на эти знания.

продумать все детали и не переписывать код по 2-3 раза

Так не получится. Всегда найдутся какие-то детали, которые ускользнут от проектировщиков или будут пересмотрены заказчиком в последний момент, leak abstraction неизбежен.

Даже если ты напишешь 100500 user stories, всегда найдется тот кто придумает 100500+1 историю, ссылаясь на потребности бизнеса.

Или делать сложные вещи сначала простым способом, а потом после детального изучения предметной области, сделать как надо?

https://habrahabr.ru/post/153225/

библиотекам(Qt4).

Какое отношение это поделие имеет к _проектированию_ систем?

"(Кю — допустимое в обществе ругательство из кинофильма «Кин-дза-дза!» (см. статью Чатлано-пацакский язык))" (С)

«Кю» вырабатывет типичное «писючковое» мышление.

Которое к «предметной области»(С) не имеет никакого отношения.

Для проектирования сложных систем масштаба предприятия используются Java EE, Spring Framework, Apache Camel, CMIS типа Apache Chemistry, OSGi типа Apache Karaf, семейство средств Apache Hadoop и т.п..

Курсовые в урюпинском радиотехническом «университете», задаваемые «титиретиками» нищебродами «давателями препы», и реальный труд программирования в нормальной компании за нормальные деньги - это разные вещи.

Проанализируй, почему получилась шняга и следующую вещь делай с учётом этих причин. Сразу, с нуля, без опыта ты не сделаешь серьёзную вещь.

Для проектирования сложных систем масштаба предприятия

А если система высоконагруженная, к примеру web-gis с большим количеством посещений?

Можешь попробовать для начала разделить систему на несколько основных максимально независимых модулей и продумать надёжный протокол взаимодействия между ними, предполагающий возможность отказа любого из модулей в любой момент времени и внятные логи относительно обстоятельств нештатных ситуаций.

Мою одну программу назовём Текстовый редактор не нужно было начинать разрабатывать, пока я не разобрался бы с компонентом Текстовое поле. Сейчас всё завязано на постраничную разбивку текста, а должно было быть рулоном как в ворде. На внутренности Текстовое поле нет описания, только отдельно методы и свойства составляющих. Я там дошёл до логического тупика и без изучения этого компонента нет смысла продолжать.
Это я к тому, что серьёзно придётся поднимать свой левел, чтобы составлять модель так как нужно, а не так, как я умею на этом языке. :D

Нехватка знаний и опыта, это понятно. Только уж больно долго этот опыт набирается. :)

Ну, это естественно: архитектура начинается тогда, когда язык становится не чем-то, что нужно преодолеть, а эффективным инструментом. По аналогии, скажем, глупо продумывать шедевральную картину, если не в состоянии красиво нарисовать даже простенькие её элементы.

Нехватка знаний и опыта, это понятно. Только уж больно долго этот опыт набирается. :)

А ты хотел всего и сразу? Ну не получается так. Вот на-ка, почитай.

Никак. Или очень дорого. Подойди с другой стороны - начни писать программы так, чтобы можно было переписывать код по 100 раз, но малой кровью и с минимумом проблем. Например пиши для этого тесты.

И?

http://www.geotools.org/

абстрагироваться от возможностей языка или неполных знаний языка и построить модель будущей программы

Это не выполнимо, абстрагируясь от языка ты создаешь говнецкое API, потом твоим поделием будет не возможно пользоваться в плане доработки или рефактринга.

Ну или можешь покопать в этом направлении https://ru.wikipedia.org/wiki/Визуальное_программирование

Ты куда-то торопишься, что ли?

Опыт для программирования набирается именно программированием. Тем, что тебе нравится, ради чего ты и стараешься. Если тебе не нравится программировать, возможно, у тебя приоритеты неправильные. Пересмотри свои интересы, вдруг из тебя получится неплохой архитектор или системный аналитик, они как раз подобными вопросами занимаются, но без кодирования.

Спасибо за наводку, гляну. Ну, так-то хотелось бы историй успеха.

Короткий ответ: я всегда смотрю на «а что будет если...»

• Если я заменю этот компонент другим;
• Если я добавлю такой-то функционал;
• Если я удалю этот компонент;
• Если я перепишу с нуля этот компонент;
• Если нагрузка вырастет в 30 раз;
• Если я выложу этот модуль на github и предложу кому-нибудь допилить - будет ли понятно человеку со стороны, что это вообще такое?

Желательно вопросы ставить сложные, даже если есть четкое представление, что никогда это не понадобится. Смысл в том, что если ты не утыкаешься сразу же в какую-нибудь нерешаемую проблему, заставляющую переписать тебя 3/4 кода, то, вероятно, все спроектировано правильно. п.1 и п.4 позволяют временно говнокодить некритичную часть функционала.

Сложный ответ: на практике в большом проекте это практически нереально. Частично помогает разбивка на абсолютно независимые самостоятельные модули, но очень часто это создает «overhead».

Как научиться абстрагироваться от возможностей языка

Знать много языков/технологий на приемлемом уровне и запоминать удачные паттерны. Тогда ты будешь автоматом тащить лучшее из Qt в Spring и наоборот.

https://habrahabr.ru/post/153225/

Спасибо, я сначала писал как Маркус, а сейчас уже стараюсь делать как Борис по-возможности.

Для проектирования сложных систем масштаба предприятия используются Java EE, Spring Framework, Apache Camel, CMIS типа Apache Chemistry, OSGi типа Apache Karaf, семейство средств Apache Hadoop и т.п..

Для проектирования я буду юзать только UML 2.0, так как хочу в будущем писать программы «производственного масштаба». Для реализации всё же будет C++. Хотя это только планы, на самом деле может будущее меня и заставит «подкорректировать» своё мнение.

Есть ещё вариант, как делают многие, создать чудовищного монстра в виде программы с кучей зависимых библиотек написанных на разных языках(!) + скрипты(Perl, Python и т.д.) вдогонку, чтобы добить окончательно разрабов :D

http://www.fugro.com/

Вдогонку еще и GeoServer -

«GeoServer relies on GeoTools, a GIS library.» -

MassGIS (Massachusetts state GIS)

MACRIS Maps (Massachusetts Historical Commission)

TriMet (Transit agency for Portland, Oregon)

Ordnance Survey (National Mapping Agency of the UK)

Institut Géographique National (National Mapping Agency of France)

GBIF (Global Biodiversity Information Facility)

World Bank [для меня это было особенно любопытно - B.]

Global Earthquake Model

GMOS (Global Mercury Observation System)

FAO (Food and Agriculture Organization of the United Nations)

New York City Department of Information Technology and Telecommunications

TeamSurv

Для проектирования я буду юзать только UML 2.0, так как хочу в будущем писать программы «производственного масштаба». Для реализации всё же будет C++.

В реальном мире инструмент выбирается под задачу, а не наоборот. Для решения большинства задач бизнес не будет ждать кучу времени пока гениальная артихектура твоего софта будет готова, а в два-три (а то и в десять) раз быстрее получит рабочий софт не на C++.

Поэтому учить кресты вообще имеет смысл только в том случае, если ты реально хочешь кучу времени потратить на то, чтобы стать хорошим специалистом и впоследствии работать в тех сферах которые ни в какое ближайшее время не перейдут на другие технологии: геймдев, тяжелый серверный софт, etc.

чтобы продумать все детали и не переписывать код по 2-3 раза

Что так уже не бывает уже написали, но есть очень простой совет который может снизить количество итераций: бери и в свободное время изучай архитектуру чужого софта. Ещё можно смотреть кто где как фейлил по части оптимизации или безопасности.

Реальный мир очень сильно отличается от книжек, а потому чужой опыт хождения по граблям поможет тебе совершать меньше ошибок.

Как научиться абстрагироваться от возможностей языка или неполных знаний языка и построить модель будущей программы так, чтобы продумать все детали и не переписывать код по 2-3 раза

Так не бывает, держи в голове, что первый вариант всегда уйдет в утиль. Старайся писать так чтобы было несложно переписывать по-частям, т.к. возможности переписать все и сразу обычно нет.

Поэтому учить кресты вообще имеет смысл только в том случае, если ты реально хочешь кучу времени потратить на то, чтобы стать хорошим специалистом и впоследствии работать в тех сферах которые ни в какое ближайшее время не перейдут на другие технологии: геймдев, тяжелый серверный софт, etc.

Как бы это не звучало глупо я это и хочу. Уже имея небольшой опыт в написании нескольких программ С++ + Qt, в одной я выделил структурную часть достаточно быстро и переписал на чистом C++, после этого я код смог использовать в вебе. В далёком будущем я хочу сравнить скорость доступа PHP к разным БД с C++, если прирост будет хотя бы в 1.5 раза, то я буду оптимизировать большие и высоконагруженные сайты(эх, мечты, мечты :) ).

Как бы это не звучало глупо я это и хочу.

Ну просто учитывай, что программист на крестах со знаниями «так себе» никому не нужен, а джуном в СНГ мало кто сейчас берет. В то же время в случае почти любой другой технологии (питоно-руби-ява-js-etc) куда проще найти работу при любом уровене знаний и уже в процессе доучиваться.

Поэтому если ты правда хочешь кодить именно на C++, то при наличии возможности соглашайся на любую работу где можно будет учится. Eсли работы нет, то выбирай любой опенсорс проект в той сфере в которой тебе было бы интересно работать и пиши туда код.

Свои велосипеды конечно лучше чем ничего, но твоему потенциальному работодателю важно знать, что ты умеешь разбираться в чужом коде и желательно имеешь опыт работы в команде.

В далёком будущем я хочу сравнить скорость доступа PHP к разным БД с C++, если прирост будет хотя бы в 1.5 раза, то я буду оптимизировать большие и высоконагруженные сайты(эх, мечты, мечты :) ).

Там драйвера баз данных всегда были на C/C++ в написаны, так что некуда там разнице в скорости доступа взяться. Плюс PHP7 и так быстрый, а в HHVM есть JIT.

Ну а если серьёзно то обычно такие «высоконагруженные сайты» оптимизируют кэшем и докупкой серверов. А то что и вправду должно работать очень и очень быстро изначально не пишется на таких язычках.

Есть базовые знания пары языков программирования.
Есть книжка по UML 2.0

omg

ключевые слова - писать код и получать результат.

иначе так и будешь «пытаться абстрагироваться и строить модели в воздухе».

omg

Что смутило? Я всю правду написал, есть книжка такая у меня :D

После получения некоторого опыта программирования, я сейчас проанализировал и пришёл к выводу, что я буду делать условные абстракции, чтобы убить двух зайцев, проверяя, как мне советовали, самые критичные моменты на реализуемость.

Самое главное - научись делать декомпозицию задачи в терминах предметной области. И реализуй это дела на любом языке программирования.

К сожалению, сейчас многие фреймверки в разных языках диктуют свои подходы к проектированию, и это плохо. Если тебе подход фреймверка не нравится, ты будешь мучаться и делать криво. Плохо, когда другого достойного фреймверка нет, тогда трудозатраты будут либо на борьбу с притягиванием традиционного в фреймверке подхода к решению твоей задачи, либо на написание библиотек, решающих твою задачу нужными тебе методами. И то и то очень трудозатратно.

Как пример - модель интервиев в Qt. Она очень неудачная, но уйти от нее весьма непросто. Приходится мучиться. И так везде. Идеал ты можешь написать только сам, вот только жизни тебе на это не хватит.

UML и иные модели для проектирования ПО нужны только тогда, когда разрабатывает их команда и есть необходимость получить что-то гарантированно рабочее, по проторенной дорожке. В противном случае их полезность стремится к 0. И да, начинай с прототипирования, если не хочешь 100 раз переделывать код, придется переделывать его как минимум 1 раз, но гарантированно.

, вот только жизни тебе на это не хватит.

лорчую :)

UML настолько уникален, что он перегружен элементами, а это значит, что есть выбор найти более подходящие элементы для описания конкретной задачи. Будет использоваться минимум возможностей.

Когда я начинал писать одну программу самую первую, я подумал, чтобы сэкономить время я не буду писать классы... как оказалось зря, я теперь переписал больше половины с классами и ещё походу до конца не нашёл все ошибки сегфолтов, после глобальных перемен.
P.S. Да, да, опыт это, Скука, вещь такая. :D

UML настолько уникален, что он перегружен элементами

Вот это и плохо

как получишь ещё некоторый опыт, вернёшься к корням: программирование это написание кода. Если код ты не пишешь, то ты <вставьте слово сами>...

как получишь ещё некоторый опыт, вернёшься к корням: программирование это написание кода. Если код ты не пишешь, то ты <вставьте слово сами>...
<вставьте слово сами>...

школоло? фантазии не хватило. Когда всё начиналось, я либо не работал, либо работал на дядю и поэтому сосредотачивался на «как можно быстрее», теперь же я могу сесть спокойно и анализировать, только и всего.