Здравствуйте, J_K, Вы писали:
J_K>Ума не приложу, что делать. С отчаяния пришла такая идея — реализовать новую функциональность не трогая существующий фреймворк — по крайней мере пока — просто добавить еще одну страницу, скажем, через меню "Дополнительно...", и добавить новую страницу, на которой и реализовать нужную функциональность — обычными методами, без использования этого супер-фреймворка. Не знаю, правильно это или нет. Просто на то, чтобы понять, как работает существующий фреймворк, и как его применять, при полном отсутствии документации — боюсь, на это может уйти слишком много времени. J_K>Что посоветуете?
Именно это и посоветую — делать отдельную дополнительную функциональность обычными методами. И потихоньку "копать" фреймворк — в конце-концов разберешься, и понапишешь комментариев. Очень возможно, что и прорефакторишь его.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, J_K, Вы писали:
J_K>Что посоветуете?
Объяснить ситуацию руководству, предложить несколько вариантов, от изучить фреймворк, до все выбросить и переписать. Варианты дать с обзором положительных и отрицательных сторон, дать временные оценки. Ждать, что решит руководство. Если руководство неадекватное и скажет, что-то вроде: "ну сделай что-нибудь по быстрому" — уйти в нормальную компанию с нормальным процессом разработки.
J_K>Ситуация следующая. Работаю полгода примерно на новой работе. Все время приходилось заниматься новыми проектами, а тут вдруг поступило задание доработать существующий проект.
Ну а что ты хотел? Работа програмиста это не только писать новый код но и разбираться в уже существующем.
J_K>Лезу в код и мне становится плохо — клиентская часть, реализованная на Javascript, сделана в виде огромного фреймворка, который совершенно непонятно, как применять. Т.е. тот, кто это делал, написал огромный фреймворк, и на его основе реализовал всю функциональность. Этот разработчик уходит через несколько дней (по личным обстоятельствам). Документации 0. Он мне сделал небольшую вводную по той функциональности, которую надо реализовать, но у меня получается сделать лишь крохотный кусок — остальное тайна за семью печатями — спагетти-код, который очень трудно раскручивать на Javascript, все это щедро сдобрено темплейтами и магическими переменными. Возможно, мне бы удалось со временем разобраться, но проблема в том, что времени нет — начальство попросило добавить функциональность в течение двух недель.
Нормальная ситуация. Я тут фигею от советов "все выбросить и переписать." Компания вложила в код деньги и что будет если каждый последущий програмист будет кричать что все надо выбросить и переписать?
J_K>Приложение наше реализовано в видно одностраничного веб-приложения — т.е. грузится одна страница, по кликам из меню открываются соответвующие секции, обновляется основная часть.
J_K>Ума не приложу, что делать. С отчаяния пришла такая идея — реализовать новую функциональность не трогая существующий фреймворк — по крайней мере пока — просто добавить еще одну страницу, скажем, через меню "Дополнительно...", и добавить новую страницу, на которой и реализовать нужную функциональность — обычными методами, без использования этого супер-фреймворка. Не знаю, правильно это или нет. Просто на то, чтобы понять, как работает существующий фреймворк, и как его применять, при полном отсутствии документации — боюсь, на это может уйти слишком много времени. J_K>Что посоветуете?
Разбирайся. Смотри как сделанны похожие вещи и делай также. Можешь и в обход этому фреймворку писать если уж совсем никак. Учись, в общем, работать в рамках кода написанного предшественниками. Не всегда ведь будут новые проекты .
Начальству тоже объясни что проект для тебя новый и ты не сможешь быстро работать как предыдущий разработчик.
Вообще разбираться в коде без документации нормальный навык программиста. У большинства проектов её нет, либо она очень сильно устарела.
В общем придётся разбираться. На это уйдёт месяц-два. Начинать надо с простых задач, вроде "переименовать кнопку". Помощь уходящего коллеги будет очень полезный, так что не теряй времени и используй его на все 100%.
Единственно, надо поставить начальство в известность. Иначе у тебя не будет времени.
Можно и сбоку что-то прилепить, но во-первых, так ты не разберёшься в существующем коде, и потом всё-равно это переделывать придётся.
Поэтому лучше сдвинуть сроки. То что уходит ключевой программист, это не твоя вина, а руководства.
Здравствуйте, J_K, Вы писали:
J_K>Что посоветуете?
Пойти к начальству и обсудить с ним. Начать с того, что существующая реализация столь сложна, что вам потребуется как минимум N времени, чтобы в ней разобраться. Оценка времени N должна быть близкой к истине (т.е., если вам предоставят это время, вы должны суметь разобраться). Если начальство будет требовать N сократить, честно сказать, что попробовать-то вы можете, но за результат не ручаетесь.
Pzz>Если начальство будет требовать N сократить, честно сказать, что попробовать-то вы можете, но за результат не ручаетесь.
Лучше так не делать. Если результата не будет, всю вину свалят на него.
Здравствуйте, mogikanin, Вы писали:
Pzz>>Если начальство будет требовать N сократить, честно сказать, что попробовать-то вы можете, но за результат не ручаетесь. M>Лучше так не делать. Если результата не будет, всю вину свалят на него.
Это зависит от того, насколько в данной конторе вменяемые отношения между людьми.
Существование проблем — это нормальное явление. В том числе, существование проблем, которые трудно или невозможно решить имеющимися силами. Я лично от своих подчиненных, когда они у меня есть , не требую способности решать все на свете проблемы, поскольку понимаю, что работаю не с волшебниками. Но когда человек берется за работу, долго копается, а потом, через существенное время, выясняется, что он никуда не продвинулся, возникает естественный вопрос, чем он все это время занимался и почему раньше ничего не сказал. Т.е., когда человек честно говорит "не могу", я считаю это нормальным. Когда человек говорит "могу", но не делает, я считаю это непрофессиональным поведением. Если это происходит не время от времени, а постоянно, с таким человеком надо расставаться.
Ну а если начальство невменяемо, то какой смысл держаться за продолжение отношений с ним?
Начальство вменяемо вполне.
Я считаю, что лучше всего реализовать функциональность вне имеющегося фреймворка, но здесь, как упоминалось выше, два скользких момента:
1. Не получится встроить код бесшовно — т.е. если сейчас это одностраничное веб-приложение, то будет как минимум 2 страницы. Впрочем, на мой взгляд, это не так уж и страшно.
2. Начальство, хотя и вменяемо, не очень разбирается в имеющейся ситуации. Поэтому боюсь, что могут задуматься о моей компетентности... но опять же, выше головы не прыгнешь — чувствую, что не будет результата (вовремя), если попытаюсь юзать этот несчастный фреймворк.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Потонет.
ОК>Ты не поверишь, но ты только что описал цикл жизни проектов которым 10-20-30 лет и над которыми поработали разные програмисты с разными квалификациями и где нет ни начальных разработчиков, ни документации зато есть сроки и "надо."
Ты работал на таких проектах? Я работал на больших проектах и не тонули они, хоть и капали в том числе и потому, что там студентам давали по рукам когда они начинали сбоку сарайчик возводить.
Здравствуйте, J_K, Вы писали:
J_K>Нужно делать так, как правильно. А правильно — делать сейчас максимально быстро независимо от подхода, а потом договориться с начальством, что надо выделить время специально на пересмотр фреймворка.
После того как задача сделана никто не даст времени ни на какой пересмотр. И в следующий раз не даст, ведь ты раньше справлялся без всякого пересмотра, значит и еще раз справишься. Стоит прогнуться один раз и потому придется лепить костыли до самого увольнения. А увольнение не задержится, потому что костыльная конструкция имеет свойство разваливаться.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, J_K, Вы писали:
J_K>>Нужно делать так, как правильно. А правильно — делать сейчас максимально быстро независимо от подхода, а потом договориться с начальством, что надо выделить время специально на пересмотр фреймворка.
M>После того как задача сделана никто не даст времени ни на какой пересмотр. И в следующий раз не даст, ведь ты раньше справлялся без всякого пересмотра, значит и еще раз справишься. Стоит прогнуться один раз и потому придется лепить костыли до самого увольнения. А увольнение не задержится, потому что костыльная конструкция имеет свойство разваливаться.
Чушь какая. Что за лексика, в самом деле? Почему сразу "прогнуться", "увольнение"? Дадут (время на пересмотр) как миленькие — ведь сами же понимают, что система будет трещать по швам, и очень скоро. Другое дело, что много времени не дадут — это очевидно. Но надо договариваться, чтобы дали хоть сколько-то, люди-то вменяемые.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Всем привет.
Ситуация следующая. Работаю полгода примерно на новой работе. Все время приходилось заниматься новыми проектами, а тут вдруг поступило задание доработать существующий проект. Лезу в код и мне становится плохо — клиентская часть, реализованная на Javascript, сделана в виде огромного фреймворка, который совершенно непонятно, как применять. Т.е. тот, кто это делал, написал огромный фреймворк, и на его основе реализовал всю функциональность. Этот разработчик уходит через несколько дней (по личным обстоятельствам). Документации 0. Он мне сделал небольшую вводную по той функциональности, которую надо реализовать, но у меня получается сделать лишь крохотный кусок — остальное тайна за семью печатями — спагетти-код, который очень трудно раскручивать на Javascript, все это щедро сдобрено темплейтами и магическими переменными. Возможно, мне бы удалось со временем разобраться, но проблема в том, что времени нет — начальство попросило добавить функциональность в течение двух недель.
Приложение наше реализовано в видно одностраничного веб-приложения — т.е. грузится одна страница, по кликам из меню открываются соответвующие секции, обновляется основная часть.
Ума не приложу, что делать. С отчаяния пришла такая идея — реализовать новую функциональность не трогая существующий фреймворк — по крайней мере пока — просто добавить еще одну страницу, скажем, через меню "Дополнительно...", и добавить новую страницу, на которой и реализовать нужную функциональность — обычными методами, без использования этого супер-фреймворка. Не знаю, правильно это или нет. Просто на то, чтобы понять, как работает существующий фреймворк, и как его применять, при полном отсутствии документации — боюсь, на это может уйти слишком много времени.
Что посоветуете?
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, J_K, Вы писали:
J_K>Что посоветуете?
просто не принимать проект невозможно?
насколько я понял ситуацию, Вы сейчас задаете правила игры? бизнес вряд ли захочет лишиться 2-х разработчиков сразу.
выставляйте сроки. во
Здравствуйте, Олег К., Вы писали:
ОК>Можешь и в обход этому фреймворку писать если уж совсем никак.
Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
ОК>>Можешь и в обход этому фреймворку писать если уж совсем никак.
MTD>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
Не потонет. Ты не поверишь, но ты только что описал цикл жизни проектов которым 10-20-30 лет и над которыми поработали разные програмисты с разными квалификациями и где нет ни начальных разработчиков, ни документации зато есть сроки и "надо."
У топикстартера проект, конечно же, не такого размаха. Так что я не понимаю криков "ой, мне дали не новый проект! что делать?" Разбираться надо, конечно же, и стараться сделать как лучше. Не всегда это возможно, правда.
Можете меня минусовать сколько хотите, но я считаю, что фреймворк, который написан без строки документации, примеров использования и т.д., должен быть выброшен на помойку. Человек, который пишет базу, т.е. фреймворк, должен всегда думать о том, как и кто его потом будет использовать. Говоря о том, чтобы писать в обход существующего фреймворка, имелось в виду, что не надо лепить новый фреймворк, а использовать имеющиеся, сторонные, хорошо документированные фреймворвки — например, помимо самопального, мы используем jQuery и KendoUI. Они для того и созданы, чтобы их использовать. Зачем нашему разработчику понадобилось писать все с нуля, я не знаю.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, J_K, Вы писали:
J_K>Можете меня минусовать сколько хотите, но я считаю, что фреймворк, который написан без строки документации, примеров использования и т.д., должен быть выброшен на помойку. Человек, который пишет базу, т.е. фреймворк, должен всегда думать о том, как и кто его потом будет использовать. Говоря о том, чтобы писать в обход существующего фреймворка, имелось в виду, что не надо лепить новый фреймворк, а использовать имеющиеся, сторонные, хорошо документированные фреймворвки — например, помимо самопального, мы используем jQuery и KendoUI. Они для того и созданы, чтобы их использовать. Зачем нашему разработчику понадобилось писать все с нуля, я не знаю.
Ты рассуждаешь как разработчик или идеалист. Конечно, еще на начальном этапе разработки должны быть выстроены процессы, код должен быть документируемым, версионным, содержать юнит-тесты и т.д. и т.п.
А теперь посмотри на ситуацию с точки зрения бизнеса. Потрачено большое количество времени (и денег), реализована функциональность, которая с точки зрения пользователя их полностью устраивает.
Теперь им понадобилось добавить одну небольшую фичу.
И тут появляется принц на белом коне, который говорит, что код говно, и вместо реализации маленькой фичи, надо все написать с нуля.
Нормально?
Конечно можно попробовать уговорить начальство потихоньку параллельно пилить версию 2.0, но это не отменяет необходимости поддержки текущей версии до тех пор, пока новая версия не сможет заменить ее.
Здравствуйте, J_K, Вы писали:
J_K>н мне сделал небольшую вводную по той функциональности, которую надо реализовать, но у меня получается сделать лишь крохотный кусок — остальное тайна за семью печатями — спагетти-код, который очень трудно раскручивать на Javascript, все это щедро сдобрено темплейтами и магическими переменными.
На Ваше счастье, темплейтов в JavaScript нет. Это очень простой язык
Здравствуйте, J_K, Вы писали:
J_K>Можете меня минусовать сколько хотите, но я считаю, что фреймворк, который написан без строки документации, примеров использования и т.д.,
ой да подумаешь. я участвовал в проекте в котором на каждую страницу вешалось yui, jquery, и три варианта старых фреймворков собственного написания с 2000 по 2009 годы. там прям видно как люди учили яваскрипт, сначала идет onclick в тегах, потом onclick на яваскрипте с ручным аяксом под IE, потом что то вроде jquery только с блекжеком и фантазиями.
фантазии — это слежение за курсором мышки и включение выключение разных обработчиков вроде onbeforeunload на лету.
ну и оно естественно в рамках портала все работает, а то не весело будет. итого порядка 100 яваскрипт файлов на страницу.
так вот. дописать кода на яваскрипт можно всегда! реальные проблемы были только с хитрыми скриптами которые следили за курсором. все остальное оверрайдится на ура. просто бери jquery и добавляй свой ajax и обработчики формочек. скорее всего абсолютно бесшовно заработает и никто не заметит.
ЗЫ use the force of preventpropagation ну и вешать в самом крайнем случае в самом теге onclick итп у таких вещей приоритет по обработке. если мего фреймворк предыдущего творца на лету много творит html я по шаблонам, то скорее всего можно даже отреюзать сами шаблонны и обойтись без копипаста, см. шаблонные движки на яваскрипте, есть очень конфигурабельные.
Не надо вырывать из контекста.
А контекст таков, что новая функциональность должна быть добавлена быстро. Ключевое слово "быстро", понимаете? Если использовать известные документированные фреймворки, такие, как KendoUI например, фича добавляется за 2 недели спокойно, и юнит тесты даже можно успеть дописать. Но если вникать в существующий код, на одно это только неделя уйдет, к тому же у меня большие подозрения, что наш крутой фреймворк не поддеживает все, что нужно реализовать, и, следовательно, придется, еще и фреймворк допиливать. Сегодня мы с этим разработчиком потратили почти час на реализацию маленького кусочка, потому что он сам уже не все помнит, что и как у него там сделано.
Дело совсем не в том, что мне неохота разбираться в существующем коде. Дело в том, что это просто совершенно нецелесообразно. Фреймворк написан, но он не удовлетворяет наши потребности, он не гибок, в нем очень трудно разобраться, трудно использовать и т.д. Ну это как если вы писали свой собственный jQuery, не документируя его, ничего, а потом обнаружили, что кто-то другой сделал такую же работу, но снабдил подробной документацией, вы будете продолжать грызть кактус только потому, что это уже сделано, что вы уже вложили время, ресурсы и т.д.? По-моему, это просто глупо.
С другой стороны, встраивание новой функциональности в обход существующего фреймворка хотя и целесообразно, но если делать это непродуманно, то в конце концов получится каша. Лично я за то, чтобы как следует продумать, как это можно сделать, сделать пару-троек (но не больше!) оберток, которые будут юзаться в дальнейшем, но времени на это тоже нет — сейчас. В этом и проблема.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Олег К., Вы писали:
ОК>>Можешь и в обход этому фреймворку писать если уж совсем никак.
MTD>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
Смотря какой фреймворк, если инфраструктурного кода значительно больше, чем прикладного, возникает вопрос в его целесообразности.
Здравствуйте, Handie, Вы писали:
H>Здравствуйте, J_K, Вы писали:
J_K>>н мне сделал небольшую вводную по той функциональности, которую надо реализовать, но у меня получается сделать лишь крохотный кусок — остальное тайна за семью печатями — спагетти-код, который очень трудно раскручивать на Javascript, все это щедро сдобрено темплейтами и магическими переменными.
H>На Ваше счастье, темплейтов в JavaScript нет. Это очень простой язык
Ах Боже ты мой, да разумеется, речь не идет об использовании чистого JS — поверх него у нас накручены jQuery, а затем темплейты из knockoutjs, которые сами по себе не страшны, но как все это вместе увязано — вот это страшно — надо знать все 30 мест, где следует прописать имя вызывающего объекта, имя вызываемого объекта, темплейт вызывающего объекта, темплейт вызываемого объекта и т.д.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Олег К., Вы писали:
ОК>>Можешь и в обход этому фреймворку писать если уж совсем никак.
MTD>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
Да блин, говорят же, времени нет. Клиент хочет новую функциональность, боюсь, что на разбирательство с имеющимся фреймворком уйдет как минимум половина времени, и не останется на собственно разработку фичи.
Конечно, лучше всего, сесть, изучить как следует, может быть отрефакторить, написать доки, тесты, примеры использования и т .д., но нет пока времени!
С другой стороны нашлепка нашлепке рознь, можно сделать и так чтобы нашлепки работали независимо (тем более, что части приложения не очень большие) и, если трабла возникнет в одной из них, то не надо пробираться по хитросплетению спагетти-кода фреймворка, смешанного с динамическими объектами, темплейтами и магическими переменными. Ну и конечно, культура дальнейшей разработки важна: писать доки, тесты, примеры, делать код-ревю, не использовать магические переменные, комментировать код и т.д. Всего этого сейчас нет, что очень сильно усложняет использование имеющегося кода, хотя, по идее, он должен помогать разработчикам добавлять функциональность, писать унифицированный код.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, Олег К., Вы писали:
ОК>>>Можешь и в обход этому фреймворку писать если уж совсем никак.
MTD>>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
ОК>Не потонет. Ты не поверишь, но ты только что описал цикл жизни проектов которым 10-20-30 лет и над которыми поработали разные програмисты с разными квалификациями и где нет ни начальных разработчиков, ни документации зато есть сроки и "надо."
ОК>У топикстартера проект, конечно же, не такого размаха. Так что я не понимаю криков "ой, мне дали не новый проект! что делать?" Разбираться надо, конечно же, и стараться сделать как лучше. Не всегда это возможно, правда.
А кто кричит? Никто не кричит. А если кричит, то совсем другое, скорее "что делать, если на разбирательство в нашем фреймворке может уйти десяток человеко-дней, а на фичу дано всего две недели?!" Нафига они наобещали клиенту 2 недели, тоже вопрос конечно.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, nile, Вы писали:
N>Здравствуйте, J_K, Вы писали:
J_K>>Можете меня минусовать сколько хотите, но я считаю, что фреймворк, который написан без строки документации, примеров использования и т.д., должен быть выброшен на помойку. Человек, который пишет базу, т.е. фреймворк, должен всегда думать о том, как и кто его потом будет использовать. Говоря о том, чтобы писать в обход существующего фреймворка, имелось в виду, что не надо лепить новый фреймворк, а использовать имеющиеся, сторонные, хорошо документированные фреймворвки — например, помимо самопального, мы используем jQuery и KendoUI. Они для того и созданы, чтобы их использовать. Зачем нашему разработчику понадобилось писать все с нуля, я не знаю.
N>Ты рассуждаешь как разработчик или идеалист. Конечно, еще на начальном этапе разработки должны быть выстроены процессы, код должен быть документируемым, версионным, содержать юнит-тесты и т.д. и т.п. N>А теперь посмотри на ситуацию с точки зрения бизнеса. Потрачено большое количество времени (и денег), реализована функциональность, которая с точки зрения пользователя их полностью устраивает.
Это к сожалению, не так. В связи с использованием фреймворка были реализованы довольно жеские паттерны, которые не позволяют сделать все, что нужно, а процесс поиска ошибок и их исправления превращается в пытку — были прецеденты, когда даже наш главный разраб не мог найти причину ошибки и ставил костыль.
N>Теперь им понадобилось добавить одну небольшую фичу. N>И тут появляется принц на белом коне, который говорит, что код говно, и вместо реализации маленькой фичи, надо все написать с нуля.
Никто не говорит, что надо писать все с нуля. И никто не говорит, что сам код говно. не надо передергивать. Было сказано лишь, что фреймворк получился большой и сложный, сопроводительной документации 0, а времени на реализацию фичи мало. N>Нормально? N>Конечно можно попробовать уговорить начальство потихоньку параллельно пилить версию 2.0, но это не отменяет необходимости поддержки текущей версии до тех пор, пока новая версия не сможет заменить ее.
Именно это я и хочу делать (НО! не писать заново свой велосипед, а построить модульную систему, которая использует только готовые решения). Другой вариант — сесть и как следует разобраться со фреймворком, посмотреть, может, он более гибок, чем кажется, написать доки, примеры использования и т.д.
Текущая же проблема связана именно с нехваткой времени.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, nile, Вы писали:
N>Ты рассуждаешь как разработчик или идеалист. Конечно, еще на начальном этапе разработки должны быть выстроены процессы, код должен быть документируемым, версионным, содержать юнит-тесты и т.д. и т.п. N>А теперь посмотри на ситуацию с точки зрения бизнеса. Потрачено большое количество времени (и денег), реализована функциональность, которая с точки зрения пользователя их полностью устраивает.
С точки зрения бизнеса или рыночного торговца помидорами? Разница есть. Небольшая такая.
N>Теперь им понадобилось добавить одну небольшую фичу.
N>И тут появляется принц на белом коне, который говорит, что код говно, и вместо реализации маленькой фичи, надо все написать с нуля.
И тут никакого принца не появляется, старые разработчики давно уволились, новыые фичу-то делают, только проект занимает полгода вместо двух недель и при этом половина старой функциональности того... работать перестает.
Это назвается technical debt. Если бизнес заинтересован в своем успешном развитии, он должен стремиться к выделенному. Иначе technical debt будет накапливаться...накпаливаться.. пока в один прекрасный момент не окажется, что легче закопать, чем починить. У нас тут, кстати, многие банки в последние пару лет осознали, в каком дерьме они оказались. Впрочем, многие их клиенты имели "щастье" вживую наблюдать, во что в итоге выливается игнорирование технического долга.
Здравствуйте, J_K, Вы писали:
J_K>Всем привет. J_K>Ситуация следующая. Работаю полгода примерно на новой работе. Все время приходилось заниматься новыми проектами, а тут вдруг поступило задание доработать существующий проект. Лезу в код и мне становится плохо — клиентская часть, реализованная на Javascript, сделана в виде огромного фреймворка, который совершенно непонятно, как применять. Т.е. тот, кто это делал, написал огромный фреймворк, и на его основе реализовал всю функциональность. Этот разработчик уходит через несколько дней (по личным обстоятельствам). Документации 0. Он мне сделал небольшую вводную по той функциональности, которую надо реализовать, но у меня получается сделать лишь крохотный кусок — остальное тайна за семью печатями — спагетти-код, который очень трудно раскручивать на Javascript, все это щедро сдобрено темплейтами и магическими переменными. Возможно, мне бы удалось со временем разобраться, но проблема в том, что времени нет — начальство попросило добавить функциональность в течение двух недель.
J_K>Приложение наше реализовано в видно одностраничного веб-приложения — т.е. грузится одна страница, по кликам из меню открываются соответвующие секции, обновляется основная часть.
J_K>Ума не приложу, что делать. С отчаяния пришла такая идея — реализовать новую функциональность не трогая существующий фреймворк — по крайней мере пока — просто добавить еще одну страницу, скажем, через меню "Дополнительно...", и добавить новую страницу, на которой и реализовать нужную функциональность — обычными методами, без использования этого супер-фреймворка. Не знаю, правильно это или нет. Просто на то, чтобы понять, как работает существующий фреймворк, и как его применять, при полном отсутствии документации — боюсь, на это может уйти слишком много времени. J_K>Что посоветуете?
Был в точно такой же ситуации, когда старший разработчик соорудил свой редактор уровней для игры, хотя кругом было полно готовых, с документацией и примерами. Он же наворотил там, каша, все неаккуратно. И заявил, что вот мол кто хочет, тот разбереться. Я говорю, что надо разработкой заниматься, а не разбираться в твоем фреймворке. Пошел к начальству, сказал, что так и так, это не промышленный подход, не дай бог уйдет Ваш старший разработчик, станет весь процесс разработки игрухи. Обьяснил, что надо юзать распространненые, документированные тулзы, где есть комьюнити и пр. Он согласился. В итоге ту игру старший остался сам дописывать, а нам с другими ребятами поручили новый проект делать.
Здравствуйте, J_K, Вы писали:
J_K>Всем привет. J_K>Что посоветуете?
я присоединяюсь к взвешанным советам ибо радикалъно послать всех и уйти вы похоже не хочете/не можете.
итак: оценка проекта состоялась, следующее -> разговор с руководством и обьяснение ситуации, при этом вы можете
напрямую сказать что человек перед вами писал код "для себя" и это затрудняет быструю адаптацию нового программиста. сделайте предложение как вы и думаете(новая страница) если совсем быстро надо ну а далее как предлагает профессор(лаптев) со временем разберётесь, переработатете код, адаптируетесь. думаю это единственно реалъный путь устраивающий обе стороны(вас и руководство).
мнение тех кто считает что вы безропотно должны код вашего предшественника перенять причём который похоже исходил из того (как у нас говорят писал толъко для машины) что никто его код перенимать не будет и не имел никаких
внутрифирменных рамок, стандартов, регламентов не говоря уже о code review через коллег — я подчёркнуто не поддерживыю
Здравствуйте, MTD, Вы писали:
MTD>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
Вредительство — это такой стиль менеджмента, когда ключевое знание по важному продукту сосредоточено в одной голове. Человек увольняется, заболевает, умирает — а клиенту плевать, "I don't care" (c). Клиенту новая фича нужна, и деньги вот они, просто доработайте имеющийся (и работающий!) проект. И примеров таких — выше крыши.
Здравствуйте, J_K, Вы писали:
J_K>Что посоветуете?
Сделай бочку, серьёзно.
Попроси его накидать HLA и примерные диаграмы что и за что отвечает. Если проектировали всё по канонам, то сложности вникунть в код быть не должно и ты сможешь достаточно просто создавать новые штуки с используя фреймвор. Фиксить сам феймворк сможешь через месяц-два.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, MTD, Вы писали:
MTD>>Похоже на откровенное вредительство — вместо того, чтобы разобраться и навести порядок, нашлепать сбоку кода. Потом придет другой разработчик, добавиться еще нашлепка, а потом проект потонет под их грузом.
MD>Вредительство — это такой стиль менеджмента, когда ключевое знание по важному продукту сосредоточено в одной голове. Человек увольняется, заболевает, умирает — а клиенту плевать, "I don't care" (c). Клиенту новая фича нужна, и деньги вот они, просто доработайте имеющийся (и работающий!) проект. И примеров таких — выше крыши.
Это, конечно, не вредительство, а просто безалаберность и нежелание думать вперед.
Вчера был короткий разговор с тех.менеджером. Он сказал, что осознает все эти проблемы и планирует в будущем потихоньку переползать с этого самопального фреймворка на что-то готовое. Кроме того, он полон желания внедрять все разумное-доброе-вечное — в смысле вводить код ревю, документацию и т.д.
Что касается текущей задачи, вчера потратили чуть ли не целый рабочий день с тем разработчиком, он показывал-рассказывал, как реализовывать фичу используя его фреймворк. Без его помощи это заняло бы неделю, не меньше. Надеюсь, что с этой задачей удастся справиться, но надо будет сразу же после что-то придумать.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
A>>Не работали Вы в азиатских конторах, чувствуется Там, по воспоминаниям очевидцев, слова "нет" начальнику не говорят.
K>Не понимаю. K>а если сказать "нет". Что будет?
передадут работу тому, кто не скажет "нет" (независимо от результата)
Вас уволят.
Здравствуйте, serra, Вы писали:
A>>>Не работали Вы в азиатских конторах, чувствуется Там, по воспоминаниям очевидцев, слова "нет" начальнику не говорят.
K>>Не понимаю. K>>а если сказать "нет". Что будет?
S>передадут работу тому, кто не скажет "нет" (независимо от результата) S>Вас уволят.
S>Разница в зарплатах компенсирует неэффективность
Все тут страдают юношеским максимализмом Ну зачем обязательно говорить "нет"? Ну почему сразу уж так и уволят??
Нужно делать так, как правильно. А правильно — делать сейчас максимально быстро независимо от подхода, а потом договориться с начальством, что надо выделить время специально на пересмотр фреймворка.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, J_K, Вы писали:
J_K>Чушь какая. Что за лексика, в самом деле? Почему сразу "прогнуться", "увольнение"? Дадут (время на пересмотр) как миленькие — ведь сами же понимают
Если так, то Вам повезло с руководством. В моей жизни в 98 году аккурат в октябре-месяце руководство как раз ничего не понимало и понимать не желало. Как и слышать слово "нет". Бывшие военные, причем повышенной тупости. Впрочем, это было одно-единственное место, да и выпало оно мне по сочетанию факторов моего салабонства и кризиса.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, J_K, Вы писали:
J_K>>Дадут (время на пересмотр) как миленькие — ведь сами же понимают, что система будет трещать по швам, и очень скоро.
M>Ты кого пытаешься убедить, меня или себя?
Никого не пытаюсь убедить, а пересказываю разговор с техменеджером. Он сам подтвердил, что переходить на новый подход надо, а раз подтвердил, то значит и время выделит.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
J_K>>>Дадут (время на пересмотр) как миленькие — ведь сами же понимают, что система будет трещать по швам, и очень скоро.
M>>Ты кого пытаешься убедить, меня или себя?
J_K>Никого не пытаюсь убедить, а пересказываю разговор с техменеджером. Он сам подтвердил, что переходить на новый подход надо, а раз подтвердил, то значит и время выделит.
Вся финансовая индустрия так держится а ты говоришь потонет.
ОК>>Ты не поверишь, но ты только что описал цикл жизни проектов которым 10-20-30 лет и над которыми поработали разные програмисты с разными квалификациями и где нет ни начальных разработчиков, ни документации зато есть сроки и "надо."
MTD>Ты работал на таких проектах? Я работал на больших проектах и не тонули они, хоть и капали в том числе и потому, что там студентам давали по рукам когда они начинали сбоку сарайчик возводить.
Работал. Иначе бы не писал. Костыли, хаки, подпорки, кривая архитектура, ненужные навороты, ненужные фичи, баго-фичи. Кучи разных зависимостей. Без танцев с бубном код просто не скомпилировать. И тем не менее это приносит деньги.
J_K>А кто кричит? Никто не кричит. А если кричит, то совсем другое, скорее "что делать, если на разбирательство в нашем фреймворке может уйти десяток человеко-дней, а на фичу дано всего две недели?!" Нафига они наобещали клиенту 2 недели, тоже вопрос конечно.
Ну что значит "разбирательство в фреймворке?" Обычно все-таки концентрируешься на какой-то конкретной задаче. Смотришь как сделанны подобные вещи. И с течением времени у тебя появляется представление как что-то работает, куда смотреть когда надо и т.д. А разбираться в вашем фреймворке досконально не вижу смысла.
L>Это назвается technical debt. Если бизнес заинтересован в своем успешном развитии, он должен стремиться к выделенному. Иначе technical debt будет накапливаться...накпаливаться.. пока в один прекрасный момент не окажется, что легче закопать, чем починить. У нас тут, кстати, многие банки в последние пару лет осознали, в каком дерьме они оказались. Впрочем, многие их клиенты имели "щастье" вживую наблюдать, во что в итоге выливается игнорирование технического долга.
Мне это напоминает речь того чувака с Голдмана где он рассказывает как Голдман нае...ает своих клиентов. Они всегда были в таком дерьме, есть и будут и тут они вдруг внезапно осознали об этом дерьме.
Никто и не вырывает.
J_K>А контекст таков, что новая функциональность должна быть добавлена быстро. Ключевое слово "быстро", понимаете?
А это всегда так.
J_K>Если использовать известные документированные фреймворки, такие, как KendoUI например, фича добавляется за 2 недели спокойно, и юнит тесты даже можно успеть дописать. Но если вникать в существующий код, на одно это только неделя уйдет, к тому же у меня большие подозрения, что наш крутой фреймворк не поддеживает все, что нужно реализовать, и, следовательно, придется, еще и фреймворк допиливать. Сегодня мы с этим разработчиком потратили почти час на реализацию маленького кусочка, потому что он сам уже не все помнит, что и как у него там сделано.
Ну не помнит и не помнит. Он что ли все должен помнить?
J_K>Дело совсем не в том, что мне неохота разбираться в существующем коде.
Ну мы поняли.
J_K>Дело в том, что это просто совершенно нецелесообразно.
Судя по твоему желанию все переписать, кода там немного. Было бы очень много кода, такого желания бы не возникло впервую очередь.
J_K>Фреймворк написан, но он не удовлетворяет наши потребности, он не гибок, в нем очень трудно разобраться, трудно использовать и т.д.
Скорее всего это так и есть но тем не менее с ним нужно уметь работать.
J_K>Ну это как если вы писали свой собственный jQuery, не документируя его, ничего, а потом обнаружили, что кто-то другой сделал такую же работу, но снабдил подробной документацией, вы будете продолжать грызть кактус только потому, что это уже сделано, что вы уже вложили время, ресурсы и т.д.? По-моему, это просто глупо.
Обычно код живет дольше чем ты этого ожидаешь. Некоторые проекты переписываются когда уже совсем не в моготу. Судя по тому что ты тут пишешь, этот момент еще не наступил.
Сейчас у тебя такое желание переписать все потому что 1) ты до этого работал только на новых проектах, 2) тебе не хочется разбираться в существующем коде и 3) кода не так уж и много. Иначе у тебя даже в мыслях не возникло бы все переписать.
J_K>С другой стороны, встраивание новой функциональности в обход существующего фреймворка хотя и целесообразно, но если делать это непродуманно, то в конце концов получится каша. Лично я за то, чтобы как следует продумать, как это можно сделать, сделать пару-троек (но не больше!) оберток, которые будут юзаться в дальнейшем, но времени на это тоже нет — сейчас. В этом и проблема.
J_K>Можете меня минусовать сколько хотите, но я считаю, что фреймворк, который написан без строки документации, примеров использования и т.д., должен быть выброшен на помойку. Человек, который пишет базу, т.е. фреймворк, должен всегда думать о том, как и кто его потом будет использовать. Говоря о том, чтобы писать в обход существующего фреймворка, имелось в виду, что не надо лепить новый фреймворк, а использовать имеющиеся, сторонные, хорошо документированные фреймворвки — например, помимо самопального, мы используем jQuery и KendoUI. Они для того и созданы, чтобы их использовать. Зачем нашему разработчику понадобилось писать все с нуля, я не знаю.
Что есть то есть. Программисты любят технические навороты воротить а не решать бизнес задачи. Однако это ничего не меняет. Этот ваш фреймворк ничем не отличается от любого другого прикладного кода. В нем надо уметь разбираться также как и в любом другом коде.
Здравствуйте, Олег К., Вы писали:
ОК>Работал. Иначе бы не писал. Костыли, хаки, подпорки, кривая архитектура, ненужные навороты, ненужные фичи, баго-фичи. Кучи разных зависимостей. Без танцев с бубном код просто не скомпилировать. И тем не менее это приносит деньги.
ОК>Чего я только не видел в общем.
Сочувствую, мне моя профессиональная гордость, не позволяет заниматься такими проектами неэффективно расходуя средства заказчика.
MTD>>На вопрос
ОК>>Работал. Иначе бы не писал. Костыли, хаки, подпорки, кривая архитектура, ненужные навороты, ненужные фичи, баго-фичи. Кучи разных зависимостей. Без танцев с бубном код просто не скомпилировать. И тем не менее это приносит деньги.
ОК>>Чего я только не видел в общем.
MTD>Сочувствую, мне моя профессиональная гордость, не позволяет заниматься такими проектами неэффективно расходуя средства заказчика.
Бред и ты все перевернул с ног наголову. Эти проекты от начала до конца такие и им не один десяток лет. Они живут и приносят деньги и я, в отличии от тебя, нос не ворочу и не кидаюсь таким напыщенными словами как профессиональная гордость.
MTD>>>На вопрос
ответишь? А то я не пойму, у меня глаз замылен?
ОК>>Да не горячись ты так. Сойдемся на том что это прозвучало как возможный вариант.
MTD>Момент ключевой — от человека который не в состоянии понять написанное вряд ли услышишь толковый совет
Момент ключевой — от человека который никогда не работал на сколь-либо более серьезных и долгих проектах вряд ли услышишь толковый совет.
ОК>Сейчас у тебя такое желание переписать все потому что 1) ты до этого работал только на новых проектах, 2) тебе не хочется разбираться в существующем коде и 3) кода не так уж и много. Иначе у тебя даже в мыслях не возникло бы все переписать.
Отчасти это так. Именно потому, что времени никогда нет, как вы справедливо заметили ниже, и не хочется тратить его на копание в самопальном фреймворке. Вернее, не то чтобы не хочется — просто не выйдет! Вот сами представьте — вам выделили на задачу две недели, и вы бы потратили на нее две недели, но надо разбираться в этом пресловутом фреймворке. Все то же самое можно быстро и легко реализовать используя например, связку KendoUI — jQuery — knockout, дерево там строится в две минуты, но нет. Надо сидеть и разбираться, как создать дерево с помощью самопального дерева, причем при полном отсутствии документации! Вот вы конкретно, что бы вы подумали — решили — стали делать в такой ситуации?
Что касается размеров фреймворка. Вы не представляете, но он огромен. Это просто монстр, в котором чего только не реализовано — там и наследование JavaScript, и разные события, и байндинг — все зашибись, видно, что писал гений (на полном серьезе), но как в этом разобраться без клочка документации — я просто не представляю.
Переписывать этого монстра желания нет никакого. Да и зачем??? Все уже сделано — достаточно заюзать jQuery, knockout, еще пару-тройку библиотек. Переходы и вызовы должны быть ясны и понятны. Когда слишком много байндится неизвестно где, отладка превращается в кошмар.
J_K>>С другой стороны, встраивание новой функциональности в обход существующего фреймворка хотя и целесообразно, но если делать это непродуманно, то в конце концов получится каша. Лично я за то, чтобы как следует продумать, как это можно сделать, сделать пару-троек (но не больше!) оберток, которые будут юзаться в дальнейшем, но времени на это тоже нет — сейчас. В этом и проблема.
ОК>А его (времени) никогда нет.
Life is very short and there's no time
for fussing and fighting... (C) Paul McCartney & John Lennon
Здравствуйте, Олег К., Вы писали:
ОК>Мне это напоминает речь того чувака с Голдмана где он рассказывает как Голдман нае...ает своих клиентов. Они всегда были в таком дерьме, есть и будут и тут они вдруг внезапно осознали об этом дерьме.
Хех. Судя по событиям последних лет, investment banking в принципе основан "обещай больше, кидай дальше".
А вот когда несоклько миллионов человек не могут воспользоваться своими счетами в течение двух суток из-за ошибки в софте или банкоматы перестают работать, причем все и сразу, то это начинает выглядеть уже несколько готично.
Да чего тут за примерами ходить — как вам банкоматы, которые требуют вводить сумму с точностью до центов, когда минимальная бумажка в них — 20 баксов, а монетки они вообще никогда в жизни выдавать не умели?
.
