Джордж Сантаяне: Фанатизм состоит в удвоении Вашего усилия, когда Вы забыли свою цель
Первый пост в этом году будет обещанием самому себе - не писать ни строки кода пока не будет до конца ясно зачем это надо. Под этим я имею ввиду, что каждая задача должна разбиваться на подзадачи (строки кода) только когда понятна сама задача (зачем это надо). Делать наоборот - на ходу придумывать подзадачи и подгонять их под конкретную задачу - пустая трата времени и источник ошибок.
вторник, 6 января 2009 г.
Меньше кодить, больше думать
Подписаться на:
Комментарии к сообщению (Atom)
3 комментария:
Тоже прошёл такой этап, очень понимаю. В итоге начал читать теорию и выносил любых менеджеров тем, что на проектирование должно уходить не менее 50% времени, как и на разработку. Работать и реально прототипировать интерфейсы им влом, да и не умеют, не повезло в данном случае. Хотя были позитивные примеры - один бывший РБК управленец. А так - отъебитесь, я сам. Для своих проектов так и делаю, где-то с год как достало иначе.
Интересно, но для меня вопрос ЗАЧЕМ что-нибудь надо, обычно не является проблемой. Это зачем может быть самым разным, ну например:
1) Так может быть написано в сторонней спецификации. Ну вот сказано там рисовать объект снизу-вверх, но без объяснений зачем.
А почему не сверху-вниз? Да, узнать зачем так было бы хорошо, но толку? (И да, можно сделать по-своему, но потом вдруг окажется что там-таки правильно написано и учли все грабли)
2) Так может захотеть клиент или заказчик. Зачем? Ну вот надо ему так, и нет времени или сложно объяснить.
Поэтому зачем - это часто наименьшее зло. Не знаю как вам, но для меня большой головной болью является вопрос ЧТО конкретно надо сделать или КАК оно должно быть? И когда на эти вопросы нет ответа, но тут дествительно беда - делаются свои предпосылки и допущения(часто неверные), отсюда и код некачественный, так как не уверен в нём. Ну и вообще, делать и понимать что многое надо будет переделывать не способствует хорошей работе.
Можно ли задачу разбить на подзадачи, не написав при этом ни строки кода? (т.е. разбить задачу на подзадачи мысленно или на бумаге). Если под "разбиением" подразумевается принятие решения о том, из каких объектов будет состоять программа и какие задачи объекты будут выполнять (кажись, по умному это называется "декомпозиция"), то пожалуй, это должно делаться перед кодированием. А вот если следует определить, как объекты будут взаимодействовать друг с другом (т.е. определить, какой у них должен быть интерфейс) - имхо, тут лучше кодировать, поскольку мысленные эсперименты могут оказаться далеки от грубой реальности :))))
Отправить комментарий