Мысли об отказе от проприетарной структуры для более крупного проекта с открытым исходным кодом

Question

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

Наше текущее решение было построено так, чтобы включать в себя только то, что нам нужно, и оно очень гибкое. Под гибкостью я подразумеваю, что оно свободно, и разработчики, создававшие сайты с ним в течение многих лет, в этом свободны, поэтому многие сайты, которые мы управляем и создали, и не соответствуют никаким стандартам. Здесь, в офисе, я немного использую фреймворк, но предпочитаю использовать другие инструменты. В течение многих лет я использовал множество PHP-фреймворков, начиная от Code Igniter и заканчивая CakePHP, и был большим поклонником Zend Framework для всех моих личных проектов, поэтому я очень предвзят, и поэтому я прошу здесь совета у людей, которые могут быть в состоянии дать мне более объективное мнение. В офисе была проделана большая работа над нашей структурой, поэтому я могу понять, почему некоторые люди не решаются отказаться от нее, но, как я вижу, это так:

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

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

Вот некоторые причины, по которым я считаю, что переход на поддерживаемую среду с открытым исходным кодом помогает нам в долгосрочной перспективе:

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

Вот негативы, которые я придумала:

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

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

Answer 1

Ваш вопрос действительно дьявольски предвзят, потому что все "за" - это долгосрочные проблемы, а все проблемы "за" - краткосрочные. :) Но если ситуация вдвое меньше, чем вы описываете, переключение - это правильно, и в долгосрочной перспективе вы сэкономите много денег.

Answer 2

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

В основном я работал с Perl и Ruby, но тенденция, которую я вижу в эти дни, - это фреймворки, позволяющие вам смешивать и сопоставлять основные компоненты фреймворка. Например, мы рассматриваем возможность интеграции частей нашей пользовательской инфраструктуры в Catalyst . Таким образом, мы все еще можем использовать некоторые из наших специально разработанных компонентов кода (наш собственный класс DBI и некоторые шаблоны Mason), и перенос наших приложений не будет таким трудным. Ruby on Rails также движется в направлении большей модульности.

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

Звучит так, будто вы делаете хороший анализ, и я желаю вам удачи в поиске.

Answer 3

Я вижу пару минусов переключения.

Во-первых, конечно, есть:

Придется портировать все существующие код, который мы имеем в нашем приложении в новую систему

Далее:

Придется портировать все существующие код, который мы имеем в нашем приложении в новую систему

и, наконец, но не в последнюю очередь:

Придется портировать все существующие код, который мы имеем в нашем приложении в новую систему

Вы говорили о «деньгах в столбце накладных расходов», и переписывание работающего проверенного кода в новый работающий проверенный код не приносит большой пользы.

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

Но есть ли существующая, поставляемая, зрелая база кода с работающими над ней знающими людьми?

Эту таблетку трудно проглотить лично.

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

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

Каждый хочет переписать код, я хочу это сделать. Наша структура нуждается в "сделать более" здесь. Но тогда мы идем "да, но ..." и что мы получаем в конце? N месяцев усилий, чтобы вернуться туда, где мы сейчас находимся. Это мало что дает в мире, где время на рынок имеет значение.

Answer 4

Я и моя команда близки к завершению переноса существующего приложения для работы на Zend Framework, и все прошло хорошо.

В старом приложении было много проблем, которые собирались исправить, и мы решили сделать решающий шаг и перестроить его в ZF.

Однако портирование заняло много времени, я бы оценил, что для нашего приложения у нас ушло добрых 4-5 месяцев на портирование всего (мы воспользовались возможностью перенастроить базу данных и другие области системы ).

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

Answer 5

Я думаю, что наиболее важные моменты вы подчеркнули здесь. Решение сейчас должно основываться на цифрах. Технически ваш анализ идеален. Теперь я бы спросил: сколько это будет стоить для вашей компании:

* сохраняйте ваше приложение, чтобы использовать новые улучшения php, не ломая старый код (это означает: анализ архитектуры, разработка и тестирование, тестирование, тестирование).

* Есть ли у вас разработчик / аналитик, занимающийся разработкой безопасности? (это означает: жизненный цикл разработки безопасности, тестирование, тестирование, тестирование).

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

У меня был тот же вопрос, что и вы когда-то, и моя компания решила выбрать фреймворк, перенести наш код, выделить 2 разработчика 1 день в неделю для работы над фреймворком. Было хорошо, если наша команда работала с командой разработчиков фреймворка, потому что мы узнали больше о фреймворке, помогли сообществу (демагогия :-)) и могли добавить некоторые бизнес-требования в дорожную карту возможностей фреймворка; -)