Код по мотивам моего недавнего видео: https://youtu.be/ewhlgo1B8dI
Три этапа развития программиста:
- Сначала мы учимся реализовывать ФУНКЦИОНАЛ
- Затем — проектировать грамотную СТРУКТУРУ кода
- И наконец, постигаем искусство ПОИСКА ОШИБОК
Пример кода из видео:
///////// NEWBIE
switch p.Equip.Hand {
case "sword":
IncreaseSkill(&p.Skill.Sword)
case "axe":
IncreaseSkill(&p.Skill.Axe)
case "mace":
IncreaseSkill(&p.Skill.Mace)
case "archery":
IncreaseSkill(&p.Skill.Archery)
case "":
IncreaseSkill(&p.Skill.Unarmed)
}
///////// BEGINNER
switch p.Equip.Hand {
case "sword":
IncreaseSkill(&p.Skill.Sword)
case "axe":
IncreaseSkill(&p.Skill.Axe)
case "mace":
IncreaseSkill(&p.Skill.Mace)
case "archery":
IncreaseSkill(&p.Skill.Archery)
default:
IncreaseSkill(&p.Skill.Unarmed)
}
///////// MID
switch p.Equip.Hand {
case "sword":
IncreaseSkill(&p.Skill.Sword)
case "axe":
IncreaseSkill(&p.Skill.Axe)
case "mace":
IncreaseSkill(&p.Skill.Mace)
case "archery":
IncreaseSkill(&p.Skill.Archery)
case "":
IncreaseSkill(&p.Skill.Unarmed)
default:
log.Println("Unknown skill")
}
///////// OK
switch p.Equip.Hand {
case "sword":
IncreaseSkill(&p.Skill.Sword)
case "axe":
IncreaseSkill(&p.Skill.Axe)
case "mace":
IncreaseSkill(&p.Skill.Mace)
case "archery":
IncreaseSkill(&p.Skill.Archery)
case "":
IncreaseSkill(&p.Skill.Unarmed)
default:
log.Fatalf("playerAttack() -> Unknown p.Equip.Hand: [%s]", p.Equip.Hand)
}
///////// GOOD
switch p.Equip.Hand {
case "sword":
IncreaseSkill(&p.Skill.Sword)
case "axe":
IncreaseSkill(&p.Skill.Axe)
case "mace":
IncreaseSkill(&p.Skill.Mace)
case "archery":
IncreaseSkill(&p.Skill.Archery)
case "":
IncreaseSkill(&p.Skill.Unarmed)
default:
shutdown.CrushAndDump("playerAttack() -> Unknown p.Equip.Hand: [%s]", p.Equip.Hand)
}
Дискуссия в комментариях с товарищем exception. Он пишет:
Ручное тестирование — это совсем не весело. Когда проект крупные — это только отнимает время.
Однако есть другие методы, такие как модульные тесты (они идеально подходят для TDD), интеграционное тестирование и приёмочные тесты.
Если обнаруживается ошибка — писать на неё тест, чтоб обнаружить её до сборки релиза. В процессе написания кода нужно предполагать, что он работает правильно, и не учитывать возможность того, что программа может упасть из-за какой-то незначительной ошибки программиста, например, если он забыл обработать какое-то действие. В таком случае можно просто проигнорировать это действие: игрок не пострадает, сообщит о баге, который будет исправлен и протестирован, чтобы избежать подобных ошибок в будущем. ИМХО
Отвечаю:
1) «В процессе написания кода нужно предполагать, что он работает правильно» — опаснейшая ересь которая умножит количество граблей неимоверно
2) автоматизированные тесты — эт замечательно. одно другому не мешает. но ты там очень многое не отсимулируешь, особенно в сложных системах. без ручного тестирования никуда
3) опять же никуда без обработки неизвестных состояний. это можно себе позволить только в простых скриптах.
4) полагаться на то, что пользователи сообщат о багах — это лютый фейл. Будет 100500 дюпов, о которых разрабы узнают последними. я уж молчу о серьезных проектах, где баг может привести к потере больших денек
Тоже «обмазываюсь» логами если пишу код со сложной логикой, т.е. чтоб все протоколировать. Но обычно я если и допускаю ошибки то они неочевидные, их сразу и не разглядишь. Баги искать это отдельное веселье, пригождается дебагер особенно быстро выяснить в каком месте падает. Но такое бывает довольно редко. Стараюсь изначально перепроверять код по 3-5 раз, и это не перфекционизм — такой подход окупается. Да и самое главное, комментарии — они должны быть избыточными и все разжевывать в подробных деталях, не лениться, иначе через год сам нихрена не поймешь что понаписывал ))
Еще можно взять на вооружение принципы кодинга от игродела Джона Ромеро (да от того самого чувака что когда-то инструментальную часть Дума создавал 🙂
John Romero’s Principles
No prototypes. Just make the program. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.
It’s incredibly important that your software can always be run.
Bulletproof your code by providing defaults upon load failure.
Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.
Great tools and libs help make great software. Spend as much time on tools and libs as possible.
We are our own best testing team and should never allow anyone else to experience bugs or see the program crash. Don’t waste others’ time. Test thoroughly before checking in your code.
As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.
И кстати глобальный рефакторинг — это катастрофа. Это значит что архитектура была выбрана неверно изначально и проще будет все переписать заново, сейчас так часто бывает у новомодных вайтишников-смузихлёбов, херак-херак и в продакшн, потом приходят новые люди разгребают легаси и волосы дыбом становятся от подобного неподдерживаемого трэша. Вот почему над проектированием нужно работать основательно, все продумать еще до начала написания кода. Мелкий рефакторинг, конечно, нормальное явление.
Я вот в прошлом году так запроектировал фундаментальные библиотеки для бизнеса, и преобразил Си++ что мне сейчас на нем проще и быстрее писать чем на скриптовых языках. Код смотрится лаконично, красиво, самый минимум зависимостей, все кроссплатформенно, поддержка компиляторов начиная с С++03, исключения не используются, есть и умные указатели, свой аналог базы данных в памяти типа систем записей как в коболе, короче куча упрощений которые следовало бы делать комитету стандартизации а не мне самому сидеть и изобретать велосипед, но что есть то есть, в этом можно найти и плюсы — когда сам проектируешь потом наизусть всё знаешь, понимаешь нюансы и лучше ориентируешься, чем когда используешь что-то стороннее, бонус Си++ это безусловно быстрое исполнение кода, низкое потребление оперативной памяти, маленькие бинарники на выходе, доступ к огромному количеству C/C++ библиотек (включая также и Modern C++). Я это называю предпринимательским программированием (или изобретательным — как хочешь это назови), когда ты — программист длинной воли, свободный волк, а не рабская собака. Такой подход в программировании разительно отличается от мейнстримного наёмного программирования (на дядю), когда тебя принудительно ставят в рамки закрепощенного галерного конвейера, ограниченного общепринятыми колхозными «стандартами». 🙂 В 90х свободных «волков» было на порядки больше чем сейчас, мне повезло, и я просто успел ещё застать то время, люди не боялись экспериментировать и иметь собственный взгляд на некоторые вещи. Сейчас скажи что-нибудь что отличается от «общепринятого» (типа как у всех) — сразу затроллят, заплюют, закидают помидорами. Поэтому свои либы публиковать на гитхабе, открывать забесплатно исходный код — не собираюсь, как говорил Иешуа — «не бросайте жемчуга вашего перед свиньями, чтобы они не попрали его ногами своими и, обратившись, не растерзали вас».