Является ли проект C # диареей нормой?

Question

Программист AC # переписал программу на Delphi 6 (без графического интерфейса, только шлифование файлов в файлах, около 50 процедур и функций общим объемом менее 1200 строк == 57kb нажатий клавиш), которая работает как один файл .DPR. 1001 *

Он доставил проект, содержащий 58 файлов (52 из них .CS-файлов) в 13 папках, вложенных в разной степени, общим объемом более 330 КБ.

Это типично для проектов на C #? Какую стратегию обычно используют программисты на C #, чтобы решить, как разделить и организовать свой проект?

Answer 1

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

1) Небольшие файлы кода легче понять, чем большие , но это может привести к некоторому повторению определенных конструкций (с помощью объявлений, объявлений пространства имен и т. Д.) И, безусловно, увеличивает количество файлов в проекте.

2) Маленькие классы легче понять, чем большие . Это основное преимущество для новичков в коде. Если они могут обернуть голову вокруг какого-то одного класса, они могут расширить свое понимание оттуда.

3) Хороший код больше, чем маленький код . Когда вы добавляете приличную проверку на ошибки, документацию и описательные имена методов / переменных, ваш код становится более устойчивым и поддерживаемым, но также и намного больше. Это совершенно нормально.

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

Answer 2

Не видя фактического кода оригинала или нового кода, я не могу сказать вам, правильно ли разработан новый код организации, просто зная количество строк, количество методов и размер файла. В C # я обычно:

1. Разделите каждый класс и интерфейс на отдельные файлы.
2. Статические вспомогательные методы сгруппированы по функции
3. Я обычно разделяю файлы на папки по слоям. Ex. Уровень графического интерфейса, уровень бизнес-логики и т. Д. ...
4. Методы расширения разделяются классом или интерфейсом, к которому они относятся, или иногда функцией.

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

Answer 3

Это скорее артефакт разработчика, использующего Visual Studio IDE (VS), а не проблема самого C # / .NET. При использовании инструментов VS чаще всего нужно помещать каждый класс в свой собственный файл .cs, поскольку в окне обозревателя решений отображаются файлы / папки в древовидной структуре, что позволяет программисту быстро нацеливаться на их классы.

Кроме того, Visual Studio Диалоговое окно добавления нового элемента поощряет подход «один класс на файл», генерируя новый файл каждый раз, когда вы добавляете класс в свой проект.

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

Пример:
альтернативный текст http://imar.spaanjaars.com/Images/Articles/UsingAccessProviders/SolutionExplorer.gif

Если бы программист работал вне среды Visual Studio, у вас, вероятно, гораздо меньше поносов. Ewww ...

Answer 4

Delphi - отличный язык, но не волшебный.Так что нет, то, что вы видите, не является типичным сценарием.

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

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