Нужна ли "инженерия кодинга"?

[valexey]

Оригинал где-то там: http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838

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

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

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

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

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

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

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

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

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

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

[alexus]

Оригинал где-то там: http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838

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

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

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

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

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

(выделено мной)
Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"

[valexey]

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

[Илья Ермаков]

Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"

Ну, alexus уже не раз обхаивал обычную науку, обычную инженерию... Несистемные мы, с его точки зрения. Частностями занимаемся, через опыт и "набивание шишек". А ему доступно знание "сразу и целиком".
Поэтому я не упрекаю его в том, что он не понимает, что развитие в науке/технике, конечно, многовариантно, но каждый из эффективных вариантов, "путей", как правило, "авторитарен". В том смысле, что не предназначен для бездумного смешивания с другими. Нельзя собрать массу людей и сказать "пусть каждый работает, как хочет, любыми методами" - и получить результат. Если на вершину есть несколько путей, то вам придётся выбрать один, которым будете восходить вы. Почему-то этот простой факт вызывает всегда обвинения в отрицании других путей. "Как? Вы выбрали один путь? Так вы считаете, что все другие неверные? Что мой и его и вот его пути неверные? Вы диктатор и не уважаете нашу свободу".
Нужно понять и принять тот простой факт, что в рамках какого-то выбранного пути приходится часто отрицать смешение с другими путями - не потому, что они неправильные, а потому, что они находятся с другой стороны горы, и у вас не хватит расстояния между ног, чтобы идти ими обоими.

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

[alexus]

Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"

Ну, alexus уже не раз обхаивал обычную науку, обычную инженерию...

Про "обычную науку" - всё правильно, а вот про "инженерию" - это Ваши фантазии...

Несистемные мы, с его точки зрения.

И это Ваши фантазии.

Частностями занимаемся, через опыт и "набивание шишек". А ему доступно знание "сразу и целиком".

И это Ваши фантазии. В частности, я много раз говорил о великой пользе ошибок/шишек. Пусть "сразу и целиком" останется на Вашей совести.

Поэтому я не упрекаю его в том, что он не понимает, что развитие в науке/технике, конечно, многовариантно, но каждый из эффективных вариантов, "путей", как правило, "авторитарен".

Это нечто новенькое... Можно подробнее... Не Вы ли говорили о том, что надо искоренять "велосипедостроение"? Не Ваши ли это слова:

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

Откуда же возьмётся многообразие, если все должны писать одинаково?.. Так, кто не понимает многовариантность развития: Вы или я?.. Почему путь "авторитарен" вообще непонятно.

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

То есть, "работать, как хочет" - это Ваш вариант творческого процесса?.. Ну... что можно сказать... оригинально, конечно, и смело... слишком... смело. Было бы лучше сначала подумать, а потом написать, а не наоборот.

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

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

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

И на этом основании надо отрицать наличие других путей?.. Мне кажется, что это... глупо.

[Илья Ермаков]

Мне в упор не понять, почему ввести правила на отдельном форуме - это заставить всех и везде.
Можно подумать,  кто-то что-то Вам обещал, а потом не оправдал ваших ожиданий?

[valexey]

Конструктор не боится индивидуально для своей конструкции, если это обосновано, спроектировать и обсчитать нестандартную часть. Нестандартную арку. Или нестандартную передачу.

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

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

PS. В плане не софтвера, а железок/устройств попытки применить "не стандартное" я вижу своими глазами. Обычно оно режется сразу на уровне идеи, хотя, теоретически, с нестандартной деталью оно было бы лучше. У устройства появились бы например новые свойства выводящие его вперед относительно конкурентов. Только вот это устройство так до производства, и тем более до конечного пользователя, не дошло бы никогда. С нестандартной деталью. Либо дошло бы, но с совершенно не конкурентной ценой.

[Илья Ермаков]

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

[valexey]

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

Мы сейчас вступаем на скользкую дорожку аналогий софтверной отрасли с физическим миром. Эта дорожка пока еще никого до добра не доводила :-) (см. например битвы вокруг копирайта и прочей коммерции).

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

[Илья Ермаков]

Откуда же возьмётся многообразие, если все должны писать одинаково?.. Так, кто не понимает многовариантность развития: Вы или я?.. Почему путь "авторитарен" вообще непонятно.

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

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

Разумеется, всегда небольшое число исследователей продолжает изучать и старые вопросы. И часто находит новые решения. Но не все топчутся на одном месте и в сотый раз решают уже решённые задачи.
В этом смысле я тоже как раз попадаю под категорию таких исследователей. ИТ-отрасль не решила проблемы уровня "кодинга" (я не люблю это слово, просто dizer мне тут его "повесил" - и я его буду употреблять в нашем разговоре), но просто нашла способы их "изолировать" - парировать проблемы уровнем выше, процессами разработки. Я же как бы зову назад: давайте всё-таки дорешаем...
P.S. Не нужно думать, что я тут только этим и занимаюсь, как этими проблемами.

[valexey]

Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам.

К слову, я пока не видел ни одного безопасного языка. То есть для защищенности ВСЕГДА нужно разносить компоненты по разным адресным пространствам. А еще лучше - по разным машинам.

[Илья Ермаков]

"Почему авторитарность".

Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко

Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
У сообщества своё понимание "пути к вершине", они и сами им идут, и желающих берут "в поход".
Поскольку люди широких интересов, то интересуются они и вообще сферой боевых искусств. Поэтому на форуме есть разделы, где все желающие могут обсуждать и дзюдо, и айкидо, и каратэ-до. Хозяева форума не прочь послушать и пообщаться и на эти темы.
Проблемы бывают трёх категорий:
1) Поклонники "дворового мордобоя", которых в обществе вокруг очень много, и которые не прочь постоянно похаять боевые искусства, как "бесполезные", "академические", "непрактичные" и проч.
2) Поклонники других направлений боевых искусств, которые считают, что направление хозяев устарело, будет отмирать, и только направления их типа выживут в будущем.
3) Люди, не выделяющие течений, а считающие, что есть "боевое искусство вообще". Когда они видят попытку развить отдельное направление в его чистой форме, они искренне возмущаются "авторитарности" этого направления, его "косности" и нежеланию "заимствовать". "Ну почему бы вам, дзюдоистам, не прикрутить вот эту замечательную штуку из бокса?"

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

[valexey]

Забавно что в качестве иллюстрации выбраны именно боевые искусства :-)
Замечу, что боевые они нынче именно что искусства. В том плане, что наличие ножа у обычного человека резко повышает его "уровень", чуть ли не до черного пояса. Интересующиеся могут посмотреть тут и вокруг: http://thesz.livejournal.com/1172418.html?thread=9887682#t9887682

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

Так вот - в плане программирования нам нужно что - шашечки, или ехать? Красивая традиция, древняя культура, или же практическая ценность?

[Илья Ермаков]

Рассмотрите мой пример применительно к разным течениям рукопашного боя спецслужб, например. Там тоже нет "единого рукопашного боя". Есть, например, стиль Кадочникова. Есть другое.. и т.п.

[DIzer]

"Почему авторитарность".

Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко

Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
У сообщества своё понимание "пути к вершине", они и сами им идут, и желающих берут "в поход".
Поскольку люди широких интересов, то интересуются они и вообще сферой боевых искусств. Поэтому на форуме есть разделы, где все желающие могут обсуждать и дзюдо, и айкидо, и каратэ-до. Хозяева форума не прочь послушать и пообщаться и на эти темы.
Проблемы бывают трёх категорий:
1) Поклонники "дворового мордобоя", которых в обществе вокруг очень много, и которые не прочь постоянно похаять боевые искусства, как "бесполезные", "академические", "непрактичные" и проч.
2) Поклонники других направлений боевых искусств, которые считают, что направление хозяев устарело, будет отмирать, и только направления их типа выживут в будущем.
3) Люди, не выделяющие течений, а считающие, что есть "боевое искусство вообще". Когда они видят попытку развить отдельное направление в его чистой форме, они искренне возмущаются "авторитарности" этого направления, его "косности" и нежеланию "заимствовать". "Ну почему бы вам, дзюдоистам, не прикрутить вот эту замечательную штуку из бокса?"

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

Ого,какие хорошие ХОЗЯЕВА  и слушают и общаются.... а остальные да, плохие - но ладно, за что же вы тогда "своих" то "мочите" - за то, что им стало тесно работать в вашем "стиле" делать Q при упоминание Вирта, "страшно выпучив глаза" каждое утро орать принцип Калашникова -а пытаются хоть как -то связать коровник с реальностью?-любители "определенного" стиля