Comments 18
UFO just landed and posted this here
Скажем так, довольно тривиальные вещи. Но в любом случае спасибо, потому что повторение... что? правильно! мать учения! ))
Здорово! Лет пять-шесть назад статья была бы мне полезна.
Только лучше бы её отнести в блог учись работать, а то как-то в "Управлении проектами" она смотрится несолидно, выдавая младоразработчицкую сущность автора.
Только лучше бы её отнести в блог учись работать, а то как-то в "Управлении проектами" она смотрится несолидно, выдавая младоразработчицкую сущность автора.
Запомнить и не забывать.
UFO just landed and posted this here
Я однажды пробовал генерить код из UML с помощью целого ряда инструментов. Придя в себя после изучения результатов, выкинул их к черту и с тех пор кодирую из UML в Perl/Python вручную. Доверять такое идиотам или машинам себе дороже.
P.S.: имхо, лучше по максимуму внедрять сторонние библиотеки и фреймворки для достижения того же результата высвобождения времени на нетривиальные задачи. Ведь сама формулировка доля кода, который может быть получен без участия квалифицированного разработчика, достаточно велика должна настораживать. Во всяком случае, в правильно организованной системе, написанной на языке высокого уровня, подобная проблема вообще не возникает.
http://en.wikipedia.org/wiki/Elisp ;-)
а если серьезно - http://www.generative-programming.org/
а если серьезно - http://www.generative-programming.org/
Из средств кодогенерации могу порекомендовать бесплатную платформу, которую можно скачать тут http://bars-open.ru/Platforma.aspx
про п 9: там действительно имелось ввиду "... достаточно велика для того, чтобы написать самим ..." ? Мне кажется, что это немного "через край". Создание собственных систем генерации кода требует серьёзной базы и большого опыта в системном программировании. Это будет само по себе немаленьким проектом - мне никак не удается представить проект, в рамках которого реализация собственной кодогенерации имела бы смысл.
Какие-то средства "генерации кодогенераторов" были у Microsoft в Visual Studio SDK, а точнее в Tools for Domain Specific Languages - но возможно ли использование этой системы в большом проекте для разработки собственных средств генерации, мне не известно...
А вот с использованием существующих систем генерации полностью согласен. Сам активно использовал кодогенерацию Java-классов для Hibernate.
Какие-то средства "генерации кодогенераторов" были у Microsoft в Visual Studio SDK, а точнее в Tools for Domain Specific Languages - но возможно ли использование этой системы в большом проекте для разработки собственных средств генерации, мне не известно...
А вот с использованием существующих систем генерации полностью согласен. Сам активно использовал кодогенерацию Java-классов для Hibernate.
Статья честно говоря не очень интересна...
Едиственное что полезно я думаю пункт.2
Глобальный проект переделывается 1000 раз. Но больше всего времени уходит на анализ новых технологий и выбор их.
А про архитектуру я вообще молчу. Но надо стремиться к тому чтобы проект получился лучше чем вы задумали, иначе он устареет пока вы его сделаете. И самое главное все почему-то забыли про немаловажный пункт: РЕФАКТОРИНГ, но это уже по окончанию создания архитектуры и в принципе основ интерфейса. Только вы начнете рефакторить, вы столкнетесь с кучей узких мест, которые могут поставить весь проект на колени… особенно по «скорости» вот тут конечно п.2 очень помогает, т е надо заранее сделать «задел» для преодоления узких мест, иначе ппц может подкрасться незаметно, когда проект что называется готов. И тогда начинаются извращения и прочая лабудень… в итоге проект получается «как всегда» и как у всех.
И еще… Если проект глобальный, лучше делать вообще «новую» архитектуру (поверьте это не изобретение велика) или вообще не делать, а развить существующие — расширениями и дополнениями.
Едиственное что полезно я думаю пункт.2
Глобальный проект переделывается 1000 раз. Но больше всего времени уходит на анализ новых технологий и выбор их.
А про архитектуру я вообще молчу. Но надо стремиться к тому чтобы проект получился лучше чем вы задумали, иначе он устареет пока вы его сделаете. И самое главное все почему-то забыли про немаловажный пункт: РЕФАКТОРИНГ, но это уже по окончанию создания архитектуры и в принципе основ интерфейса. Только вы начнете рефакторить, вы столкнетесь с кучей узких мест, которые могут поставить весь проект на колени… особенно по «скорости» вот тут конечно п.2 очень помогает, т е надо заранее сделать «задел» для преодоления узких мест, иначе ппц может подкрасться незаметно, когда проект что называется готов. И тогда начинаются извращения и прочая лабудень… в итоге проект получается «как всегда» и как у всех.
И еще… Если проект глобальный, лучше делать вообще «новую» архитектуру (поверьте это не изобретение велика) или вообще не делать, а развить существующие — расширениями и дополнениями.
Думаю, чтобы эта тстатья действовала, при том не только на новичков, надо не просто сказать что надо делать, а описать, чем грозит невыполнение этих простых рекомендаций.
>РедактируемыйОбъект.Сохранить();
А разве объекты бизнес-логики должны зависеть от слоя доступа к данным?
Мне казалось, что должно быть так:
МенеджерРедактируемогоОбъекта.Сохранить(объект);
А разве объекты бизнес-логики должны зависеть от слоя доступа к данным?
Мне казалось, что должно быть так:
МенеджерРедактируемогоОбъекта.Сохранить(объект);
И не надоедает вам это мыло писать?
Sign up to leave a comment.
Десять рекомендаций разработчику программного обеспечения