Схороненный псто из умершего базза.
Наткнулся на интересную статью у avva, про избыточность кода с целью повышения читабельности. А потом и +Евгений Доронин запостил про законы Мерфи для разработки. Пару лет назад я тоже задавался подобным вопросом. До сих пор не нашел однозначного ответа, хотя и //do nothing с тех пор эволюционировал в log.error("Inconsistent state {}",...) или throw new IllegalStateException, чтобы сильно умный статический анализатор заткнулся и не предлагал убрать пустые условия и максимально быстро упасть если забыли, после добавления enum, также добавить обработку этого значения.
Тернарные операторы по возможности избегаю, а уж если там сложные выражения, с подусловиям, то гораздо читабельней становится замена их на обычный if-else.
Продолжаю читать "Идеальные команды", и там Гради Буч высказал интересную мысль про неявные решения.
И теперь, поскольку мир не стоит на месте, встает интересный вопрос – та архитектура не была подробно отражена в документации, зачастую никакой документации вообще не было, и хотя код верен, он
не может быть истиной в последней инстанции, потому что не отражает ни логического обоснования, ни аспектов, по которым принималось компромиссное решение, ни любых других вещей, которые невозможно вывести из отдельных строк кода; есть схемы, выходящие за пределы самих этих строк. Такие вещи обычно сохраняются в «родовой памяти». И в любой организации есть патриархи, которые работают там уже давно и лично помнят эти обоснования и возникавшие междисциплинарные вопросы. Сложность здесь в том, что организация продолжает расти, люди перемещаются, и этот адресат может, фактически, уже на ходиться в другом месте.
То есть помимо проблемы временного и географического распределения есть проблема утечки интеллектуальной собственности, потому что хранить ее в «родовой памяти» – страшно дорого, точнее, память эта ничего не стоит, но извлечь из нее информацию может оказаться очень затратным, и чем меньше этой памяти, тем она дороже.
Такие вещи нужно выносить из головы и в код, давая обоснование принятым решениям и описывая допущения в которых эти решения принимались. Такие послания на порядок повышают читабельность кода.
Порой решение принять нельзя потому, что не хватает информации, либо времени на детальный анализ. Такие места описываются через TODO или FIXME с описанием проблемы и текущей ситуации:
// TODO Нужно ли это внести в контейнер?
// TODO подумать как прикрутить локализацию
// FIXME не уверен, что первоначальное заполнение списка должно выполняться по событию
// FIXME без этой строчки список почему-то не инициализируется
// FIXME when resolved https://javafx-jira.kenai.com/browse/RT-19089
// FIXME пока нет нормального чего-то, делаем так-то
Когда случается проблема, то такие места выделенные ядовито зеленым цветом сразу привлекают внимание.
 |
| PEP-20 |
Тернарные операторы по возможности избегаю, а уж если там сложные выражения, с подусловиям, то гораздо читабельней становится замена их на обычный if-else.
Родовая память
Продолжаю читать "Идеальные команды", и там Гради Буч высказал интересную мысль про неявные решения.И теперь, поскольку мир не стоит на месте, встает интересный вопрос – та архитектура не была подробно отражена в документации, зачастую никакой документации вообще не было, и хотя код верен, он
не может быть истиной в последней инстанции, потому что не отражает ни логического обоснования, ни аспектов, по которым принималось компромиссное решение, ни любых других вещей, которые невозможно вывести из отдельных строк кода; есть схемы, выходящие за пределы самих этих строк. Такие вещи обычно сохраняются в «родовой памяти». И в любой организации есть патриархи, которые работают там уже давно и лично помнят эти обоснования и возникавшие междисциплинарные вопросы. Сложность здесь в том, что организация продолжает расти, люди перемещаются, и этот адресат может, фактически, уже на ходиться в другом месте.
То есть помимо проблемы временного и географического распределения есть проблема утечки интеллектуальной собственности, потому что хранить ее в «родовой памяти» – страшно дорого, точнее, память эта ничего не стоит, но извлечь из нее информацию может оказаться очень затратным, и чем меньше этой памяти, тем она дороже.
Такие вещи нужно выносить из головы и в код, давая обоснование принятым решениям и описывая допущения в которых эти решения принимались. Такие послания на порядок повышают читабельность кода.
Порой решение принять нельзя потому, что не хватает информации, либо времени на детальный анализ. Такие места описываются через TODO или FIXME с описанием проблемы и текущей ситуации:
// TODO Нужно ли это внести в контейнер?
// TODO подумать как прикрутить локализацию
// FIXME не уверен, что первоначальное заполнение списка должно выполняться по событию
// FIXME без этой строчки список почему-то не инициализируется
// FIXME when resolved https://javafx-jira.kenai.com/browse/RT-19089
// FIXME пока нет нормального чего-то, делаем так-то
Когда случается проблема, то такие места выделенные ядовито зеленым цветом сразу привлекают внимание.
