Голосование — да, в первой 3-й версии (сборка 300) оно глючило, в одном из следующих патчей исправлено. Форум — нет, просто макет подключается чуть сложнее, чем к обычному разделу, см. ртфм по модулям, 65 страница. Глючит цвет — как глючит? Саппорт по данной формулировке мне ничего путного не сказал.
В прошлом мессаге вы писали «половина модулей не работает, после каждого обновления система «ложится» и приобретает кучу багов» — можно ли поподробнее об этом? Какая именно половина модулей не работает и как они это (не) делают, как после каждого обновления система ложится и какие баги после каких обновлений приобретаются? Описанные вами проблемы — дикий ахтунг, тысячи пользователей о них не подозревают, хотя и обновляются, и модулями пользуются. Надо же народ предупредить.
Спасибо за пожелания. На самом деле, вопрос полностью новой версии (не совместимой со старой) изучался. Мы пришли к выводу, что в нашем конкретном случае это не имеет смысла ни с маркетинговой, ни с технической точки зрения. Даже полный рефакторинг выйдет дешевле и закроет принципиальные проблемы, которые были (и еще остаются). Главный плюс — мы не «подвешиваем» судьбу текущих пользователей.
Ну и плюс к тому — есть и другие факторы, которые рассказывать очень долго. Проблемы, которые вы подняли, будут решаться, просто не такими кардинальными способами.
По закону жанра я должен всячески отрицать претензии, но я не вижу причин спорить с очевидным :) Да, документация разработчика далека от идеала, и поэтому сейчас мы ей и занимаемся.
Обращения мы не игнорируем, а складываем в списки и по мере поступления разбираем. Что-то действительно «минусим», но большинство ставится в план — либо в ближайший патч, либо в следующую версию. Но вы правы насчет фидбэка, не всегда получается информировать об этом того, кто обращается с предложением.
Да я вам не оппонирую :) Хотя бы потому что вы говорите правильные вещи, и в целом я с вами согласен. Просто мы немного о разном говорим. Смотрите. Пример несколько утрированный, но тем не менее.
Сейчас у всей команды разработки NetCat есть свои задачи. Они расписаны на три месяца вперед. Разумеется, эти сроки отодвинутся, если появится срочная задача — например, найден серьезный баг или что-то в этом роде.
Мы ставим на «через три месяца» одной из групп рефакторинг. Но к этому времени появляется новая версия, вишлист наполняется новыми пожеланиями и пр. И мы видим, что объективно надо отодвигать рефакторинг. Что делать?
Отодвигать? Ну так оно всегда будет отодвигаться и никогда не произойдет. Отодвигать новые задачи? А если их решение влияет на бизнес наших клиентов/партнеров, и те банально могут уйти?
Приходится искать компромиссы.
Впрочем, в реальности не все так плохо, как в этом примере. Сейчас как раз такая ситуация, что на «через три месяца» вполне можно поставить такую задачу.
Такие вопросы лучше разбирать на примерах. Если есть пример — давайте попробуем его разобрать. Чаще всего (по статистике обращений в саппорт) к изменениям в ядре прибегают, когда не до конца разбираются в инструментах разработки системы. Это, кстати, одна из причин, почему мы сейчас занимаемся тотальной переработкой документации разработчика.
А что делать с задачами, которые сейчас решает эта группа? Например, одна группа делает SaaS, другая визарды, третья — готовые решения. С кого из них снимать задачи и почему? Можно конечно сказать, что нужно нанять еще программистов и сформировать из них новую группу, но не все так просто. Механическое увеличение штата не ведет автоматически к пропорциональному увеличению скорости разработки. Иногда даже наоборот.
Про инвестора — подпишусь. Но что из этого следует в контексте вопроса?
Форум — не новый модуль. Когда он писался, такой подход представлялся правильным. Почему — рассказывать долго. Сейчас уже понятно, что это была ошибка. До конца года будет выпущен новый модуль, уже в рамках идеологии.
У нас и так две команды, и они примерно этим и занимаются. Команды в свою очередь делятся на мобильные рабочие группы. 4-ю версию нельзя делать с нуля, она должна быть совместима с третьей, иначе придется либо кидать текущих пользователей, либо поддерживать две ветки и все равно кидать пользователей. В «тройке» была переписана наверное половина кода, но совместимость с 2.х осталась. Архитектура продукта на мой взгляд довольно удачная с точки зрения модернизации и масштабирования.
Инвесторам объяснить можно все что угодно, но с позиции денег. Я вот не знаю, как доказать, что вариант «бросить все на два месяца» более выгоден, чем «в течение полугода постепенно провести аудит и рефакторинг, не бросая приоритетных задач». Вы утрируете проблему — если бы у нас все оставалось на уровне PHP3 и не собиралось меняться — да, из этого ничего путного не вырастишь. Я же говорю лишь о том, что рефакторинг нужен, но не кардинальный и не одномоментно.
Отвечаю в качестве официального представителя NetCat.
Собственно, по большинству примеров я толком не понял претензию. Почему нехорошо так приводить к инту? Почему нельзя эвалить? Примеры со слешами выдраны из контекста. Ну и пр.
Можно ли задачи, выполняемые этим кодом, решить красивее? Наверное, да, по крайней мере, часть из них. Нужно проводить рефакторинг кода? Да. А нужно ли бросить все и вылизывать код? Сомневаюсь. Рефакторинг производится постоянно, и с точки зрения оптимизации, и красоты кода, и безопасности. Проблема в том, что производство коробочного ПО подразумевает кучу тонкостей и непопулярных решений. Ресурсы никогда не бывают безграничны, всегда приходится ставить приоритеты. Например, ввод некоторого востребованного инструмента приоритетнее, чем вылизывание кода, написанного некрасиво, но работающего правильно.
Наши разработчики прекрасно знают проблемы кода, и мне в аську скинули ссылку на этот топик со словами «а я тебе говорил». Смысл в том, что именно я ставлю задачи программистам (с точки зрения приоритетности задач). И я не раз ставил в план работ другие работы в ущерб очередному этапу рефакторинга.
NetCat разрабатывается с 99-го года. За эти 9 лет над кодом ядра трудились самые разные разработчики. От некоторых из них оставалось довольно веселое наследие, которое приходилось (или еще придется) исправлять. Далеко не всегда у нас нас был SVN, CVS, правила документирования кода и тестирования.
Я могу привести много примеров, когда приходилось, например, оттаскивать нового разработчика от рефакторинга, потому что другая задача более приоритетна. Мы можем потратить пару месяцев на аудит кода и его частичное переписывание, сюда же полный перевод на PHP5, но в это время все разработка остановится. Посмотрите на ситуацию с точки зрения не стороннего программиста, а нашего партнера, который запостил в вишлист просьбу включить в ядро новый функционал. Будет ли он рад решению отложить его пожелание на пару месяцев, пока мы вылижем код? Поэтому программистам и приходится наступать на горло собственной песне.
В общем, резюме. iBear, спасибо за топик, проблема есть. Рефакторинг проводится и будет проводиться и дальше, но, увы, это не наивысший приоритет.
Да, прием инверсии, к кому бы мы не обратились, получим в ответ неправду. Как вариант - "тот мужик сказал бы мне, что это - ворота Рая?" Vialle фактически угадала чуть выше.
В прошлом мессаге вы писали «половина модулей не работает, после каждого обновления система «ложится» и приобретает кучу багов» — можно ли поподробнее об этом? Какая именно половина модулей не работает и как они это (не) делают, как после каждого обновления система ложится и какие баги после каких обновлений приобретаются? Описанные вами проблемы — дикий ахтунг, тысячи пользователей о них не подозревают, хотя и обновляются, и модулями пользуются. Надо же народ предупредить.
Ну и плюс к тому — есть и другие факторы, которые рассказывать очень долго. Проблемы, которые вы подняли, будут решаться, просто не такими кардинальными способами.
С UTF вопрос пока не решен, в сентябре будет принято решение, будет ли официальная поддержка этой ветки. Если да — уже осенью будет официальный релиз.
Обращения мы не игнорируем, а складываем в списки и по мере поступления разбираем. Что-то действительно «минусим», но большинство ставится в план — либо в ближайший патч, либо в следующую версию. Но вы правы насчет фидбэка, не всегда получается информировать об этом того, кто обращается с предложением.
Сейчас у всей команды разработки NetCat есть свои задачи. Они расписаны на три месяца вперед. Разумеется, эти сроки отодвинутся, если появится срочная задача — например, найден серьезный баг или что-то в этом роде.
Мы ставим на «через три месяца» одной из групп рефакторинг. Но к этому времени появляется новая версия, вишлист наполняется новыми пожеланиями и пр. И мы видим, что объективно надо отодвигать рефакторинг. Что делать?
Отодвигать? Ну так оно всегда будет отодвигаться и никогда не произойдет. Отодвигать новые задачи? А если их решение влияет на бизнес наших клиентов/партнеров, и те банально могут уйти?
Приходится искать компромиссы.
Впрочем, в реальности не все так плохо, как в этом примере. Сейчас как раз такая ситуация, что на «через три месяца» вполне можно поставить такую задачу.
Про инвестора — подпишусь. Но что из этого следует в контексте вопроса?
Инвесторам объяснить можно все что угодно, но с позиции денег. Я вот не знаю, как доказать, что вариант «бросить все на два месяца» более выгоден, чем «в течение полугода постепенно провести аудит и рефакторинг, не бросая приоритетных задач». Вы утрируете проблему — если бы у нас все оставалось на уровне PHP3 и не собиралось меняться — да, из этого ничего путного не вырастишь. Я же говорю лишь о том, что рефакторинг нужен, но не кардинальный и не одномоментно.
Собственно, по большинству примеров я толком не понял претензию. Почему нехорошо так приводить к инту? Почему нельзя эвалить? Примеры со слешами выдраны из контекста. Ну и пр.
Можно ли задачи, выполняемые этим кодом, решить красивее? Наверное, да, по крайней мере, часть из них. Нужно проводить рефакторинг кода? Да. А нужно ли бросить все и вылизывать код? Сомневаюсь. Рефакторинг производится постоянно, и с точки зрения оптимизации, и красоты кода, и безопасности. Проблема в том, что производство коробочного ПО подразумевает кучу тонкостей и непопулярных решений. Ресурсы никогда не бывают безграничны, всегда приходится ставить приоритеты. Например, ввод некоторого востребованного инструмента приоритетнее, чем вылизывание кода, написанного некрасиво, но работающего правильно.
Наши разработчики прекрасно знают проблемы кода, и мне в аську скинули ссылку на этот топик со словами «а я тебе говорил». Смысл в том, что именно я ставлю задачи программистам (с точки зрения приоритетности задач). И я не раз ставил в план работ другие работы в ущерб очередному этапу рефакторинга.
NetCat разрабатывается с 99-го года. За эти 9 лет над кодом ядра трудились самые разные разработчики. От некоторых из них оставалось довольно веселое наследие, которое приходилось (или еще придется) исправлять. Далеко не всегда у нас нас был SVN, CVS, правила документирования кода и тестирования.
Я могу привести много примеров, когда приходилось, например, оттаскивать нового разработчика от рефакторинга, потому что другая задача более приоритетна. Мы можем потратить пару месяцев на аудит кода и его частичное переписывание, сюда же полный перевод на PHP5, но в это время все разработка остановится. Посмотрите на ситуацию с точки зрения не стороннего программиста, а нашего партнера, который запостил в вишлист просьбу включить в ядро новый функционал. Будет ли он рад решению отложить его пожелание на пару месяцев, пока мы вылижем код? Поэтому программистам и приходится наступать на горло собственной песне.
В общем, резюме. iBear, спасибо за топик, проблема есть. Рефакторинг проводится и будет проводиться и дальше, но, увы, это не наивысший приоритет.
В общем, оба варианта решения найдены. :)