DataLife Engine > Блог / Статьи о главном > Шаблоны как ускорители

Шаблоны как ускорители


6-02-2015, 20:24. Разместил: admin
Многие ли программисты в своей работе в последующем для себя универсализируют модули, отчеты, обработки, которые написали? Или к каждому новому отчету приступают через конструктор и делают его с нуля?
 
Кто из них позаботился о себе и подготовил шаблоны? Здесь речь не столько чтобы программисты о себе позаботились. Здесь важно понять, что именно через однородный повторяющейся способ настройки интерфейса программы дает результат ускорения работы в том числе и самих пользователей информационной системы. А в руках специалиста, который настраивает этот инструмент, появляется скорость разработки и внедрения нового, которое по-сути являться уже будет не столько новым, сколько расширением действующего.
 
Шаблоны представляют собой готовые решения часто встречающихся проблем и ситуаций в процессе разработки программы.
 

 

«Великие возможности приходят ко всем, но многие даже не знают, что встретились с ними»
У.Э. Чэннинг


Много лет мы считали, что достаточно знать в какой конфигурации 1с можно взять тот или иной кусок учета, скопировать его оттуда и внедрить в другое место. И в этом, по-большей части, полагались на собственную память. За гонкой, чтобы как можно быстрее сделать, быстро получить данные, мы не замечали, что многие вещи - элементы решений довольно часто повторяются. Конечно, всегда брали за основу подходящий отчет или обработку, и переделывали ее под реализуемую задачу. Много раз приходилось в буквальном смысле рыскать по всей конфигурации в поисках того, что где-то подобное мы уже делали. Также довольно часто в разработки привносились небольшие «фишки», которые так и оставались там внутри в этих обработках. И если кому-то это стало нужно в новой разработке, то оттуда можно было бы забрать, при условии, что мы о них вспомнили.

 

 

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

 

 


Ты можешь уметь что угодно, пока ты не докажешь это  — ты не умеешь ничего! Ричард Дэвид Бах (американский писатель, философ и публицист) 
    
Необходимо позаботиться о себе и дать возможность работать с полной линейкой инструментов, которые используется в программе. Неплохо было бы иметь побольше шаблонов. А еще лучше иметь под рукой такую картотеку, где будет все запротоколировано, что можно взять и откуда. Так называемую  — базу знаний.

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

 

 


 

Удобство работы

 

Под удобством работы с шаблонами (usablity of template) подразумеваем следующее,  — это то качество шаблонов, которое делает отчет или обработку или документ или справочник, построенные на них, более удобными в работе со всей совокупностью инструментов, которые встречались на практике и были удобными самим пользователям, а также разработчикам при внедрении.

 

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

 

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

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

 

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

 

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

 


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

 

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

 

 

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

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

 

 

 

 


Каждая песчинка важна

 

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

 

 


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

 
«Мало обладать выдающимися качествами, надо еще уметь ими пользоваться»
Ф.Ларошфуко

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

 

 

Работа в этом направлении далеко не закончена, это постоянная каждодневная (!) работа. Нет предела совершенству. Открыв любой объект, мы постоянно привносим изменения для увеличения удобства работы интерфейса (юзабилити).


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

 

 


Разработки «на коленках»

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

 

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

 

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

 

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

 

«Вещи, которые выглядят по-разному должны действовать различно. Вещи, которые выглядят одинаково, должны действовать так же»
Larry Marine



Бизнес покупает услугу по той цене, которою считает справедливой

 

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

 

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

 

 

Об универсальном подходе не было и речи. А ведь достаточно было подойти более комплексно: объединить все в подсистему, где по-сути нужно было бы войти в одну обработку по типу АРМа – автоматизированного рабочего места. И в нем найти и настроить все то, что требуется для учета, проверки и настройки данной подсистемы. Да, для этого потребовалось бы в два-три раза больше времени разработчику. Но это правильный подход, который исключает по максимуму вопросы по ее функционалу, т.е. минимизирует обращение к инструкции.

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

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

Результатом таких действий у нас, например, получилась линейка универсальных инструментов, которая позволяет создавать новые вещи гораздо быстрее, выдавать не просто хороший результат, а выдавать целые автоматизированные рабочие места  — АРМы. При этом они стали как на стройке «по кирпичику» складываться очень быстро в единые комплексы.
 
Соберите свой «кейс» всех внедрений. Возможно, вы делаете одно и то же, только разными способами. Так может быть лучше пользоваться одним универсальным и закрепить его во всех местах. И тогда вы, как с эскалатором, всегда сможете уже наработанные модули («ступеньки») использовать по кругу в нескольких разработках, вместо того, чтобы постоянно выстраивать новую лестницу.
 

 

 


Вывод

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

 

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

- на своевременное завершение работы над проектами,

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

- позволяет упростить поддержку разработки,

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


 

 

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

 

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

Хаки для Dle 10.4
скачать форекс советники Ilan

Вернуться назад