Список вопросов
Как зайти в Даркнет?!
25th January, 01:11
4
0
Как в tkinter из поля ввода Entry получить значение в одну переменную и обновить строку кнопкой, затем получить ещё одно введённое значение и затем сложить их. Ниже пример кода
21st July, 19:00
892
0
Программа, которая создает фейковые сервера в поиске игровых серверов CS 1.6 Steam
21st March, 17:43
948
0
Очень долго работает Update запрос Oracle
27th January, 09:58
912
0
не могу запустить сервер на tomcat HTTP Status 404 – Not Found
21st January, 18:02
905
0
Где можно найти фрилансера для выполнения поступающих задач, на постоянной основе?
2nd December, 09:48
938
0
Разработка мобильной кроссплатформенной военной игры
16th July, 17:57
1724
0
период по дням
25th October, 10:44
3955
0
Пишу скрипты для BAS только на запросах
16th September, 02:42
3720
0
Некорректный скрипт для закрытия блока
14th April, 18:33
4613
0
прокидывать exception в блоках try-catch JAVA
11th March, 21:11
4380
0
Помогите пожалуйста решить задачи
24th November, 23:53
6084
0
Не понимаю почему не открывается детальное описание продукта
11th November, 11:51
4350
0
Нужно решить задачу по программированию на массивы
27th October, 18:01
4395
0
Метода Крамера С++
23rd October, 11:55
4308
0
помогите решить задачу на C++
22nd October, 17:31
4002
0
Помогите решить задачу на python с codeforces
22nd October, 11:11
4492
0
Python с нуля: полное руководство для начинающих
18th June, 13:58
2598
0
Какой метод разработки Вы считаете правильным?
Просмотров: 374
 
Ответов: 10
1) Пишу много кода, потом проверяю все сразу
2) Пишу небольшими кусками, которые сразу же проверяю
На мой взгляд, оба подхода имеют как плюсы, так и минусы:
Подход №1:
+Не тратится лишнее время на проверку правильно написанных участков, Работает и все. Что не работает — исправляем
-Легко забыть, о чем думал в момент написания того, или иного участка. Особенно, если куски очень большие
Подход №2 — соответственно, ровно наоборот:
+Только что писал — если вдруг какая-то ошибка обнаруживается, не сложно будет вычислить
-Тратится много времени на проверку хорошо написанных участков
А что вы думаете по этому поводу?
Алгоритмы, которые я точно знаю, обычно пишу большими кусками, а потом за пару запусков правлю всё. Обычно это просто опечатки. А вот с библиотеками, с которыми работаю впервые, либо алгоритмы, которые пишу редко, обычно отлаживаю по частям. Так проще, потому что на этапе привыкания постоянно где-нибудь да сфейлишь.
Никак не могу себя приучить к правильной (согласно TDD) работе: сначала пишем тесты, потом код, такой чтобы тесты не работали, а лишь потом его правим, чтобы заработали.
Сложности две:
— лениво писать тесты на тривиальный код (то есть кода ещё нет «на бумаге», но «в голове» уже он есть)
— лениво писать тесты, предусматривающие всё и вся, например, что методы доступа к СУБД вернут какую-ту ахинею, а не либо корректные данные, либо ошибку. Или, скажем, конструкция return new SomeClass() вернёт не экземпляр SomeClass.
Вероятно я написание тестов так до конца и недопонял, особенно что касается тестирования связанных объектов (например кобинации контроллер, модель, репозиторий)
Зависит от обстоятельств — бывают модули, которые не оттестишь сразу — зависимости там и прочее. В таком случае довожу работу до какой-никакой логической единицы на которой можно провести логичное тестирование. Иногда получаются довольно большие блоки.
В целом подход — разбить функционал на несколько логичных «кусков» — допустим не больше 1-2 дней работы в идеале — и соответственно написал-оттестил-забыл.
В общем и целом — старайтесь найти золотую середину — когда кусок кода всё еще представляет из себя что-то единое, цельное, выполняющее единый функционал, но с другой стороны — уже поддаётся тестированию, в отличие от подвешенной сферической функции в вакууме
ЗЫ: пишу приложения, поэтому мелкая разбивка не получается — в той же MVC зачастую просто контроллер подвешенный в воздухе без модели и представления корректно не оттестируешь…
Смотря как писать эти «много кода». Ничто не мешает коммитить каждое изменение кода или добавление функций, а тесты писать отдельным коммитом после добавление достаточно большого количества кода. Но при каждом коммите стоит проверять код на прохождение имеющихся тестов. Меня такой подход вполне устраивает.
кхе-кхе, а почему нельзя совместить второй способ и вот это:
>Работает и все. Что не работает — исправляем
я так и пишу: написал участок кода какой-то законченный, проверяю как он работает, если работает, то приступаю к следующему, если нет, то правлю. И времени тратится больше разве что на переключение между средой и браузером (я пишу на html/php).
Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться