Yesterday, Sequoia made good on this promise and you can now pull the source code they've made available from their Subversion repository here:They should be applauded to ensure full confidence in their product. I just wish many companies, particularly those producing ERP and critical software, are that inclined.
http://sequoiadev.svn.beanstalkapp.com/projects/
What is of great interest to me is the fact that this system is developed using MS .Net Framework V2/3.5 and the projects are developed using C# in VS2008.
A quick scan of the projects revealed some issues:
1) The solution failed to be self-contained. In other words, the solution should contains all the third party supporting DLLs and then projects needing it are then referring them in relative path. In this way, the source control and solution will contain everything a developer would need when the solution is checked the solution out. Perhaps they are not included in the public code because of licensing issues.
2) Many classes should be marked static but are not. There are signs showing the code may have been migrated from .Net 1.x, which does not have static class. For example, the Contract class in Core solution.
3) Projects have not turned on Code Analysis. May be they do not use Visual Studio Team System.
4) The System.Data.IDataReader that is returned by Sequoia.EMS.Core.DataServices.BaseDataService or Sequoia.Ems.Data.Custom.BaseEntrySet does not appear to have been disposed after entries are added in Sequoia.Ems.Data.Custom.BaseEntrySet.Load(). IDataReader is derived from IDisposable.
5) Good to see the use of the Workflow engine.
6) Use of NUnit is evidence in the code but does not appear to be widespread usage of the Unit Test or TDD.
7) It is also using Microsoft Enterprise Library but it appears that it is using its own implementation to do logging.
8) Some project for example, the Core, is set to use .Net 2.0 but it contains references to .Net 3.5 specifics namely System.Xml.Linq. Very strange. Just wondering if it is in the process of upgrading all project to .Net 3.5. There are currently 10 projects in .Net 2 and 12 in .Net 3.5. Altogether there are 22 projects.
9) Personally I am not too keen on the way the Core project is organized. Essentially Core is a project containing 34 files which are grouped into pseudo-sub-projects using solution folders. This kind of design can encourage tight coupling because each sub-project's internal artifacts are available to each other. May be that is their intention. Preliminary review does not support this.
This kind of organization also makes partitioning the module to be managed by several developers difficult. It is most unfortunate that VS2008 does not support netmodule in the IDE otherwise, partitioning Core into several netmodules is a better organization.
No comments:
Post a Comment