Previous Entry Share Next Entry
Не могу не поделиться с камрадами
webbyte
Крик души одного из моих программистов. Теперь уже бывшего.
Так «земляным червяком» меня еще не называли :)

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

Вместо выполненного задания я получил примерно это (спустя 5 рабочих дней):


Проблемы связанные с отсутствием методологии разработки или «методологии скорее экстремально нет».
Описание проблемы: Многие проекты на базе гибких методологий выполняют значительный объем архитектурного планирования, но распределяют его по всему жизненному циклу проекта посредством рефакторинга (обращаю внимание, что многие тут предполагают что код пишется сразу бездумно — это не так, делается ставка на опыт разработчика и он уже пишет исходя из необходимости рефакторинга в будущем) Такой процесс весьма эффективен для малых и некритичных проектов, но в других ситуациях как раз возникает проблема «быстрого старта». Более того у меня каждый раз возникает улыбка при словосочетании «Платежная система — стартап», а сроки реализации в четыре месяца и выход в продакшн через полгода явл. скорее нормой для большинства даже наиболее сложных проектов связанных с электронной коммерцией. Конкретным примером может служить разрастание небольшого и не содержащего сложной бизнес-логики проекта, когда выясняется что рефакторинг кода предоставляющего функционал «платежное окно» связан с высокими и дорогостоящими рисками, а понимание что там происходит под капотом есть только у одного разработчика ( не помогает даже попытка добавить программиста в помощь, а кол-во дефектов можно определить по кол-ву обращений пользователей за последний полгода). Также характерной особенностью проекта явл. откладывание качественной реализации фундаментального функционала... Хочется написать красным шрифтом: при проектировании системы не была произведена работа ( в достаточном объеме ) по выделению стабильных и прогнозируемых эволюционных требований, даже учитывая необходимости обеспечения высокой отказоустойчивости, защищенности, стабильности.

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

С чем связано такое кол-во дефектов? Возможно будет дешевле переписать систему с чистого листа заимствуя отработанный бизнес-процесс с теперь уже не стартапа, а прототипа под названием ДМР? Или все же сократить затраты на доработку/переработку и заменить стратегию постоянного дорогостоящего связанного с высокими рисками рефакторинга, применяя стратегии на основе архитектурного подхода к разработке ( например RUP ). Даже учитывая что существуют элементы с высокой изменчивостью требований такие как веб-интерфейс (если честно сомневаюсь, что это характерно для платежной системы ) можно локализовать код подверженный изменениям и применять максимально гибкие подходы — при условии, что система в целом базируется на архитектуре, использующей метод сокрытия информации посредством инкапсуляции источников изменений в модулях [ Parnas 1979, тема раскрыта у Макконела ]
Для обоснования необходимости проведения работ по определению требований и важности архитектурного планирования можно обратится к модели издержек разработки COCOMO II [ см. фактор архитектурного планирования и устранения рисков RESL ]

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

  • 1
Пацан просто не туда попал. Во многих организациях такой документ бы очень даже прокатил.

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

О да - даже премию бы дали за агрессивное перевыполнение KPI и удачный драйв скоупа!)

В моём уютном бложике попрошу не выражаться! =)

О да! "Давайте все выкинем нафиг и перепишем с нуля"

Угу. Даешь пятилетку за три недели.

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

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

По всей видимости автор приведенной мной цитаты прочитал больше книжек по методологиям разработки, чем ваш покорный слуга книжек по техническим нюансам той или иной СУБД, языка программирования итп. А ведь он еще молод. Ему бы жить да жить...

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

И вдогонку - сколько времени до этих пяти дней он разбирался с кодом?

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

Edited at 2012-06-20 02:02 pm (UTC)

А у меня вот другой вопрос: как он вообще к вам попал?

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

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

>Всего второй случай сотрудника с такой крайней формой диагноза ...
Похоже толковых работников все меньше и меньше :-( ...

Смотря кого считать толковыми. «Кому и кобыла невеста»

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

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

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

К сожалению, нормально донести мысль, что «красота кода» — одно, а задачи бизнеса — другое за полгода, видимо, не получилось. Ну и ладно.

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

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

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

> Человеку была дадена задача собрать и систематизировать проблемные места.

Т.е. то что в этих местах говнокод - было понятно и без него. А поставленную задачу он так и не решил, верно? =)

Некрасиво ты, Макс. Даже инфу для служебного пользования публиканул. Давай еще первый пункт и куски кода из проекта. Пусть все сделают объективные выводы прав парень или нет. Да и предложения тебе были с первого месяца. Несмотря на твои "посмотрим кому ты еще продашь" функционал, ты ведь пользуешься ( как только вся команда юзать начала )? Тебе продал?!

Последний раз, залетая на штраф я тебе предложил наработки по архитектуре, а ты даже не захотел смотреть - "революция понимаешь". Конечно, нормальная такая обратно-совместимая революция, с оборачиванием ~ 6800 SLOC, содержащихся в одном файле, в пакетики. Тогда я принял решение уходить, но ты отговорил: "ты прав, потихоньку будем". Прошел месяц, команда все дальше вязнет, я на ситуацию повлиять не могу - ты упираешься. И вот я прихожу с просьбой уволить и тебе срочно список потребовался ( ведь парень прав ). Я тебе ответил, что собрал вещички и готов валить хоть задним числом лишь бы с тобой больше не ругаться, что не собираюсь писать никаких списков.

Что в итоге? В итоге ты меня тут [censored]: "мальчик, ООП-мозга, НИАСИЛИЛ". А был ли мальчик? Парень не над одним крупным проектом работал и в sql substring отсчет первого символа с 1 начинает, а не как "супер специалист", который много книг "по техническим нюансам той или иной СУБД" читал. Да и команда с тобой сейчас спорит, те кому не боязно.

Я уходил сохранив уважением к тебе, но видимо ошибался.

P.S. Как же блять противно, ты потерял мое уважение.
Привет !

Если честно, то я конечно не знаю, как у вас в компании заведено, но, с моей точки зрения человек с заданием не справился. Нужно было что? "Собрать и систематизировать проблемные места с целью составить план рефакторинга". Он это сделал? Нет. Что мне может дать просмотр кода? Понимание того, что он не айс? Так это и так ясно, иначе не было бы подобного задания.

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

В общем, несмотря на негатив ситуации, успехов всем в делах!

Даже инфу для служебного пользования публиканул
Служебности в ней сильно меньше, чем в предложении о работе, в котором, кстати, прописаны те деньги, которые тебе обещала и выплачивала компания. Цитата была обезличенная, фамилий я не называл, ты сейчас сам пришел и «палишься».

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

Последний раз, залетая на штраф
Штрафов в нашей компании нет. И у тебя, кстати, не было.

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

Edited at 2012-06-22 06:33 am (UTC)

> ты ведь пользуешься
Пока. В единственном случае. Потом посмотрим. На странице 20 платежей отключение кэширования в твоем коде приводит к замедлению рендеринга до 20-40 секунд. Это к слову.


Работает поверх твоего функционала, в твоем оригинале кэширование производится путем хранения в глобальной переменной ( проблемы помнишь, залеты надеюсь тоже, детали о реализации приводить не буду ). В моем исполнении что-то очень похожее на то, что сделано в mojolicious. Что у тебя исключи твой оригинальный способ кэширования ( особенно учитывая фактор персистентности mod_perl'a [ см. залеты ] ) , что у меня отключи кэширование. Да и кстати, не устраивает кэширование - запили/замени бэкенд кэширования [ см. "...метод сокрытия информации посредством инкапсуляции источников изменений в модулях", ага :-) ]. Да и основную проблему решает другую, а именно искоренение практики передачи хэша с конфигом по всему стеку вызовов, передачи на всякий случай в функцию утилиту - "вдруг ниже-то потребуется конфиг пусть даже что сейчас нет". :-) Вот бы парням ты сейчас показал как писать надо TRUE-way


> Последний раз, залетая на штраф
Штрафов в нашей компании нет. И у тебя, кстати, не было.

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

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


Я-то хорошо знаю и о тебе и о себе, и почему ты меня остаться уговаривал или на-крайняк в другой проект перейти, и почему меня люди поддержали, и про то что о ТЕБЕ, Макс, в компании думают тоже знаю ( даже не смешно и даже не самая маленькая из причин почему я валил ). И про то почему у тебя трое сбежали и в меил остались работать, причем ими все другие довольны, особенно тем вторым с ООП-мозга. Видимо у этого успешного проекта все такие, раз приняли с таким страшным диагнозом. Думал тебе глаза открою, а ты упорно не хочешь критически мыслить, слушать окружающих и даже своих. Как обычно все заканчивается угрозами, на этот раз с перебором даже. В одном согласен, дальше не намерен мараться, сам свой уютный бложек по-пачкал.


P.S. Кстати у тебя единственный такой подход к разработке и парадигма во всем меил, что служит плодотворной почвой для твоего обсуждения. Да, они наверно не такие крутые пацаны из мейла как ты.

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

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

Да, они наверно не такие крутые пацаны из мейла как ты
Если они работают в компании, значит, крутые пацаны™.
Крут ли я — решать не мне, а моим руководителям, сотрудникам и коллегам из других отделов.
Лично ты крут, я без иронии. К сожалению или к счастью, проекту Деньги такая крутизна пока ни к чему.
Хотя рефакторить проект мы будем. Только не так, как предлагал ты, революций не будет.

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

На этом и закончим.

(Deleted comment)
«По бабкам» тебе обещали ровно то, что прописано в предложении о работе, которое ты принял.
Ровно от него пляшет отдел кадров, когда принимает на работу и опосредованно бухгалтерия, когда начисляет зарплаты. Если тебе начисляли меньше, чем в нем прописано (обрати внимание, указан гросс, то есть с налогами), сообщи мне письмом, я попробую разобраться с бухгалтерией по этому вопросу.

Я - слоупок, раз столько пропустил.

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

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

Как у вас дела обстоят на самом деле, я не в курсе. Но пример, тем не менее, показательный.

Edited at 2012-07-03 06:13 am (UTC)

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

Вот за что я люблю олдскульных слоупоков, так это за четкость формулировок =)


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


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

ЗЫ. Слоне, а ты из Рамблера-то чего намылился?

>ЗЫ. Слоне, а ты из Рамблера-то чего намылился?

Давай об этом поговорим в аське))

Пахнет цепями Маркова. То есть, подозрительно напоминает продукт Яндекс.Рефератов...

  • 1
?

Log in

No account? Create an account