Программерский подход к технологиям работ

Проекту исполнилось 15 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".

Число просмотров: 16 706 

ВНИМАНИЕ! Мне не хотелось бы, чтобы этот пост был опубликован на других ресурсах (репост). Я хочу сохранить за собой право на его уникальность. Публикация поста возможна на определённых условиях.

Я тут в очередной раз распинался на форуме по поводу того, как круто что-то делать такими способами, при которых ты очищаешь мозги, и решил наконец-то набросать небольшой пост по этому поводу на блоге. В этот раз картинок не будет, потому что не с чего =)

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

xxx: мля… я наконец отчетливо понял разницу между инженером и программистом
xxx: Инженер сначала продумает чертеж, учтет все на бумаге, а потом соберет корабль. Прораммист сначала наделает переборки, движки, каюты, пластины корпуса, а потом будет долго ебать мозг как эту груду металлолома собрать в корабль и чтоб оно хотя бы не потонуло через 10 секунд после спуска на воду.

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

При таком подходе мы получаем следующий профит:

  • Пока мы выделяем какие-то куски программы, мы сами же лучше понимаем её структуру. Образно говоря, чтобы выделить куски — надо хотя бы блок-схему нарисовать. А потом ей же можно и пользоваться;
  • Каждый кусок можно отлаживать отдельно и гонять как влезет. Например проверять, как какая-нибудь функция будет вести себя при неверно заданных параметрах, или ещё чего-то в этом роде;
  • Сокращение количества ошибок. Потому что ты сначала отладил все свои блоки, а потом, зная что они работают 100% верно, собираешь и отлаживаешь всю программу. Причём можно даже рассуждать по другому: «Блок работает верно. Значит косяк не в нём!»

То-есть, подход получается таким: Конечный результат -> Структурная схема -> Блоки -> Сборка из блоков.

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

Самая главная фишка такого подхода в том, что МОЗГ ЧИСТ. Это сначала смешно, а потом, когда понимаешь то, о чём идёт речь, начинаешь уважать этот подход к работе.

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

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

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

Дальше я не умею объяснять, поэтому переношу мой подход на электрику. Именно так я и работал, когда по квартирам бегал.

Итак, наша задача: электрика под ключ. Без ошибок. Значит её надо разбить на этапы. На какие? Сначала — на крупные: составить план, отштробить и растянуть кабели, собрать щиток, после отделки всё подключить. Но кто-то задумывался о том, что даже черновую стадию ремонта можно делать по такому же подходу?

А вот поглядите:

1. Нам нужна разметка. Значит лазерный уровень. Зашибись. А что размечать? А просто УРОВЕНЬ! Возьмём и отобьём какую-то черту по всем-всем стенам (даже там, где она не нужна). А какой уровень? А вот тут нужен мозг. Мозг говорит: надо взять что-то такое, что можно было бы считать «базой» для других измерений.

Отлично. Значит возьмём уровень в 1 метр от чистого пола. Отбили лазерником, и — внимание! — лазерник лично нам больше на этом объекте вообще не нужен никогда: у нас есть черта. А значит этот самый лазерник не будет валяться в грязи при штроблении, не попадётся под ноги и его не своруют с объекта.

А что же черта? А теперь выключаем мозги! Возьмём и пересчитаем наши «координаты» с абсолютных на относительные! Вместо «розетка ставится на 200 мм от чистого пола» переведём это в «розетка ставится в 1000-200 = 800 мм от черты». И так же для выключателя (100 мм от черты). Вот тут и сработал наш подход: мы вообще уже «не знаем», откуда там эта черта взялась, нафиг она нужна. А работаем по мелкой задаче, в которой вероятность ошибки мала: «Отбей от черты горизонтали блоков выключателей и розеток».

Единственные моменты, где нам надо думать головой — это нестандартное расположение блоков розеток. У кого-то телевизор висит на стене, и там надо сделать розетки на высоте 1200 от пола. На кухне над фартуком надо сделать на 1100 от пола. Но так у нас же есть ЧЕРТА! =) Вот только тут мы вспоминаем что она у нас 1000 от чистого пола — и откладываем от неё необходимое.

2. Ну, отбили блоки розеток, наметили центра. Теперь нам снова надо «забыть» разметку блоков розеток. Как это можно сделать? А возьмём бур и просверлим ВСЕ (везде, по всей квартире) центра подрозетников. Иии… забудем про них нахер. А про то, где там выключатель или розетка — мы даже и не начинали вспоминать.

Опять очистка мозга: использовали только один инструмент — значит ничего не потеряется, не изгрязнится: инструмент же один, в твоих руках, на глазах и на виду. А ещё у нас же стена не долбленная. Значит вся разметка на виду, и центра можно проверлить очень точно.

А теперь берём коронку и снова, не думая, исполняем новую задачу: «везде, где есть дырка — ебошь подрозетник коронкой!». Обратите внимание, как просто ставится задача на этом этапе. А это значит, что её просто и проверить («а вот тут дырка — где подрозетник? почему забыл?») или даже продолжить вообще другому человеку.

3. Штробы. Опять всё предыдущее забыли! Мыслим так: «Во! Откуда-то у нас тут есть дырки. Надо штробить!». Снова бросаем все инструменты нафиг, убираем их. Берём план помещения и работаем мозгами: соображаем, сколько кабелей в какой штробе пойдёт. Ну я например писал на стене что-то вида «2х», «4х».

Как только сообразили — снова очистили мозг (на стене теперь есть пометки — по ним и работаем) и режем штробы.

4. Кабели. Опять: есть список кабелей. Тяни и вычёркивай. Всё =)

Ну и так далее.

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

Этот подход позволяет всегда иметь свежую голову во время работы, адски экономит время и … ну у меня как-то всё автоматически получалось: весь инструмент на своих местах, и к тому, что я сделал — я не возвращаюсь. Ну то-есть не было такого, чтобы я потом носился по квартире с видом «ой, блин, а теперь тут надо поддолбить, тут срезать».

Ну и, как потом оказалось, весь этот подход «чёрного ящика» можно использовать вообще ВЕЗДЕ. Вот даже ща я пост накатаю и про него «забуду» =)

Проекту исполнилось 15 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".

20 Отзывов на “Программерский подход к технологиям работ”


  • Это же пакетная обработка. Сначала всю работу этого типа, потом другого и т.д. И на конвейер, в принципе, похоже.

  • 2 CS  [Москва]

    Хм! Ну вроде на Фордовский конвеер похоже, ага.

    Просто для таких задач она вообще идеально подходит: сделал — забудь!

  • 3 Intelligent being

    Очень удобный подход, экономит время и силы :)

  • 4 eleclab

    Структурное программирование (СП) — отец-основатель Н.Вирт и другие, рулит и будет рулить, пока во главе представления мыслительной деятельности человека выступает логика. Правда использование СП, после появления мудаков от бизнеса, и по совместительству агитаторов за ООП, ушло в тень на долгий период, сейчас вроде опять начинает выходить в общемировой тренд. Ибо вечно разбирать тонны багов дерьмо-классов индусов, при сопровождении проектов, ни у кого нет желания.

    А так, да подход СП использую в жизни постоянно. Не думал, что это такое откровение :) Как и для большинства, становится откровением, действенность принципа Парето в повседневной деятельности :D

  • 5 shp

    Только у меня было как раз наоборот: я успел застать старую школу…

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

  • 6 Ivan_OS

    Если говорить про подход к кораблю, то с появлением САПР типа SolidWorks и некоторые инженеры стали строить корабль от переборок.

  • 7 sergeyev792

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

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

    Сразу видно, что это писал программист ))) Ибо первое правило инженера старой школы можно сформулировать незамысловатым постулатом: у каждого элемента системы входные и выходные параметры в отдельности одни, а когда они [элементы] собираются в систему — другие. В программировании всё просто: есть типы данных, с которыми работает программа/библиотека/процедура, и эти типа данных регламентированы и жёстко заданы. По сути это линейная задача, которая сводится к тому, чтобы к двум конфетам добавить ещё две конфеты. В реальности такого не бывает, по любому в каждой задаче данные всегда разные. А входными данными, порой, могут быть совершенно взаимоисключающие вещи. Применительно к электротехнике, напримре: стоит задача сделать корректор коэффициента мощности. Программист скажет: фигня, вона нахуярим кондёров, и всё заебись! Инженер же увидит в этом более сложную задачу, ведь коэффициент реактивности нагрузки может быть отрицательным, нулевым, положительным. Так что нахуяренные кондёры могут не решить, а сильнее усугубить проблему.

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

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

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

    Спешу вас утешить: по указанный выше причине работники просто не представляют конечного результата вцелом, поэтому в итоге получаются несоответствия. Не ОШИБКИ, а именно НЕСООТВЕТСТВИЯ. Несоответствие размерам, несоответствие взаимному расположению деталей/коммуникаций, несоответствие материала и инструмента, etc. А значит, как минимум, и конечный работяга также должен быть знаком с планом работ вцелом…

  • 8 shp

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

    Нене, без ООП иногда очень сложно ) Просто тут больше возможностей, поэтому и дров можно больше наломать если не шаришь.

    Программист скажет: фигня, вона нахуярим кондёров, и всё заебись! Инженер же увидит в этом более сложную задачу

    Не надо крошить батон на программистов, они тоже умеют думать! ) А еще они гугл написали!

  • 9 Cimmer

    по указанный выше причине работники просто не представляют конечного результата вцелом, поэтому в итоге получаются несоответствия

    Во-от, давайте побухтим про ГИПов/ГАПов. Которые, в теории, должны обеспечить полную стыковку проектов разных систем, а на практике ни хера не рубят в половине, если не больше, задач, которые на них возлагаются.
    Я за свою довольно богатую практику работы прорабом по кое-каким инженерным системам один-единственный раз видел реального ГИПа. Дядечка лет пятидесяти, с лицом завязавшего алкоголика и внешностью жэковского сантехника. Вот это был монстр. Такое ощущение, что он помнил все проекты объекта (а это, на минуточку, огромное здание в 4 этажа, 240х30 метров). Говоришь ему: Николаич, вот тут хочу лоток завести. Он полминуты подумает и отвечает: не, тут нельзя, здесь вентиляция заходить будет. Вот тебе привязка, заходи так.
    Как следствие — минимум косяков. Они возникали только из-за самодеятельности отдельных персонажей, которых потом карали анально и заставляли переделывать. А если на руках был чертеж с подписью этого ГИПа — никогда никаких накладок не было.

    Любой объект, где единовременно устанавливается более 2-х систем, нуждается в ГИПе. А у нас на мелких объектах (типа квартир) на это кладется болт. В итоге собираются 3-4 подрядчика и начинают договариваться между собой, как и что у них пойдет. И хорошо, если установятся нормальные отношения. А если попадется какой-нить говнюк, который целенаправленно будет всем гадить — вот тут-то пиздец и встанет в полный рост. А потом выясняется, что забыли пригласить каких-нить слаботочников, и в только что отделанной квартире появляется охуенно дизайнерский белый короб над плинтусом.

    В общем, Cs нам поведал, как должен работать монтажник. Но вот только на монтажнике свет клином не сошелся, и голова должна работать, в первую очередь, у ИТР. А для этого, блеать, неплохо этих самых ИТР на объекте завести.

  • 10 tomich

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

  • 11 CS  [Москва]

    Да это даже не статейка, я так… обещался на форуме мысли постом оформить — оформил. Мы там на форуме про лотки спорили. И я тоже сказал что это мозги очищает: прокинул трассу лотков, ЗАБЫЛ. Кидай туда кабели и не думай, как их крепить.

    Вот точно: «Кончил? Оботри станок!» ;) И этот подход верный. Нас ещё учили думать о том, как собранное будут ремонтировать, перевозить и так далее. В общем, думать о тех, кто после тебя это будет держать в руках.

  • 12 mf

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

    Конкретные рецепты, под какими углами, в какой последовательности и на что смотреть, приводить не буду — сам уже от канонов отошел. Главное — не зашиваться одним лишь исполнительством («прокинул, забыл») или одним лишь представлением конечного результата, не искать одного идеального режима работы мозга, а периодически переключаться между разными, по-разному полезными. Переключаться полностью, без сидения одной извилиной здесь, а другой там.

  • 13 CS  [Москва]

    О! Мне про такое одна тётка говорила.
    Чуть-чуть в другом контексте, но тоже про переключение внимания, как я сейчас понимаю. Она говорила, что если на каком-то этапе что-то в упор не получается — ПЛЮНЬ, брось и займись тем, что умеешь хорошо делать и тем, что тут отлично получится. А потом мозг в фоне переварит, и вернёшься к тому, что не получалось.

  • 14 mf

    > А потом мозг в фоне переварит, и вернёшься к тому, что не получалось.

    Ага. «Переваривание» в фоне — вообще шикарная тема.

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

    Кстати. Я бы порекомендовал к прочтению книжку Девида Ди Салво «Быстрые решения не приводят к успеху». К теме заметки напрямую не относится, но там есть много интересных вещей про окружающих нас хомо сапиенсов. Весьма забавно почитать в свободное время. Например, как вы думаете, кто лучше сдаст контрольный тест (в школе, в вузе) — тот, кто получит результат сразу, или тот, кто узнает его только через неделю ? Оказывается, зависимость очень существенная (у одной из групп результат на 22% выше другой при прочих равных). А если результат заранее не знать, то… сколько знакомых вам людей будут готовы поспорить, что разницы вообще не будет ? :) Спойлерить больше не буду.

  • 15 Makar4eg

    Если честно, то все эти гениальности с отлаживанием блоков программы, называются в народе библиотеками.
    Хочешь пополнить библиотеку своими блоками — отлаживай и пополняй.
    …Хотя, я под 1С не писал ни разу, возможно что эта местечковая макросреда привносит какие-то свои, принципиально несовместимые с общей парадигмой программирования понятия…

  • 16 CS  [Москва]

    Чего-то это вообще не в кассу. Ни про 1С, ни про блоки. Как-то вы по-кодерски рассуждаете, товарищ, а не по-программистски.

  • 17 Wan-Derer  [Москва]

    Собственно, ничего особо программерского в этом нет :)
    Описаны два совершенно здравых подхода к технологии проведения работ.
    1. Разделение труда. Существует издревле, с тех пор когда люди разделились на охотников, колхозников, тёток и начальников. А уж в промышленности возникло… раньше самой промышленности :) Помните: один куёт, другой качает воздух? :)
    Другое дело — разделение может быть «внешним», когда разные операции производят разные работники, и «внутренним» — когда работает один, но стремится свести по времени однотипные операции. Профит подхода: выше качество и меньший бардак на рабочем месте :)
    2. Движение от общего к частному. Чтобы за исполнением массы мелочей не забыть чего-то важного типа ДСУП или проводка у вентилятору в сортире.

    Хм… Неужели кто-то из мастеров работает по-другому? :)

  • 18 CS  [Москва]

    ДА ЩАС!! Ты любого мастера, млять, возьми. Это у нас в технике сначала идеи и железо, потом IO, потом МК, потом схема, потом печатка и потом прошивка…
    А в электрике всё через жопу. Например, сначала розетки поставят, а потом штукатурят. Или щиток собирают вместе с протягиванием кабелей…

  • 19 Wan-Derer  [Москва]

    Я думаю, дело в глубине понимания темы. Если мастер понимает электрику на уровне физических процессов, он и работу строитправильно. Если нет — просто по-обезьяньи выполняет операции. Совпадёт результат с ожиданием — хорошо, нет — ну… не срослось :)

  • 20 CS  [Москва]

    Нет. Есть три темы:
    1. Понимание смысла того, что делаешь.
    2. Общее мышление и мозги — что идёт первым, что вторым — технология, грубо говоря.
    3. Любовь к тому, что делаешь.

    А обезьяньи дела — это не про нас всех и пофигу как они там устроены =)

Оставить отзыв

Вы должны войти на блог, чтобы оставить комментарий.