Собственно, сабж

А, ну да, основы знаю, ******* написана куча, а вот хорошую архитектуру строить не научился совсем

Вроде еще не тяпница ))
системы чего?

— Семёнов, ты по какой системе водку будешь пить?
— А ты по какой пьёшь?
— Я по ян.
— Тогда я по инь.
— Это для гармонии?
— Да нее… я ж на службе!
(с) "Операция с новым годом"

Хороший архитектор. Это у кого здания (системы) не падают.

Ну или не посадили. Еще. Когда упали.

(2) Ну, начинки конфигурации, метаданные, алгоритмы. Есть что прочитать про примеры разработки? Не книги, где учат базовой работе, а книги по разработке, может с примером?

(1) опыт, сyко, сын ошибок трудных. Пока пару раз с нуля или около того не перепишешь одно-двух-трехнедельную работу из-за того что чего-то изначально не предусмотрел - вряд ли начнешь печенкой понимать что и как делать

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

(5) +100500
(4) Прежде все это четкое понимание что ты хочешь, после этого много, много, много, и еще раз много думать, рисовать, пробовать, проверять, мозги ломать, работать до тех пор пока по экрану буквы ползать не начнут... )  
это если хочешь сам учиться

(0) Жизнь научит. Но больно! :-)

(0) у тебя хоть какое то понимание про вот это есть?
https://studfiles.net/preview/4229380/

+9 ну может ты где то что то учил?

(9) Это бесполезные знания. И даже вредные. Для архитектора систем. Не простого кодера.

(11)+ Вот полезные.
https://ru.wikipedia.org/wiki/12_правил_Кодда
http://www.mista.ru/oop_book/glava2.htm

(11) Ну почему?
Он же говорит про внутренности про методанные, вот пусть сначала просто поймет из (9):
Алгоpитм – это точное и понятное предписание исполнителю совершить последовательность действий, направленных на решение поставленной задачи.

(13) Архитектура это не предписанный алгоритм.

Архитектура это полнота моделирования/описания допустимых процессов/ситуаций. Даже пока несуществующих. Но возможных в будущем.

+13 Кроме того архитектором системы он ни когда не станет не зная на что способна среда обитания системы

(15) Среда обитания меняется очень быстро.
Архитектуре на это пофиг.

Абсолютно пофиг регистры/ячейки памяти или вектора/объекты.

Еще скажи кодер обязан знать особенности n-p-n и p-n-p переходов и устройстов/принципы работы электроники.

(16)>>Еще скажи кодер обязан знать особенности n-p-n и p-n-p переходов
и про туннельные переходы и т.д. тоже )
Обязан. Если кодер будет делать конфу на эту тему, а точнее он ее не сделает не зная предметной области.

(16) Помнишь в лихие 90-е на машинах на стоп сигналы еще делали гирлянды с бегущими огнями? в основном все привозили из китая? )))
я когда курсантом был, то на TTL-овской логике это все сам разрабатывал и на коленках в мыльнице делал, ну жить надо как то было ))

(4) что членом на старте не вложено, то потом книжкой не вобьешь

(19) Как всегда пять балов ))))

(20)

(21) Присоединяюсь ))
спасибо за предложение ))
С Новым годом!

(17) Исполнитель должен уметь использовать инструмент.
Не как его (инструмент) делать. И как чинить.

Или будет как у нас сча. Все с в/о. Все "инженера". А кодить и архитектурить не умеют.

Случаи информатизации процесса "создания инструментов" не учитываем. Тут предметка вынужденно.

Для задач системного администрирования я выработал три принципа:
1) Дублирование
2) Резервное копирование
3) Мониторинг

Для задач ИТ систем, пока прокатывает нечто более абстрактное:
1) Называть вещи своими именами.

(0) Я просто сажусь и делаю.
Особо не думаю.
Никогда не рисую схемы, не пишу себе ТЗ, дичь это, некогда.
Иногда задумка не удается, переделываю.
В любом случае, мне проще набросать каркас кодом и метаданными и потом, в случае успеха, нарастить все мясом, чем думать.

Часто совещаюсь с братом, он въедливый и вредный, любит покритиковать и знает УТ11/БСП как свои 10 пальцев и все подводные ее камни.

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

Не гнушайтесь тратить время на написания хорошего кода.
Хороший код пишется быстро.

Немного не так.

Можно быстро накидать копрокода, но ты потом замудохаешься его отлаживать и разбираться в хитровложенности ЕСЛИ.

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

(16) Еще Аль Капоне говорил, что с помощью кодинга и знания особенностей n-p-n и p-n-p переходов можно достичь гораздо большего, чем с помощью только кодинга.

(1) Архитектуру надо не строить, а использовать. Можно начать с этого.

(27) Замечательный пример. Посадили за неуплату налогов. Архитектура подкачала.

Но согласен что знать два инструмента лучше чем только один.

(28) Кстати, да)

(0) Чтобы быть программистом - нужно думать, как программист. Чтобы быть архитектором - нужно думать как архитектор. Т.е. какие объекты нужны для системы, как они будут взаимосвязаны и какая структура будет наиболее оптимальна. Как с точки зрения производительности, так и с точки зрения сопровождения этой структуры.

(31) >>какие объекты нужны для системы, как они будут взаимосвязаны и какая структура будет наиболее оптимальна. Как с точки зрения производительности, так и с точки зрения сопровождения этой структуры.

Вот это правильно, если архитектор не будет знать внутренностей, то как он будет думать про производительность и сопровождение?

(0) Часть архитектуры реализована платформой, разработчику следует только придерживаться рекомендаций в большинстве случаев - создавать структуру данных как пишут в желтых книжках и не допускать совсем уж грубых ошибок. Есть, конечно, программные механизмы, вроде того же партионного учета или РАУЗ, которые следует делать с оглядкой на производительность и масштабируемость решений - это уже можно назвать архитектурой, но часто ли приходится что-то подобное реализовывать? Ну или часто в отраслевках свои уникальные костыли, вроде хранения остатков в регистрах сведений или реализация бюджетирования каким-то уникальным способом. Там да, видно что была работа для архитектора. А так, в большинстве случаев понятия "архитектор" и "1С", имхо, нерелевантны.

Иногда, мне кажется, что достаточно того, чтобы у человека был сертификат "Профессионал по платформе". Это хотя бы гарантирует, что человек узнает о наличии многих объектов в системе кроме наличия справочников. Потому как просто страшно, когда менеджер проектов проектирует хрень, и искренне считает, что он гуру. Да, она - эта хрень - работает, но как...?!

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

— Что это за книга? Роман?
— Нет, детектив.
— Страшно?
— Бывает страшно, бывает и нет. В основном, пугает то, как паршиво написано.

(С)Из фильма «Реальная любовь»

(0) Архитектура много чего бывает. Архитектура функциональности всего приложения, архитектура окружения, в котором ПО работает, архитектура БД, конкретных модулей и даже пользовательского интерфейса.

Если рассматриваем функицональность, кури Use Case View и User Story. Моделирование бизнес процессов в классическом понимании  не кури - вредно.

Если окружение - кури всю админскую часть. Ну и про оптимизации и кластеры всякие.

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

Если дело касается организации кода, что в ООП языках называется моделью классов, в 1С тоже надо это делать (моделировать). Устойчивого кунг-фу тут не сформировалось, кури типовые, думай сам. Надо крепко знать назначения модулей, галки общих модулей и т.д. А проектировать надо не для решения конкретной задачи, а так чтобы потом это вписалось даже туда, о чем сейчас и никто не думает. Для этого достаточно просто честно передирать в модель сущности окружающего мира и не фантазировать. Впрочем, это всех пунктов касается.

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

(0) >>
- Инженеры! - продолжал Модели, вложив в это слово чуть ли не пуд презрения. - "Творчески одаренные и рационально мыслящие ученые, которые способны выстроить планету в любое время в любом месте". Хоть одному из вас знакома эта фраза?

- Так написано в типовой брошюре, - сказал Орин.

- Правильно, - подтвердил Модели. - А теперь скажите, можно ли вот это назвать образцом творческого и рационального подхода к инженерному искусству? (c)
Полностью здесь http://www.metodolog.ru/00179/00179.html

(36) категорически не согласен с выражением "побольше ярких цветов и разных шрифтов" - потому что на выходе получается мегапрайс и прочие попугайства в стиле "поиграйте со шрифтами". Наоборот в таких вещах нужна осторожность, чтобы не перегрузить внимание пользователя.

(38) Это я тонко пошутил.

(39) спасибо за уточнение, я представил как кто-нибудь прочитает эту ветку и в голове отложится - "яркие цвета на форме - гут".

(0) Хочешь потренироваться на кошках? )))
Напиши для себя что нибудь, типа домашнюю бхглактерию))
или возьми любую задачу которую реализовал кто угодно,
и не подсматривая во внутренности уже готового, сделай свое, как ты это видишь, потом сравнишь.

(37) мне кажется, что любой одинэсник с несколькими внедрениями прочитает этот рассказ без тени улыбки, потому что "кто в армии служил - тот в цирке не смеется"

(25) с таким подходом ты никогда не станешь серьезным разработчиком, так и останешься 1с-ником....

(0) архитектор приложений БД должен всего 2 вещи
1. представлять порядок изменения в объёме и функционале через N лет (обычно это 5 лет)
2. обеспечить в системе отсутствие стоп факторов для таких изменений.


пример
Есть ТЗ примерно такого содержания: сделать делаем заявки с вложенными файлами, размер 1 файла 0.5 метра планируется 10 000 заявок в год.
Простой кодер банально посчитает 0.5 * 10000 * 5лет = 25 гигов и исходя из этого будет планировать место хранения...

Архитектор обязательно введет дополнительные коэффиц.
1. на версии файлов (в среднем 3 версии на 1 заявку)
2. сопутствующие файлы (акты, договоры 10 видов)

и будет считать место так 0.5 * 10000 * 5лет * 3 * 10 = 150 гиг.

(43) а хороший архитектор увеличит финальную цифру на 25%-50% - в зависимости от веры словам заказчика.

(43) Да-да.  Проектировать объемы - это вообще "пальцем в небо". Хорошо, если сможешь предсказать с вероятностью 50%. И то...  Я бы не рискнул делал подобные прогнозы на 5 лет.  Тут на три года бы "попасть". А на пять лет - это плюс/минус километр.