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


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ют. Альберт Эйнштейн
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует