Вход | Регистрация


1С:Предприятие ::

Метки: 

Как стать хорошим архитектором своей системы?

Я
   breezee
 
28.12.17 - 20:00
Собственно, сабж
 
  Рекламное место пустует
   breezee
 
1 - 28.12.17 - 20:01
А, ну да, основы знаю, ******* написана куча, а вот хорошую архитектуру строить не научился совсем
   nordbox
 
2 - 28.12.17 - 20:08
Вроде еще не тяпница ))
системы чего?

— Семёнов, ты по какой системе водку будешь пить?
— А ты по какой пьёшь?
— Я по ян.
— Тогда я по инь.
— Это для гармонии?
— Да нее… я ж на службе!
(с) "Операция с новым годом"
   mingw
 
3 - 28.12.17 - 20:11
Хороший архитектор. Это у кого здания (системы) не падают.

Ну или не посадили. Еще. Когда упали.
   breezee
 
4 - 28.12.17 - 20:12
(2) Ну, начинки конфигурации, метаданные, алгоритмы. Есть что прочитать про примеры разработки? Не книги, где учат базовой работе, а книги по разработке, может с примером?
   NorthWind
 
5 - 28.12.17 - 20:13
(1) опыт, сyко, сын ошибок трудных. Пока пару раз с нуля или около того не перепишешь одно-двух-трехнедельную работу из-за того что чего-то изначально не предусмотрел - вряд ли начнешь печенкой понимать что и как делать
   NorthWind
 
6 - 28.12.17 - 20:16
чтобы чего-то делать хорошо - надо это много делать. Других вариантов не вижу. Книги хорошо и нужно, но они не дают того чего дает практика. Их только вместе с практикой употреблять можно.
   nordbox
 
7 - 28.12.17 - 20:20
(5) +100500
(4) Прежде все это четкое понимание что ты хочешь, после этого много, много, много, и еще раз много думать, рисовать, пробовать, проверять, мозги ломать, работать до тех пор пока по экрану буквы ползать не начнут... )  
это если хочешь сам учиться
   Lama12
 
8 - 28.12.17 - 20:20
(0) Жизнь научит. Но больно! :-)
   nordbox
 
9 - 28.12.17 - 20:22
(0) у тебя хоть какое то понимание про вот это есть?
https://studfiles.net/preview/4229380/
   nordbox
 
10 - 28.12.17 - 20:22
+9 ну может ты где то что то учил?
 
  Рекламное место пустует
   mingw
 
11 - 28.12.17 - 20:24
(9) Это бесполезные знания. И даже вредные. Для архитектора систем. Не простого кодера.
   mingw
 
12 - 28.12.17 - 20:26
   nordbox
 
13 - 28.12.17 - 20:28
(11) Ну почему?
Он же говорит про внутренности про методанные, вот пусть сначала просто поймет из (9):
Алгоpитм – это точное и понятное предписание исполнителю совершить последовательность действий, направленных на решение поставленной задачи.
   mingw
 
14 - 28.12.17 - 20:30
(13) Архитектура это не предписанный алгоритм.

Архитектура это полнота моделирования/описания допустимых процессов/ситуаций. Даже пока несуществующих. Но возможных в будущем.
   nordbox
 
15 - 28.12.17 - 20:31
+13 Кроме того архитектором системы он ни когда не станет не зная на что способна среда обитания системы
   mingw
 
16 - 28.12.17 - 20:35
(15) Среда обитания меняется очень быстро.
Архитектуре на это пофиг.

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

Еще скажи кодер обязан знать особенности n-p-n и p-n-p переходов и устройстов/принципы работы электроники.
   nordbox
 
17 - 28.12.17 - 20:45
(16)>>Еще скажи кодер обязан знать особенности n-p-n и p-n-p переходов 
и про туннельные переходы и т.д. тоже )
Обязан. Если кодер будет делать конфу на эту тему, а точнее он ее не сделает не зная предметной области.
   nordbox
 
18 - 28.12.17 - 20:55
(16) Помнишь в лихие 90-е на машинах на стоп сигналы еще делали гирлянды с бегущими огнями? в основном все привозили из китая? )))
я когда курсантом был, то на TTL-овской логике это все сам разрабатывал и на коленках в мыльнице делал, ну жить надо как то было ))
   Лефмихалыч
 
19 - 28.12.17 - 21:05
(4) что членом на старте не вложено, то потом книжкой не вобьешь
   nordbox
 
20 - 28.12.17 - 21:11
(19) Как всегда пять балов ))))
   Лефмихалыч
 
21 - 28.12.17 - 21:13
(20)


   nordbox
 
22 - 28.12.17 - 21:23
(21) Присоединяюсь ))
спасибо за предложение ))
С Новым годом!
   mingw
 
23 - 28.12.17 - 21:53
(17) Исполнитель должен уметь использовать инструмент.
Не как его (инструмент) делать. И как чинить.

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

Случаи информатизации процесса "создания инструментов" не учитываем. Тут предметка вынужденно.
   stopa85
 
24 - 28.12.17 - 22:06
Для задач системного администрирования я выработал три принципа:
1) Дублирование
2) Резервное копирование
3) Мониторинг

Для задач ИТ систем, пока прокатывает нечто более абстрактное:
1) Называть вещи своими именами.
   H A D G E H O G s
 
25 - 28.12.17 - 22:08
(0) Я просто сажусь и делаю.
Особо не думаю.
Никогда не рисую схемы, не пишу себе ТЗ, дичь это, некогда.
Иногда задумка не удается, переделываю.
В любом случае, мне проще набросать каркас кодом и метаданными и потом, в случае успеха, нарастить все мясом, чем думать.

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

Не гнушаюсь взять и перепилить кусок архитектуры, с написанием обработок переноса данных, ПРОСТО потому что мне так видится лучше, в свободное от работы время.
   H A D G E H O G s
 
26 - 28.12.17 - 22:15
Не гнушайтесь тратить время на написания хорошего кода.
Хороший код пишется быстро.

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

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

Есть еще один момент. Если я долго поддерживаю какую то конфу - в ней может накопиться много костылей-доработок, критичная масса которых вызовет во мне желание переписать блок, универсиловав функционал. Гоните свою лень и недовольство пользователей-программистов которые у вас на поддержке и переписывайте.
   Юрий Лазаренко
 
27 - 28.12.17 - 22:15
(16) Еще Аль Капоне говорил, что с помощью кодинга и знания особенностей n-p-n и p-n-p переходов можно достичь гораздо большего, чем с помощью только кодинга.
   art commander
 
28 - 28.12.17 - 22:32
(1) Архитектуру надо не строить, а использовать. Можно начать с этого.
   mingw
 
29 - 28.12.17 - 22:40
(27) Замечательный пример. Посадили за неуплату налогов. Архитектура подкачала.

Но согласен что знать два инструмента лучше чем только один.
   stopa85
 
30 - 29.12.17 - 06:18
(28) Кстати, да)
   VladZ
 
31 - 29.12.17 - 06:43
(0) Чтобы быть программистом - нужно думать, как программист. Чтобы быть архитектором - нужно думать как архитектор. Т.е. какие объекты нужны для системы, как они будут взаимосвязаны и какая структура будет наиболее оптимальна. Как с точки зрения производительности, так и с точки зрения сопровождения этой структуры.
   nordbox
 
32 - 29.12.17 - 07:53
(31) >>какие объекты нужны для системы, как они будут взаимосвязаны и какая структура будет наиболее оптимальна. Как с точки зрения производительности, так и с точки зрения сопровождения этой структуры.

Вот это правильно, если архитектор не будет знать внутренностей, то как он будет думать про производительность и сопровождение?
   d4rkmesa
 
33 - 29.12.17 - 08:23
(0) Часть архитектуры реализована платформой, разработчику следует только придерживаться рекомендаций в большинстве случаев - создавать структуру данных как пишут в желтых книжках и не допускать совсем уж грубых ошибок. Есть, конечно, программные механизмы, вроде того же партионного учета или РАУЗ, которые следует делать с оглядкой на производительность и масштабируемость решений - это уже можно назвать архитектурой, но часто ли приходится что-то подобное реализовывать? Ну или часто в отраслевках свои уникальные костыли, вроде хранения остатков в регистрах сведений или реализация бюджетирования каким-то уникальным способом. Там да, видно что была работа для архитектора. А так, в большинстве случаев понятия "архитектор" и "1С", имхо, нерелевантны.
 
  Рекламное место пустует
   PCcomCat
 
34 - 29.12.17 - 08:24
Иногда, мне кажется, что достаточно того, чтобы у человека был сертификат "Профессионал по платформе". Это хотя бы гарантирует, что человек узнает о наличии многих объектов в системе кроме наличия справочников. Потому как просто страшно, когда менеджер проектов проектирует хрень, и искренне считает, что он гуру. Да, она - эта хрень - работает, но как...?!

После увиденного я понимаю, что не важно как ты проектируешь, важно то, как ты это преподносишь и как возносишь себя в глазах клиента. Но, к счастью, не все так могут.
   PCcomCat
 
35 - 29.12.17 - 08:29
— Что это за книга? Роман?
— Нет, детектив.
— Страшно?
— Бывает страшно, бывает и нет. В основном, пугает то, как паршиво написано.

(С)Из фильма «Реальная любовь»
   Mort
 
36 - 29.12.17 - 08:38
(0) Архитектура много чего бывает. Архитектура функциональности всего приложения, архитектура окружения, в котором ПО работает, архитектура БД, конкретных модулей и даже пользовательского интерфейса.

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

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

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

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

Ну и архитектура интерфейса пользователя, единственное что видит пользователь, лицо программы, на которое многим почему-то наплевать. Так что херач на формы побольше ярких цветов и разных шрифтов. Или почитай умные книжки по дизайну.
   Dotoshin
 
37 - 29.12.17 - 08:45
(0) >>
- Инженеры! - продолжал Модели, вложив в это слово чуть ли не пуд презрения. - "Творчески одаренные и рационально мыслящие ученые, которые способны выстроить планету в любое время в любом месте". Хоть одному из вас знакома эта фраза?

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

- Правильно, - подтвердил Модели. - А теперь скажите, можно ли вот это назвать образцом творческого и рационального подхода к инженерному искусству? (c)
Полностью здесь http://www.metodolog.ru/00179/00179.html
   ildary
 
38 - 29.12.17 - 08:46
(36) категорически не согласен с выражением "побольше ярких цветов и разных шрифтов" - потому что на выходе получается мегапрайс и прочие попугайства в стиле "поиграйте со шрифтами". Наоборот в таких вещах нужна осторожность, чтобы не перегрузить внимание пользователя.
   Mort
 
39 - 29.12.17 - 08:46
(38) Это я тонко пошутил.
   ildary
 
40 - 29.12.17 - 08:51
(39) спасибо за уточнение, я представил как кто-нибудь прочитает эту ветку и в голове отложится - "яркие цвета на форме - гут".
   nordbox
 
41 - 29.12.17 - 08:53
(0) Хочешь потренироваться на кошках? )))
Напиши для себя что нибудь, типа домашнюю бхглактерию))
или возьми любую задачу которую реализовал кто угодно,
и не подсматривая во внутренности уже готового, сделай свое, как ты это видишь, потом сравнишь.
   ildary
 
42 - 29.12.17 - 08:57
(37) мне кажется, что любой одинэсник с несколькими внедрениями прочитает этот рассказ без тени улыбки, потому что "кто в армии служил - тот в цирке не смеется"
   vde69
 
43 - 29.12.17 - 09:17
(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 гиг.
   ildary
 
44 - 29.12.17 - 09:24
(43) а хороший архитектор увеличит финальную цифру на 25%-50% - в зависимости от веры словам заказчика.
   VladZ
 
45 - 29.12.17 - 09:35
(43) Да-да.  Проектировать объемы - это вообще "пальцем в небо". Хорошо, если сможешь предсказать с вероятностью 50%. И то...  Я бы не рискнул делал подобные прогнозы на 5 лет.  Тут на три года бы "попасть". А на пять лет - это плюс/минус километр.



Список тем форума
 
Кaк может человек ожидaть, что его мольбaм о снисхождении ответит Тот, кто превыше, когдa сaм он откaзывaет в милосердии тем, кто ниже его? Петр Трубецкой
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует