Читателям этой статьи: выкиньте всё, что вы прочитали из головы. Автору статьи: выложите статью на тот же хабр, или более айтишный ресурс, чтобы услышать другое мнение, почему вы не правы (или мб правы, и я ошибаюсь)
Ниже будет моё мнение, почему так (как написано в статье) не стоит делать.
Если бы такое "пособие" было по фотографированию, фотография вышла бы как у автора поста на аве. Не парьтесь про свет, просто фоткайте - всё равно в итоге будет фотография, на которой что-то видно.
Чистота и стандартизация кода нужны по всего одной причине. Это не красота и не выпендривание перед коллегами - это поддержка. Код надо писать так, как будто после вас его будет поддерживать психопат с ружьём, который знает где вы живёте (с).
Зачем тратить время на документацию и описывания чего-то, если можно писать функции просто и понятно. Хороший код абсолютно не требует документирования - он очевиден и легко читается. Более того, ваша функция "кашей" на страницу будет хороша до момента первого бага, который должен будет поправить другой разработчик. Удачи с пунктом "10. Дебаг".
Нет не единой ситуации, в которой я бы советовал кому-то говнокодить. Хотя бы по причине, по которой спортсмены должны всегда дышать через нос - это должно быть на автомате. Скажешь ему дышать через рот, и он никогда ничего не выиграет. Но есть ситуации, в которых говнокод допустим. Например, вам нужно подготовить пруф концепта за минимальные сроки, который никогда не будет переиспользоваться и займёт меньше нескольких файлов. Тут можно не тратить ресурсы. В противном случае - вы будете страдать. Не обязательно автор говнокода (хотя зачастую и он, попробуй разобраться в том, что ты написал месяц назад), но кто-то обязательно.
Это правильное замечание! Но есть нюансы: 1) на хабре в основном наёмные сотрудники, IT-профессионалы, а у них совсем другой взгляд, чем у владельца бизнеса, им платят за часы (условно). Они как раз и критикуют то что критикуем мы, бизнес позиция очень проста - платим за то, что работает, и за скорость прототипирования/воплощения в прод. 2) Представьте что этому фотографу поставили задачу сфотографировать количество крыш на заднем фоне за ограниченное количество времени. он со своей задачей справился? Спасибо за коммент!!
Читателям этой статьи: выкиньте всё, что вы прочитали из головы.
Автору статьи: выложите статью на тот же хабр, или более айтишный ресурс, чтобы услышать другое мнение, почему вы не правы (или мб правы, и я ошибаюсь)
Ниже будет моё мнение, почему так (как написано в статье) не стоит делать.
Если бы такое "пособие" было по фотографированию, фотография вышла бы как у автора поста на аве. Не парьтесь про свет, просто фоткайте - всё равно в итоге будет фотография, на которой что-то видно.
Чистота и стандартизация кода нужны по всего одной причине. Это не красота и не выпендривание перед коллегами - это поддержка. Код надо писать так, как будто после вас его будет поддерживать психопат с ружьём, который знает где вы живёте (с).
Зачем тратить время на документацию и описывания чего-то, если можно писать функции просто и понятно. Хороший код абсолютно не требует документирования - он очевиден и легко читается. Более того, ваша функция "кашей" на страницу будет хороша до момента первого бага, который должен будет поправить другой разработчик. Удачи с пунктом "10. Дебаг".
Нет не единой ситуации, в которой я бы советовал кому-то говнокодить. Хотя бы по причине, по которой спортсмены должны всегда дышать через нос - это должно быть на автомате. Скажешь ему дышать через рот, и он никогда ничего не выиграет. Но есть ситуации, в которых говнокод допустим. Например, вам нужно подготовить пруф концепта за минимальные сроки, который никогда не будет переиспользоваться и займёт меньше нескольких файлов. Тут можно не тратить ресурсы. В противном случае - вы будете страдать. Не обязательно автор говнокода (хотя зачастую и он, попробуй разобраться в том, что ты написал месяц назад), но кто-то обязательно.
Это правильное замечание! Но есть нюансы: 1) на хабре в основном наёмные сотрудники, IT-профессионалы, а у них совсем другой взгляд, чем у владельца бизнеса, им платят за часы (условно). Они как раз и критикуют то что критикуем мы, бизнес позиция очень проста - платим за то, что работает, и за скорость прототипирования/воплощения в прод. 2) Представьте что этому фотографу поставили задачу сфотографировать количество крыш на заднем фоне за ограниченное количество времени. он со своей задачей справился?
Спасибо за коммент!!