Комментарии 17
Спасибо, как для меня-начинающего, вы направили мой путь в нужное русло.
Раз уж топик связан с рельсами. Подскажите какую-нибудь хорошую, понятную статью про тестирование rails-приложений. Я уже осознал, что тесты нужны, я понял зачем они нужны, но я пока не понял что же мне в них писать. Мне нужны примеры, в которых мне покажут какие тесты нужно писать для действий контроллеров, какие — для методов моделей. Что должно проверяться и как. А что не должно. Вот в статье есть плохой пример теста, а где хороший?
Я хочу от вас детей с вами работать.
Спасибо, но я лишь перевел отличную статью. Большинство лавров — автору. А что, в Яндексе есть рубисты? ;)
Только дочитав понял, что это — перевод (по всей видимости, хороший).
Если говорить именно о «будущем разработчике», а не пользователе проекта, то кажется самый проблематичный вопрос, на который не может дать ответ ни сам код, ни описание методов, ни тесты, это вопрос «что вообще эта херня здесь делает? почему было принято решение делать так, а не иначе?» Это как раз то место, где должен появится комментарий между строк с обязательным «because» или «so»:
Не представляю, как можно было бы поддерживать чужой код, не имея подобного способа взаимодействия между прошлыми/будущими разработчиками.
Если говорить именно о «будущем разработчике», а не пользователе проекта, то кажется самый проблематичный вопрос, на который не может дать ответ ни сам код, ни описание методов, ни тесты, это вопрос «что вообще эта херня здесь делает? почему было принято решение делать так, а не иначе?» Это как раз то место, где должен появится комментарий между строк с обязательным «because» или «so»:
# imported lazily here because google app-engine doesn't support write access on the file system and the function does not exist normally.
# error into the generated code. We could catch that at compile time too, but i welcome it not to confuse users by throwing the same error at different times just "because we can".
# we reached the end of the template too early, the subparser does not check for this, so we do that now
Не представляю, как можно было бы поддерживать чужой код, не имея подобного способа взаимодействия между прошлыми/будущими разработчиками.
Проклятый телефон, я оставил комментарий ниже. habrahabr.ru/post/159421/#comment_5465859
> Только дочитав понял, что это — перевод (по всей видимости, хороший).
«он или она» выдаёт язык оригинала с головой.
«он или она» выдаёт язык оригинала с головой.
Одно упоминание шаблона «он или она (he or she)» должно было вас насторожить :) В русских текстах он не используется, смело можно употреблять слово «он», т.к. речь идёт о представителе профессии, а в этом случае правильным является местоимение «он». Англицизм «он или она» — неграмотен. А, в целом, да, перевод хорош.
Согласен, это одна из самых больших проблем — необходимость сообщать унаследовавшему код человеку предпосылки существования этого кода. Это тоже обсуждается в посте. Мое мнение таково — в коде этому не место, но место в репозитории. Каждый коммит по возможности должен быть привязан к соответствующей задаче (багу, таске, фиче) в трекере, быть атомарным и сопровождаться кратким емким описанием. Порой даже автор коммита не может назвать причину его существования, и комментарий в коде поможет в таком случае разве что самую малость. В остальном — инлайновые комментарии мне кажутся визуальным шумом, осложнявшим чтение кода.
Этот ответ относится к комментарию habrahabr.ru/post/159421/#comment_5465453
советую к прочтению «Чистый код. Создание, анализ и рефакторинг» Роберт Мартин
В статье упоминается эта книга Роберта Мартина. Речь об одном и том же?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работая в интересах Будущих Разработчиков