Как писать меньше кода и получать больше толку

[neurocore]

Страшные вещи пишет автор: «если вы преследуете цель писать меньше кода, нужно стремиться к максимально простой реализации, из разряда «лишь бы работало»». По моему скромному мнению, метод написания «тяп-ляп» не выход, я бы скорее выделил идею переносить большую часть проверок из кода в тесты.

[Deosis]

Скорее, автор высказывал следующую идею:

1. Написать код для наилучшего случая (все данные валидны, все сервисы отвечают правильно)
2. Для каждого такого допущения оценить вероятность, что что-то пойдет не так.
3. Сравнить стоимость исправления сейчас и ожидаемую величину ущерба из-за ошибки.
4. Исправить только то, что нужно.
5. Ариан-5

[nekt]

Это цитата из «экстремального программирования» К. Бека. из раздела юнит-тестирования. Основная идея — как раз в том, как определить минимально необходимый уровень кода, чтобы выполнить текущую задачу, не воздвигая замков.

[abbath0767]

Все бы ничего, однако, согласитесь, это не всегда работает. Я думаю нет смысла придираться к частностям, так как в других комментариях уже это сделали, но все же лично меня больше всего задел пункт, с котором я никак не могу согласиться — Не пишите неуязвимый код. Где та грань между НЕ неуязвимым кодом и говнокодом или же на скорую руку собранным дерьмом непонятного качества. Требуемого качества пересечения этой границы помогают достичь тесты, ревью коллег и некоторые другие инструменты и способы улучшения кода, но вот что делать тем кто работает один или совсем небольшими командами?

P.S. Как всегда не стоит забывать что все советы это конечно хорошо, но личный удачный/не_удачный опыт ничем не заменишь

[sergeperovsky]

Советы для кого? Для сферического программиста в вакууме?
Есть задачи, которые так решать нельзя. Пример с аппаратом для лучевой терапии тому подтверждение.
Если хотите писать меньше кода, нужно заложить в разработку больше математики.
Большинство интерактивных программ хорошо описывается конечным автоматом. Честно построив модель и получаем хорошее т.з. на минимально-необходимое программирование.
Да, не все «побочные» ветви необходимо сразу реализовать в виде подробного анализа нештатной ситуации. Достаточно стандартного сообщения.

[Ilya81]

Соглашусь только с последним пунктом. По мне всякая необходимость оставлять неиспользуемые функции полностью исчезла с появлением Git.

А вот на счёт остального скажу — такие рекомендации и без того часто понимают превратно. Вообще, много раз убеждался, что любую разумную идея можно довести до абсурда. И особенно могу сказать про первые два пункта, во что это скорее всего превратится в реальности. Умельцев внедрят функциональность самым примитивным способом хоть отбавляй. После этого соответствующие задачи переходят в статус выполнено и включать в очередной sprint время на refactoring редко кто топорится. Вместо этого реализуется дальнейшая функциональность со всё новыми костылями. В итоге очередную новую функцию становится нереально в сколь-нибудь сопоставимые сроки реализовать без новых костылей, как ни хотелось б. Ну и далее характерный реальзтат, когда исправление одной ошибки создат другую ошибку.