Pull to refresh

Comments 13

Дык нет же, это в "пяти звездах".
Правда автор, как обычно, не рассказал о всех промежуточных шагах между кружочками и совой: как имея быстрый оптимизированный компактный код получить из него такой же, но еще и "легко читаемый".

На мой взгляд, так себе классификация. Во-первых, перечисленные уровни звёзд не являются вложенными множествами. Куда отнести код, который является компактным, но при этом весьма неэффективным по скорости работы и использованию памяти?
Во-вторых, отнесение неработоспособного кода к 0-й категории мне кажется довольно странным. Хорошо написанный (с точки зрения других критериев — скорости, оптимальности, читабельности и т.д.) код, содержащий ошибки, может быть гораздо легче и дешевле довести до работоспособного состояния, чем код, в принципе правильно работающий, но использующий неэффективный алгоритм.
Наконец, не упомянут такой важный критерий, как наличие ошибок, не проявляющихся при обычной работе кода, но потенциально способных вызвать проблемы при определённых условиях. Код, не содержащий защиты от переполнения буфера, может прекрасно работать годами, если буфер достаточно велик, пока однажды сервер не грохнется по непонятной причине, или же эта дыра не будет использована для взлома.
UFO just landed and posted this here
Это вы еще про деньги забыли упомянуть (т.е. про стоимость разработки). И про скорость той же разработки.

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

Понятие совершенного кода, imho, в первую очередь подразумевает код, который лёгок в сопровождении, расширении и модификации. Всё остальное: читаемость, комментарии, алгоритмы, оптимизации — вытекает из этого. Не говоря уж о том, что код должен работать и выполнять свою задачу.

Очень ироничный скриншот — по автору это получается идеальный код. Быстрый, оптимизированный, компактный, легко читать.


Ни слова про расширяемость. Поступила задача рисовать не 5 конечную звезду, а 7? Ну всё, приехали.

Поступила задача рисовать не 5 конечную звезду, а 7?

А нет ли здесь антисемитизма? (Это шутка, если что.)

Разные классификации могут быть. Например:


  • ненужный код
  • не критичный код
  • код который участвует в получении прибыли
  • и код, где если что-то пойдёт не так всем трындец

Главное уточнить хороший код для кого/чего. Для машины это явно — тот который требует меньше ресурсов на выполнение. А для человека — тот который ему будет легче понять.
По моему мнению трудность в понимании кода другими сегодня это основная проблема в промышленной разработке.
Пришел к выводу что легкий для восприятия код это простой код т.е. с минимальным кол-во элементов и связей между ними. Другими словами проблема комбинаторная.
Поэтому при рефакторинге, считаю, нужно уделять внимание не добавлению абстракций а уменьшению кол-ва элементов и связей между ними — явных и неявных.

Поэтому при рефакторинге, считаю, нужно уделять внимание не добавлению абстракций а уменьшению кол-ва элементов и связей между ними — явных и неявных.

Т.е. идеал кода — public static void main() и далее весь проект внутри?

Если вы напишите весь проект в одной функции то сложность этой функции будет равна всему функционалу проекта т.е. для программиста это будет овер сложно держать такое кол-во элементов и комбинаций в голове.
Если разбить все на некоторое кол-во функций с четко понятным входом и выходом то сложность будет сильно ниже т.к. данные фукнции будет скрывать в себе сложность. Но вот если вы обернете все эти функции в паттерны или другие теоретические конструкции то сложность повысится.

У автора две звезды получит код только с линейной сложностью. То есть даже сортировка отпадает.

Sign up to leave a comment.

Articles