Рано или поздно любому иногда приходится браться за какой-либо проект, который надо самому написать. Т.е. я один пишу, я один документирую, я один тестирую. Так вот. Сейчас я пишу библиотеку одну. Библиотека подразумевает какую-то функциональность, логику. Не примитивный мост между нативным API к удобному представленную классами. Я не очень четко представляю как весь этот процесс сделать правильно, ведь любой из названных этапов важен. Важно правильно тестить продукт.
Скажем я начинаю какой-либо класс, с чего мне начать? Чем руководствоваться?
result = MySuperClass::runSuperAction();
assertEqual(result, 'Expected result');
затем реализуете саму функцию (пустую), чтобы скомпилировались тесты, запускаете тесты и видите, что они не проходят, потом изменяете функцию так чтобы тест прошёл и, считайте, функциональность вы реализовали, тестирование этой функциональности и документацию.
Я бы посоветовал вам выкинуть из головы всю мишуру вроде юнит-тестов, кошерной архитектуры и абстрактных фабрик. Главное — не тесты, не документация и не мана небесная, снизошедшая на вас после написания богоугодного кода. Главное — сам код, который выполняет поставленную задачу. Вот и пишите код, руководствуясь здравым смыслом. Если потом почувствуете, что вам нужны тесты — напишете тесты. А нет, так нет.
«Потом» тесты пишутся редко, а если пишутся, то чаще всего по необходимости, «из под палки». Почему бы сразу не начать с них, если они подразумевают:
— формализацию задачи (сложно же решить поставленную задачу, если она толком не поставлена, не так ли?)
— проверку решает ли код задачу (вручную проверять решает ли код задачу во всех сценариях использования, граничных и критических точках несколько затруднительно, если сценариев много, они не примитивны, одни зависят от других и т. п.)
— постоянный контроль над тем, что на очередной итерации код всё ещё решает задачу во всех сценариях использования, а не так что добавленое решение по одному сценарию, ломает другой.
Atrax
Если проект не умещается в голове, то это уже явно проект не для одного человека. И не стоит недооценивать возможности своей головы.
VolCh
> «Потом» тесты пишутся редко, а если пишутся, то чаще всего по необходимости.
Вот именно, ключевое слово — «необходимость». Когда пишешь проект в одиночку, главное — это энтузиазм. Если в самом начале растратить энтузиазм на бесполезные тесты, вместо того, чтобы написать пусть говнокодистый, но зато рабочий прототип, есть риск так и остаться только с этими тестами.
ThePretender
Само собой, код важнее всего. Я как раз хочу понять как написать эффективный, хороший, работающий код. Мне кажется есть способы уменьшить количество грабель, не наступая на них.
Atrax
Суть вопроса в том, что проект пишется в одиночку. Никак иначе. От проблем с головой, что там не умещается проект, я не могу ничего сделать. Разве что мозг развивать. Помошников нет.
VolCh
Сценариев много, очень много. Уж слишком много кто в шахматы играет…
ThePretender, бесполезными они будут если их писать после кода «для галочки» или тестировать то, что тестировать не нужно. И в классическом TDD тесты не пишутся кучей: в идеале может быть только один непроходящий тест — тот, для которого ты ещё не реализовал функциональность или реализовал её неправильно. Хотя, конечно, у каждого свои методы повышения мотивированности, но лично мне TDD помогает энтузиазм не растрачивать слишком рано — я постоянно вижу как растёт рабочая функциональность проекта, а не просто количество строк кода. И пускай эта функциональность говнокодистая, но я уверен, что в целом архитектура позволяет безболезненно заменить любой кусок говнокода на «совершенный» и нечего от этого не посыпется, а если посыпется, то я моментально об этом узнаю, а не из багрепорта пользователей.
Думается многие на хабре писали, скажем дипломную. Куча примеров с open source проектов. Они ж писались! Сложно или нет, не суть. Мне вот интересно как? Найдется пару правил, которые подскажут что есть true, а что делать совсем epic fail.
Open Source и разработчик-одиночка все-таки не одно и то же, почему бы вам не собрать команду?
Если же все-таки нет, то я надеюсь найдутся более опытные, чем я, разработчики и помогут советом.
Для меня ещё важный момент — измеряемость результата.
Если просто сесть городить код, то можно сдуться где-то в процессе, чисто из-за потери «энтузазизьма». И тогда либо проект бросается на полдороги, либо пургу начинаю гнать.
С этих позиций те же тесты немного помогают — видно более-менее, какую часть тестов я уже успел засатисфачить.
Раньше отправилось. А тесты, да, помогают измерять результат вполне наглядно. У меня, правда, не по принципу «какую часть сделал», а просто «сколько сделал»
Ну так там дата стоит — 29 марта 2000.
Тогда не было и речи ни о какиой МакОС. И даже про iPod речи не было.
А у Джобса на визитке было написано что-то типа «И.О. директора».
С тех пор, кстати, Яббл стал поставлять продукты точно в срок (ну или переносить сроки до того, как о продуктах было объявлено).
Средний
