Качество оценки IT кодирования - как мы знаем то, что хорошо? [закрытый]

First, set ground rules (that all programmers sign up to) that say what's 'good' and what isn't. Automate tests for those that you can measure (e.g. functions less than a number of lines, McCabe complexity, idioms that your coders find confusing). Then accept that 'good coding' is something you know when you see rather than something you can actually pin down with a set of rules, and allow people to deviate from the standard provided they get agreement from someone with more experience. Similarly, such standards have to be living documents, adapted in the face of feedback.

Code reviews also work well, since not all such 'good style' rules can be automatically determined. Experienced programmers can say what they don't like about inexperienced programmers' code - and you have to get the original authors to change it so that they learn from their mistakes - and inexperienced programmers can say what they find hard to understand about other people's code - and, by being forced to read other people's code, they'll also learn new tricks. Again, this will give you feedback on your standard.

On some of your specific points, complexity and function size work well, as does code coverage during repeatable (unit) testing, but that last point comes with a caveat: unless you're working on something where high quality standards are a necessity (embedded code, as an example, or safety-critical code) 100% code coverage means you're testing the 10% of code paths that are worthwhile to test and the 90% that almost never get coded wrong in the first place. Worthwhile tests are the ones that find bugs and improve maintainability.

Great question. Should get some good responses.

1. Code cleanliness (indented well, file organization, folder structure)
2. Well commented (not just inline comments, but variables that say what they are, functions that say what they do, etc.)
3. Small understandable functions/methods (no crazy 300 line methods that do all sorts of things with nested if logic all over the place)
4. Follows SOLID principles
5. Is the amount of unit test code similar in size and quality as the code base of the project
6. Is the interface code separate from the business logic code which in turn should be separate from the infrastructure access code (email, database, web services, file system, etc.)
7. What does a performance analysis tool think of the code (NDepend, NDoc, NCover, etc.)

There is a lot more to this...but this gets your started.

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

Вы знаете разработчика, чью работу вы доверяете? Возможно, этот человек будет участвовать в процессе оценки.

how can I evaluate whether coding is written well

There are various ways/metrics to define 'well'or 'good', for example:

• Delivered on time
• Delivered quickly
• No bugs after delivery
• Easy to install
• Well documented
• Runs quickly
• Uses cheap hardware
• Uses cheap software
• Didn't cost much to write
• Easy to administer
• Easy to use
• Easy to alter (i.e. add new features)
• Easy to port to new hardware
• ...etc...

Of these, programmers tend to value "easy to alter": because, their job is to alter existing software.

У кода есть 2 основные аудитории:

• Люди, которые его используют
• Люди, которые его разрабатывают

Итак, вам потребовалось 2 простых теста:

• Запустите код. Сможете ли вы заставить его выполнять работу, которую он должен делать?
• Прочтите код. Можете ли вы понять общие намерения разработчика?

Если вы можете ответить утвердительно на оба эти вопроса, это отличный код.

Читая код, не беспокойтесь, что вы не программист. Если код хорошо написан / задокументирован, даже непрограммист должен уметь догадываться о многом из того, для чего он предназначен.

BTW: Отличный вопрос! Я бы хотел, чтобы больше непрограммистов заботилось о качестве кода.

Its a difficult one and could be where your non-functional requirements will help you

• specify your performance requirements: transactions per second, response time, expected DB records over time,
• require the delivery to include outcome from a performance analysis tool
• specify the machine the application will be running on, you should not have to upgrade your hardware to run the app

For eyeballing the code and working out whether or not its well written its tougher, the answers from @Andrew & @Chris cover it pretty much... you want code that looks good, is easy to maintain and is performant.

Резюме

Используйте Джоэл Тест .

Почему?

Спасибо за сложный вопрос. Я собирался написать длинный ответ о достоинствах прямой и косвенной оценки кода, понимании вашего организационного контекста, точки зрения, выяснении процесса и установке критериев для того, чтобы код был достаточно хорошим, а затем о разнице между идеальным и справедливым кодом достаточно хорошо, что может означать «очень впечатляюще». Я собирался сослаться на Кодекс Стива МакКоннелла завершен и даже предложить делегировать аудит кода кому-то беспристрастному, которому вы можете доверять, который достаточно сообразителен в бизнесе и программировании, чтобы понять контекст, перспективу, применить разумно оценивать критерии и аккуратно сообщать вам о результатах. Я собирался порекомендовать посмотреть на части пользовательского интерфейса, которые обычно недоступны для конечного пользователя, точно так же, как можно было бы оценивать качество очистки, проверяя наличие грязи в труднодоступных местах.

Ну, а затем меня осенило: какова конечная цель? В большинстве, но очень немногих сценариев крайнего ковбойского кодирования в результате аудита вы, вероятно, обнаружите, что код лучше, чем мусор, но определенно не чертовски хорош, может быть, чуть ниже отметки «достаточно хорошо». А что дальше? Вероятно, будет несколько вариантов:

1. Смена поставщика.
2. Настаивать на реорганизации кода.
3. Оставить все как есть и с этого момента потребовать лучшего кода.

К сожалению, ни один из вариантов не является идеальным или очень хорошим. Сделать инвестицию в замену поставщика - дело затратное и довольно рискованное: часть концептуальной целостности программного обеспечения будет потеряна, вашей компании придется, хотя и косвенно, принять на себя неизбежные затраты, связанные с тем, что новый поставщик возьмет на себя разработку и пройдет через кривую обучения (в точности противоположную тому, что большинство поставщиков собирается вам сказать попробуй залезть в дверь). И будет большой риск пропустить исходные сроки.

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

Это подводит меня к фактическому выводу, или, по сути, к двум:

1. Сконцентрируйтесь на выборе правильная компания-производитель программного обеспечения в первую очередь, поскольку возможности для дальнейшего развития будут несколько ограничены.
2. Используйте знания в области ИТ и управления, чтобы выбрать компанию, которая ориентирована на привлечение и удержание хороших разработчиков, которая создает рабочую среду и культуру, подходящие для производства качественного кода, вместо того, чтобы полагаться на постфактум-анализ.

Нет необходимости подробно останавливаться на важности выбора правильной компании в первую очередь, в отличие от итоговой оценки выполненного проекта; надеюсь, это уже сделано.

Ну, а как мы узнаем, что компания-разработчик программного обеспечения права? Здесь я полностью присоединяюсь к философии, проповедуемой Джоэлем Спольски : качество программного обеспечения напрямую зависит от качества вовлеченных людей, которое, как показывали несколько исследований , может варьироваться на порядок величины. . И благодаря работе свободных рынков разработчики в конечном итоге объединяются в компании в зависимости от того, насколько конкретная компания заботится о их привлечении и удержании.

Как правило, лучшие программисты работают с лучшими, хорошие с хорошими, средние со средними и ковбойские кодеры с другими ковбойскими кодерами. Однако есть нюанс. У большинства компаний есть по крайней мере один или два очень хороших разработчика, о которых они заботятся и изо всех сил стараются сохранить. Этих разработчиков всегда ставят на передний план: сражаться, переманивать клиента, доказывать потенциал и компетентность организации. Работая среди более чем обычных коллег, перегруженных между несколькими проектами и с которыми обращаются как с королевскими особами, к сожалению, эти звездные программисты очень часто теряют связь с реальностью и становятся примадоннами, которые не будут «пачкать» руки какой-либо реальной работой по программированию.

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

Решение состоит в том, чтобы найти компанию, в которой таланты разработчиков более последовательны, и каждый, по крайней мере, достаточно хорош, чтобы создавать код нужного качества. И когда дело доходит до выбора такой организации, вот где Джоэл Тест очень пригодится. Я считаю, что это особенно удобно для тех, кто не имеет опыта программирования, но хорошо разбирается в ИТ и управлении.

Чем больше очков наберет компания в тесте Джоэла, тем больше у нее шансов привлечь и удержать хороших разработчиков и, что наиболее важно, предоставить им условия для создания качественного кода. А поскольку большинство великих разработчиков на самом деле влюблены в программирование, все, что нужно, - это объединиться в команду, учитывая хорошую и благоприятную рабочую среду, заслуживающую доверия цель (или, что еще лучше, невероятную), и они начнут выбрасывать высококачественный код. Это так просто.

Что ж, единственное, что компания, набравшая полные двенадцать баллов на тесте Джоэла, вероятно, будет взимать больше, чем потогонная мастерская, получившая всего 3 или 5 (самооценка среднего отраслевого показателя). Тем не менее, преимущества синергии эффективных операций и специального безотказного программного обеспечения, которое реализует стратегические цели организации, несомненно, обеспечат исключительную окупаемость инвестиций и преодолеют любые препятствия, намного перевесив любые проектные затраты. Я имею в виду, что в конце концов работа компании, вероятно, будет стоить денег, каждой копейки.

Также надеюсь, что кто-то сочтет этот длинный ответ стоящим.

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

Также надеюсь, что кто-то сочтет этот длинный ответ стоящим.

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

Также надеюсь, что кто-то сочтет этот длинный ответ стоящим.

Также надеюсь, что кто-то сочтет этот длинный ответ стоящим.

Также надеюсь, что кто-то найдет этот длинный ответ стоящим.