Какова структура вашей небольшой компании по веб-разработке?[закрыто]

Question

Я работаю в небольшой компании по веб-разработке (всего 2-3 разработчика), которая работает над широким спектром проектов для разных клиентов (все, от CMS до сайтов электронной коммерции).

Обычно мы работаем над собственными проектами, но иногда нам нужно работать вместе над одним.Мы используем Subversion, поскольку наше программное обеспечение для контроля версий и сайты разрабатываются в .NET с использованием VS 2008 и SQL 2005.

Прочитав множество сообщений о модульном тестировании и других методах кодирования «корпоративного» уровня, мне стало интересно, что другие разработчики делают для небольших проектов, которые требуют минимального обслуживания и имеют короткое время разработки?

Я думаю, в частности, о таких вещах, как необходимость модульного тестирования и т. д.

Answer 1

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

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

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

Короче говоря, делайте то же самое, что вы бы делали, если бы вы были больше, но вам не обязательно нужны те же инструменты.Приобретайте по мере необходимости.

РЕДАКТИРОВАТЬ:Однако я должен упомянуть, что часть того, что вы делаете, конечно, зависит от ваших методов/процессов, которые вы используете.Например, занимаетесь ли вы гибкой разработкой?Будучи маленьким, вам не обязательно делать все одинаково.Я, например, стараюсь быть гибким, но парным программированием явно не занимаюсь :).Вам просто нужно научиться адаптировать их к тому, что работает для вас.

Answer 2

Я думаю, что самая большая ошибка, которую вы можете сделать, — это отвергнуть что-то как стандарт кодирования уровня «корпоративного уровня».Хотя такие вещи, как CI, серверы сборки, модульное тестирование, стандарты кодирования (не могу придумать, что еще вы имеете в виду) и т. д.могут взять на себя первоначальные накладные расходы, они принесут дивиденды в долгосрочной перспективе.Например, если ваш проект сейчас взломан, а через три года ваш клиент захочет добавить функцию, вы будете рады, что потратили время на модульные тесты сейчас.(Хорошо, это может произойти, а может и не произойти, но...если ваш клиент предложит кому-нибудь взглянуть на ваше решение в будущем и увидит сильно взломанный код, он может больше не обращаться к вам).

Помните также, что чем больше вы этим занимаетесь, тем быстрее это произойдет.

Answer 3

Наша среда разработки также довольно мала.В основном мы занимаемся веб-разработкой на Java (некоторые PHP), а не на .NET или чем-то еще.Мы используем Project locker для нашей вики, SVN и системы отслеживания ошибок.Для разработки кода это варьируется между Netbeans 6.1 и Eclipse и MySQL в качестве серверной части базы данных.
Мы сделали стандартной практикой написание модульных тестов для нашего кода.Спустя 4 месяца это значительно упрощает обновление нашей кодовой базы.

Answer 4

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