войти зарегистрироваться

Web-разработка whois

индекс
184,85

Десять способов ускорить разработку

    Сегодняшние слухи и громкие слова вроде «быстрая разработка приложений» (RAD), AJAX (мы теперь не можем ждать даже перезагрузки страницы) и методики «Agile» дают нам понимание, какие требования выдвигаются в мире, в котором мы с вами живем.

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




1. Используйте фреймворки



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

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

    То же самое можно сказать и о JavaScript-фреймворках, например о MooTools. Он так же ускоряет разработку, предоставляя решения, которые были широко протестированы разработчиками ядра и сообществом для кроссбраузерности. Есть и другие варианты для клиентского программирования, такие как JQuery, Prototype и YUI. Если вы не хотите использовать «мэйнстримовые» продукты, можете воспользоваться списком перспективных фреймворков (многообещающих, если хотите).

    Для разработки серверной части, попробуйте CakePHP, CodeIgniter или Symfony, если вы работаете с PHP. Или, если вы используете поддерживаемые Microsoft технологии, например, C# и VB, ваш выбор, скорее всего, упадет на .NET.

    Вы можете попробовать даже CSS-фреймворки, вроде 960 Grid или BluePrint что бы молниеносно и без лишних затрат описывать структуру вашей страницы.


2. Используйте интегрированные среды разработки (IDE)




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

    Интегрированная среда разработки — приложение, которое несет в себе все инструменты, которые могут вам понадобиться при разработке даже огромных проектов. Возможности IDE достаточно обширны, мы рассмотрим некоторые из них:
  • Управление проектом и решения для командной разработки.
  • Инструменты для отладки и диагностики ошибок.
  • Подсказки по синтаксису и авто-заполнение (предполагает, что вы собираетесь писать).
  • Подсветка синтаксиса.
  • Встроенный FTP, который позволяет синхронизировать ваши локальные и удаленные файлы на сервере.

    «IDE» — причудливый термин, с которым некоторые могут быть незнакомы, но, наверняка, все слышали об Adobe Dreamweaver. Dreamweaver является интегрированной средой разработки, так как несет в себе все функции, указанные выше и помогает вам разрабатывать и писать код намного быстрее (обычно, Dreamweaver используют для front-end разработки, но имеется поддержка некоторых серверных технологий, например PHP или ASP.NET).

    Сейчас существует достаточно много IDE и все, что вам или вашей команде нужно, это выбрать одну из них. В самые популярные полнофункциональные IDE можно включить Eclipse, Komodo IDE, NetBeans, Visual Studio, и Aptana Studio.

    Если вы все еще хотите использовать просто текстовые редакторы, как минимум, проверьте список текстовых редакторов для программистов.


3. Модульность (уместная, разумеется)


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

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

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

    Но излишняя модульность может сильно увеличить объем кода, а много лишних операторов «include» может резко затормозить работу вашей системы. Так что всегда старайтесь найти золотую середину между слишком много и недостаточно (компромисс, короче).


4. Отлаживайте front-end компоненты более эффективно с помощью браузерных инструментов



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

    Firebug и Web Developer являются отличными времясберегающими инструментами и одними из самых популярных продуктов на рынке. Firebug позволяет достаточно просто просмотреть DOM-дерево, посмотреть как и что работает, «на лету» изменять CSS-стили, HTML-разметку, отлаживать и профилировать JavaScript-код, помогая выяснить что же заставляет ваши скрипты падать. Web Developer, в свою очередь, дает вам доступ к интересным возможностям, например, возможность кликнуть на тот или иной элемент и посмотреть, какие CSS-объявления в данный момент на него распространяются, а также позволяет отключить CSS и JavaScript чтобы посмотреть, какой пользователь увидит страницу при отключенных функциях.

    Если вам требуется отлаживать Internet Explorer, попробуйте IE Developer Toolbar, который имеет примерно тот же функционал, что и Firebug с Web Developer. Еще несколько инструментов для отладки и поиска ошибок в IE можно найти здесь.


5. Повторно-используемый код


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

    Например, если вы часто используете БД, вы, возможно, захотите разработать Database Access Class для управления соединениями, запросами и выводом информации.


6. Командная разработка и работа с проектом в сети


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

    Инструменты вроде Basecamp, Lighthouse, и activeCollab дает вашей команде общую точку сбора для работы и слежения за статусом того или иного проекта. Вы можете выставлять дедлайны и цели проекта, при этом всегда сохраняя синхронизовацию между членами команды, предохраняя вас от ответов на письма и встреч для проверки статуса/подведения итогов.

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


7. Автоматизируйте форматирование кода и стандартаризацию


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

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

    Существует множество инструментов, которые помогут вам с этой проблемой и многие из них реализованы даже как веб-сервисы. В случае с CSS, достаточно популярна утилита с открытым исходным кодом CSSTidy (Clean CSS, онлайн версия CSSTidy). Для HTML существует HTML Tidy.

    Для скриптовых языков можете применять PHP Source Code Formatter, Ruby Script Beautifier, и Code Beautifier Plus (который умеет работать с C#, ActionScript и Java).


8. Уделяйте больше времени формированию требований и проектированию (планированию)


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


9. Используйте уже написанный код



    Нет никакой необходимости изобретать колесо. Если вы собираетесь разработать какое-либо решение, которое видели где-то еще, возможно кто-то уже написал его для вас (да и не только для вас, для всех). Если вы используете PHP, PHP Classes Repository предоставляет коллекцию готовых классов и скриптов, которые вы можете свободно скачивать и использовать. Hot Scripts предоставляет решения на многих языках. Если же вы ищете сниппеты, вам поможет devSnippets.


10. Урежьте функционал


    Вы должны оценивать необходимость какой-либо новой функции в вашем веб-приложении и решать, стоят ли того затраты времени на ее разработку. Пользователям действительно нужны персональные RSS-каналы для категорий редко обновляемой CMS? Вам действительно нужен style switcher, который определяет географическое положение пользователей?

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


Полезные ссылки:



А что думаете вы?


Вы можете разделить свои соображения об ускорения разработки в комментариях.
Либо, в комментариях к оригиналу.

От себя: буду рад любым замечаниям по ошибкам в тексте.
+84
22 декабря 2008, 19:53
Jacob Gube
Ueasley

комментарии (112)

  • На мой взгляд, один из самых интересных на данный момент JS фреймворков — это ExtJS. Содержит хороший набор готовых интересных бизнес-решений, использование которых может сильно сократить время разработки. Поэтому был несколько удивлён, что его не нашёл в списке рекомендуемых фреймворков.

    Статья очень хорошая. Прекрасная систематизация. Этого зачастую и не хватает.
    • Использовал (точнее, просто ознакомился) ExtJS, действительно, понравился набор базового функционала.

      Но я, все-таки, приверженец jQuery :-)
      • Очень нравится jQuery. Поэтому радует их совместимость. Однако, в jQuery зачастую не все плагины выполнены на одинаково качественном уровне.
      • То же самое. ExtJS круто использовать, когда используется только ExtJS и все, для сложных интерфейсов с контролами, похожими на виндоусовские. А для легковесных решений — jQuery — просто класс. Ну еще MooTools.
      • Нельзя ExtJs с jQuery сравнивать :) Другое дело — jQuery UI, но ему еще далеко до ExtJs.
        • Да, я имел в виду решения на jQuery.
        • Ага-ага. Мы использовали и Ext.JS и jQuery. Могу сказать, что jQuery хорошо подойдет для небольших клиентских фич («местный» AJAX, всплывающие окна, упрощение написания java-script в целом. Хорош для обычных сайтов.), а вот Ext.JS — это «всерьез и на долго» (Если и связываться с Ext.JS, лучше всего весь UI делать на нем. Хорошо подходит именно для веб-приложений со сложным UI).
          • Мда, надо посерьезнее познакомиться с ним.
          • Полностью согласен. Если хочешь использовать ExtJS в проекте, то возможно даже придётся несколько адаптировать требования к возможностям данного фреймворка, которых по созданию UI очень не мало. Можно сказать, что ExtJS будет задавать тон всей клиентской части проекта.
    • Опять же тут все зависит от задач, иногда проще воспользоваться тем же jQuery
      • Ага грузовик что бы сездить в супермаркет как то не оч удобно :)
        jQuery — больше для веб сайтиков
        ExtJS — для разработки веб-приложений
    • Делаем сейчас проект, весь UI полностью на Ext'е. В результате — феноменальное УВЕЛИЧЕНИЕ времени разработки. До этого везде использовали jQuery и бед не знали. В общем жалеем что связались — система получается «тяжелая» для клиента, русурсоемкая в поддержке и понимании для разработчика, + еще неизвестно наколько совместимы будут последующие релизы с ее сегодняшней реализацией…
      • Может быть вы не умеете его готовить? :-)
        • Да нет вроде, умеем, до сих пор все получалось )))
      • Похоже вы что-то делаете не так: то ли вам Ext.JS просто не нужен, то ли вы его не правильно «готовите».

        Нужен ли вам Ext.JS? Если использовали jQuery и «бед не знали» — зачем переходили?

        По поводу правильности использования: после внедрения Ext.JS в ASP.NET, у нас тут внутри компании появился небольшой фреймворк, который позволяет эффективно использовать Ext.JS в ASP.NET.
        Да, зачастую «хакаем», зачастую работает только в ИЕ (у нас требование: ИЕ обязательно, остальное как получится), часто сидим в отладке. Но сказать, что без Ext.JS мы бы написали подобные приложения быстрее — чистые враки :)
    • Давно используем в своей компании под RIA, результат не очень радует, наткнулись на многие баги в коре, ограничения. Одно дело побаловаться в небольших проектах, другое — крупные продакшен системы, когда надо все вылизывать. В итоге перешли на flex, который на несколько голов опытнее, стабильнее и быстрее в разработке. Вот такой личный опыт.
      • как пример попробуйте сделать на ExtJS грид с хотя 10 000 стоками, все будет печально. На flex 70 000 полет нормальный, причем OLAP.
        • вне контекста фреймворков, просто для общего развития — нахуа на клиенте десять тысяч строк?
          • Администрирование?
            • администрирование чего? десяти тысяч строк? их можно увидеть одновременно? сделать с ними что-то полезное? может быть они поместятся на экран все сразу?
              • Всякое бывает, а выводить можно и не все сразу (хранить в памяти, хотя, как правило, это крайне хреновый способ).
                • крайне хреновый способ дергать базу тяжелыми запросами, по принципу «кул аякс, а нахрен нам все», когда она в миллионы записей. Поверьте 10 000 в памяти это совсем не много=)
                  • Ну, IE (у меня) откидывается сразу. А когда начинается сортировка…
                    • на extJS да
                      • Без фреймворков.
          • модули аналитики когда-нибудь видили? Вот там и надо, выкачивают запросами в кубы, потом анализируют, обычная практика.
            • и че? в гриде зачем отображать 10000 строк?
              • отбражать не получиться, экрана не хватит, а вот запихать в грид чтоб можно было работать надо.
    • Для меня ExtJS слишком громоздкая, да и лицензия у них платная для коммерческих продуктов, если я не ошибаюсь.
  • НЛО прилетело и опубликовало эту надпись здесь.
    • В самом Eclipse ничего особенно сложного нет. Сложнее сделать хорошую и удобную для себя сборку с плагинами.
      Вот пара неплохих скринкастов:
      первый, второй.
      • Я, все таки, остановился на NetBeans 6.5 для разработки на Python и PHP.
        От Эклипса, почему то воротит. Да и тормозит он даже на сильной машинке — будь здоров (чего не скажешь о NetBeans).
        А для новичка плюсы от NetBeans очевидны — все работает из коробки.
        Не спорю, что для Java — Eclipse — #1 Open Source решение, но для PHP и Python я бы больше посоветовал NetBeans.
        • НЛО прилетело и опубликовало эту надпись здесь.
        • Да, после эклипса недбинс действительно приятнее (для питона, как минимум).
        • тока переносов нет ;(
          а так очень приятный, и дебаг работает
        • Zend Studio for Eclipse вполне себе ничего.
          • Если забыть про его стоимость.
        • IntelijIDEA #1 =)
          • для JAVA
          • С каких это пор IDEA — Open Source? )
    • Я тоже так и не смог пока преодолеть это «страх». Сейчас для PHP использую Notepad++
      • А я вот отвел 2 часа для того чтобы разобраться с Эклипсом.
        Специально сел, поставил, начал настраивать…

        Первые минут 10 — ну неудобно, криво, громоздко…
        А потом очень понравилось (опять же прикрутил поддержку SVN)

        Так что попробуйте пересилить себя — вдруг понравится? ;-)
      • Пора бы уже :)
  • Спасибо за статью, но я не услышал того, чего хотел — новинок. Зажрался может уже…
    • новинок в положениях или новинок в примерных софте и продуктах?
  • как то так:

    1. используйте фреймворки — и вы не узнаете о тонкостях реализаций и приятных ощущениях от того, что вы говорите что делать, а не подстраиваетесь под фреймворк;
    2. Используйте интегрированные среды разработки (IDE) — и вы никогда не сможете собрать элементарный проект в командной строке средствами компилятора, а возможно даже и не узнаете, что такое точка входа;
    3. Модульность (уместная, разумеется) — в меру, проектирование не должно побороть затраты на программирование;
    …
    7. Автоматизируйте форматирование кода и стандартаризацию — вы же про IDE говорили, в смысле комбинацию клавиш нажимать? странно, что еще при автоформатировании IDE не спрашивают какие нотации применять (:;
    8. Уделяйте больше времени формированию требований и проектированию (планированию) — очень трогательно, как работа программиста;
    9. Используйте уже написанный код — и вы всегда будете потребителем и никогда не узнаете о том, что ваш код работал бы в разы быстрее «уже написанного»;
    10. Урежьте функционал — сокройте функционал, он вам ой как пригодится при расширении.

    естественно, тут доля юмора, но не поддавайтесь на эти «способы». это «способы» — как стать серым и невостребованным программистом. если вы уже востребованы, то, конечно, ваше право решать по каждому из «способов», потому что решения ваши будут временем и опытом подтверждены.
    • >> это «способы» — как стать серым и невостребованным программистом

      Имхо, это способы вначале писать более-менее нормальный код. Умный программист — всегда найдет способы для своего дальнейшего развития. Неумный же, полагаясь на эти методы, станет хорошим «серым» программистом, которые тоже очень нужны и полезны и иногда даже более полезны чем некоторые юные «гении» от программинга, которые действительно перспективны, но их неорганизованность сводит весь их потенциал к нулю.
      • доля правды есть, но как стать «умным», если есть «10 способов ускорить разработку»?
        • Нужно сначала стать «умным», а потом уже ускорять разработку ;)

          Как один из примеров. Зачем мне знать все тонкости если я и так уже большинство знаю и для меня это превращается постепенно в рутину? Рутины нужно избегать при разработке, либо поручать тем, кому это ещё не рутина.
          • я о том и говорил. в последнем абзаце. осознанный и объективный выбор автоматически перечеркивает мою тираду о «способах ускорения».
            я говорил о тех, кто хочет научиться программировать, а в итоге учится копипастить примеры из документации к очередному фреймворку, не понимая и третьей части кода. думаю, частенько с таким сталкиваетесь.
            • У меня так сложилось, что начинал учиться с голого C/C++, потом года 3 программировал на .NET и был категорически против фреймворков, поэтому всю платформу изучил достаточно хорошо, теперь могу ними свободно пользоваться осознанно. А с тем что люди учатся таскать мышкой контролы в IDE и копировать примеры из статей/документаций сталкивался — печальное зрелище. Вам просто нужно было уточнить, что ваш первый комментарий относится к начинающим разработчикам. А в том что опытный человек со стажем будет применять все 10 пунктов не вижу ничего плохого :)
              • потом года 3 программировал на .NET и был категорически против фреймворков


                Интересная фраза.
                • Согласен, каламбур немного :)
                  Но в моем понимании .NET Framework — это больше как платформа, а фреймворки под него — это уже фреймворки в контексте данной статьи. Как без .NET Framework на C# писать-то :)
                  • так же, как и на C без стандартной библиотеки :)
        • «10 способов» и подобные вещи — это для того чтобы стать профессионалом. Профессионалом, не в смысле крутой программер, а в смысле профессинальный программист, т.е. удовлетворять обычным требованиям работодателей и зарабатывать себе на жизнь программированием. Расти и развиваться — это уже зависит от человека.

          Простой пример:
          «2. Используйте интегрированные среды разработки (IDE) — и вы никогда не сможете собрать элементарный проект в командной строке средствами компилятора, а возможно даже и не узнаете, что такое точка входа;»

          А оно надо? Обычному программеру — не надо. Продвинутые — сами найдут где про это прочитать.

          Ваш юмор про эти пункты весьма уместен, но для того чтобы самому все прощупать и все понять — нужны… ну как минимум годы. Чтобы действительно чувствовать — что, где и когда надо делать и что использовать. Такие профи — дорогие и очень востребованные спецы и ими становятся очень немногие и далеко не сразу. Но до этого — будут кучи проб и ошибок. Имхо, данные «10 способов» позволяют эти ошибки уменьшить.
    • НЛО прилетело и опубликовало эту надпись здесь.
      • ну почему же :) на спектруме и с магнитофоном :)
        • (: я всегда знал, что чем мощнее компьютер — тем лучше код пишется и быстрее цели достигаются.
          раньше мерились знаниями, а теперь гигагерцами и выученными хоткеями.
          • Ну, я конечно не спорю, что на старых машинах можно писать отличные программы.

            Но для того, что бы использовать необходимые инструменты, мне, например, нужна нормальная машина. А сначала я тоже сидел на P4 с 1.5ГГц и 256 оперативы (со временем, это стало ужасно).
            • вопрос не в мощности машины, вопрос в том, что люди путают мягкое и круглое.
      • т.е. я придумал отмазку от отмазки, которая позволяет меньше думать и больше копипастить? (:
        в развитии остановились те, кто без NetBeans не могут простейшую программу написать, а без фреймворка не могу обратиться к базе данных.
        • НЛО прилетело и опубликовало эту надпись здесь.
          • вы обобщаете, а я в своем первом комментарии говорил не обо всех программистах, а о тех, которые делают свой выбор в пользу «способов ускорения» мотивируясь не опытом и знаниями.
            выше пояснил уже.
          • Имхо, переходить на IDE и, особенно, фреймворки (даже просто сторонние библиотеки) нужно тогда, когда ты понимаешь что ты теряешь, а что ты приобретаешь от их использования. И если минусов у использования IDE не так уж много, то у использования сторонних фреймворков их достаточно для того, чтобы не всегда это использование было оптимальным решением. Изучение, например, какого-нибудь фреймворка в объеме достаточном для решения поставленной задачи может оказаться куда более длительным процессом по сравнению с решением этой же задачи «с нуля».
    • И вообще надо ездить на лошадях и письма пересылать почтой.
      Да, и кирпчи надо делать самому, иначе нмкагда не узнаете как правильно обжигать глину…
      • если ты кирпичных дел мастер — то делать кирпичи придется научится самому, для начала. хотя, ведь можно купить кирпич и сказать, что ты мастер тех самых кирпичных дел.
        • А если ты строитель? Так уж нужно знать как делать кирпичи?
          • не обязательно, но вполне себе уверен, что даже Дональд Трамп очень даже знает, как делать кирпичи.
            • Говорите себе это почаще.
              • мне не нужен психоаналитик, спасибо (:
                аргументы у вас откровенно слабые, раз уж на личности переходите.
                • Аргументы «я уверен» тоже к сильным не относятся.
                  Да я не пытался никого переубедить.
                  Вы же типичный тролль, которого я ради развлечения немного покормил.
                  • ведь в ваших комментариях знаки вопроса, т.е. вы пытались заставить меня ответить на свои недалекие вопросы и тем самым переубедить.
                    хотя. о чем это я? как можно оспорить ваши аргументы: «тролль» и рекомендации (:
                    удачи.
                    • Тро́ллинг (от англ. trolling — блеснение, ловля рыбы на блесну) — написание в интернете (на форумах, в группах новостей Usenet, в вики-проектах, ЖЖ и др.) провокационных сообщений с целью вызвать флейм, конфликты между участниками, пустой трёп, оскорбления и т. п. Занимающийся троллингом называется троллем, что совпадает с названием мифологического существа. (с) Википедия.

                      Ваш первый пост — образец троллинга. Нескрытое провокационное утверждение.
                      Так что самый что ни на есть тролль. Хотя может и не сознательный.

                      • Мне кажется, человек в первом комментарии писал больше в адрес людей, которые начинают осваивать программирование с этих 10 способов. В данном контексте я с ним согласен тоже. Если он это по другому толковал, то нет :) А насчет кирпичей и т.д. это вас уже обоих чуть занесло, как по мне.
                        • Мне так не показалось. В контексте топика человек повёл себя как типичный тролль.
                          • Нормально он себя повел, успокойтесь уже :-)
                          • прозреваю троллинг
    • и вы не узнаете о тонкостях реализаций
      по-моему, исходники у фреймворков никто не шифрует
      вы говорите что делать
      без фреймворка вы ещё говорите, как делать
      вы же про IDE говорили, в смысле комбинацию клавиш нажимать
      В IDE — да. В консоли — вызывать периодически TidyYourFavoriteLanguage.
      ваш код работал бы в разы быстрее «уже написанного»
      Ну не факт же. Да и нужно быть очень уверенным в своих силах, чтобы браться за свой, скажем, парсер XML с блэкджеком ипр.
      сокройте функционал
      Это не «функционал есть, но спрячьте»; это «блин, не успеваем, ещё полгода нужно на эту фичу — фичу нафиг, стартуем через неделю, допишем потом»
    • НЛО прилетело и опубликовало эту надпись здесь.
    • >1. используйте фреймворки — и вы не узнаете о тонкостях реализаций

      По моему ровно наоборот. Я пока не встречал фреймворка, который бы позволял делать что-то не самое банальное не вникая в тонкости реализации фреймворка, а вникать там есть куда, и есть чему поучиться.
  • + автоматизированные тесты
    • Вот по этому поводу хотелось бы очень статью :)
      Давно хочется заняться юнит тестами и, наконец, понять их на 100%, но времени все не хватает. Вот бы если кто-то рассказал..:-)
      • автоматизированные тесты и unit-тесты не совсем одно и тоже :)
        у нас автоматизированные тесты для веб-приложений пишутся в Selenium IDE. и покрывают почти весь функционал, в то же время unit-тестами обычно покрывают 50-60% функционала.
        • По терминологии.
          Автоматизированные тесты — это те, которые проводятся не человеком, а машиной.
          Это могут быть и юнит-тесты. Скажем так, юнит-тесты являются автоматизированными тестами.
          А то, о чем вы говорите — тесты в Selenium — это автоматизированные функциональные тесты.
        • Может осветите про Selenium и как вы им пользуетесь? Было интересно почитать такую статейку…
          • Вот будут большие январские праздники — напишу обязательно.
      • Я тоже :)
      • Это странно, но нужно просто попробовать :) Сами они себя использовать не научат. А вообще, принцип довольно простой, надо только выделить пару часиков и почитать, допустим, Agiledev
  • Отличная статья, спасибо. особенно за полезные ссылки.

    В самом первом абзаце смущает фраза «методики «Agile» и AJAX», я конечно со второго прочтения понял, что вы сначала указали «методики agile», а потом указали технологию ajax, и все же резануло по глазам.
    • Вроде, теперь не режет.
      • да, вот теперь все отлично.
  • не Symphony, а Symfony
    Почему фреймворк назвали symfony? Потому что Фабьен Потенсьер хотел дать фреймворку короткое имя, легко запоминающейся, не ассоциирующейся с другими проектами, содержащее буквы «s» (Sensio) и «f» (framework).
    • Фабьен Потенсьер — гендиректор Sensio (http://www.sensio.com/), французкой веб-фирмы известной своими инновационными взглядами на веб-разработку.
    • Исправил, спасибо.
      • И в конце статьи: «style switcjer». Похоже больше на опечатку.
  • Отличная статья! Мне, как начинающему и стремящемуся развиваться, разработчику очень полезно было ознакомиться и подчерпнуть. Спасибо!
    • Начинающему врядли. Перед тем как использовать все вышеперечисленное? нужно хорошо понимать как работает IDE, как реализованы фреймворки внутри и т.д.
      • Может быть я выразил свою мысль не как абстрактный вердикт статье, но дал личностно-субъективную оценку ;-)
        У меня лично опыт большой. Но не в web-разработке. Поэтому мне — полезно :-)
        • Спасибо за карму. Очень по-мужски.
  • Совет по поводу IDE — очень спорный. Например, большинство разработчиков на Rails не используют IDE, а пользуются TextMate или gedit. Про vim и emacs я вообще молчу — как минимум производительность там такая же, если не больше (а функционал понятно больше, столько шуток ходит уже, что emacs — это отличная ОС).
    • vim и emacs, соответствующим образом настроенные — это и есть IDE.
  • Ни о чем. Грамотное проектирование (не планирование!) системы приводит к пониманию, какие инструменты нужны, и в каком объеме их использовать. Ибо система — это не набор технологий да инструментов, а идея и ее реализация.
  • Статья правильная — систематизирующая.
    Вы забыли упомянуть про систему контроля версий — Subversion, или теперь есть еще что-то более модное. Но с такой штукой пропадают всякие проблемы синхронизации, когда кто и где и чего изменил и т.д. Даже для одиночки очень полезная вещь
    • опередили :)
    • Это перевод, так что ничего не мог поделать.
  • Хорошя статья, ничего нового — но систематизировать уже известное — всегда полезно. Подпишусь под каждым пунктом. От себя добавлю только:
    11. используйте системы контролья версий (cvs,svn, git) по вкусу. Любой лучше чем ничего.
    "как же хорошо работать с svn, а не с «тебе не нужен этот файл?» :)))" (Баш)
    у нас на фирме к subversion прикручен php codeСniffer, что силно помогает в п.7.
    12. MCV. значительно экономит время, особенно при повторном использовании. п. 5
    про юнит-тесы уже говорили.
    • l1r
    • l1r
    • 24 декабря 2008, 04:22
    • #
      • +2
    Что касается сниппетов, есть ещё один неплохой ресурс — snipplr.com/
  • Интересно, на что еще кроме .NET может упасть мой взгляд, если я использую C#?
  • «Start With No» нужно распечатать каждому манагеру, повесить с обоих сторон двери туалета и вдумчиво читать в моменты озарений.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.