Проверить работу софта без реального оборудования довольно затруднительно, так что основная работа происходит у заказчика.

Да это всегда пожалуйста! Но ведь это не значит, что собирать продукт тоже надо у заказчика ;) К заказчику надо ехать уже с готовым.

Продукт на фирме собирать практически бессмысленно.

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

Первую функцию можно обозреть за довольно короткое время, во втором случае нужно вначале пройтись по всем частям.

Вторую фунцию обозреть еще проще, т.к. всего две строчки. Шифруем и отсылаем. Функция эта больше ничего не делает и во втором варианте это читается. А в первом слишком много букв.

Зачем делать то, что никогда не понадобится.

Зачем, что это побочный эффект.Самое важное заключается в том, что 2-й вариант поддается тестированию, а 1-й - нет. А расщиряемость - это приятный бонус.

Не заметил этой связи. И тот и другой вариант делается в зависимости от контекста использования.

Зря не заметил. Все изменения я вроде бы объяснил. Интерфейсы я ввел для того, чтобы можно было делать Dependency Injektion. Используя интерфейсы мы можем лучше протестировать саму функцию и ее реакцию на ошибки. Например, ты задолбаешься тестировать поведение функции из 1-ого варианта, в случае если не получилось передать все данные (например если выдернули провод), используя DI это тестируется на раз. Кроме того, передача данных по реальному каналу (он еще должен быть! у меня на ноуте COM порта вообще нет) может занимать много времени, да и шифрование тоже может долго длиться, а нам надо протестировать енкодер. При этом нам не надо тестировать ни DESCryptoServiceProvider ни SerialPort - они работают правильно.

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

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

Все зависит от мотивации. Если бы ты сказал, что тебе это для тестирования, то врядли кто-нибудь стал бы возражать, что мол тестировать нам не надо :)

А вообще, если бы вы использовали бы юнит-тестирование, то вам надо было бы гораздо меньше времени проводить около реального оборудования.

Помню, на прошлом проекте у нас один из клиентов разбил диск на партиции и партицию D скрыл правами доступа. Так, что видимые партиции у него были С и Е. А наша праграмма запрашивала все биски у системы, отфильтровывала fixed drives и если там был диск D, то мы использовали его для данных. И вот везде это годими работало, а у это клиента нет (диск находился, но при обращении к нему кидалось исключение). Понятно, что можно взять PC , разбить диск, закрыть D и протестировать работу (или поехать к клиенту и протестировать у него), но это все очень затратные способы. Я решил эту проблему юнит-тестом. Просто сделал обертку и кидал исключение. Все. Быстро и надежно. И никто никогда не удалит "непонятный код", т.к. есть тест и тест этот станет красным если удалить код.

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