Я перетянул себя с этим проектом? - PullRequest
6 голосов
/ 28 октября 2009

В настоящее время я переписываю приложение базы данных нашей компании, являющееся интерфейсом Access-VBA для серверной части SQL Server (Express).

Я управлял приложением в течение 4 лет или около того, и когда я начал здесь, это был один * .MDB-файл на сетевом ресурсе (который еженедельно портился).

С тех пор я изменил БД на многопользовательский * .MDE, позже я перенес данные на SQL Express Server как * .ADE.

С тех пор приложение работает гладко и очень надежно.

Но, конечно, есть некоторые недостатки в использовании Access (отсутствие управления исходным кодом, в зависимости от версии Office и т. Д.), Поэтому я предложил своему боссу переписать интерфейс в C # и WPF.

Несколько лет назад я немного освоил Java и C ++, но это так. Сейчас я работаю над этим проектом 3 месяца или около того, и это очень тяжело. Просто для таких простых задач, как заполнение поля со списком, я должен искать в сети и читать много вещей.

Я действительно хочу выучить C # (а также многому научился с тех пор, как начал!), И я нахожу это отличной возможностью, но, возможно, я переоценил себя, начав с настоящего LOB-приложения в качестве одного младшего разработчика

Ответы [ 7 ]

10 голосов
/ 28 октября 2009

Выбор технологии для проекта, потому что вы хотите узнать, это всегда риск. Я также беспокоился о WPF. С одной стороны, это не проверенная технология (в том же смысле, что и Winforms). Это все еще довольно новый. Во-вторых, это ставит потенциально проблематичные ограничения на то, на каких системах он может работать. Vista / Win7 или я думаю XP SP3. Это может или не может быть проблемой.

Хорошее эмпирическое правило заключается в том, что вы должны отправлять рано и часто. Прервите часть функциональности и поставьте это. Какое-то время пользователи могут использовать оба приложения для разных задач. Вы гораздо лучше делаете это, чем пытаетесь проглотить все это за один раз.

Кроме того, и я думаю, что вы обнаруживаете это, полное переписывание почти всегда является ошибкой. Это большая работа, но не большая выгода, вы даете себе много возможностей вносить ошибки в уже работающие вещи, и вы теряете много знаний о предметной области (и рабочий код).

4 голосов
/ 29 октября 2009

Я бы сказал Чак, что бы вы ни делали в C #, и вернитесь в приложение Access.

Вы создаете интерфейс базы данных для серверной части SQL Server. Доступ идеально подходит для этого - вот и вся причина существования.

Для управления исходным кодом есть Visual SourceSafe (хотя я не совсем понимаю, зачем он нужен для проекта с одним человеком). Что касается зависимости от версии Office, это больше не проблема с Access 2000, хотя ADP сильно зависят от версии, поскольку ведут себя не одинаково во всех версиях Access. И в этом отношении MS в течение последних нескольких лет осуждает ADP в пользу внешнего интерфейса MDB / MDE, связанного с SQL Server через ODBC.

Я думаю, что вы выбросили ребенка с водой из ванны и должны вернуться в Access для своей передней части. Вы хотите работающее приложение? Или вы хотите сказать, что вы разработчик C #?

Можете ли вы дать количественную оценку фактической окупаемости инвестиций за переписывание внешнего интерфейса? Если это так, я думаю, вы обнаружите, что оставаться с Access будет гораздо выгоднее, чем переписать оптом.

2 голосов
/ 30 октября 2009

Если вы хотите изучить основную новую технологию, вам не советуют начинать с переписывания критически важной системы. Это почти стереотипная ошибка - такая вещь, которая в итоге получает 250 голосов здесь, на Stackoverflow, под вопросом «Какая самая большая ошибка, которую вы когда-либо видели при обновлении бизнес-приложения?»

Лучше всего сначала сделать собственный проект в .NET, даже маленький. Например, для того, чтобы получить удовольствие от jQuery, я недавно написал игру «Память» (где вы переворачиваете две плитки за раз, ища подходящие картинки). Вы можете сделать что-то подобное или простую программу чековой книжки.

Если вам абсолютно необходимо выполнять реальную деловую работу с основным приложением вашей компании в качестве учебного проекта, выберите небольшую и отдельную (отдельно от остальной части приложения) единицу работы и сделайте это в качестве тестового проекта. Это не должно нарушать работу существующего приложения, просто добавьте отдельную часть функциональности. Основываясь на этом эксперименте, вы и ваш начальник можете решить, стоит ли продвигаться к следующей, немного большей, единице работы.

2 голосов
/ 28 октября 2009

отправляем рано и отправляем часто.

Я согласен с cletus () в этом. "Отправим его!" это краткое чтение с некоторыми полезными советами на эту тему.

Большой риск при работе над переписыванием заключается в том, что вы тратите на него много времени, а затем проект либо отменяется до того, как он будет близок к завершению, либо поставляется со 100% функциональностью в состоянии 50% работы. , Если ваша перезапись находится в руках некоторых пользователей, то проект с меньшей вероятностью будет отменен, и пользователи будут использовать те функции, которые им необходимы. Может оказаться, что старое приложение обладает множеством функциональных возможностей, которые используются редко, поэтому вы можете получить большую часть ценности в руках пользователей за гораздо меньшее время, чем требуется для полного переписывания.

Как только ваш код будет запущен, вы почувствуете себя счастливее и будете еще более мотивированы, и это поможет вам работать быстрее.

Просто для таких простых задач, как заполнение комбобокс я должен искать в сети и много читаю.

Вы недовольны своей скоростью прогресса (или "скоростью" в Agile-говорить)?

Очевидно, что если бы вы могли производить больше каждый день, тогда задача могла бы показаться вам менее трудоемкой. Существует большая разница в производительности между лучшими программистами и средними показателями (см. Peopleware или Mythical Man Month), поэтому все, что вы можете сделать, чтобы стать лучшим программистом, может иметь существенное значение.

В вашем случае мне интересно, поможет ли какое-нибудь обучение? Я обычно не большой поклонник обучения в классе, но если вокруг вас не так много опытных людей, это даст вам толчок для начала. Если обучение не вариант, у вас есть локальная группа пользователей C #? Если в вашей компании есть более опытные разработчики, не могли бы вы обратиться к ним за советом? Или просто забрать себе мозги у кулера с водой?

Одна большая проблема с самостоятельной работой заключается в том, что иногда вы застреваете на чем-то очень простом, что кто-то другой сразу замечает. Иногда простое объяснение проблемы кому-то еще помогает вам взглянуть на нее таким образом, который поможет вам решить ее. Если бы вы могли работать с кем-то еще хоть какое-то время каждый день, это могло бы повысить вашу производительность.

У вас есть (и вы используете) все необходимые инструменты? Абсолютный минимум: а. Система контроля версий. б. База данных отслеживания ошибок. с. Хорошая среда разработки, например Visual Studio д. Лучшая среда разработки, чем Visual Studio! например Resharper.

См. текст ссылки для лучшего списка.

Удачи!

1 голос
/ 02 ноября 2009

Вы можете использовать SourceSafe с MS Access, он довольно хорошо интегрируется. Я бы порекомендовал, будь то проект с одним человеком, он пару раз спас мой бекон ...

Я не уверен, что WPF будет подходящим выбором для первого приложения, его крутая кривая обучения и преимущества приложения для бизнеса далеко не убедительны, на мой взгляд. C # или VB.Net с привязкой данных могут быть мощными и быстрыми в построении, но мне не ясно, что это может предложить сверх вашего текущего приложения, которое уже «очень надежно». Использование SQL Server в качестве серверной части устраняет многие возражения (производительность, масштабируемость и т. Д.), Возникающие в связи с использованием Access для критически важных бизнес-приложений. Действительно, у нас есть интерфейсы Access для баз данных SQL Server с сотнями одновременно работающих отлично работает.

Я бы сохранил .Net для следующего приложения .....

1 голос
/ 28 октября 2009

Очевидно, я вас не знаю, но я думаю, вы должны быть в состоянии справиться с этим. На абстрактном уровне вы можете многое сохранить от старого приложения (например, общий макет, формы, что и т. Д.), Что значительно облегчает задачу полного не потеряться в постоянно растущем лесу. Вы также можете использовать это для оценки своего прогресса: из скольких форм (процедур и т. Д.) Состоит старое приложение, сколько из них уже переписано?

Конечно, у вас есть проблемы с деталями в начале (например, упомянутые поля со списком), но как только вы преодолеете это и получите некоторую рутину (и некоторые исходные файлы для копирования-вставки), это не будет труднее для Вы, чем для кого-либо еще.

1 голос
/ 28 октября 2009

Я почти всегда согласен с Клетусом, но я собираюсь сыграть обе стороны и сказать, где провести черту? Вы продолжаете поддерживать тот проект, который был передан вам в конце 1903 года? Когда нужно стиснуть зубы и переписать систему? Я думаю, что когда вам дается проект, который отличается от того, что вы описываете, вы должны разбить систему на функции, основные этапы, которые вам нужно достичь, и протестировать тестовый тест, тесты, подтверждающие переписываемую вами функцию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...