Всем привет.

Хочу повысить свой скилл, потому что начал замечать, что чем сложнее задача, тем больше недочётов на этапе оценки допускаю и потом за ними тянутся длинные хвосты, когда задачу оценил в 20-30 часов работы, а на реализацию ушли все 60. Полагаю основная проблема тут в моём неумении правильно и быстро проектировать систему и потому на этапе оценки сложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализации. Да и решения не всегда лучшие получаются (код легко поддерживается только первых пол года, потом возникают трудности... спустя год неизбежно появляется необходимость длительного рефакторинга).

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

Заранее всем очень благодарен!

P.S. Я мог бы загуглить самостоятельно, но хотелось бы получить рекомендованную литературу именно по моей ситуации и желательно от тех, кто сам эту литературу читал :)

P.S. На всякий случай уточню: в основном занимаюсь вэбом и код пишу на php... Но как я понимаю с учётом интересующей темы это не должно иметь никакого значения :)

Relic Hunter,

А кого именно из классиков? Я в вопросе литературы совсем не в теме.
Надеюсь классиков не имелось ввиду "но вы держитесь"

Relic HunterПрограмёрсложность задачи и решение представляются совсем не такими, какими они оказываются по итогу реализациисделайте индексацию, поднимите пенсионный возраст, делов-то?

Не вариант. по двум причинам:
1. Мне не нравится выполнять свою работу плохо (а срывать все планы - это плохо)
2. Мало кто согласится доплачивать, ведь нередко клиенты выбирают подрядчика и с учётом озвученной стоимости, а когда она вдруг "переиндексируется" у них возникают вполне обоснованные вопросы :)

Мы же не правительство, у нас тут конкуренция работает и свободный рынок.

Но как бы то ни было, это решение не позволит мне перейти на уровень Senior'а... так и останусь в мидлах до 60-ти, а потом мидлом и помру :)) Меня такая перспектива не устраивает.

mayton,

Так и пытаюсь всё делать... И по скраму давно уже пашем, и пессимистический режим ключаю, и постоянно пытаюсь по результату спринта разбирать проблемные места, и всё это приводит к улучшению, но очень медленному, при чём с перебоями :) Вот щас как-раз сдал задачу рассчитанную на день, которую 3 дня пилил (оценил в 8 баллов, а щас хочется все 24 сказать)... правда тут брал не пессимистическую оценку, а среднюю изначально... но и задачу сдаю с парочкой TODO в коде очень серьёзными. Походу на днях полезу допиливать, пока никто не нашёл тех мест, где оно гарантированно завалится.

В общем учитывая как всё медленно и сложно движется, есть ощущение, что я что-то очень неправильно делаю, и не могу понять что. Даже курс по скраму просмотрел, пытаюсь всем рекомендациям следовать, но у нас в основном проекты, к которым подобную практику сложно применить (точнее применимо всё, кроме указанной декомпозиции на задачи... никто не станет проверять по 5 раз каждую функцию на этапе разработки, чтобы проследить, что она правильно реализуется и расширяется). Ещё там была рекомендация умножать сроки в 3-4 раза, что больше похоже на костыль с пометкой "TODO: попытаться выяснить какого фига нам приходится постоянно этот коэффициент применять" :))

Какие ещё причины могут к такому приводить? Как я говорил в моём представлении только одна: мне нужно учиться лучше проектировать свои решения и желательно достаточно быстро, чтобы понимать пути решения уже на этапе оценки задачи, а не на этапе реализации, когда пришло понимание, что реализация предполагаемая на этапе оценки невозможна и первую половину задачи удалось реализовать как задумывалось, но вот с этого момента пора в другую сторону ползти :)

mayton,

за книжечки спасибо. Роберта Мартина (дядю Боба) читал. Книга "Идеальный программист" называется, если не ошибаюсь. На самом деле хорошо мозги на место ставит и на работу настраивает, я после прочтения посадил менеджера проектов с которым работаю и долгие часы объяснял как оно должно быть... правда и тут от половины рекомендаций пришлось отказаться из-за "феее" от менеджера проекта, который сказал что так задачи готовить не сможет, бизнес аналитиков нет и не будет, тестировщиков тоже пока не будет и т.д. :)

А вот остальные не читал, но если они того же уровня, то почти уверен, что тоже много чего прояснят.

mayton
Какие ещё причины могут к такому приводить? Как я говорил в моём представлении только одна: мне нужно учиться лучше проектировать свои решения и желательно достаточно быстро, чтобы понимать пути решения уже на этапе оценки задачи, а не на этапе реализации, когда пришло понимание, что реализация предполагаемая на этапе оценки невозможна и первую половину задачи удалось реализовать как задумывалось, но вот с этого момента пора в другую сторону ползти :)
Причины - скорее всего недостаток уровня senyority. Ты наверное просто мало опыта накопил.

Давай так. Чтоб топик не был эмоциональным. Если у тебя нет NDA и запретов на публикацию.
Покажи фрагмент кода (без бизнес-секретов и имен) где у тебя были проблемы. И расскажи
что ты сделал чтобы их решить.

Кто-то в топике знаток в PHP полюбому что-то подскажет.

P.S. Это не rocket science.

По самому коду обычно проблем особых нет. Скорее есть проблемы с тем, что для решения задачи нужна уйма вспомогательных телодвижений, которые не входят в изначальную оценку. В борьбе с этим последних несколько задач полностью проектировал в "event-driven process chain", но и тут вот с этой последней задачей провтыкнул, потому что выполнил всё больше на уровне взаимодействия пользователь-система (хотя в этом отношении помогло сильно, ни один момент клиентского интерфейса не остался без внимания, так что пользу принесло), и не влез вглубь системы, а там оказалось, что заказ создал - не просто услугу продли, а сначала её при создании заказа создай, при оплате заказа продли... потом с самим хранением услуги.. раньше в корзине идентификатором покупаемой позиции выступал ID товара, а теперь с появлением услуг, имеющих срок действия, уникальности посредством ID товара не добиться, нужна продолжительность (то есть нужно частично переписывать существующее решение, а это не было должным образом учтено)... Но и это решение было не лучшим, потому что при продлении услуг и это не даёт уникальности (я могу продлить 2 одинаковых услуги с одинаковым периодом действия) и нужно ещё и id продлеваемой услуги включать в идентификатор, чтобы он стал уникальным. Обновление заказа (добавление или удаление позиций) с учётом нововведений оказалось намного сложнее из-за тех самых скрытых телодвижений.

В общем там пол часа, тут час, там час... и так ещё на лишних часов 10 и набежало, а с учётом возросшей вдвое сложности задачи и отладка из планируемых часов 2 превратилась ещё часов в 6 устранения мелких багов, недочётов, просто опечаток и прочего :)

SiemarglAnatoly Moskovskyпропущено...

Не волнуйтесь. Такое у всех.
Просто если вы неопытный умножайте оценку на 4..8.
Если вы опытный то умножайте на 2.
Меньше 2 кратной ошибки не бывает ))
Хотел посоветовать на 3.

Но похоже, я слишком оптимист =)

эмм.. ну я то вообще на 1.5 умножаю, потому взял на заметку, что надо больше коэффициент брать. Но очень бы хотелось разобраться с причинами, нельзя же просто умножать и всё, особенно если часть задач вполне получается решить в срок (а получится, что на них стоимость выйдет втрое завышена). Я в душе перфекционист и потому не смогу жить спокойно, пока не добьюсь того, чтобы я называл срок разработки 10 часов, выполнял задачу ровно за 9 и часок спокойно пил кофе :)) Это вот идеальный вариант, которого хотелось бы добиться, и мой уровень счастья измеряется в близости к этому варианту :))