Вобщем, поручили мне перевести одно приложение на другую БД. Отвели на это n-ое количество месяцев и понеслось. Я, нахлебавшись до этого поддержкой своего же написанного когда-то в студенческие годы ПО, решил сделать все "правильно". Решил применять только ООП и паттерны проектирования. Каждый раз приходится долго обдумывать каждую абстракцию и писать кучу кода. Разделил приложение на несколько логических слоев и стараюсь придерживаться этого расслоения. Но, катастрофически не хватает времени и опыта. Вот уже половина срока прошло, а мне толком и показать нечего, не буду же я им показывать несколько сотен модулей, которые для юзера не представляют никакой ценности, а начальник у меня такой, до сих пор пишет на С копипастом. Вот как мне ему объяснить, чем я тут вот уже 4 месяца занимаюсь? Я понимаю, что дальше будет все легче, потому что буду использовать написанное ранее, но ему-то этого не понять. Он не привык, выискивать какие-то там абстракции, он вообще не имеет представления о том, что такое абстракция. Вот я и впадаю в апатию и панику, когда думаю о том, что нафиг мне это все, писал бы как раньше, без всякого разделения на логику, интерфейс и т.д. и т.п. без этого ООП, клепал бы по несколько форм в день и не тужил. Другие вон наклепают без всякого ООП и гордые ходят от того что закончили раньше, а я сижу и будто них... не делаю. И поговорить даже не с кем (сотрудниками), все имеют смутное представление обо всем этом, как в тундре... Но с другой стороны знаю, что нет, надо делать так нужно, но постепенно веру теряю в это. Хотя, опыт я уже получил большой. Кто что скажет по этому поводу?
Если ты потратил 4 месяца на абстракции, которые даже не можешь объяснить начальству и которые для конечного пользователя не представляют ценности, значит, что-то идет не так?
KBH wrote:
> это. Хотя, опыт я уже получил большой. Кто что скажет по этому поводу?
Тебе стоит поднапрячься и ближайшие неделю-две выдать хоть какой-то реально работающий результат (пусть плохо, пусть
неправильно, но работающий!). А потом, продолжая идти с тем же идейным направлением — подправлять напильником. Т.е.
лучше идти маленькими шажками, чем пытаться сесть на шпагат.
А 4 месяца на одни абстракции действительно многовато.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan_izh, Вы писали:
_>Тебе стоит поднапрячься и ближайшие неделю-две выдать хоть какой-то реально работающий результат (пусть плохо, пусть _>неправильно, но работающий!). А потом, продолжая идти с тем же идейным направлением — подправлять напильником. Т.е. _>лучше идти маленькими шажками, чем пытаться сесть на шпагат.
_>А 4 месяца на одни абстракции действительно многовато.
Если у него получилось сотни модулей, то какова размерность задачи? Может там было работы как минимум на двоих?
Здравствуйте, KBH, Вы писали:
KBH>Вот уже половина срока прошло, а мне толком и показать нечего
Ты пошел по классической модели waterfall.
Главный ее недостаток: нужны стабильные начальные требования, что как следствие не требует постоянного контакта с заказчиком на всем этапе разработки.
Тут тебе советовали обратить внимание на XP.
Основной принцип: дизайн развивается из требований через непрерывное тестирование.
Для выделения требований напиши user-stories.
На каждом этапе у тебя должен быть работающий прототип (с реализацией только части требований).
Кроме того, что это будет постоянно вдохновлять тебя самого (работает!), ты также сможешь в любой момент показать часть работающей програмы шефу. Тут у тебя двойной выигрыш: шеф реально видит, что прогресс идет, кроме того, на каждом этапе он сможет выразить свои пожелания (то есть изменить требования) и тебе не будет большого труда их внести (рефакторинг), пока еще "не все запущено".
При таком процессе использование тех или иных паттернов проектирования будет именно реакцией на тесты, что гарантированно сводит к минимуму риск неверного с ними обращения и злоупотребления.
Здравствуйте, KBH, Вы писали:
KBH>Решил применять только ООП и паттерны проектирования. Каждый раз приходится долго обдумывать каждую абстракцию и писать кучу кода.
Абстракции и паттерны ради абстракций и паттернов намного хуже копипейста. Так уж получается, что все наработанные человечеством техники и методики имеют смысл только в контексте конкретной решаемой задачи. Сами по себе они представляют ценности не больше чем любой сферический конь в вакууме. Да, красиво светится, но полезный выхлоп никакой.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Вообще-то автор говорит, что переводит имеющуюся систему. Все требования и даже работающий прототип уже есть и водопадный принцип как нельзя к месту и в таких условиях является наикратчайшим путем по количеству трудозатрат. Вполне возможно, что автору осталось совсем чуть-чуть, может быть схема уже готова, осталось заимплементить буквально еще сотню методов и картинка начнет оживать.
Парня поддержать надо.
А вообще, если честно, работать над объемными проектами (в сотни и тысячи прикладных сущностей), это с непривычки утомительно, есть такое. Вроде и работа не сложная... А херачишь, херачишь и порой может показаться что конца края не видно. На самом деле есть и конец и край Главное, чтобы было желание довести проект до конца и умение "поднажать".
---------
Из собственного "боевого" опыта. Как-то взялся за учетную системку для одной фирмы и даже взял предоплату — 50%. Договорились делать вдвоем с товарищем. Начали, месяц делали, но потом товарищ отказался. У него на основной работе запарка началась и он был просто не в состоянии полноценно работать на 2 фронта. Прихожу к заказчику, объясняю ситуацию, пытаюсь оттянуть сроки. В общем, нарвался на ситуейшн: либо возвращать предоплату (которую частично проел к тому моменту, да и труда уже было вложено некоторое кол-во), либо вкладывайся как можешь в срок, иначе он будет ставить себе Акцент (тогда был 4.2 в ходу — полный отстой, надо сказать)... Изначально планировали на 3 месяца. Итого, работы осталось на 4 месяца (и даже более, товарищь, если честно, не сильно ворвался с ходу в проект и сделал немного), а я один и у меня этих месяцев 2. И вот пришлось поднажать, да не в шутку.
В принципе, уже к концу первого месяца вырисовывается окончательный список сущностей, их связей и основных операций по ним. К концу второго месяца вырисовывается общая механика, накапливаются первые хелперы и сущности более четко и осмысленно делятся на все более уточняющиеся веточки иерархий классов по характеру их использования.
Так вот, в какой-то момент (к концу второго месяца) наступает ситуация, когда ты уже отчетливо представляешь себе всю систему. Статическая схема уже есть. Часть динамики начеркал на обрывках бумаги, часть "ты всегда помнишь", а об остальном "ты всегда знал" (ибо это была не первая учетная система, в репертуаре, разумеется). Наступает просто тупое время кодирования. В этот момент надо просто суметь понять всю важность сосредоточения именно на этом тупом, но очень важном моменте. Когда меня тянуло откинуться эдак по хозяйски от монитора, веско прищуриться, немного критично погонять то что получается, погрызть карандаш, и, разумеется, еще раз немножко "допроектировать"... я тут же себя одергивал простой, но очень действенной формулой самовнушения: "Не втыкать! Не втыкать, мля!" Ага, именно. Все эти мелкие "допроектирования" существенно ничего не изменят, а времени могут отожрать будь здоров.
Ну что... полтора месяца херачил до боли в пальцах (юзал С++/COM/ActiveX, на верхнем уровне VB плюс к этому хостил у себя в проекте VBA для прикладных скриптов). В общем, костяк набился, и основные операции вроде бы нормально проходили и отчеты вроде бы не врали. Оставалось еще немного времени на "довылизывание". Умудрился успеть сделать тонны контекстных меню и всяких дополнительных способов отображения и допю способов ввода информации на основных формах. Заодно успел почти к каждому отчету сделать его экранный view. Т.е. сами print preview отчетов на экране смотреть не так чтобы очень... Те же самые отчеты, которые печатаешь на бумаге, на экране должны выглядеть малость по другому, со своими областями прокрутки и другим расположением итогов. Плюс совсем иная система навигации и фильтрации.
Потом 1.5 месяца внедрял. За первый месяц еще доотладил и доразработал несколько моментов (система уже активно юзалась !!!). Однако, спасало то, что юзвери от операторов и менеджеров до директора еще банально не успели пройтись по всем пунктам меню и кнопкам, и постепенно осваивали функциональность, что так же дало некоторую фору. В это же время разработал с 0-ля упрощенную систему архивирования данных. До этого юзал утилиты MS SQL, и прекрасно понимал, что в мое отсутствие никто грамотно это делать не сможет. Так что нарисовал еще пару пунктов меню и форм с "дружественным" интерфейсом к процедурам архивирования/восстановления.
В общем, если уметь навалиться, то выкрутиться можно. Главное, не отвлекаться на незначащие детали. Возможность "вылизать" их потом обязательно представиться, если убедительно покажешь функционирование системы в целом.
-------
В общем, та система проработала потом на этой фирме 3 года, они снова вышли на меня, и предложили "дальше развивать" систему... но мы уже не сошлись на финансах... к тому моменту я уже успел вкусить удаленной работы на заокеанских друзей и банально "приборзел" . В общем, система проработала у них еще год и потом они за многие тысячи заказывали себе подобную систему на 1С. Внедрил систему на еще одной фирме спустя пол-года после внедрения на перво, тоже проработала она там примерно 4 года.
Особенность там была в том, что стандартная конфигурация 1С по работе с товаром даже близко не подходила под их требования — у них одна и та же позиция товара либо учитывалась одной строкой во всех документах по оптовым складам, либо разбивалась на десятки подвидов для торговых точек. А перемещения м/у складами с разной политикой учета — это вообще пестня была. Да и формирование движений и отчестности и особенно системы заказов на поставки — тоже. Короче, прикладную настройку надо было рисовать вообще с 0-ля. А рисовать в 1С что-либо с 0-ля — это застрелиться и по деньгам и по времени, вот и вызвались мы для решения интересной задачки... А к этой задачке еще как приложение вся бухгалтерия и кадры
Здравствуйте, KBH, Вы писали:
KBH>Привет всем. KBH>Пардон за кучу текста.
Тут уже много кто чего написал, хочу присоединиться к вышенаписанному, и добавить, что у Вас, видимо, отсутсвуют способы измерения проделаной работы (как гласит американская инженерная присказка: Если Вы не можете что-либо измерить, значит этого не существует). Хорошим решением в Вашей ситуации будет XP c модульными тестами и приёмочными тестами. Первые показывают степень готовности исходного кода, вторые служат мерой функциональности системы, так, что можно чётко говорить, что выполнено 70% функциональных требований т.е. приёмочных тестов. Ну а про user stories и прочее тут уже написали
Здравствуйте, Alxndr, Вы писали:
A>Если ты потратил 4 месяца на абстракции, которые даже не можешь объяснить начальству и которые для конечного пользователя не представляют ценности, значит, что-то идет не так?
Не могу объяснить, потому что начальство для меня, такие же пользователи, им начхать на эти абстракции, они и слово такое редко употребляют. Ну а для конечного пользователя тем более, потому что им нужны только красивые формочки и правильные отчеты.
Здравствуйте, Eugene Beschastnov, Вы писали:
EB>Мне кажется, вы решаете задачу не с того конца. Всё-таки плясать надо от потребностей пользователя, а абстракции вычленяются в процессе.
Потребности мне уже известны более менее, я просто перевожу написанную когда-то в далекие времена на С с непонятной базой, на новую, которая должна иметь возможность работать на разных базах, при этом, требовалось прикрутить всего лишь дополнительный уровень доступа к базе, не меняя всего остального.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, KBH, Вы писали:
KBH>>Решил применять только ООП и паттерны проектирования. Каждый раз приходится долго обдумывать каждую абстракцию и писать кучу кода.
IT>Абстракции и паттерны ради абстракций и паттернов намного хуже копипейста. Так уж получается, что все наработанные человечеством техники и методики имеют смысл только в контексте конкретной решаемой задачи. Сами по себе они представляют ценности не больше чем любой сферический конь в вакууме. Да, красиво светится, но полезный выхлоп никакой.
Нет, ну не выделяю абстракции когда это уже необходимо, а не на всякий пожарный.
Здравствуйте, vdimas, Вы писали:
V>Вообще-то автор говорит, что переводит имеющуюся систему. Все требования и даже работающий прототип уже есть и водопадный принцип как нельзя к месту и в таких условиях является наикратчайшим путем по количеству трудозатрат. Вполне возможно, что автору осталось совсем чуть-чуть, может быть схема уже готова, осталось заимплементить буквально еще сотню методов и картинка начнет оживать.
Да, вот именно так, схема уже начинает оживать, осталось совсем немного, и скелет станет обрастать мясом, но шефу не понять, почему я какую-нить простую, с его точки зрения, задачку делаю так долго, а он привык долго не думать и просто копирует какой-нить алгоритм и шарашит его в новый модуль, вставляет несколько условий и все, задачка готова, ну так ведь нельзя.
Здравствуйте, VladGalkin, Вы писали:
VG>Тут уже много кто чего написал, хочу присоединиться к вышенаписанному, и добавить, что у Вас, видимо, отсутсвуют способы измерения проделаной работы (как гласит американская инженерная присказка: Если Вы не можете что-либо измерить, значит этого не существует).
Да их вообще нет, контора маленькая, провинциальная. Дело в том, что шеф со своей колокольни назначил сроки выполнения и влепил в самом начале срок сдачи определенный, с его точки зрения должен был занять мало времени, а у меня на этом этапе нужно реализовать чуть ли не 60% приложения.
VG>Хорошим решением в Вашей ситуации будет XP c модульными тестами и приёмочными тестами. Первые показывают степень готовности исходного кода, вторые служат мерой функциональности системы, так, что можно чётко говорить, что выполнено 70% функциональных требований т.е. приёмочных тестов.
Для себя стараюсь делать тестовые модули, но шефу они не нужны.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Андрей Коростелев, Вы писали:
V>[skip]
V>Вообще-то автор говорит, что переводит имеющуюся систему. Все требования и даже работающий прототип уже есть и водопадный принцип как нельзя к месту и в таких условиях является наикратчайшим путем по количеству трудозатрат.
+1
Я как раз это и имел ввиду: требования к него уже почти на 100% известны, потому водопад тут напрашивался сам по себе. Однако дальнейшее следование этой модели породило отсутствие промежуточного контакта с шефом, что собственно автора больше всего и беспокоит. Потому серая коротких циклов "тестирование (оно же использование) — рефакторинг — тестирование" со следущим за ними добавлением новой user-story (например, добавление отчетов) во-первых позволит на каждом этапе иметь осязаемые артефакты, во-вторых укажет петтертнам проектирования на их реальное место (что очень актуально, когда имеешь с ними дело в первый раз, ято как раз является ситуацией автора).
V>Парня поддержать надо.
Тот опыт, что он получит, пытаясь спректировать систему "по-взрослому", будет для него бесценен в будущем. И, по прошествии некоторого времени, научившись в итоге мыслить на объектном уровне, он заткнет за пояс тех "кодогенераторов", которые "гордые ходят от того что закончили раньше". Особенно это будет заметно на этапе поддержки, который в итоге занимает большую часть разработки.
Если нам не помогут, то мы тоже никого не пощадим.
