Про документирование API и библиотечного кода для публичного использования — это отдельная песня. И часто документируют его потому, что в исходники по идее может даже не быть возможности заглянуть и разобраться. Плюс много людей должны быстро понимать для чего создан какой-то класс, функция или метод. К вашему внутреннему коду далеко не всегда предъявляются такие же требования, поэтому детальное документирование излишне для большей части проектов. Особенно для внутренних реализаций, которые склонны к частым изменениям.
В упор не понимаю зачем сама ветка ELSE существует. Самый нормальный способ — добавить юнит тест наподобие ifEquationIsZeroDoNothingBecause… Но если так и прет дописать комментарий, то можно сделать его перед первым IF. Сама ветка ELSE вообще ни к селу ни к городу. По поводу вашего return без параметров — вы просто набрались опыта и поняли, что это бесполезная практика. А другие разработчики, которые с вами работали, одобряли эту практику?
Жесть какая-то. Тогда надо к каждому IF писать ELSE с комментарием «не, я не забыл про этот случай — просто ничего не надо делать». Ну чтобы уже наверняка! А то мало ли кто заподозрит…
Ваше утверждение ничуть не потиворечит созержанию поста. Автор предлагает решение взамен комментариев, которое работает даже лучше них. Понятное дело, что если никто не трудился над понятностью и чистотой кода, то встретить хотя бы комментарий — это просто счастье. Вопрос в том, как писать код сейчас, чтобы при его поддержке не приходилось так же «радоваться».
Может быть проще и правильнее предвосхитить этот вопрос тестом? Если вы знаете о какой-то ситуации, из-за которой код написат так как написан, то воспроизведите ее в тестах. Это не даст вашим «потомкам» на скорую руку поправить «якобы баг» в вашем творении. А если вы такую ситуацию не можете воспроизвести, то может быть и не стоит так код писать. Исключительно редко на моей практике попадались такие ситуации, в основном из-за дефектов во внешнем коде. Вот тогда комментарий с линкой на проблему очень даже полезен.
Уху! Наконец-то я нашел человека, который пишет идеальный код и сразу проектирует систему правильно! Теперь понятно, почему вам больше по душе работать в одиночку… [trollface]
Поэтому вам и предлагается работать по TDD: пишете тест -> убеждаетесь, что он не работает -> пишите код -> убеждаетесь, что тест заработал, не меняя теста. Еще ни разу в таком цикле не встречал, чтобы в тест закрадывалась проблема и после написания кода она исчезала. Обычно тест с ошибкой продолжает не работать и после написания кода, что демонстрирует ошибку в тесте. Ошибка исправляется и потом цикл повторяется. Таким образом код и тесты помогают валидировать друг друга.
А вы задумайтесь когда-нибудь над фактом, что если ваш тест стал сложным настолько, что в нем можно допустить ошибку, то ваш код плохо спроектирован. Это отличный показатель для качества кода. Иногда готовишь входные данные для вызова метода и понимаешь как же это неудобно тому, кто этот метод вызовет в реальной жизни… Но проще всего не обращать внимания на гниющую ногу…
Нет противоречия — про алгоритмы, шаблоны проектирования и т.д. надо читать в книгах, блогах, на конференциях. А если взял библиотеку или фреймворк, то без надобности изучать его внутренние алгоритмы работы досконально — это потеря времени.
Это не я такого мнения, а большая часть людей. Я сам уже много лет занимаюсь архитектурой, но в то же время и реализую ее с командой, а не только «отдаю приказы». Речь шла о архитекторах-теоретиках, которые спускают вниз диаграммы и теоретические решения.
По поводу точечного решения с оптимизацией вы не туда. Речь в статье идет о ежедневной работе, а не о «выстреле», которых у вас может быть за карьеру пару штук всего. А может и не быть.
Нет конечно, куда мне до уровня понимания того, что пишу…
Автор, это гениально! Один классный разработчик общается с другими классными разработчиками (ну, а с кем же еще?), а в свободное от взаимоприятственного общения время все эти классные разработчики мечутся в информационном пространстве в поиске готовых решений!
А вы в компании общаетесь о разработке с теми, кто в ней совсем не смыслит? Тогда вы так и останетесь на том же уровне. Или у вас нет хороших разработчиков, с которыми можно обсудить решение и пообщаться на тему библиотек, фреймворков, инструментов? Тогда сочувствую…
Это называется — провести патентный поиск. Но, в отличие от ПП, коллеги очень постараются вникнуть в идею проекта со всеми вытекающими в условиях рынка и конкуренции последствиями.
Вы что сидите на каких-то наркотиках, искажающих сознание? Речь шла о том, чтобы перед реализацией своей задумки поделиться ей с коллегами и спросить совета, провести дизайн-сессию. Благодаря этому часто решение становится гораздо лучше, а бывает что и меняется в корне. ПРИ ЧЕМ ТУТ ПАТЕНТНЫЙ ПОИСК И РЫНОК С КОНКУРЕНЦИЕЙ???
Кода должно быть столько, сколько требуется.
Гениально! Это как совет «надо писать только хороший код, а плохой вовсе не писать»…
Вот поэтому, когда кнопишь код сам, лично, еще попутно и соображаешь.
Если при этом еще использовать технику работы головой — то не очень…
Опять КЭП в вас заговорил. Да ну, неужели еще и соображаешь??? Не может быть! Это в корне меняет дело!
Откуда у описанного Вами разработчика будет интеллект, если он стремится использовать уже готовое — то есть не нарабатывает собственного опыта, рефлексов, интуиции и т.п.?
Опыт, интуицию, рефлексы и прочие навыки он нарабатывает на полезном коде, а не на велосипедах, которые не помогают продвигаться к решению задачи. Я видел столько раз самописные ORM-фреймворки, интерграционные решения, кеши, разнообразные утилиты, которые мало того что сожрали кучу проектного времени и не принесли пользы, но и сидели потом как шило в ж… у следующих поколений разработчиков на этом проекте. Зато их авторы наработали себе опыт, рефлексы и интуицию… Чего и вам желаю!
Отнюдь не так. Как раз читать про алгоритмы, ООП, шаблоны проектирования и т.д. надо побольше. Цель остается прежней — не городить велосипеды там, где это ненужно. Как все устроено внутри вы ознакомитесь, когда будете отлавливать проблемы. А до этого тратить несколько дней рабочего времени на «дай-ка я разберусь как оно там устроено внутри» пока все прекрасно работает просто нет смысла.
Остальные выводы про прототиписта не понимаю с чего вы сделали.
По поводу написания классного кода я с вами и не спорю. А вот на тему «передать решение классному кодеру, который реализует ее в IDE» — так это вы сейчас про «бумажных архитекторов» рассказываете. Которые могут строить воздушные замки и бла-бла-бла по любому поводу, но идеи свои на практике не воплощают, а просто отдают их «челяди», которая потом с ними мучается.
По поводу первого пункта вы видимо не совсем осознали. Рекомендуется не писать велосипеды без надобности. Библиотеки как раз появились закономерно, потому что отсутствовали публичные решения в этой области. Но писать их заново на каждом проекте смысла нет вообще. Рост индустрии за счет написания библиотек??? Вы о чем? Рост индустрии происходит от роста количества реализованных решений, сервисов и услуг. И чем быстрее они будут реализованы, тем быстрее будет расти рынок. Поэтому те, кто умеет интегрировать и решать поставленную проблему — это правильные разработчики.
Лучше писать код понятным и простым, чтобы не требовались комментарии. А если возникали вопросы по поводу того как он работает, то можно было обратиться к модульным тестам и быстро это понять.
Поэтому вам и предлагается работать по TDD: пишете тест -> убеждаетесь, что он не работает -> пишите код -> убеждаетесь, что тест заработал, не меняя теста. Еще ни разу в таком цикле не встречал, чтобы в тест закрадывалась проблема и после написания кода она исчезала. Обычно тест с ошибкой продолжает не работать и после написания кода, что демонстрирует ошибку в тесте. Ошибка исправляется и потом цикл повторяется. Таким образом код и тесты помогают валидировать друг друга.
По поводу точечного решения с оптимизацией вы не туда. Речь в статье идет о ежедневной работе, а не о «выстреле», которых у вас может быть за карьеру пару штук всего. А может и не быть.
Нет конечно, куда мне до уровня понимания того, что пишу…
А вы в компании общаетесь о разработке с теми, кто в ней совсем не смыслит? Тогда вы так и останетесь на том же уровне. Или у вас нет хороших разработчиков, с которыми можно обсудить решение и пообщаться на тему библиотек, фреймворков, инструментов? Тогда сочувствую…
Вы что сидите на каких-то наркотиках, искажающих сознание? Речь шла о том, чтобы перед реализацией своей задумки поделиться ей с коллегами и спросить совета, провести дизайн-сессию. Благодаря этому часто решение становится гораздо лучше, а бывает что и меняется в корне. ПРИ ЧЕМ ТУТ ПАТЕНТНЫЙ ПОИСК И РЫНОК С КОНКУРЕНЦИЕЙ???
Гениально! Это как совет «надо писать только хороший код, а плохой вовсе не писать»…
Опять КЭП в вас заговорил. Да ну, неужели еще и соображаешь??? Не может быть! Это в корне меняет дело!
Опыт, интуицию, рефлексы и прочие навыки он нарабатывает на полезном коде, а не на велосипедах, которые не помогают продвигаться к решению задачи. Я видел столько раз самописные ORM-фреймворки, интерграционные решения, кеши, разнообразные утилиты, которые мало того что сожрали кучу проектного времени и не принесли пользы, но и сидели потом как шило в ж… у следующих поколений разработчиков на этом проекте. Зато их авторы наработали себе опыт, рефлексы и интуицию… Чего и вам желаю!
Остальные выводы про прототиписта не понимаю с чего вы сделали.
По поводу первого пункта вы видимо не совсем осознали. Рекомендуется не писать велосипеды без надобности. Библиотеки как раз появились закономерно, потому что отсутствовали публичные решения в этой области. Но писать их заново на каждом проекте смысла нет вообще. Рост индустрии за счет написания библиотек??? Вы о чем? Рост индустрии происходит от роста количества реализованных решений, сервисов и услуг. И чем быстрее они будут реализованы, тем быстрее будет расти рынок. Поэтому те, кто умеет интегрировать и решать поставленную проблему — это правильные разработчики.