Comments 36
Меня всегда интересовало как быть с таким сценарием — приходишь в компанию (большую, известную, хорошую), начинаешь работать, а у них супер-пупер-мега продукт, который писало сто-двадцать-три поколения уволившихся, сто сорок мегабайт исторических исходников на Си без плюсов и двадцать два гигабайта документации (не отвечающей, впрочем, на простейшие вопросы). И любой чих занимает месяц чтоб только понять что с ним делать. И как со всем этим правильно жить? Увольняться и идти в другое место? Дык там с вероятностью 0.99 будет такая же лажа. Тогда надо идти в стартап, чтоб правильно начинать с самого начала, но там ведь денех платють в разы меньше. Как быть? У кого какие есть идеи?
Рекомендую построить и запустить «каток» с использованием Agile/Scrum — стараетесь выбить себе одного/двух аналитиков, пишите детально продуманные формальные требования, насильственно оцениваете их на PlanningPoker с текущими разработчиками, набираете критическую массу требований, планируете релизы.
Может произойти чудо и топы наймут высокопрофессиональную команду разработчиков, которые закатив рукава перепишут/прорефакторят кучу г… на и вы сможете выпускать фичи долго и счастливо.
Может произойти чудо и топы наймут высокопрофессиональную команду разработчиков, которые закатив рукава перепишут/прорефакторят кучу г… на и вы сможете выпускать фичи долго и счастливо.
И что будут делать высокопрофессиональные разработчики с тоннами невнятного спагетти-кода?
Позволю себе влезть в обсуждение и доложить свои пять копеек. Как показывает опыт поколений, тонны невероятного спагетти-кода обрабатываются так же, как и в процессе поедания слона: по кусочкам :)
опыт поколений не врет, я вам скажу
Приходит задача — научить слона жить в условиях России. Мехом его обшить — не проблема, только надо ведь чтоб на хоботе сопля не замерзала, а документации на хобот нет, зубы у него не перемалывают берёзовые веники, а от отечественных пельменей случается понос, плюс после трёх часов на холоде слон начинает болеть воспалением лёгких, уши у него леденеют и он дохнет через день. Пытались уменьшить уши, чтоб меньше мёрзли, но он тогда ни хрена не слышит, плюс оказалось, что через уши реализована вся система кровообращения и терморегуляции (кстати, у слонов реально так) и т.п. Вы поняли, о чём я? Не получается по кусочкам, тем более быстро. Тем более, когда не слон, а совершенно неизвестный науке организм, хромяющий всеми конечностями.
Не получится «быстро и все». А медленно и по кусочкам — вполне себе. Сам руководил такими проектами ^_^. Создаются временные прокси, меняются по одной пути выполнения кода. По достижении критической массы временные прокси убираются и старое взаимодействие внутри кода меняется на новое.
Конечно, есть древы Семфрот где совсем все на все завязано — но это редкость. Как правило если неторопливо и аккуратно — то по кусочкам перебрать можно.
Конечно, есть древы Семфрот где совсем все на все завязано — но это редкость. Как правило если неторопливо и аккуратно — то по кусочкам перебрать можно.
накройте слона одеялом и продолжайте свои тесты. Одеяло, в последствии, можно снять.
Один из вариантов — создается API, и все новое цепляется на него. SOAP API — отдается наружу клиентам.
Т.е. вы проводите черту и дальше работаете правильно. Можно это апи начать покрывать тестами.
Т.е. вы проводите черту и дальше работаете правильно. Можно это апи начать покрывать тестами.
UFO just landed and posted this here
Про ищите-ищите-ищите. Как на стадии интервью выяснить, творится ли в компании гавнокодный бардак?
Один из вариантов, посмотреть на код продукта или поговорить с ведущим программистом прежде чем принять предложение.
UFO just landed and posted this here
Заходите в мойкруг, например. Находите людей которые там работали инедавно уволились — и разговариваете с ними.
В самой компании:
посомтреть какие задачи стоят в системе заданий
поспрашивать PMа о том сколько людей ушло с проекта, почему уволились
попросить главного по тарелочкам используется ли у них TDD или хотябы просто юнит тестирование. Если используется — сколько времени уходит на тесты, какой они длинны. Если неиспользуется- то почему.
Распросить об архитектуре и поыптаться на слух найти признаки циклических зависимостей.
Если это «вебпроект» — попросить посомтреть «код контроллера» в котором происходит обработка загруженных файлов.
В самой компании:
посомтреть какие задачи стоят в системе заданий
поспрашивать PMа о том сколько людей ушло с проекта, почему уволились
попросить главного по тарелочкам используется ли у них TDD или хотябы просто юнит тестирование. Если используется — сколько времени уходит на тесты, какой они длинны. Если неиспользуется- то почему.
Распросить об архитектуре и поыптаться на слух найти признаки циклических зависимостей.
Если это «вебпроект» — попросить посомтреть «код контроллера» в котором происходит обработка загруженных файлов.
Как на стадии интервью выяснить, творится ли в компании гавнокодный бардак?
Тупо спросить человека с которым вы беседуете.
Спросите сколько проект продолжается, как качество кода, как поддерживается оно, какие практики используются, чем придется заниматься. Если прямо не отвечают, это странно. По другим косвенным признакам можно понять что все не так радужно (с большой гордостью говорит, что ввели Continious Integration, только еще переводят сборку на «нажатие одной кнопки»). А если человек рассказывает о проекте с горящими глазами или с придыханием, как тут все круто — этому можно верить. Кстати это описано в классическом труде.
На интервью тестируют не только вас, но и вы их. Им тоже не надо нанять человека, который придет и через неделю впадет в отчаянье и будет искать работу или ничего не делать.
Boy Scout rule.
Всегда оставляйте за собой код чище, чем он был. Со временем наиболее меняющиеся части станут адекватными. Новые части будут нормальными сразу. Остальное закостенеет в рабочем состоянии :)
Это долго и надо много упорно работать. Или вы хотели попроще и побыстрее? :)
Всегда оставляйте за собой код чище, чем он был. Со временем наиболее меняющиеся части станут адекватными. Новые части будут нормальными сразу. Остальное закостенеет в рабочем состоянии :)
Это долго и надо много упорно работать. Или вы хотели попроще и побыстрее? :)
Спагетти — испытание твоей силы, юный падаван.
А если серьезно — надо относиться к этому по-философски.
Любой крупный проект для вновь входящего представляет из себя спагетти, но стоит привыкнуть и проникнуться (ведь чаще всего в основе всей каши лежат вполне адекватные архитектурные решения), то все идет как по маслу.
А если серьезно — надо относиться к этому по-философски.
Любой крупный проект для вновь входящего представляет из себя спагетти, но стоит привыкнуть и проникнуться (ведь чаще всего в основе всей каши лежат вполне адекватные архитектурные решения), то все идет как по маслу.
В статье рассмотрен прекрасный идеализированный мир, который никогда не сложится в реальности. Квалифицированные программисты, аналитическая документация, рефакторинг, чистая модульность… Ещё наверное надо добавить разумные сроки и вменяемого заказчика :)
За статью +1 как за хорошую сказку. Но по своему более чем 10-летнему опыту работы ПМ-ом и техдиром скажу: основная задача техдира — это уметь наиболее эффективно оперировать той реальностью, которая ему дана в конкретном проекте.
За статью +1 как за хорошую сказку. Но по своему более чем 10-летнему опыту работы ПМ-ом и техдиром скажу: основная задача техдира — это уметь наиболее эффективно оперировать той реальностью, которая ему дана в конкретном проекте.
А что такое «технический бэклог»? У команды может быть 1-2 бэклога (в идеале 1), за которыми следят Product Owner-ы. И всё.
Что брать на следующую итерацию решается совместно, т.е. технические извраты и излишества проскочить не должны. Если это не так, то что делают в проекте Scrum Master и что делает, если есть, Team Lead. Team Lead — вполне допустимая роль, которую можно использовать как раз по вопросам, связанным с выбором технологий.
И, наконец, причем здесь технический директор?
Что брать на следующую итерацию решается совместно, т.е. технические извраты и излишества проскочить не должны. Если это не так, то что делают в проекте Scrum Master и что делает, если есть, Team Lead. Team Lead — вполне допустимая роль, которую можно использовать как раз по вопросам, связанным с выбором технологий.
И, наконец, причем здесь технический директор?
Техбэклог — это предложения команды по поводу как потратить время, не добавляя функционал. Тимлид наверно будет активнее всего писать туда, т.к. когда требования меняются рефакторить придется часто. Чтобы тимлида не уволили за «трату времени впустую» — его прикрывает… техдир. Он должен быть сильнее ProductOwners, разумеется, по полномочиям и донести — что рефакторить нужно, иначе через год проект загнется к черту.
Один из принципов итеративной разработки — на каждой итерации поставлять продукт имеющий ценность для бизнеса.
Вы же, получается, пишите о некоем техническом бэклоге, который прикрывает «техдир», который, по сути, провоцирует несогласованное с Product Owner-ом уменьшение ценности релиза для бизнеса, причем, из написанного вами, чем дальше отстоит итерация от начала проекта, тем больше.
Появление технических историй в ходе проекта — это нормально. Искать решение вне проектной команды — не уверен, что правильно. Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
Вы же, получается, пишите о некоем техническом бэклоге, который прикрывает «техдир», который, по сути, провоцирует несогласованное с Product Owner-ом уменьшение ценности релиза для бизнеса, причем, из написанного вами, чем дальше отстоит итерация от начала проекта, тем больше.
Появление технических историй в ходе проекта — это нормально. Искать решение вне проектной команды — не уверен, что правильно. Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
> Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
По-моему это не очень сложно, если команда сможет количественно оценить необходимость конкретной технической истории. Это возможно как при падении velocity, так и просто посчитать, что, при введении той или иной технической истории, компания будет экономить определённе количество финансов. Далее, при оценке историй на выручку / трудозатраты, техническая история может попасть в спринт. Если не может, значит она там и не должна быть, за некоторыми исключениями.
По-моему это не очень сложно, если команда сможет количественно оценить необходимость конкретной технической истории. Это возможно как при падении velocity, так и просто посчитать, что, при введении той или иной технической истории, компания будет экономить определённе количество финансов. Далее, при оценке историй на выручку / трудозатраты, техническая история может попасть в спринт. Если не может, значит она там и не должна быть, за некоторыми исключениями.
Дело в том, что не всегда нетехнический ProductOwner может принять адекватное решение, делать рефакторинг или нет. Ему нужно добавлять фичи побольше и побыстрее — желательно мгновенно. Я в многих проектах видел рефакторинг, отложенный на потом по причине расстройства желудка у руководителя проекта, никогда не выполнялся, затем этот РП увольнялся и с кучей г… на приходилось разбираться техническому директору.
Т.е. команда и владелец продукта не могли договориться о том, что должно быть сделано? Иначе говоря, Agile процесс у вас не работает?
Вы бизнес с командой разработки ведете, что-ли? Как можно о чем то договариваться с командой? Люди в команду приходят и уходят. За качество проекта изнутри отвечает либо главный разработчик компании либо техдир, а за весь продукт в целом отвечает руководитель компании. Эджайл тут не причем.
Владельца продукта должны страховать эксперты по качеству, безопасности, производительности — в 80% команд, по моему опыту, вообще об этом никто не задумывается.
Владельца продукта должны страховать эксперты по качеству, безопасности, производительности — в 80% команд, по моему опыту, вообще об этом никто не задумывается.
И ещё, из написанного можно сделать следующий вывод:
я не буду думать над тем, как написать простой код, реализующий бизнес-задачу,
а буду писать как мне хочется и использовать ту технологию, которую хочется,
т.к. я всегда могу пополнить «технический бэклог» заданиями, по исправлению моих ошибок,
который «крышуется» «техническим директором»,
который важнее владельца продукта,
а так же пользы для бизнеса, которую несет продукт.
Без обид. Я просто хочу понять, что же вы имеете в виду.
я не буду думать над тем, как написать простой код, реализующий бизнес-задачу,
а буду писать как мне хочется и использовать ту технологию, которую хочется,
т.к. я всегда могу пополнить «технический бэклог» заданиями, по исправлению моих ошибок,
который «крышуется» «техническим директором»,
который важнее владельца продукта,
а так же пользы для бизнеса, которую несет продукт.
Без обид. Я просто хочу понять, что же вы имеете в виду.
Рефакторить надо не по бэклогу, а по факту — надо добавить новую фишку в модуль, разработчик лезет в код и видит, что там нужен рефакторинг — Вперед! Ему и карты в руки. А если модуль, который не требует изменений написан криво, но он работает и при этом устраивает заказчика, нечего туда лезть с рефакторингом. Имея такой бэклог через полгода команда будет заниматься только рефакторингом, при этом этот бэклог будет только расти, т.к. рефакторинга будет требовать уже и тот код, который когда-то был отрефакторен! Не помню, кто, но кто-то сказал: «Дайте программистам волю, они любой проект угробят». Рефакторинг — круто, когда к месту!
«Постараемся понять, кому «бить морду».»
Очевидно, что «себе».
Очень странно такое читать. Мы наняли людей, квалифицированных, с признаками лояльности и прозрачной заинтересованностью в успешном завершении проекта. Люди честно работают. Но случилась ошибка. Если вместо того чтобы разобраться в причинах и подумать возможно ли её избежать в будущем, мы начнём кого-то «мутузить» — то лучше не станет, а хабр пополнится ещё одним топиком с «плачем ярославны» о том какие программисты плохие и как же их надо правильно стегать кнутом.
«Гибкость» гибких методов не превышает «гибкость ума» людей «принимающих решения» (как технические так и управленческие). Стремление избежать ошибок (в широком смысле) — проявление «негибкости».
Очевидно, что «себе».
Очень странно такое читать. Мы наняли людей, квалифицированных, с признаками лояльности и прозрачной заинтересованностью в успешном завершении проекта. Люди честно работают. Но случилась ошибка. Если вместо того чтобы разобраться в причинах и подумать возможно ли её избежать в будущем, мы начнём кого-то «мутузить» — то лучше не станет, а хабр пополнится ещё одним топиком с «плачем ярославны» о том какие программисты плохие и как же их надо правильно стегать кнутом.
«Гибкость» гибких методов не превышает «гибкость ума» людей «принимающих решения» (как технические так и управленческие). Стремление избежать ошибок (в широком смысле) — проявление «негибкости».
Когда вы заметите ошибку, может быть уже поздно — пройдете точку невозврата. Уровень квалификации IT-специалистов не просто оценить, особенно на нашем российском рынке.
Конечно «бить морду» это метафора. Цель стати — заставить задуматься о последствиях сразу, чтобы не провалить проект.
Конечно «бить морду» это метафора. Цель стати — заставить задуматься о последствиях сразу, чтобы не провалить проект.
«Конечно «бить морду» это метафора» — да метафора. метафора для наказания.
«Когда вы заметите ошибку, может быть уже поздно» — да может быть, а может быть и нет. Но вы в своём топике говорите о техдире как о некоем сверх человеке, который сам не допускает ошибок + проверят работу других и недаёт ошибиться другим. В теории всёздорово, но в жизни — все ошибаются. Достаточно посомтреть на гугл, яндекс, мейл — могут нанять (а некоторые и наняли) умнейших людей — но у них постоянно случаются проблемы связанные с ошибкой «самого умного». Уберечься от этого невозможно. Надо просто адекватно реагироваться на такие события, а не «пинать» или «бить морду»
«Когда вы заметите ошибку, может быть уже поздно» — да может быть, а может быть и нет. Но вы в своём топике говорите о техдире как о некоем сверх человеке, который сам не допускает ошибок + проверят работу других и недаёт ошибиться другим. В теории всёздорово, но в жизни — все ошибаются. Достаточно посомтреть на гугл, яндекс, мейл — могут нанять (а некоторые и наняли) умнейших людей — но у них постоянно случаются проблемы связанные с ошибкой «самого умного». Уберечься от этого невозможно. Надо просто адекватно реагироваться на такие события, а не «пинать» или «бить морду»
Еще хочется добавить про принцип из личного опыта: «лучше медленнее, да качественнее».
Заставляйте разработчиков проектировать фичи перед их написанием — либо в виде design-документов в вики, либо в виде прототипов интерфейса, либо хотя бы в виде design-митингов. Причем все это можно совмещать.
И после реализации проверяйте её правильность обязательными ревью кода.
Заставляйте разработчиков проектировать фичи перед их написанием — либо в виде design-документов в вики, либо в виде прототипов интерфейса, либо хотя бы в виде design-митингов. Причем все это можно совмещать.
И после реализации проверяйте её правильность обязательными ревью кода.
это не «медленнее, да качественнее», это «вместо создания проекта рисовать мышкой схемы»
Если разработчиков не заставлять думать перед погружением в код — они будут «думать» в коде. Ясно, что из этого получится, постоянные доработки и баги. Часто разработчик с горящими глазами бегущий к консоли пропадал на неделю, когда я просил его набросать схему интерфейсов и логическую модель данных.
Sign up to leave a comment.
Роль техдира в Agile — игра в Тетрис