Вобщем, поручили мне перевести одно приложение на другую БД. Отвели на это 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>Парня поддержать надо.
Тот опыт, что он получит, пытаясь спректировать систему "по-взрослому", будет для него бесценен в будущем. И, по прошествии некоторого времени, научившись в итоге мыслить на объектном уровне, он заткнет за пояс тех "кодогенераторов", которые "гордые ходят от того что закончили раньше". Особенно это будет заметно на этапе поддержки, который в итоге занимает большую часть разработки.
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Я как раз это и имел ввиду: требования к него уже почти на 100% известны, потому водопад тут напрашивался сам по себе. Однако дальнейшее следование этой модели породило отсутствие промежуточного контакта с шефом, что собственно автора больше всего и беспокоит. Потому серая коротких циклов "тестирование (оно же использование) — рефакторинг — тестирование" со следущим за ними добавлением новой user-story (например, добавление отчетов) во-первых позволит на каждом этапе иметь осязаемые артефакты, во-вторых укажет петтертнам проектирования на их реальное место (что очень актуально, когда имеешь с ними дело в первый раз, ято как раз является ситуацией автора).
Добавлю, что обычно никто не переписывает просто так, обычно хочется при этом еще и часть функционала переделать, часть добавить.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, KBH, Вы писали:
KBH>... Но, катастрофически не хватает времени и опыта.
Сдается мне, что нехватает именно опыта. Даже если между временем и опытом зависимость и не линейная, то она все равно есть. И пока опыта будет недостаточно, времени никогда не будет хватать.
KBH>Вот уже половина срока прошло, а мне толком и показать нечего, не буду же я им показывать несколько сотен модулей, которые для юзера не представляют никакой ценности,
А почему собственно и нет. Заказчики, как раз таки часто любят оперировать абстракциями. И хотя воспринимают их сложнее, нежели работающую систему, но все равно достаточно хорошо к ним относятся. И тут не надо скупиться на слова о расширяемости, отказоустойчивости, легкости поддержки (и многих других плюсах) такого подхода.
KBH>а начальник у меня такой, до сих пор пишет на С копипастом. Вот как мне ему объяснить, чем я тут вот уже 4 месяца занимаюсь? Я понимаю, что дальше будет все легче, потому что буду использовать написанное ранее, но ему-то этого не понять. Он не привык, выискивать какие-то там абстракции, он вообще не имеет представления о том, что такое абстракция.
И ты хочешь набраться опыта с таким начальником?
KBH>Вот я и впадаю в апатию и панику, когда думаю о том, что нафиг мне это все, писал бы как раньше, без всякого разделения на логику, интерфейс и т.д. и т.п. без этого ООП, клепал бы по несколько форм в день и не тужил. Другие вон наклепают без всякого ООП и гордые ходят от того что закончили раньше, а я сижу и будто них... не делаю. И поговорить даже не с кем (сотрудниками), все имеют смутное представление обо всем этом, как в тундре... Но с другой стороны знаю, что нет, надо делать так нужно, но постепенно веру теряю в это.
Я, конечно, понимаю, что после таких слов многие начальники мне спасибо не скажут и на работу не позовут. НО! В твоем положении опыт превыше всего, даже в ущерб каким-то срокам. Скорее всего и ты был не прав устраиваясь в такую фирму. Я бы подумал о переходе на, возможно, меньшую зарплату, но в толковый коллектив разработчиков.
KBH>Хотя, опыт я уже получил большой. Кто что скажет по этому поводу?
А что тут скажешь — молодец! Я в свое время работал над проектом в несколько похожей организации. Где начальник, причем далекий от программирования, был заинтересован исключительно сроками выполнения работ, и не о каком качестве написанного кода никогда не слыхивал. А когда я начинал докапываться до юзеров с просьбой подробней описать процесс, он говорил (утрирую): "ну че ты к ним пристал, иди сначала сделай, а они посмотрят и подправишь". Но я упорно стоял на своем, хотя и порывался несколько раз на все плюнуть. В итоге, почти все задуманное мной я довел до конца, как считал нужным. Юзеры остались довольны. Вообще говоря, я и не пошел бы работать туда, но обстоятельства так сложились и пришлось. Уволился я оттуда через пол года (при увольнении был сперва скандал, потом попытки поднять зарплату и уговорить остаться), но люди работавшие после меня говорят, что начальник меня им всячески хвалил и заставляет их придерживаться моего подхода. А им самим в свою очередь очень приятно поддерживать мою писанину
Здравствуйте, ie, Вы писали:
ie>Сдается мне, что нехватает именно опыта. Даже если между временем и опытом зависимость и не линейная, то она все равно есть. И пока опыта будет недостаточно, времени никогда не будет хватать.
Да, не отрицаю.
ie>И ты хочешь набраться опыта с таким начальником?
Не с ним, без него.
ie>Я, конечно, понимаю, что после таких слов многие начальники мне спасибо не скажут и на работу не позовут. НО! В твоем положении опыт превыше всего, даже в ущерб каким-то срокам. Скорее всего и ты был не прав устраиваясь в такую фирму. Я бы подумал о переходе на, возможно, меньшую зарплату, но в толковый коллектив разработчиков.
Да, сам не раз думал об этом, но у нас тут с работой не разгуляешься.
ie>А что тут скажешь — молодец! Я в свое время работал над проектом в несколько похожей организации. Где начальник, причем далекий от программирования, был заинтересован исключительно сроками выполнения работ, и не о каком качестве написанного кода никогда не слыхивал. А когда я начинал докапываться до юзеров с просьбой подробней описать процесс, он говорил (утрирую): "ну че ты к ним пристал, иди сначала сделай, а они посмотрят и подправишь". Но я упорно стоял на своем, хотя и порывался несколько раз на все плюнуть. В итоге, почти все задуманное мной я довел до конца, как считал нужным. Юзеры остались довольны. Вообще говоря, я и не пошел бы работать туда, но обстоятельства так сложились и пришлось. Уволился я оттуда через пол года (при увольнении был сперва скандал, потом попытки поднять зарплату и уговорить остаться), но люди работавшие после меня говорят, что начальник меня им всячески хвалил и заставляет их придерживаться моего подхода. А им самим в свою очередь очень приятно поддерживать мою писанину
Вот примерно такой же начальник и у меня, наплевать ему на качество, главное — результат.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, KBH, Вы писали:
KBH>>Нет, ну не выделяю абстракции когда это уже необходимо, а не на всякий пожарный.
IT>Судя по тому, что за 4 месяца у тебя не появилось работающего прототипа, этого не скажешь.
Думаю, моя беда в том, что не могу не отвлекаться на мелочи, все кажется важно.
Здравствуйте, ie, Вы писали:
ie>А почему собственно и нет. Заказчики, как раз таки часто любят оперировать абстракциями. И хотя воспринимают их сложнее, нежели работающую систему, но все равно достаточно хорошо к ним относятся. И тут не надо скупиться на слова о расширяемости, отказоустойчивости, легкости поддержки (и многих других плюсах) такого подхода.
Переделывал тоже существующую систему, это ужас Самое главное, что внедрение новой системы происходило одновременно с ее созданием — это отдельная песня, трудно забыть такое... Но дело не в этом; была в старой системе некая функция, реализованная из рук вон плохо, я аж проплевался когда увидел код и структуру хранения данных, а функциональность эта была одна из важнейших в системе, то есть такой компонент, что без него никуда, все на нем держалось (но это не значит, что все остальное хухры-мухры ). Вздохнув я стал "правильно" ее реализывовать (удивляясь как раньше с ней работали, ибо глюков, дублирования данных было предостаточно, и не ругались). Это заняло некое время, да еще часто приходилось выкладывать сырые версии, так как пользователи просто выли без этого. С сырыми версиями они выли еще больше, но ждать не хотели, да и не могли Мне часто приходилось мазаться — почему сейчас так плохо, так медленно и тому подобное. Объяснял свое решение реализовать все именно так, а не иначе. Понимания не встречал, ну и ладно Обошлось.
Примерно через месяц после сдачи почти готовой системы звонят пользователи и говорят спасибо. На мой вопрос объяснить, выдают: "Да мы тут то-то сделали, круто! Одно нажатие кнопки, а в старой программе на эту работу неделя уходила" Я аж прослезился Рассказали заодно какие глюки в старой программе были, а не ругались на нее потому что привыкли...
К чему рассказал, не знаю... Может автора подбодрит
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Если у него получилось сотни модулей, то какова размерность задачи? Может там было работы как минимум на двоих?
S>ИМХО Более вероятно, что АТ спустился до моллекул .
Меняй работу. Судя по всему и начальник у тебя не очень, раз тем, что делаешь не интересуется, да и коллеги, как я понял, не сильно квалифицированы. Иди в другое место.
AVK>Добавлю, что обычно никто не переписывает просто так, обычно хочется при этом еще и часть функционала переделать, часть добавить.
Иногда переписывают именно для того, чтобы в будущем иметь такую возможность — добавлять функционал без напряга. Т.е. на первом этапе достаточно даже перевести 1-в-1 по функциональности, но переработать архитектуру, вложив "расширяемость".
Например, свою первую учетную системку на MS Access (примерно 96-й год) я сделал "в лоб", т.е. каждая сущность — это отдельная таблица (или набор связанных таблиц). Итого, при 8-ми операциях на складах и около 2-х десятков с финансами SQL-запросы для подсчета итогов выглядели устрашающе. И практически невозможно было расширять, ибо добавление новой транзакции означало необходимость перешерстить вообще почти всю приложуху. Поэтому когда переделывал на MS SQL, то перевел 1-в-1 по функциональности и даже GUI оставил прежний поначалу, но разделил механику движения всего (денег и ТМЦ) на "документ-источник" и "движение". В результате добавление новых видов операций стало легкой операцией и я смог развивать это дело дальше.
Здравствуйте, vdimas, Вы писали:
V>Иногда переписывают именно для того, чтобы в будущем иметь такую возможность — добавлять функционал без напряга. Т.е. на первом этапе достаточно даже перевести 1-в-1 по функциональности, но переработать архитектуру, вложив "расширяемость".
В этом случае начальник не из разряда "фиг ли думать, трясти надо" и проблем с объяснением что происходит не возникает.
KBH wrote:
> Здравствуйте, Alxndr, Вы писали: > > A>Если ты потратил 4 месяца на абстракции, которые даже не можешь > объяснить начальству и которые для конечного пользователя не > представляют ценности, значит, что-то идет не так? > > Не могу объяснить, потому что начальство для меня, такие же
Обьясни нам?
Здравствуйте, StanislavK, Вы писали:
SK>Здравствуйте, KBH, Вы писали:
KBH>>Привет всем.
SK>Меняй работу. Судя по всему и начальник у тебя не очень, раз тем, что делаешь не интересуется, да и коллеги, как я понял, не сильно квалифицированы. Иди в другое место.
Помнится еще года три назад, один коллега, старший инженер или кто он там, напару с главным специалистом, настоятельно рекомендовал не объявлять переменные внутри цикла, потому как, якобы, "это приводит к переполнению стека, потому что в начале итерации переменная создаётся, а при окончании не уничтожается!" (он имел в виду стековые переменные в С++).
KBH wrote: > Помнится еще года три назад, один коллега, старший инженер или кто он > там, напару с главным специалистом, настоятельно рекомендовал не > объявлять переменные внутри цикла, потому как, якобы, "это приводит к > переполнению стека, потому что в начале итерации переменная создаётся, а > при окончании не уничтожается!" (он имел в виду стековые переменные в С++).
Так что ты там делаешь три года? Либо становись старшим инженером (или кем-то там), чтобы самому решения принимать, либо
беги оттуда.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Если нам не помогут, то мы тоже никого не пощадим.
Я аж прослезился 
Может автора подбодрит 
