Pull to refresh

Comments 72

Мораль — фигачить хорошо, работать по SDLC — плохо. Или нет?

Не тот я человек, чтобы мораль формулировать. Просто история.
Мораль — фигачить возникшие проблемы и задачи хорошо, а фигачить ради фигачить потому что у кого то перфекционизм зудит в одном месте — плохо.
Просто не бросайтесь в крайности, а то можно будет подумать, что фигачить как нибудь на костылях это круто.
фигачить хорошо, работать по SDLC — плохо
Если «фигачить» — это безалаберно гнать конвейер, а «по SDLS» — это формальный подход и процессы превыше всего, то обе крайности плохи, баланс между ними нужен.
Как я понял рассказ, то мораль такая:

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

Если же опыта нет, то попытки сделать крутые SDLC, Agile, ООП с UML — не факт что взлетит, так как найдутся миллион мелочей неучтенных из-за банального недостатка опыта и понимания как ставить приоритеты.
Грамотному человеку все эти баззворды — что зайцу триппер, а дураку — хоть сертификатами он обклейся, все одно — толку не будет.
Мне кажется мораль такая: для опытного д. Толи уже не так важен инструмент для получения хорошего результата.
Молодые больше обращают внимания на инструмент и меньше думают о результате. Это про стройку. А про программистов — аналогично одна группа была ориентирована на результат, а другая на сам процесс разработки. Короче важен результат, а не процесс.
Это история полная проекция на попытки писать всегда идеальный код, а не просто рабочий и удобно читаемый.
Но сравнение достаточно познавательное.
Спасибо за статью.
Идеальный и удобночитаемый — это не одно и тоже?

А если он удобночитаемый — то вроде как его работоспособность или неработоспособность должна быть хорошо видна при чтении.
Идеальный код — удобночитаемый. А вот удобночитаемый код может и не быть идеальным. Например, selection sort очень простой и понятный, по сравнению с quicksort, но применимость его весьма ограничена.
Идеальный код — это его отсутствие.
далеко не…
Идеальный код — это не про процесс разработки это про результат, так что идеальный код далеко не всегда удобочитаем…
Вы наверное не в теме. В разработке нет конечного результата(обычно нет). Успешный продукт пишется и переписывается много лет подряд. Поэтому он не обязан работать идеально — неидеальную работу можно исправить. Но код должен быть написан так, чтобы в него легко можно было вносить изменения. Удобочитаемость — это одно из требований к такому коду.

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

В жизни обычно по мере усложнения программы каждое следующее изменение требует всё больше усилий и ломает всё больше старого функционала.
Засилье «Микро»-сервисов намекает на недостижимость идеала…

и результат тут тоже не совсем тот который вы подумали… результат — это корректное функционирование бизнеса, а уж как оно обеспечено и идеальность кода для этого далеко не на первом месте…
так что идеальный код это код который обеспечивает отличное функционирование бизнеса(развитие тоже функция) и удобочитаемость здесь в принципе не самый важный фактор…

Спасибо. С утра хорошо зашло. Таки пойду класть копия.

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

Не знаю как там на стройках, но в разработке такое, на мой взгляд, встречается редко.

Либо человек нормально понимает ТЗ и подводные камни, делает из чего есть тногда позволяя себе костыли, либо струячит кое-как, что «окна с разницой по уровню в полметра», но тогда и о правилтном цементе с размерами кирпичей т прочих технологиях никто не задумывается.

Автор просто придумывает истории. Они не обязаны никак коррелировать с реальностью. Это как сценарии фильмов для Марвела, только для Хабра.

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


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

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

Дядя Толя норм мужик и отфигачил свое ТЗ на 100%.

А если ты заказчик хочешь ещё и "качественно", то сначала надо хотя бы спросить. А ты спросил не дядю Толю, а аналитиков, вот с них и спрашивай за остальное.

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

там вина на менеджере проекта (прорабе), который упустил контроль и допустил халатность - риск перешел в ошибку. которую потом пришлось переделывать

Помимо заказчика есть ГОСТ, который должен знать не заказчик, а исполнитель.
На то он и специалист, чтобы делать правильно, а не как угодно его кривым рукам и кривой совести.

Нет. Всё переделывал дядя Толя


Исправлял, естественно, дядя Толя. Костю и Рустама выгнали в тот же день.

Да вы правы, значит старое заклыдывали битым кирпичем, а новое пробивали ржавой лопатой :)

Точно, битым, потому что целый Рустам с Костей израсходовали.

>следуя технологии ребята не читали документацию, а дядя из говна и палок точно отмерял позиции окон.

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

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

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

А по моему — афтар подыгрывает дяде Толе… Иным я не могу объяснить то, что у двух его оппонентов окно ВНЕЗАПНО оказалось не там где надо. Казалось бы — с какого такого панталыку если они всё делали по ТЗ? Что, кирпичи внезапно в объёме прибавили по оси Y?

это "гипербола" - такая авторская уловка. я уверен ;)

Казалось бы — с какого такого панталыку если они всё делали по ТЗ?

Как раз про «делали по ТЗ» не говорилось. Делали по технологии, при этом не вникнув глубоко в задачу. Та же самая ситуация и на проекте — разработчики делали всё по технологии, но не уделив должное внимание потребностям пользователей. Мораль сей басни в том, что первично как раз ТЗ, а не подход к разработке. Если разработка решает реальные потребности пользователей, то проект «взлетит», даже если он делался на коленках. Если же потребностям не было уделено должное внимание, то проект не взлетит, как бы хорошо он не был организован.

Я вижу всё большее и большее подыгрывание дяде Толе…
Значит, один "вник в суть" и из полуфабрикатов сварганил "конфетку"… По наититию. А двое других — "делали по технологии", которая наверное где-то внутри описывает, что окна "по технологии" должны быть там-то и там-то а не где-то… И конфетку не сделали.


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

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

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

Ок
Во-первых, так как здание кирпичное, качество раствора не имеет такого значения как для бетонного монолита. Гораздо важнее перевязка арматурой либо кладкой.
Во-вторых, кладки половинками кирпича никак не избежать, по-моему это очевидно. Использование готовых обломков, вместо разбивания целых, приводит к экономии времени и меньшему схватыванию вышеупомянутого раствора. Плюс уменьшается расход кирпича на бой. Целый кирпич нужен только для внешней — лицевой стороны стены, для внутренней обломки прекрасно подойдут. Я не думаю, что он обломками выкладывал прям целые кубометры кладки.
Здание двухэтажное и они выкладывали второй этаж. Выше только перекрытие и кровля. Какое тут может быть обрушение стены из-за «не такого» раствора, я не могу представить.

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

и да. Это я говорю по своему опыту строительства.
1) Лишний расход раствора. Он дороже кирпича на единицу объема.
2) Стена некрасивая, бой нужно использовать только на стенах под отделку, где он будет спрятан.
3) Труднее выдержать прямолинейность. И швов, и рядов кладки, и собственно стены.
4) Дольше кладка по времени. Положить целый кирпич и битый по времени одинаково, а выработка меньше.

Обычно битым кирпичом заполняют внутренние объемы несущих толстых стен. Т.е. наружная кладка и перевязки ровные целые красивые из цельного кирпича, между ними заполнено чем под руку попало. Не выбрасывать же.
Проблема в том, что дядя Толя 100% знал про косяки «коллег» — но смолчал.

Проблема в том, что ключевая проблема этого проекта — дядя Толя. Он не командный игрок, а "звезда" (по Хабру можно найти статью под заголовком вроде этого: как работать со звёздами? И выводы были однозначные — несмотря что они могут тянуть весь проект в одиночку — лучше их уволить. Команда выгодней, просто потому что зазвездившийся сотрудник хоть и тянет всё на себе, но при покидании места — у тебя встаёт весь бизнес. К себе в проект он никого не пускает — поломают — а в результате никто не знает как проект сделан и весь твой бизнес зависит от капризов и выкаблонов одного человека). А звёзды — ни разу НЕ командные игроки. И вместо того, чтобы с самого начала работать в команде — дядя Толя хреначил только свою часть работы, держа фигу в кармане, зная о рисках. Т.е. в результате человек, из за которого потратили в Н раз больше времени — это дядя Толя.

Так почему же именно на участке «звезды» все было хорошо, а на участке «команды» все плохо? Особенно учитывая, что никакой зависимости от «звезды» у них не было, скорее команда зазвездилась — и то им подай, и это. А результат — пшик.
Дядя Толя ни от кого ничего не скрывал.
если так смотреть, то тогда там оба три — звезды, только жанры разные…
дядя Толя — шансонье или просто бард какой, а костя с рустамом — попсовики-затейники, у которых всё красиво, но без пи чутких указаний от менеджера и контроля звукача результат получается… своеобразный.
Нет, звезда — это про внешние признаки, статус.
Надежный исполнитель, но с фигой в кармане.
kontur.ru/articles/282
А Рустам с Костей были специалистами по дверям. Действительно профессионалами, знающими лучшие практики установки дверей и форму идеальной ручки. Предыдущие заказчики восхищались тишиной и герметичностью дверей, отсутсвие сквозняков позволило им хорошо сэкономить на отоплении. Дверь и окно это же почти одно и то же, не так ли, говорил подразумевал подрядчик при заключении контракта. Вот их и прислали на стройку, забыв, что дверь выравнивают по полу, а окно, внезапно, нужно расположить посреди ещё не достроенной стены.

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

Хорошая визуализация байки про "вам шашечки или ехать?"

UFO landed and left these words here

"2 стула" это более радикально!

есть быстро и бесплатно, есть долго и дорого. Что выбираешь?

:D
Вообще очередной пример как количество работы на результат никак может не влиять, и даже ухудшать текущее положение вещей. Важнее всего — понимание, как достичь результата. А достичь результата при минимальных усилиях — то, к чему нужно стремится всегда.
в контексте данного рассказа в чем разница между программистами и разработчиками?

программисты - дядя Толя (рабочий инструмент)

разработчики - свежий цемент для Рустама&Co (аналитиков)

каменщики должны были оставить под эти окна дырки

Этта… На стройке дырок нет. Там проёмы!

А я хочу напомнить в ответ историю Final Fantasy XIV.

Разработали как-то Square Enix новую ММО Финалку. Очень амбициозную, похожую на предыдущую ММО (FF XI), совершенно не обращая внимания ни на ВоВ, ни на других конкурентов.
Качество игры оказалось внезапно ниже плинтуса. И геймплейно она была плоха, и фич в ней не хватало, и багов было море, и лагала она не по-детски. Игроки из игры уходили, журналисты рвали и метали, перед руководством встал серьезный вопрос — деньги на игру затрачены немалые, прибыли не предвидится, репутация огребла мощный удар под дых и подняться не может. Что делать?
Старый менеджмент вежливо попросили удалиться на какой-нибудь другой проект, назначили новым главным Наоки Ёсиду и отправили его разгребать проблемы.
Ёсида походил, посмотрел, поиграл в ВоВ, пошел к руководству и предложил свой план решения проблемы.
Команду разработки разделили на две части. Одна часть дорабатывала текущую версию игры, устраняя мелкие недоработки, а вот вторая — разрабатывала новую, устраняя крупные ошибки предыдущей версии. Прямо как в этом топике(!).
Доработка текущей версии включала в себя выпуск нескольких обновлений, благодаря которым удалось остановить падение онлайна. Под конец эпохи был проведен масштабный эвент, в процессе которого мир игры был разрушен, а сервера отключены. В ноябре 2012 года первая версия была отключена.
В то же время вторая команда создавала новую версию игры — на новом движке, с переделкой серверной части. После окончания поддержки первой версии, команды были объединены и брошены на разработку второй версии.
Вторая версия, Final Fantasy XIV: A Realm Reborn, была запущена в августе 2013 года. Она оказалась отличной. Нет, она не просто оказалась отличной, она до сих пор хороша и развивается — к ней до сих пор выходят дополнения, её считают одной из лучших ММО на рынке, в нее играют больше 2 млн. игроков каждый день, а общая база игроков превышает 20 млн.

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

"расстреляли меня, внучок" (с)

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

С точки зрения аналогии в программировании программисты строили ПО из имеющихся кусочков решений, связывая их воедино. Да, структура и архитектура так себе. Но это тоже работает.
С точки зрения строительства каменщик не имеет квалификации для оценки соответствия норме. У него есть регламент, по которому он должен работать. Если по регламенту можно делать стену из кусков кирпича и загустевшего раствора — то прораб должен был соответствующим образом стимулировать Костю с Рустамом не выёживаться, а работать. А если нельзя — то даже вот это вот «мамой клянусь, 40 лет опыта, всегда так делал» плохое оправдание.
За современными тенденциями к джамшутингу ( применение низкоквалифицированного труда ) многие забыли, что профессия строителя — это прежде всего СПО (среднее профобразование). И соответствующие знания в этой области у дяди Коли и у Романа с Рустамом имеются (что выражается в их стремлении следовать некому стандарту).
Кстати, прорабы тоже, как минимум, имеют СПО.
Знания — возможно. Квалификация и ответственность — нет. Когда упомянутая стена упомянуто ляжет на посетителей, дядю Толю в суд никто не потащит.
> загустевший раствор по технологии можно продолжать использовать при добавлении воды и перемешивании (те же миксеры так и делают, пока доставят до точки).

Прочность и морозостойкость падает у раствора/бетона. Нет такой «технологии», по которой так можно делать, если нет достаточного запаса по характеристикам бетона.
Ну так дядя Толя своё честно отработал, а QA пропустил результаты «дальше»…
Или не было никакого QA? :)
Очень уж странная история без логики.
Два каменщика, которые работают «по стандартам» вдруг, ни с того, ни с сего, промахиваются с окнами, а «дядя Толя» попадает. Ммм, интересно, а какие к этому предпосылки, кроме желания автора что-то такое сочинить?
Чему должна научить эта история? Разве что тому, что автор — хозяин всему, как захочет, так и придумает. Но это и так известно, в общем-то.
Так что ничему дядя Толя нас на этом примере научить не может, увы. Автор, выдумывай получше.
Хорошая притча.
Но, как это обычно и бывает, истина посередение. Нормальные проекты получаются только тогда, когда программеры и бизнес-аналитики работают сообща и в одной команде.
А если дать волю програмистам, то 9 из 10 раз оказывается что плевать они хотели на ТЗ, а сделали так как умеют/знают/подсмотрели в инете.
Т.к. работы по нормальному запуску было много, привлекли людей из двух отделов. Первый – программисты, второй – разработчики с аналитиками.

Вывод: У разработчиков с аналитиками плохо получается программирование :)
> Когда раствор подсыхал, становился более вязким, Костя и Рустам останавливали работу и требовали заказать следующий цементовоз. Дядя Толя просто звал нас, разнорабочих, и говорил – ребятки, пару вёдер воды плесните, и лопатами, лопатами поработайте (бетономешалки не было).

Насколько знаю 4 ведра воды на 6м3 бетона превращают марку М400 в М350. 8 ведер в марку М300. И так далее. Еще более стремительно снижается морозостойкость.

Дядя Толя конечно большой талант в стройке. Зато окно по чертежу.

Особенно печально, если в ходе строительства таких талантов набирается 3-4 подряд и наносимый ущерб перестаёт компенсироваться запасом прочности.

так и "программисты" с костылями на проекте - так же снижают его надёжность. пропорционально

Ну хз, работал я на стройке, правда цементовозов не было, если нас с другими подсобниками за них не считать. Какая-то мораль от (не было у нас дяди Толи, был только дядя Вова, и Васильич, хотя им на тот момент было чуть больше 30), это: «беги ты чудак с этой стройки, беги, а то как мы, очнешься, тебе 30+, в руках кирпич, и никаких перспектив».
Слава богу сбежал, и из помогающего, только вспоминаю, как руки, ноги, жопу(простите) от цемента отмывал, и вот уже почти 8 лет каждый день благодаря этому нахожу стимул учиться. А мужики классные, недавно на дне рождения общей знакомой с ними встретился, и дома стоят, хотя они тоже иногда из половинок собирали

Зубная паста в тюбике закончилась, а мы все пытаемся выдавить...

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

Контрпример — Госуслуги. Яркий пример того, как программисты из очень разнородных источников сколхозили чего-то, но… Для проектов такого рода требуются архитекторы и специалисты по моделям уровня тех, что разрабатывали OPC UA или 61850, к примеру. Отсутствие «скелета» никакими заплатками не скомпенсировать.
В нормальной компании с квалифицированным руководством:
— д.Толя (перед возможным увольнением) получил бы первое и последнее предупреждение от прораба, за игнорирование технологии строительства
— Костя, Рустам должны были получить проф. образование и проработать пару лет под контролем д.Толи, прежде чем стать самостоятельными специалистами
— Внедрению ЕРП системы предшествовал этап анализа и планирования, проведенный опытными и высокооплачиваемыми специалистами (с референсами на успешно завершенные проекты)
— Внедрение производились бы опытными и высокооплачиваемыми специалистами (с референсами на успешно завершенные проекты)
— Внедрению ЕРП системы предшествовал этап анализа и планирования, проведенный опытными и высокооплачиваемыми специалистами (с референсами на успешно завершенные проекты)
— Внедрение производились бы опытными и высокооплачиваемыми специалистами (с референсами на успешно завершенные проекты)

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

Не совсем ясно, создание стены из кусочков - это microservices to monolith?

Sign up to leave a comment.

Articles