Думаю, что в вашем случае проектирование — «зло», только потому, что вы не имели достаточного опыта/знаний, чтобы грамотно спроектировать систему до начала разработки.
Например, когда вы разрабатываете нечто, что будет повторно использоваться в других проектах (допустим фреймворк или библиотека для чего-то). Перед началом разработки необходимо решить, что вообще должен уметь фреймворк, как он это будет делать, как сделать так, чтобы ваша разработка была удобна в повторном использовании и как её можно будет гибко расширить при необходимости. Подозреваю, что если «с ходу» приступить к написанию кода, большинство проблем, которые были бы очевидны после нескольких часов проектирования на бумаге будут очевидны только через несколько дней/недель, и чем позже эти проблемы будут выяснены, тем дороже они могут обойтись, так как некоторые не заложенные возможности могут создать необходимость переработки почти всей архитектуры фреймоврка, а если вы уже потратили неделю на его создание у вас может возникнуть желание оставить всё как есть или придумать хак, так как выбрасывать уже написанный код жалко.
По поводу документирования — почитайте Макконнелла. Думаю, что если вы пишите, действительно очевидный и понятный код, наличие хотя бы небольшого количества комментарий сделает ваши исходники только лучше.
Плюс, иногда (вообще не иногда, а довольно часто), разработчик за полгода может участвовать в разработке очень большого количества проектов, и, когда придёт время перерабатывать исходный продукт, разработчик сам может забыть некоторые (или большинство?) аспектов работы программы. Так что комментарии нужны не только сторонним разработчикам, которые дорабатывают продукт, но и тому, кто писал исходный код.
Ещё вы пишите о том, что через полгода, продукт будет дорабатывать тот же человек, который его писал изначально, но вы не рассматриваете ситуацию, когда заказчик решит сменить разработчика и у новой компании будет куча поводов вспомнить добрым словцом первого разработчика и «поблагодарить» его за отсутствие какой-либо документации.
«…к тому же отсутствие музыки само по себе не является раздражителем.»
Не соглашусь с вами =) Мне кажется, что музыка может являться ещё каким раздражителем.
«Мне кажется, нельзя сравнивать «Х любит музыку, но сидит в тишине» и «Х не любит музыку, но сидит с музыкой» нельзя.»
На мой взгляд, в этом эксперименте сравнивались те, кто работает в тишине и те, кто работает с включенной музыкой. Т.е. и в той и в другой комнате были люди, которые попадали в «зону дискомфорта». А результаты брались, для каждой комнаты отдельно, а не по группам, которые попадали в «зоны комфорта/дискомфорта».
Делили, наверно, для того, чтобы посмотреть, как тишина и наличие музыки влияют на разные типы людей. Т.е. чтобы доказать, что музыка действительно мешает или действительно помогает, а не «каждому своё».
«Затем половину участников каждой из подгрупп поместили в тихую аудиторию, а вторую половину — в аудиторию, оборудованную наушниками с возможностью выбирать музыку…»
Если я правильно понял, то в каждой аудитории сидели и те, кому нравится слушать музыку и те, кому музыку слушать не нравится.
Попробуйте скомпилировать и запустить исходники, которые представлены в конце урока, если они будут нормально работать, возможно, то проблема в вашем проекте.
У меня нет причин говорить, что в документации по PBE есть что-то непонятное. Краткие и лаконичные уроки, которые описывают работу с фреймворком с нуля.
На данный момент мною переведены только 5 официальных уроков, но в ближайшее время я хотел бы заняться переводом официальных статей, которые предполагают более глубокое изучение PBE.
Всё, что вы сказали выше про экономию времени, может так же относиться к фреймворкам, библиотекам и т.п. Никто не говорит, что написание своего — это зло. Это не зло, это хороший опыт, но вы можете никогда не узнать, какие тенденции сейчас есть в разработках, что используется и что нового придумано, если не будете изучать чужие проекты, библиотеки, фреймворки, движки и т.д. и т.п.
В общем использование чужих фреймворков/движков/библиотек, на мой взгляд, не является злом. Если если есть инструмент, который упростит вам разработку, то почему бы его не использовать?
Если есть готовый молоток, зачем брать рубанок и полено, и строгать ручку для молотка, а потом искать железную руду, выплавлять из неё металл и заливать его в нужную форму?
Разве что в ваших проектах < 10 классов каждый из которых состоит из < 10 методов.
Плюс, иногда (вообще не иногда, а довольно часто), разработчик за полгода может участвовать в разработке очень большого количества проектов, и, когда придёт время перерабатывать исходный продукт, разработчик сам может забыть некоторые (или большинство?) аспектов работы программы. Так что комментарии нужны не только сторонним разработчикам, которые дорабатывают продукт, но и тому, кто писал исходный код.
Ещё вы пишите о том, что через полгода, продукт будет дорабатывать тот же человек, который его писал изначально, но вы не рассматриваете ситуацию, когда заказчик решит сменить разработчика и у новой компании будет куча поводов вспомнить добрым словцом первого разработчика и «поблагодарить» его за отсутствие какой-либо документации.
Прошу, прощения, не правильно вначале понял ваш комментарий.
Не соглашусь с вами =) Мне кажется, что музыка может являться ещё каким раздражителем.
«Мне кажется, нельзя сравнивать «Х любит музыку, но сидит в тишине» и «Х не любит музыку, но сидит с музыкой» нельзя.»
На мой взгляд, в этом эксперименте сравнивались те, кто работает в тишине и те, кто работает с включенной музыкой. Т.е. и в той и в другой комнате были люди, которые попадали в «зону дискомфорта». А результаты брались, для каждой комнаты отдельно, а не по группам, которые попадали в «зоны комфорта/дискомфорта».
Если я правильно понял, то в каждой аудитории сидели и те, кому нравится слушать музыку и те, кому музыку слушать не нравится.
Я для себя из них всех выбрал только 2-3 движка, остальные, как-то, слабенько совсем выглядят.
У меня нет причин говорить, что в документации по PBE есть что-то непонятное. Краткие и лаконичные уроки, которые описывают работу с фреймворком с нуля.
На данный момент мною переведены только 5 официальных уроков, но в ближайшее время я хотел бы заняться переводом официальных статей, которые предполагают более глубокое изучение PBE.
В общем использование чужих фреймворков/движков/библиотек, на мой взгляд, не является злом. Если если есть инструмент, который упростит вам разработку, то почему бы его не использовать?
Если есть готовый молоток, зачем брать рубанок и полено, и строгать ручку для молотка, а потом искать железную руду, выплавлять из неё металл и заливать его в нужную форму?