dagrigorev

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

dagrigorev

Знакомство.

Какую проблему решаем?

Как решаем проблему?
  - использовать существующее решение (плюсы: не тратятся ресурсы, готовое 
  решение проверено на безопасность, можно переиспользовать в любом месте, минусы: тяжело кастомизировать, возможная закрытость);
  - реализовать собственное решение (плюсы: можно реализовать полностью свое решение);
  
Основные проблемы построения велосипедов:

dagrigorev

Это первая заметка из серии "Познание шарпа". Сюда записываю свои заметки по работе на платформе .NET C#.
На эту мысль меня натолкнули кучи пройденных собеседований на различные вакансии шарп разработчика.
Хочу оставить здесь свою заметку по поводу сборщика мусора в шарпе (GC или GarbageCollector).

В одном собесе был задан вопрос, а что будет, если на финализаторе класса возникнет исключение?
(кстати, а что вы думаете на этот счет?)
Тут стоит вспомнить немного теории. При создании объекта с финализатором, "ссылка на него добавляется в специальную очередь, 
называемую очередью финализации (finalization queue). Эта очередь воспринимается сборщиком мусора как корень, 
в том смысле, что даже если в приложении не останется ни одной ссылки на объект, он все равно будет удерживаться 
в памяти очередью финализации. 

dagrigorev