Справедливости ради, никакого противоречия в том, что новую более функциональную технологию надо внедрять с усилиями, с «поддержкой», нет. Примеров тысячи. Самый хабровский, наверное — браузеры. Тот же IE6, который годами лидировал, несмотря на всё возрастающее техническое устаревание. И довольно серьезные усилия разных гигантов типа Google, Vkontakte и даже Microsoft, с трудом преодолевали эту инерцию. Несмотря на, казалось бы, очевидные преимущества новых браузеров.
Если провести аналогию на браузеры, то ваш контраргумент звучит как-то так:
Как вы думаете, если бы Firefox\Chromium\Opera была бы в 10 раз быстрее\надёжнее\удобнее Internet Explorer 6, нужно бы было его «поддерживать\продвигать»?..
Я тоже было подумал, что будет что-то навроде «этот ваш vim — это круто, конечно, но можете ли вы в нём так же быстро и удобно как в emacs делать <описание рутинной операции>».
Уже много выше говорилось, что кликов реально много. В номеронаберателе нету Т9, т.е. ты набираешь только номер, даже если он есть у тебя в записной книжке, ты вынужден будешь набрать его до конца руками.
Было бы круто, если бы при наборе, во-первых, работал бы Т9 (+поиск по набираемому номеру, чего нету даже в текущем Т9 в контактах), а во вторых, при наборе незнакомого номера, он бы лез в справочник и проверял бы номер.
Кроме того, сам номеронабератель глючный: если очень быстро набирать номер, то какая-нибудь цифра в середине обязательном пропадёт. В последнем обновлении стало лучше, но он всё ещё глючит.
А так:
1) Избранное кружочками — круто. Я даже ради этого запарился и объединил контакты из вконтакта с фотками, с людьми с номерами, чтобы красиво было
2) Поиск по коротким именам Митя = Дмитрий = Дима — очень круто
3) Значки операторов возле номера — круто
4) Карта при наличии адреса в карточке контакта — круто
1. Пример прекрасной документации библиотеки Rspec, написанной исключительно на тестах: www.relishapp.com/rspec/rspec-expectations/docs. Вообще, покопайтесь на Relish — там вся документация построена на тестах.
2. Когда вы пишете публичное API неважно веб-сервиса или библиотеки типа QT, то да, конечно, оно должно быть хорошо задокументировано. Но речь идёт о документации кода, который живёт и постоянно меняется. Речь идёт о документировании методов, которые пишет внутренний разработчик, который, априори, должен разбираться как тут всё устроено. Тесты для этой цели подходят прекрасно, иногда гораздо лучше комментариев, ибо ты видишь живой код, видишь, как он применяется и как он работает, с какими данными на входе и с какими на выходе.
Описывайте то, как работает этот код. Обязательно, хоть и кратко, в начале каждого файла, содержащего класс, описывайте, что он реализует. Перед методами класса кратко описывайте, что метод получает и что должен создать в конце своей работы, коротко описывайте цепочку, по которой пройдут данные. Так же в файлах-модулях. Комментируйте вычисляемые автоматически значения и назначения создаваемых миграциями полей. В случае длинной цепочки вызовов функций (длиннее трёх) — описывайте цепочку, что вызывает что, хотя бы просто последовательность.
Вместо комментариев гораздо эффективнее писать тесты. Тест сразу даёт возможные входные и выходные значения, а также способы применения данной функции\метода\класса\вьюхи. Поддерживать свой\чужой код с тестами не составляет больших проблем. Речь, конечно, не идёт о говнокоде и говнокоде в тестах. Его поддерживать проблема при любых раскладах.
Я бы озаглавил статью: «Поскольку я всё ещё не пишу тесты, я снова комментирую код приложений на Ruby/Rails» :) Без обид.
Здорово! Буду вам очень благодарен, если вы напишете комментарий к этой ветке, когда это будет исправлено. Сразу после этого я с огромным удовольствием спасу свою коллекцию!
некорректна. Более-менее понятно, что имеется ввиду, но протеины нельзя перенести из ДНК.
Правильнее было бы сформулировать так: «переноса гена отвечающего за флуоресцентный протеин»…
Если скидка — это один разговор, а если он потом в продаже будет стоить 18, например, или озвученные 15, то как-то не айс.
Гугл что ли? :)
А у нас через половину этого срока страна развалилась. Там выжить бы, а вы ГЛОНАСС требуете.
Если провести аналогию на браузеры, то ваш контраргумент звучит как-то так:
Всё ещё убеждены, что он что-то доказывает?
Было бы круто, если бы при наборе, во-первых, работал бы Т9 (+поиск по набираемому номеру, чего нету даже в текущем Т9 в контактах), а во вторых, при наборе незнакомого номера, он бы лез в справочник и проверял бы номер.
Кроме того, сам номеронабератель глючный: если очень быстро набирать номер, то какая-нибудь цифра в середине обязательном пропадёт. В последнем обновлении стало лучше, но он всё ещё глючит.
А так:
1) Избранное кружочками — круто. Я даже ради этого запарился и объединил контакты из вконтакта с фотками, с людьми с номерами, чтобы красиво было
2) Поиск по коротким именам Митя = Дмитрий = Дима — очень круто
3) Значки операторов возле номера — круто
4) Карта при наличии адреса в карточке контакта — круто
Речь, конечно же, о коде, который находится в эволюции и постоянно изменяется.
2. Когда вы пишете публичное API неважно веб-сервиса или библиотеки типа QT, то да, конечно, оно должно быть хорошо задокументировано. Но речь идёт о документации кода, который живёт и постоянно меняется. Речь идёт о документировании методов, которые пишет внутренний разработчик, который, априори, должен разбираться как тут всё устроено. Тесты для этой цели подходят прекрасно, иногда гораздо лучше комментариев, ибо ты видишь живой код, видишь, как он применяется и как он работает, с какими данными на входе и с какими на выходе.
Вместо комментариев гораздо эффективнее писать тесты. Тест сразу даёт возможные входные и выходные значения, а также способы применения данной функции\метода\класса\вьюхи. Поддерживать свой\чужой код с тестами не составляет больших проблем. Речь, конечно, не идёт о говнокоде и говнокоде в тестах. Его поддерживать проблема при любых раскладах.
Я бы озаглавил статью: «Поскольку я всё ещё не пишу тесты, я снова комментирую код приложений на Ruby/Rails» :) Без обид.
Потом, сегодня нельзя — а завтра уже можно. А я своё разрешение выдал…
Но, спасибо за информацию.