OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:09

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 8 ] 
Автор Сообщение
 Заголовок сообщения: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Суббота, 11 Февраль, 2012 10:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Так получилось, что уже не раз люди, ратующие за "анализ сложных задач" и т.п., бросали мне упрёк, что я акцентирую внимание на "всякой ерунде, этого внимания не заслуживающего". На данном форуме это некогда делали и alexus, и Galkov, и другие.
Поскольку непонимание до сих пор имеет место быть... Возникло желание разъяснить данный вопрос.

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

2) Ну а теперь про "рутину".
На мой взгляд, одна из нерешённых проблем в ИТ - внедрение "инженерного подхода" на уровень кодирования. Под этим я понимаю:
- гарантированное получение результата (мы доверяем тому, что написали, даже до тестирования, зная, что оно правильное с точностью до опечаток и глупых ляпов, которые и должно будет "срезать" тестирование);
- снижение многообразия в коде, его "обезличивание" (чтобы два обученных "инженерии кодинга" программиста выдавали практически одинаковый код);
- снижение рисков в "велосипедостроении" (чтобы банальная необходимость написать какой-то поисковый или сортирующий цикл не вела к трудностям, ломанию мозга и повышению плотности ошибок. Как выразился Пётр Алмазов - "я хочу переезжать такие задачи трактором, практически не снижая скорости").

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

Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам. Ошибки и разрушение памяти неизбежно - выстроим аппаратные барьеры, и пусть там компонент чудит как хочет. Надёжность обеспечим уровнем выше, на всём множестве изолированных компонентов.
Кстати, именно по такому принципу разрабатывется - и вполне успешно - софт в РКК "Энергия". В частности, для российского сегмента МКС. Недавно на одном отраслевом мероприятии они подробно рассказывали. Используется C++ и инфраструктура GNU, используются библиотеки типа boost, работает это всё на базе QNX и Винды. "Инженерный подход" имеется на уровне организации системы из изолированных компонентов, которые обмениваются данными по протоколам. Проблема кодинга и языка программирования "изолирована" в этих "резервациях". На вопрос: сравнивали ли С++ и Аду? - отвечали: да, конечно, но где нам брать программистов на Аде? И добавляли: "главное - правильная организация жизненного цикла ПО". И я полностью с ними здесь соглашусь. Но если ряд проблем можно решить ниже, ещё на уровне "программирования в малом", зачем тратить усилия на их парирование на организационном уровне?

Чтобы парировать "любой бред" на уровне модулей, используют модульное тестирование. Нет, я не против его - но я хочу, чтобы на тестирование выходил уже практически правильный модуль. Это позволяет нам иметь хорошее качество БЕЗ модульного тестирования, и просто отличное - если потратить дополнительные усилия на него (в ответственным случаях).

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Суббота, 11 Февраль, 2012 11:49 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Все правильно.

И я согласен с высказанным.

Кстати, не случайно возник же термин software engineering!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Суббота, 11 Февраль, 2012 12:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Что я имел в виду выше под "нестандартными конструкторскими решениями"?
В первую очередь вот что:

В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле.
Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. :) Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом.
Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 17 Февраль, 2012 12:06 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Как синхронно, однако, мы мыслим... :) Одно из добавлений к графит-методу, которое делал во время отсутствия на форуме, как раз касается различия между повторным использованием "для содержания" и "для представления" - в Правиле 239 здесь. Как раз для этого набросал схемы, иллюстрирующие, видимо, и сказанное Вами насчёт "когда не надо упаковывать"... :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Пятница, 17 Февраль, 2012 16:34 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Что я имел в виду выше под "нестандартными конструкторскими решениями"?
В первую очередь вот что:

В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле.
Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. :) Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом.
Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч.


На самом деле возможны и другие альтеранативы:
  • копирование и доработка (метод, порождающий ошибки),
  • сниппеты, требующие наполнения (этот вариант очень хорош для структурных редакторов),
  • "пустые" шаблонные объекты/модули/подсистемы и т.п. (тоже для структурных редакторов) - отличаются от сниппетов поддержкой внутренней структуры редактором.
Два последних варианта дают повторное использование на физическом, а не ментальном уровне - но при отсутствии сложности ООП и проблем с упаковкой "неупаковываемых" задач.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Понедельник, 20 Февраль, 2012 11:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
В принципе, да.

Но здесь нет связи между исходным образцом и всеми его местами применений. И, в принципе, это ПРАВИЛЬНО (если мы выпускали приборы на старых микросхемах - и вдруг появились новые, от этого в старых приборах они не обновятся).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Понедельник, 20 Февраль, 2012 13:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
...Зато "прошивки" можно обновить (для тех же микросхем)... :)
Видимо, шаблоны - что-то из разряда графит-областей - сегодня одно наполнение, завтра - и/или другое...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нужна ли "инженерия кодинга"?
СообщениеДобавлено: Понедельник, 20 Февраль, 2012 16:11 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
...Зато "прошивки" можно обновить (для тех же микросхем)... :)
Видимо, шаблоны - что-то из разряда графит-областей - сегодня одно наполнение, завтра - и/или другое...


Сам по себе структурированный сниппет (заполняемый шаблон) стабилен, что обеспечивает простое и безошибочное применение в указанных Ильей Ермаковым случаях:
  • задание архитектуры/структуры программы;
  • задание универсальных алгоритмов обработки данных разнообразных типов (вместо C++ ых шаблонов).
Тяжело было бы работать с инструментом, который кардинально обновляется прямо у Вас в руках: взялись за рубанок, а он превратился в молоток.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 8 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB